Things I have learnt as the software engineering lead of a multinational

This really is an exceptionally good article, written by a pragmatic and insightful student of working life.

I have often experienced the following but could never have described it as elegantly:

> Incompetence is fiercely gregarious while knowledge is often fractious; the reason for this is that raw ideas transfer more easily through untrained minds than refined ideas transfer through trained minds. There’s a reason why large organisations focus so much on simple messages, pity that difficult problems often have simple solutions that don’t work.

That's about where I stopped reading.

"18. Don’t shy away from leading without doing, it is unavoidable, so just do it. Then do some work to stay pertinent.

19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it."

the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley

You either need more people or less work. And having too much work may be because the organization has lost focus on what really matters, and is trying to do everything. You cannot hire enough people to solve that problem, because as you add people, management says "great, now we can do even more..."

I think what he was going for was that you shouldn't solve the overworked problem with hiring. It indicates you need more manpower, yes, but it's also indicative of planning and resource allocation problems that need to be solved first. Adding more people before you solve those problems will probably make things worse. Things need to be properly divided and conquered, some things may need to be put on the back burner. It often indicates that you haven't split up the workload into manageable pieces, and are instead trying to get it all done at one time.

Someone might now jump and say 'sometimes crunch time is necessary!', and I would reply that if you're in crunch time you've just demonstrated the exact issue I'm describing.

I think he's essentially restating 'the mythical man month' for a modern environment.

>> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.

> I disagree - if you have overworked people, that is usually a red flag.

Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires. I think the author hits the nail on the head here -- first and foremost hire for future opportunities.

Almost every military metaphor in this piece fell flat for me, but this one might have been the worst of the bunch. Not only is it a forced metaphor that barely fits the point being made, it's not even a particularly good point.

Getting lots of people together to work on a large problem is an engineering problem in itself. It has its own language and constructs. Doing it wrong means millions or billions are wasted, and enterprises lose ground on the world stage.

Some of these ideals don’t translate well to smaller scale. A 5 person team doesn’t have to work out much except the work. How do you get 1000 people to agree on a plan, an IDE, a language, and to row in the same direction? Not magic. Study and practice.

Sadly, you are correct. You need some experience. "Experience is the great teacher, and some will learn from no other."

In my career, I've seen shocking, astounding, career, organization, and company threatening examples of nearly everything he mentions, and to me his reactions are terrific and make a lot of sense.

But, likely as you mentioned, need lots of real world examples from which he has extracted general, "abstract" lessons.

He has terrific stuff. He is an excellent observer and, then, analyst of what the heck he saw.

I put the text in my collection of management essays and regard it as by a wide margin the best management advice I've found for my startup: Currently I'm a sole, solo founder, so far have done it all, including all the important work and a lot of grunt work, but if my startup is successful then I'll have to hire and manage, all of it. Sure, eventually I'll get a COO and delegate a lot to them, but, still I'll have to know what's going on. And there will have to be more software development; I'll have to manage that either directly or through, say, a CTO or CIO, and that essay is the best advice I've seen so far.

Other good advice is in Brooks, The Mythical Man-Month. Brooks is deeper in technical issues; the OP is better in the human and management issues which, IMHO, is where the real problems really are.

