Almost exactly one year ago I posted a list of lessons I learnt about software development organizations. Recently that post generated a lot of interest, with people approving, disapproving or generally commenting one or more of my pointy points. Some feedback can be seen in the comments section of the post itself here, but most of the conversations happened on Hacker News. In general the discussions triggered on Hacker News were so rich and interesting, often branching away from the original topic, that I decided to sit back and enjoy reading it all, amazed by the thoughfulness of the exchanges and giggling all the time. I refrained from participating in the discussions for two main reasons : first, I feel more contemplative during the holiday season, and indeed here was much to contemplate; second, I really didn’t want to risk sterilizing or polarizing the discussions with an “actually I meant…”.
Now that the action seems to have mostly petered out, I feel free to do exactly that: here is my “actually I meant…” post, and other thoughts.
#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.
I’ve read a lot of reactions to the second statement of this point : “Being overworked is not a good reason to hire” and they were all very interesting. I stand by it and I wish to articulate it further : a software organization produces systems, systems produce more work (yes, even perfectly working, bug-free software). If you are tackling 50% more than what you should, adding more people will grow the share of work to do at least as much as the share of work being done, and you’ll have more people overworked.
For a software organization, overwork is more of an environmental variable depending on the company’s work culture, the organization’s engineering culture and, in some rare and transient cases, actual external pressures. So, if you and your people are tackling too much, I suggest that you need to prioritize, reduce noise (increase focus), improve engineering and general work ethics (in this order). Once the priorities are in place, everything that was dropped (and likely much more which was not being considered due to the amount of “extra work” that “needed to be done”) becomes opportunities.
You can decide to recruit for some of those opportunities, but at the very least you will be doing it without the pressure of people being crushed by overwork; even more important, you’ll recruit within the specific scope of an opportunity and that will inform your recruitment parameters and color the new entity with goals and a character, this is infinitely better than adding to a generic goo of “workers”.
There’s of course another reason why recruiting for current work is not a good idea, it is uncorrelated to #9 and it pertains to the project lifecycle rather than broader organization dynamics, but it is still very valid and deserves mentioning: the mythical man-month. Anyone interested can look it up.
#32 Delivery dates…
The whole point here is not that delivery dates are bad per-se, but that they tend to polarize attention to something very easy to understand: the fact that there are “things that depend on the date”; Moreover, dates seem to loom larger and larger as time passes, if they were not one from the beginning, soon they become a dogma. Hence the example of the surgeon fixated on surgery duration, the problem is not the data-point (the duration) the problem is that the less competent the surgeon, the more she will focus on that one easy-to-understand data-point. The more incompetent people you have, the more the cult of the date will be strong and damaging, creating its own heroic narratives (the developers who work week-ends, the testers that test during the night, the early morning go-no-go meeting…). All of this theater takes the focus away from critically thinking about what needs to be delivered.
I should also note something that I left on the side when I wrote #32 and possibly deserves a point of its own, so:
#32.b Time synchronizations make for irrational organizations. Inter-department dependencies (think Software and Marketing), but also internal dependencies (for instance, Development and Testing) are often established around time synchronizations. This reinforces the status of dates as a major success indicator and isolates people in their own time-box: critical thinking about the overall goal dies as teams focus on respecting the rendez-vous with the next team. Avoiding time synchronizations is difficult, but it is a very good heuristic for organization improvements: it tends to lead to cross-functional teams covering much of the value chain.
#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.
The brain-dump nature of the list allowed for some interpretations by people that obviously come from contextes that are very alien to the one I was implying; getting a glimpse of those contextes through their (at times horrified) reactions has been very instructive.
So, my context: imagine an organization that does not distinguish between productive and unproductive people, converting every hire in a bunch of mandays to allocate over one or more projects, those mandays being the only numerical metric used to describe the capability of the organization: “they can deliver 12K mandays in six months”.
When I say unproductive I mean it literally, near-zero or negative productivity people, true blackholes of team motivation. Organizations that for years have been hiring to grow their mandays, instead of knowing and managing their actual performance, are magnets and creators of extremely poor colleagues, at every level. Firing someone in a pile-of-mandays organization can be tricky and time-consuming: plenty of people will react badly to the idea of reducing the available mandays, after all, it’s reducing the organization “productivity”. Hence, it’s best to start early.
I’m definitely not talking of drawing a line between top-performers and everyone else to use the later group as hunting ground for this month’s “competitiveness-boosting-sacking”, in a soft re-enactement of Stephen King’s The Long Walk. If the only line you can draw is between great and ok people, it’s better to focus on coaching, rather than learning the company’s dismissal procedures.
#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 a heroic corner.
This initial part of #2 relates to a very subtle equilibrium that the head(s) of a software organization has to contend with. Corporate politics generate a stream of “news” every day, it is a social-network with very real power struggles. Software development, and, generally speaking, productive work, doesn’t fit well with such an amount of noise; besides, when the context is heavily entropic, some of that noise might include talk of dismantling everything and sending it packaged to the other end of the Earth, every second Tuesday.
Since there’s always a death-ray pointing at them (and yes, this is a movie reference), it is only natural that your duty is to at least apply a low-frequency filter when passing along the “news” so that good, productive people can carry on without too much hassle.
At the same time having the trust and respect of your good, productive people is enormously helpful when you need to steer one way or another without reverting to authoritarianism (which is a bad idea, btw).
These two elements combine into a dangerous cocktail: you don’t want to be perceived as lost in a stormy sea, because you’ll scare your people AND possibly have them lose their trust in you, which you need. Not to communicate negative news and uncertainties in your vision is both comfortable and bathed in the light of common sense and altruism. This is how machismo and, more broadly, heroic approaches to leadership often present themselves. The problem is that when you do this you isolate yourself from the people that your are supposed to guide: you tell a very shallow tale of the situation, which the teams cannot use to take their own decisions without your clarifying help (and validation) and you build a rosy image of yourself and your decisions which will entrap your thinking and stop your people from spotting and solving the most difficult problems, those that you certainly could not solve alone.
So, you need to communicate even when you are uncertain and when you have to picture a bad situation, or you’ll isolate yourself and your people from reality, but you also need to carefully sort the real concerns and useful insights from the general, scary noises.
There would be more to say
For instance, I’ve not delved here in the details about The Entropic Organization, because I’ve already expounded on it a bit in the original post’s comments and because I find that while it does deserve further enrichment, readers have generally got the meaning and the character of it, so, for now I’m content.
Finally, as I said in the beginning, the discussions were rich and of broad topic, and I could end up adding a page of comments to each of the original points and many of the resulting threads, but I want to get this post out, so I close it here.