
Things I have learnt as the software engineering lead of a multinational - kuahyeow
https://minnenratta.wordpress.com/2017/01/25/things-i-have-learnt-as-the-software-engineering-lead-of-a-multinational/
======
cjcenizal
Point 1 resonated with me (and its value outweighs that of the others by an
order of magnitude IMO):

> 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.

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.

~~~
abraae
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.

------
Bahamut
> 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 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.

~~~
ptero
>> 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.

~~~
geezerjay
> 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.

Not necessarily. Accepting a new project or extra responsibilities in exchange
for a generous sum may increase your company's workload unexpectedly, which
leads to overworked people while the company struggles with the hiring
process. Another example is losing a team member right before crunch time.

~~~
ptero
Sure, there are exceptions. For example, I do not see a team flying out for a
2 60+ hour week test campaign as a red flag as long as the participation is
mostly voluntary and the team gets an ample opportunity to detox after the
fact.

The exceptions, for me, have three key properties: (1) they are temporary, (2)
overworked people know that it is temporary and have a clear (maybe not 100%
realistic) date for return to normalcy and (3) this state of affairs is seen
by most of the team as acceptable at the moment: not pleasant, but bearable
and probably least bad of all options.

If (1) and (2) hold, (3) is usually easy to achieve with sweeteners: $x bonus,
T extra vacation, etc. But break either of the three and you have a clear red
flag. Just my 2c.

------
programmer_dude
The article is too abstract for me. I don't have enough leadership experience
to relate to what is being said. I'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.

~~~
reilly3000
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.

------
cbcoutinho
I'm a bit confused by the authors use of the words entropy and entropic,
starting specifically with this point:

> _Don’t let entropy get at your daily routine. Avoid entropy-driven work_

In a physical sense, my understanding of entropy is that it's a degenerative
phenomenon, a lowest common denominator - it doesn'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 'entropy-driven' work are meaningless.

I'm sure there'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.

~~~
foobarchu
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.

~~~
mmcnl
Your example is right on the money. I used to be consumed by organizational
disorder, and even worse, wasn't aware that it was happening. Agile is no
magic solution but it can be a vehicle to creating organizational order if you
need it, especially if it's a hot buzz word in your company.

~~~
lowbloodsugar
Scrum, if you do it right, is precisely the solution. Scrum specifically
rejects the idea of "just doing something on the side".

Unfortunately, most organizations believe in cults and magic, and believe (and
act) that Scrum is a cargo cult where you say the magic words and hold the
magic rituals and get the results.

------
scrame
"When the plan is foggy, that’s the moment to communicate as broadly as
possible."

Here's a good rule of thumb: Ask them to explain what has to be done, and then
count the number of times they say "it should be pretty straightforward".

Consider those multipliers of complexity.

~~~
dudul
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?"

~~~
zitterbewegung
Using Just and extremely easy should be where you make a milestone for each
statement(s) after that .

------
KKKKkkkk1
_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 love that metaphor.

~~~
crocal
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)

~~~
lj3
That doesn't apply to software development unless you're a startup with
limited funding and no positive cash flow. In the vast majority of cases, the
software is already released and making money. Whether you finish the next
release in 1 month or 2 is of no practical importance, except that it makes
the manager look good. He can report a larger profit margin because the cost
that went into that release is roughly half if it was released in 1 month
rather than 2.

And therein lies the conflict that this post doesn't really address or
resolve: there's rarely a discernible difference in revenue between a high
quality release and a buggy, low quality release, but the profit margin of the
former can be (and often is) much lower. A great real world example of this is
PUBG.

~~~
Negitivefrags
Since you picked a gaming example, I would like to present the idea that in
gaming the opposite is true.

If you have a live game that you intend to last a long time, it’s extremely
important to establish a reliable release cadence that the players can depend
on.

Our company first released our game in 2012. After release we didn’t know how
important this is. We just kinda made updates and released them when we
finished them.

The player numbers never went above what we had at release. For a few years
our numbers were pretty flat. We would have up releases and down releases but
we never broke our initial numbers.

Then we changed to a cycle of having a release every 3 months.

This was a massive improvement. Most players won’t keep playing your game
continuously forever, but if they always know that there will be a thing to
come back for, and when that will be, they will stop playing before they are
burned out with a plan to come back.

Suddenly our numbers grew with every release. Each 3 month cycle saw a large
percentage increase over the previous one.

After a few years of that our game is massively larger than it was at release,
and it’s still growing with each subsequent release.

I’m not saying that it’s okay to release a buggy game, you have to scope each
release so that you can do it on time without being too buggy. What I am
saying is that the release schedule is actually really really important.

~~~
Everlag
For context to other readers, Negitivefrags is talking about Path of Exile[0]
and seems to be downplaying the success GGG has achieved in the last few
years. The regular release of compelling content has driven PoE into a great
position as the market leader for ARPGs.

One thing they didn't mention is that the regular release cycle lets you mess
up and recover. For example, the Essence league(a 3 month batch of content)
was underwhelming for most players. However, the Breach league following that
regrew any goodwill that might've been lost.