Oh, by the way, I still believe that nearly all the best ideas in software management I've heard about are old (although I do have along list of questions where the old stuff doesn't give good answers and where I haven't seen good answers either old or new). So, e.g., I have essentially no faith in "agile" or "object-oriented". And I believe that (A) code without good documentation is essentially worthless, (B) the documentation is more work than the code, and (C) between the code and the documentation, if I had to save just one, it would be the documentation. So, in particular, for the work, the most important part of it is writing documentation; writing the code is the lesser part. And (D) my view of writing code is that it's simple: Start with a good description of (i) the programming language to be used and (ii) good descriptions of the functions, classes, APIs, etc. to be used, and between these two by far the more difficult is (ii). [No, right, usually it's not automatically simple, not at all; instead, in the end it should look and be simple, and that can take a lot of hard work.] Then from the documentation get the really crucial stuff -- what the heck the code is to do. It is the documentation that makes clear the issues of threading, locking, roll back, exceptional condition handling from small scale to large, the UI/UX, etc. Those issues are to be clear in appropriate parts of the documentation and not to be worked out only during the coding. So, e.g., try to get most of the coding down to (a) allocate storage, (b) the usual control structures if-then-else, do-while, select-when, (c) call-return, (d) clear architecture on exceptional condition handling, logging, etc., and (e) the functions, classes, APIs, etc.

From what I learned from before the OP, although the OP has it better but maybe not as explicit, here are two lessons:

First Lesson.

"Why should I"? If you see a person in an organization and some work they might do, ideas they might have, etc. you have to ask the question, how will that person answer the question "Why should I". What's important here for a manager is not how YOU would answer this question but how you would anticipate that subordinate, other person, would answer the question. To be cynical, just because some area A is in the person's area of work, for some work X, will they actually do X and do it well? First way to know is, how would that person answer "Why should I do X"? To be cynical and likely often realistic, without a good answer, the person may simply neglect to do X.

E.g., there is the old Ross Perot joke: Most organizations, when they see a snake, form a committee on snakes. In a good organization, when someone sees a snake, they kill it. Well, then, the answer to "Why should I kill the snake" is that Perot had a good organization.

Second Lesson.

There is a field, with courses, in public administration, business schools, and parts of sociology called organizational behavior. There one of the better ideas is goal subordination. Well, the OP is awash in cases of goal subordination. The idea of goal subordination, and common for middle managers, is to "subordinate" the "goals" of the organization to the "goals" of that middle manager. So, the manager does what he believes is good for his career even if it is bad for the organization. So, an exercise is to read the OP essay and list and explain the places where the author is suggesting goal subordination.

There's much more to say, but, trust me, the OP is talking about stuff that is darned real.

For me, I want my startup to work. A big, huge advantage of being founder and 100% owner is that I don't have to explain stuff to some BoD that, as in the OP, has no chance of understanding reality. So, I'd constantly have to create "company theater" for the BoD, and that would be so wasteful it could kill my company.

My point here generalizes and is generalized in the OP: The crucial details of a serious real problem and its best solution are typically too difficult for communicating up a management chain or even just from a CEO to a BoD. The OP is correct. So, as sole founder and 100% owner, I don't have to try to communicate to a BoD that has no hope of understanding or waste effort on company theater. Instead, I just concentrate on making my company successful. If I am successful, then the main evidence visible externally will be just the financial, brand, etc. success, a lot of which the news media will likely heavily distort; the real reason the company was successful will be known just to me and maybe a COO or CTO if I get really good ones.

I'm an architect at a huge multinational, and I also found it to be too abstract, even vague. I'm sure it works for some people, but I'm really not a fan of this writing style.

Entropy is the measure of disorder in a system, so my interpretation here was that you shouldn't take on work that was generated by organizational disorder. An example I have in mind is when someone on the product side asks for a new feature that you know wouldn't take much time at all. Even though you could knock it out quickly, the correct action is to have them go through proper feature request channels.

I apply a similar algorithm, except I use the word "just" as variable. As in "we could just stick this in a DB", or "isn't it just about adding a checkbox to the page?"

Or measure how annoyed they are when you ask them to go into specifics about what they expect.

Relevant XKCD [0].

Lots of topics vary wildly in complexity, depending on what's actually expected of the developer. For example, I could see how implementing an authentication system might take as little as a few hours to as much as a few months.

I think developers sometimes get overconfident when they can just reach for a library to do anything they need, so they underestimate the complexity of having to implement everything themselves. I've seen tons of great examples of this while doing frontend work. Need a typeahead component? Just pull in some plugin or library and wire it up, frontend development is so easy! But if you actually go implement your own you quickly realize there's lots of details to consider in order to make it accessible and user-friendly. Working with local data? Might want to go brush up on search algorithms. Throw in a bit of extra fun if you need to support multiple languages.

[0] https://xkcd.com/1425/

This. +500 The devil is always in the details something that sounds obvious but yet is hard to express clearly by PMs will def. be the thing that takes a while to implement (and more importantly to get all stake holders to agree on what "it" actually is)

Yeah but not all things are like surgery. Often, « A good violent attack now is better than a perfect one next week » (George S. Patton)

Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version.

If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.

FYI - They use the same metaphor in Mythical Man Month and it's very apt.

Deadlines do matter in many situations. Like, for example, being able to announce a new product or feature at a conference with a fixed date. Or before a sales meeting with a new client, or before a yearly allocated budget expires, etc.

I have, however, also encountered arbitrary deadlines that people hang onto for no good reason.

I think this explains a great deal and was a concept I had been mulling over myself recently: basically there's an asymmetry in clueffulness that works to propagate cap around much more widely than you'd expect.

Speaking as someone that has never seen Star Wars, I still get his point.

Seating arrangements. Be it putting people who work well together in adjacent offices, or on adjacent tables.

Giving people freedom and allowance for failure, not having a strict "I am the boss" micromanaging hierarchy on the team.

Reward people for taking initiative. Find work that people want to do, and give them time to do it on their own but only if they self organize all of it, this builds necessary skills.

Taking someone who looks like they may have leadership potential aside and asking them to take on a small feature.

Combine all these together and you'll come in one day and find your team in a huddle tackling tasks together.

Requirements: Not being an insecure manager. Knowing that your value to the team and org is not in telling people what to do, but rather in helping them do what needs to be done. Sometimes this means communicating directives from on high, other times it means getting the team the resources that they've determined they need.

Have you read Peopleware ? There's some good gems there

I have to completely agree with that paragraph. As long as we are talking about metrics, impact is the one to measure.

Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.

For a competent team, arbitrary dates, generally leaving not enough time, only serve to limit scope. A competent team will produce as fast as is possible, given a specified scope.

Agree. Dates are good for limiting scope. Without that constraint, it is usually very hard to set boundaries as to what should and what shouldn't go into a project. There is also validity to the notion that time is money. Eventually, we'll all be lying in our graves.

But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.

> 24. Don’t let entropy get at your daily routine. Avoid entropy-driven work.

Your anecdote is rule 24 in practice. Good job.

Theoretically, it might not be a good reason to hire. Maybe the problem is bad planning or project management. Hiring more people won't really solve that.

But, in general, I agree with you.

Rereading the advice, I think he means hire before you get to overworked. I agree it's phrased poorly.

The way I understood this: "If you are overworked, first look at your team, is everyone at their place and pulling their weight, evaluate your deadlines and promises, check your planning and management and your relationship with stakeholders. Because most of the times it's one of those things that's broken and probably affects the rest".

That's your (negative) take on it. You can do something about being overworked without hiring (evaluate deadlines and scope, learn to say no). There's a good chance that hiring people without establishing the underlying cause of "being overworked" will only lead to more people being overworked. If you're hiring because of "being overworked", you're hiring too late.

The idea that entropy works on the direction of "hard work -> easy work", instead of "complex work -> simple work" or even "more work -> less work" is a great insight.

So it is true Americans don't use past participles?

Have you considered studying how you communicate? There was something on HN recently titled How to write emails like a CEO (or similar).

I studied my old CEO's communication style, holding it up against how many of my peers communicated. I noticed that he got right to the point, expecting other people to assume he considered multiple ancillary points. My (lower status) peers' emails would meander, and read like they wanted to show their superiors how good/smart they were at their job, and that they thought of every last thing.

The high status person didn't feel the need to pre-emptively brain dump.

My larger point is if your emails are perceived in such a way, it's worth improving.

Avoid metaphors in general. In my experience, metaphors lead to discussion about the correctness of the metaphor instead of the subject the metaphor was referring to. This is a waste of time.

You have to be careful. I am currently in an org that has embraced this philosophy. Instead of making the survivors feel valued, it has motivated most of them to move into more stable environments. These employees have dependents and don't like the idea of having their health insurance in play on a daily basis.

People read Glassdoor. If your company earns a rep for rapidly and casually dismissing people, you will see good resumes dry up. In our case, the quality of candidates has nosedived. It's not clear why a strong candidate would join a company that opts to fire people so casually.

Companies like Netflix have the cachet and can retain people despite an anti-worker culture. It's also a self selecting group of over-achievers who may like the environment.

I'd argue most above average but not stellar workers would not put up with Netflix's implicit demands.

Company talk about "we are a family" is a red flag for a work environment where people may be pressured to work overtime ("it's more than a job; we're family.") or overlook inappropriate behavior ("that's just how Bob is; we can't fire him because family has got to stick together."). People on a team don't need to be "family" to be respectful and supportive of each other.

This is where I stopped reading. Maybe if you work for Netflix-tier company which swims in the new candidates this makes sense but otherwise it's a great way to get a bad fame and make remaining employees focus only on KPIs to avoid getting fired(Goodbye good code quality, mentoring etc.; Hello "please create a ticket before asking any questions").

Besides, a good organization hires mostly right candidates. Firing should be really exceptional.

Unfortunately, "fire fast" is now known widely enough to become a business fad / cargo cult. Which means, people are going to do it because it's the thing to do, and not because there's a good business reason to do it.

As a consequence, a company could strategically use "fire fast" by claiming it as a policy but not doing it. This would attract the people who perceive themselves as high performers, with minimal impact on employee morale.

That may sound nice to some people on paper, but the reality is that it creates a negative feedback loop. Consider the following review of the company from a senior software engineer. This review is not unique in its opinion:

I worked at Netflix full-time (More than 3 years)

Pros

They pay a ridiculous amount of money.

Cons

Horrible culture, everyone is afraid they will get fired any second. People hire their own friends/groups or people with less skills/experience so they can defend themselves against weaker employees and throw them under the bus. Lord help you if you don't know anyone when you get hired to form a posse' with.

Advice to Management

Stop with all your nonsense pitch deck, it's dated, old and you aren't hired the best talent away from Google, FB, Amazon....the sooner you realize you are just a content company, and maybe pay reasonable salaries with reasonable fostering environment the better. Just ask yourself: how many employees would leave if you cut their salary. Probably every one.

If a company has to constantly fire a lot of people - supposedly for not performing well enough - then the company might want to investigate why it's so bad at making people reach their potential.

Note: a constantly looming threat of being fired might be involved in it too.

It really resonates with me and a job I used to have too.

“Multinational” is in regular use (reflected in most current dictionaries) as a standalone noun with an equivalent meaning to the noun phrase “multinational corporation”.