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

Point 1 resonated with me (and its value outweighs that of the others by an order of magnitude IMO):<p>&gt; When the plan is foggy, that’s the moment to communicate as broadly as possible. In fact you should not frame it as a plan, you frame it as the situation and the final state you want to achieve. When you have a detailed plan, that’s when you DON’T need to communicate broadly. So, clearly state the situation and clearly state the foggy goal to everyone who will listen.<p>This is a great way to clarify a complex problem, draw out and resolve disagreements in understanding, enlist others’ help, and methodically arrive at the optimal solution. It also works well for all kinds of problems, whether they be engineering-related, organizational, or interpersonal.

&gt; Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.<p>I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.

The article is too abstract for me. I don&#x27;t have enough leadership experience to relate to what is being said. I&#x27;d be grateful if someone could rewrite this article with some concrete examples. I am sure there are many others in the same boat as I am. They will find this useful too.

I&#x27;m a bit confused by the authors use of the words entropy and entropic, starting specifically with this point:<p>&gt; <i>Don’t let entropy get at your daily routine. Avoid entropy-driven work</i><p>In a physical sense, my understanding of entropy is that it&#x27;s a degenerative phenomenon, a lowest common denominator - it doesn&#x27;t create anything. This point means avoiding distracting or sporadic work, which is a test of discipline. But the rest of this point and others further down using words like &#x27;entropy-driven&#x27; work are meaningless.<p>I&#x27;m sure there&#x27;s a good point to be made here about valuable work in large corporations, but the (over)use of the word entropy has lost me.

&quot;When the plan is foggy, that’s the moment to communicate as broadly as possible.&quot;<p>Here&#x27;s a good rule of thumb: Ask them to explain what has to be done, and then count the number of times they say &quot;it should be pretty straightforward&quot;.<p>Consider those multipliers of complexity.

<i>There are some very rare cases where delivery date is more important than what you are delivering, but modern management seems to delight in generalizing this unusual occurrence to every situation. People do get promoted for having been able to deliver completely broken, useless and damaging solutions on time. If that’s the measure of project success you can expect dates to rule (even when they continuously slide). After all, if you are not a trained surgeon, and the only thing you are told is that a given surgery should last no more than X hours, guess what will be the one criterium for all your actions during the operation.</i><p>I love that metaphor.

<i>&gt; If you feel like you don’t know what you are doing it’s probably because you don’t know what you are doing and that’s bad.</i><p>I think this one depends on one&#x27;s personality. I know people who have been relatively successful in their role for years who still regularly express impostor syndrome.

&gt; 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.<p>This resonated with me and definitely gave me food for thought. Raw ideas with uninformed opinions can easily percolate throughout organizations and even across the industry. Feels like something we as a society need to more actively guard against.

OT, but: funny, I felt the name was familiar, and turns out I commented on a post on this blog 12 years ago[0]. A reading lost due to the death of google reader, I presume.<p>[0] How time flies! <a href="https:&#x2F;&#x2F;minnenratta.wordpress.com&#x2F;2005&#x2F;12&#x2F;23&#x2F;le-proporzioni-del-mondo&#x2F;" rel="nofollow">https:&#x2F;&#x2F;minnenratta.wordpress.com&#x2F;2005&#x2F;12&#x2F;23&#x2F;le-proporzioni-...</a>

&gt; Teams don’t self-organize unless you organize them to do so.<p>...or, teams self-organize <i>unless</i> you have organized them not to, in which case, if you want them to self-organize, you have to hire an Agile coach and start putting up posters telling people what it means to be &quot;self directed&quot; and fire everyone who is insufficiently short-term in their thinking.<p>&#x2F;s

Nitpicking.<p>&gt; 20. The Sith are right, rage propels. But the Jedi are right, you must not let it control yourself. What nobody tells you is that the rage game is intrinsically tiring and rage will take control as soon as you get too tired, so stop well before.<p>37. Don&#x27;t assume everyone reading your article gets the Star Wars reference.

<i>Teams don’t self-organize unless you organize them to do so.</i><p>Interesting. I wish there was a bit more detail on <i>how</i> you organize them to do so...

Most people are commenting on what bullet points they agreed or disagreed most with. I am sure, however, that there are other software engineering leads on HN --- what other lessons have you learned, and&#x2F;or what were the best resources to learn them (if not just experience).

I have to disagree slightly on the paragraph about dates (#32). Engineers leaders cannot dismiss dates as one of the metric of their performances. The metric is not the goal nor the means in itself, though. In my view, entropic organization and management make this mistake constantly of confusing the metric with the job, like driving a car looking at the speed meter and not at the road (sounds absurd, I know, but is really what happens).

Favorite quote:<p>&gt; Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts.

Nice list, although I was horrified by one (sorry to need to pick on the one thing that was bad):<p>&gt;Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.<p>That&#x27;s why we as programmers should say no to overwork, because only then will they see the need to hire. I only do overwork when some unexpected disaster happens, or when there is a sudden huge opportunity. In the other cases, they should plan better or hire more people, simple as that.

&quot;Being overworked is not a good reason to hire.&quot;<p>Because the world certainly needs more sociopathic management advice.

All of the comments about entropic organizations ring true and hit close to home. Way too close to home.

Thing one: use &quot;learnt&quot; instead of &quot;learned&quot; to sound multinational. ;)

&gt;Mass emails and top-down communication are not taboo: just because most such communications are irrelevant it doesn’t mean yours will be perceived as such.<p>Mine are always perceived as such :-(

&gt;&gt;Construction work is not a good metaphor for software&#x2F;product development. Factory work neither.<p>I like this, really fed up with everyone comparing software development with construction work and&#x2F;or building a house. Don&#x27;t compare those, apples to oranges. Sure, borrow the best, most appropriate things, techniques, methodologies, approaches and not just from construction. Just don&#x27;t compare.

Interestingly he (she?) seems confused and rage driven (!) over entropic organisations - i think the main issue with entropic organisations is simply size - there is no organisational approach that can ever make hundreds of thousands of people co-ordinate in a positive manner.<p>we don&#x27;t lack the technology, just that there is no good strategy at that level.

<i>Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people</i><p>I like this. Put another way &quot;we are a team not a family.&quot;<p><a href="https:&#x2F;&#x2F;www.slideshare.net&#x2F;reed2001&#x2F;culture-1798664" rel="nofollow">https:&#x2F;&#x2F;www.slideshare.net&#x2F;reed2001&#x2F;culture-1798664</a>

This list made me realize I have only ever seen Entropic Organizations. Is there even any other kind?

A great article mostly nailing problem descriptions. This is usually represented too briefly. I believe “The Entropic Organization” (Teo) would be a highly cited book, cited by all kinds of management books emphasizing the solutions. Please, write TEO.

Looking at things related to Entropy I can can clearly see the company I&#x27;m working for(which is sad).Considering that I&#x27;m not at leadership position, my next action is to quit and find a better one.

I&#x27;m not sure if this is brilliant advice or really bad advice.

&gt; People appreciate when you fire the right people, so don’t worry about morale.<p>When you select for sociopaths, you get sociopaths.

Title whinge: a multinational what?<p>(That&#x27;s not intended as a pedant&#x27;s review of the article, just a note on the title presented on HN, which was praised in a recent thread for making even small changes to improve the grammar and quality of the site.)