Making the case for investing in SWE growth
October 12, 2019
I've been thinking about this a lot of recent, and it is in my view, one of the most important aspects of what we do for our engineering teams, or indeed more broadly our companies. I put forward an idea of engineering teams over time, generating a maintenance burden for themselves, that acts as a pressure on their velocity. Hiring is probably an insufficient solution to this, so we need to really open up the conversation about how we learn within teams.
Throughout say, a quarter, an engineering department will complete a certain amount of projects, creating or refining functionality as they go. The creation of value does not always coincide with the creation of code, but we can say that in the case of an engineering department, their core means of providing value is by building stuff. However, the code has a maintenance cost. On the subject of program maintenance, The Mythical Man Monthfn:1 asserts that
The total cost of maintaining a widely used program is typically 40 per cent or more of the cost of developing it
A nice corollary from this is:
The cost is strongly affected by the number of users. More users find more bugs.
This is not a case of developers being 'bad', but rather, as the book states:
First, even a subtle defect shows itself as a local failure of some kind...unless the structure is pure or the documentation is very fine, the far-reaching effects of the repair will be overlooked.
This doesn't even cover off the interaction between systems where a new capability is built at some later time, and the impedance mismatch between the two needs to be negotiated.
Even paying down these costs is not a straight forward journey. From the same book:
Fixing a defect has a substantial (20-50 per cent) chance of introducing another. So the whole process is two steps forward and once step back.
My experience would support these assertions that Fred Brooks makes in The Mythical Man Month, and it leaves us with a conundrum; as we build, there is a background cost, a liability which is increasing over time. There is constant downward pressure on our delivery velocity.
It stands to reason that to continue to deliver value into the platform, whilst also maintaining and improving the stability of the platform over time, it is critical that a teams capacity increase over time. Even if you had caffeinated super soldiers working 24/7, the things they build require maintenance, and maintenance requires capacity.
Hiring is the worst way to remedy this. Hiring is expensive, both in terms of time and moneyfn:2. Done right, hiring is a boon, supercharging a team to deliver amazing things.
However, hiring Software Engineers in most places is practically a pseudo-scientific process. If you've done a good job, you haven't unleashed a false positive into your internal ecosystems (in this scenario the cost of hiring is about to get super expensive for you). Most places have reacted to these pressures with the seven circles of white-boarding, which is still expensive because you need your engineers to be involved with this process.
Furthermore, if you don't get on top of progressing your Software Engineers, you're likely going to keep incurring this cost; funnily enough to a crowd full of nerds, learning stuff turns out to be pretty important, not to mention that batting away bugs whilst delivering new stuff at a rate of knots can burn out people if you're not careful.
So when should you hire? Growing the abilities of a workforce is by no means a linear process, and sometimes, the next step up for a company requires the injection of new blood. As I said, when hiring goes well, you've technically added a whole person worth of capacity, which is a fair amount of capacity.
This is the bit where I don't really have enough experience to come out with something concrete. I saw a sprint goal recently that I was very, very fond of.
X is going to learn Y
This was fantastic to my mind:
It supports somebody getting up to scratch whatever they need to learn. There's no expectation on them to deliver something immediately - they've got the space to sink into a topic and come out swinging later on.
Part of the capacity of a sprint was scheduled not only to learn but to teach - by making these things explicit, we create a more workable environment for this
The most important facet of this is that it centralises the planning of learning, in a way that can be built around by the company. Teams can develop ability in certain areas in an organised way, and work can be structured bearing this in mind.
I think the openness of the above approach seemed very powerful to me. I'd be interested to see if people have examples of workplaces where they managed learning very well, even if their system of managing learning was not managing learning!
In closing, as engineering departments build things, the cost of maintenance increases over time. To be in a position where that doesn't gum up the works, people need to be progressing and learning within a team, increasing the capacity over time. A ham-fisted way of increasing the capacity of a team is hiring, but that's an expensive band-aid solution at best. We best put ourselves in a position to create a culture of learning when we're open about it, and a suggested means of achieving that is to prioritise learning as an outcome on the team level, rather than the individual level.