[0] [https://pathofexile.com](https://pathofexile.com)

------
mikeokner
_> 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 think this one depends on one's personality. I know people who have been
relatively successful in their role for years who still regularly express
impostor syndrome.

------
hkarthik
> 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.

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.

~~~
dboreham
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.

------
riffraff
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.

[0] How time flies! [https://minnenratta.wordpress.com/2005/12/23/le-
proporzioni-...](https://minnenratta.wordpress.com/2005/12/23/le-proporzioni-
del-mondo/)

------
zbentley
> Teams don’t self-organize unless you organize them to do so.

...or, teams self-organize _unless_ 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 "self directed"
and fire everyone who is insufficiently short-term in their thinking.

/s

------
0xFFFE
Nitpicking.

> 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.

37\. Don't assume everyone reading your article gets the Star Wars reference.

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

------
AnimalMuppet
_Teams don’t self-organize unless you organize them to do so._

Interesting. I wish there was a bit more detail on _how_ you organize them to
do so...

~~~
com2kid
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.

------
asafira
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/or what were the best
resources to learn them (if not just experience).

------
crocal
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).

~~~
yoyar
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.

~~~
imiric
Right. I wish more managers/coaches/masters understood this.

Features are done when they're done (for a given definition of "done"). Once
we're satisfied with what we have, we release it. Otherwise we keep working,
or we scope down.

Strict deadlines are seemingly based on financial period expectations, rather
than on what actually produces better software, and thus, ironically, more
revenue for the same stockholders who were demanding a date. It seems more of
a short-term strategy than long-term.

Anyway, that's my pessimistic, armchair interpretation of it.

------
misterbowfinger
Favorite quote:

> Delivery dates have often irrelevant but very simple to understand impacts.
> Good and bad solutions have dramatic but very difficult to understand
> impacts.

------
koonsolo
Nice list, although I was horrified by one (sorry to need to pick on the one
thing that was bad):

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

That'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.

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

Your anecdote is rule 24 in practice. Good job.

------
knieveltech
"Being overworked is not a good reason to hire."

Because the world certainly needs more sociopathic management advice.

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

~~~
ckip
I agree with his advice and not yours. Good candidates are a good reason to
hire. Overworked is a good reason to reexamine priorities.

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

~~~
marcosdumay
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.

~~~
tenkabuto
Could you please elaborate on this?

~~~
marcosdumay
The articles has some examples on the difficult -> easy propagation. Like
discovering what a company does well and creating a vision that uses it is
difficult; joining all current projects and creating a slogan that fits them
all to use as a vision is easy. Measuring impact is difficult; setting and
measuring deadlines is easy.

There is more there. I leads to an "I know it when I see it" understanding. If
I tried to compress it into a definition I would certainly miss lots of
relevant details, at least without refining it for some time, so I won't.

------
sam0x17
Thing one: use "learnt" instead of "learned" to sound multinational. ;)

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

~~~
sam0x17
At least in this case yes. For us the past participle would simply be
"learned"

------
BeetleB
>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.

Mine are always perceived as such :-(

~~~
tinymollusk
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.

~~~
asafira
Along similar lines: I often write an e-mail with all of the information I
want to include, and read it over and edit it several times to cut down on
things that aren't necessary. The unnecessary things can be as simple as an
awkward prepositional phrase, but often they are a technicality that is
hogging too much space in the e-mail.

I personally think this really improves my communication. In a workplace where
people are expected to read through dozens of emails each day, it makes a
difference in the information that's finally conveyed to my colleagues, which
is often what matters the most to me.

~~~
tinymollusk
Great point. I wonder how often people shoot emails out without serious
editing.

------
egor598
>>Construction work is not a good metaphor for software/product development.
Factory work neither.

I like this, really fed up with everyone comparing software development with
construction work and/or building a house. Don't compare those, apples to
oranges. Sure, borrow the best, most appropriate things, techniques,
methodologies, approaches and not just from construction. Just don't compare.

~~~
mmcnl
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.

------
lifeisstillgood
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.

we don't lack the technology, just that there is no good strategy at that
level.

------
scarface74
_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 like this. Put another way "we are a team not a family."

[https://www.slideshare.net/reed2001/culture-1798664](https://www.slideshare.net/reed2001/culture-1798664)

~~~
pizzetta
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.

~~~
scarface74
I would gladly work for a place like Netflix for a year or two, bust my butt,
put it on my resume and move on. My market value would make it well worth it.

~~~
ebbv
Having worked at a “name” company is not the big boost to your value lots of
people think it is. That’s a lie that those big companies use to get people to
accept bad working conditions.

~~~
scarface74
You can't just "work" at the company, you have to produce.

There was an anecdote about Netflix about how a group of engineers who were
top performers were let go after they did their part in transistioning
Netflix's data center to AWS.

So should we feel bad for the people that got laid off? They will be some of
the most sought after people in the industry.

~~~
ebbv
That's exactly it. And the thing is no matter where you worked, if you did
great things and have great skills, you're going to get opportunities and
recognition. If you don't have the skills and don't do the work, it doesn't
matter where you filled a seat.

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

------
xamde
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.

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

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

------
nickthemagicman
I'm not sure if this is brilliant advice or really bad advice.

------
tboyd47
> People appreciate when you fire the right people, so don’t worry about
> morale.

When you select for sociopaths, you get sociopaths.

------
OJFord
Title whinge: a multinational what?

(That's not intended as a pedant'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.)

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

