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

A surprisingly long cycle has just closed for me and I think it’s a good time to share some lessons learned.

I have been collecting these points in the last six months, but none of them popped up recently, they have taken shape over a few years and they include both things I did and that I failed to do.

Most of these points act as a personal reminder as well as a set of suggestions to others; don’t be surprised if some of them read cryptic.

So, here it is. A summary of what I learnt in the last six years :

The productive organization

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

2.  Don’t be prudish. If you fear that people will lose faith in you because of the foggy goals and dire situation statement you are painting yourself in an heroic corner. People just need to hear and share the situation they are into. Having a common understanding will act as bonding among them and with you, which is actually all you need to make them work out the right answers.

3.  Don’t assume that a specific communication medium can’t be effective. 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.

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

5.   Fostering personal initiative in every developer requires showing the vital need for personal initiative. These are birds that mostly don’t fly out of the cage just because you open the door. You must find a way to show them that the cage is burning.

6.  People sitting side-by-side can communicate less than people sitting a continent away. Communication is a chemical reaction that requires catalysers, the thing you get by co-locating people is lowering the cost of the catalysers, but no setup creates automatic communication.

7.  Within a development organization both good and bad communication exist, but they are not a function of politeness or rudeness, it’s much more a matter of clarity and goals. You need to learn what the good kind of communication looks like, find some examples and use them as a reference for everyone.

8.  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, it is often due to a crisis situation and you’ll likely fire or otherwise lose the wrong people. People appreciate when you fire the right people, so don’t worry about morale. Also, the average quality of people tends to grow more when dismissing than when recruiting.

9.  Hire only for good reasons. Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.

10.  It’s often better to lose battles than to staff desperately and win desperate battles at all costs (World War I anyone?).

11.  Don’t export recruitment, recruitment must be the direct responsibility of everyone in the organization.

12. People must select their future colleagues, there are infinite benefits in this, but it must not become a conclave. Keep the process in the hands of the people who do the work, but make it as transparent as possible.

13.  Always favor actual skill testing in recruitment. When you don’t feel that you are directly testing the candidate skills you are either not competent enough in that skill or you have switched to just playing a set piece (I call this The Interview Theatre) and you will ultimately decide on a whim. Not good.

14.  Build some of your teams as training and testing grounds for freshmen. Put some of your best people there.

15.  Lack of vision is not agile, it is not data-driven, it is not about ‘taking decisions as late as possible’, it is not something that you should paint out in a positive light at all. It’s just lack of vision, and it’s not good.

16.  Construction work is not a good metaphor for software/product development. Factory work neither. Allied junior-officer initiatives during the first week after the d-day in WWII is probably a good guideline, but it is still not a good metaphor overall and, anyway, not known enough to base your communication on.

Yourself

17.  Train people to do all of the previous points. Including this one.

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.

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.

21.  Write down the situation, for your own understanding just as much as for the others’.

22.  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. Anyway, until you learn you don’t really have much of an alternative. Just don’t let that feeling of desperation numb your ability to learn. It does.

23.  There’s more and more good content to read and absorb on effective organizations. Don’t despair and don’t stop reading.

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

25.  Ask questions to people in order to make sure they understand. Trust people who do the same to you. “Do you understand?” is NOT a valid question.

26.  Avoid having people waiting on you. Don’t create direct dependencies on your work or decisions, make sure people feel that they can take decisions and still stay true to the vision without referring to you (hence the importance of point 1).

27.  Take the time to coach people in depth. Really, spend time with the people who are or have the potential to be great professionals in the organisation.

28.  The time you spend with the people you see most potential in is endorsement enough. Avoid any other kind of endorsement of individuals. Unless you are leaving.

The Entropic Organization

29.  An organization populated by a majority of incompetents has less than zero net-worth : it is able to destroy other adjacent organizations that are not similarly populated.

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

31.  Entropy self-selects. Hierarchical  and other kinds of entropic organizations always favor solutions that survive within entropic organizations. Thus they will favor easy over simple, complex over difficult, responsibility-dilution over empowerment, accountability over learning, shock-therapy over culture-nurturing. This is the reinforcing loop that brings ever-increasing entropy in the system : entropy generates easy decisions with complex and broken implementations, which in turn generate more entropy. An example of easy decision with a complexity-inducing implementation: this scenario “our company does not have a coherent strategy, as such many projects tend to deliver results that are not coherent, hampering the organic growth of our capabilities.” will be answered by the most classic knee-jerk decision-making pattern “we don’t know how to do X, so let’s overlay a new Y to enforce X”, in this case :”Group together strategic projects into a big strategic program that will ensure coherence”. The difficult but simple option will not even be entertained : “let’s discover our real strategy and shape the organization around it.”

32.  Delivery dates have often irrelevant but very simple to understand impacts. Good and bad solutions have dramatic but very difficult to understand impacts. The Entropic Organization will thus tend to make date-based decisions. The Entropic Organization will always worry about the development organization ability to deliver by a given date, never about the ability to find the right solution. 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. This showcases the direct link between the constituents incompetence and the establishment of classic Entropic Organization decision-making.

33.  Having a strategy will only go so far when you face the Entropic Organization, since it will be only able to appropriate that strategy at the level of energy (understanding) they can attain, which, being entropic, is very low. This results in something that does not look like a strategy at all : ever seen a two-years old play air-traffic control? He got the basic understanding of “talking to planes”, but that’s it.

34.  Partially isolating the Development Organization to stay effective does not work. Adapting your organization to be accepted by an incompetent background does not work either. What is left in the scope of alternatives is radical isolation supported by the attempt to radical results and crossing fingers for top-management recognition (also known as `Deus-ex-machina for the worthy’) and the top-down sales-pitch (or POC) to the CEO (also known as “He who has the ear of the King…”). But don’t forget : Nemo propheta in patria, so, act and look like an outsider as long as you can.

35.  Growth-shrink symmetry. When an organization grows unhealthily (too fast, for bad reasons or through bad recruitment) it will also shrink unhealthily. When it grows it’s bold and confused, when it shrinks it’s scared and nasty.

36.  Most of the ideas that will pop up naturally from the Entropic Organization are bad in the context of modern knowledge-based work, but possess a superficial layer of common-sense to slide through. Exercise extreme prejudice.

Advertisements

32 thoughts on “Things I have learnt as the software engineering lead of a multinational

  1. Do you have any good sources going into the details of “Allied junior-officer initiatives during the first week after the d-day in WWII”, would be interesting to read even if it’s “still not a good metaphor”

  2. Sure, the source for this is Ambrose’s classic D-Day : https://books.google.it/books/about/D_Day_June_6_1944.html?id=R8WgPwAACAAJ&redir_esc=y&hl=en

    Relatively early in the book (I don’t recall which chapter), there’s a very interesting analysis on the allied junior-officer (lieutenant/captain) empowerment to take decisions and initiatives without approval from higher ranks. Ambrose also draws a comparison with late-war Wermacht’s obsession for hierarchical validation (from junior officers and up to the famous case of Rommel having to wait for the Fuhrer to approve the use of the armored divisions).

    I don’t have the book here now, but tomorrow evening I should.

  3. what bullshit, I am betting you know nothing about actual software development. its because of useless fucks like you that everyone in the industry suffers. you pseudo fuck.

    1. I’ll counter with this was great advice and its unhelpful comments like this brought by the self-righteous that cause the most toxic of workplaces and the worst of productivity.

    2. If you don’t think this is relevant to actual software development, you are probably at a pretty immature phase of software development. Software development is seldom about writing code.

  4. You lost me at the entropic organization. I roughly know the concept of entropy from physics, but how is it applicable to an organisation? Why would easy and simple have two different entropy values? Why would complex and difficult have different entropy values?

    1. Yeah, I didn’t spend time with definitions and for the last section it certainly doesn’t help. The Entropic Organization is an organization that has such structural problems and/or such low competence density that its defining characteristics are chaotic decision making, poor information transfer and a general tendency for every constituent to play “his own game” instead of playing for the good of the whole.
      About your specific questions : it’s not that easy and simple have different entropic values, it’s that an organization that is highly chaotic, low skilled and governed by individuals self interest will never reach the level of focus required to do difficult things that result in simple solutions. It will thus always opt for things that are easy to do, but introduce complexity. Take integration : it is hard to align the concepts of system A with the concepts of system B to make them work together, but if you manage to, it will be seamless, natural, simple. It is far easier to add system C to do some data-mapping tricks and act as a bridge between A & B, but then you not only have two different conceptual models (one in A and one in B) to work with in the future, you also have a third system that is required for the whole to work.

    2. As a parent, I understood (or so I believed) this use of “entropy” immediately. “Entropy” is Mommy-Daddy code for “mess”. Mommy and Daddy have a nickname for whichever kid is age zero to three or four: Entropia.

  5. I’m confused about what this sentence means:

    “If you fear that people will lose faith in you because of the foggy goals and dire situation statement you are painting yourself in an heroic corner.”

    Can anyone clarify? Does it mean that by fearing speaking the truth, you’ll end up in a much worse place?

    1. Yes, kind of. It’s a bit more complicated than that. I’m writing another post where I will clarify this and other points that raised many questions.

  6. Interesting points raised. Some good and some that could be challenged. Here are my thoughts:

    If you are going to point out communication it is worth checking that you have a mature communication strategy that is regularly evaluated. Many agile organisations do not get this right and suffer.

    “Fire people whenever you can.” – this is a lazy excuse for leadership and more from the Taylor era. If you have to fire someone look first at their attitude, then if they have the skills for the job, then the system they’re in, then at the people around them. If you can rectify these do so, only then consider that action.

    Your discussion on “Entropy self-selects.”. I get where you’re coming from, the way I see this is you occasionally need to challenge how a whole organisation is set up by someone external to it. Taking a systemic approach with an outside in view is more likely to be effective than individuals applying change to small areas. Your organisation may require wholesale change that will not be the product of evolution.

    Delivery dates is a usual issue, how have you solved this within your organisation? I often here this from development teams with no accountability for budgets.

    1. Thanks for your thoughts. In lieu of articulating here I’ll address the “fire people whenever you can” point in another post I’m writing.

    2. > Taking a systemic approach with an outside in view is more likely to be effective than individuals applying change to small areas

      True although I’ve seen this fall foul of cynical consultancies pulling common stunts like “Put everyone with the same job title in the same org. Thank you! That will be mucho deniero please”

      1. Yeah, I tend to prefer not having external actors push for re-organizations. It happens, but it’s extremely rare that you find someone with the required honesty and clair-voyance to jump into the context and push for truly relevant and positive changes.

  7. I like the summary of your experience with the large (entropy) org, but what didn’t quite get was what the joy to suffer all that?

    1. :-) what if you manage to build a productive organization out of (or nested within) an entropic one? Wouldn’t that be worth all the suffering?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s