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.

Motivating Growth

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

Badissimo.

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.

Once we've accepted the notion that the demands on a team continually increase as they continue to build new features, the question moves to - how might we increase the capacity of a team in parallel?

Upskilling your engineering teams is then potentially a low-risk way of attempting to improve the capacity of your teams, as the engineers spread their wings, and dive into subjects or technologies that interest them. By carving out time for this process, engineers may demonstrate clean solutions to technological problems you face, or feel more empowered to try and find better solutions in future, knowing that you've got their back, and they'll have the time and resources to understand new techniques, tools, and theory.

If you've managed to construct an effective learning process that works, engineers should be getting noticeably better over time, which means that everyone feels more confident giving them chunkier and less well-known pieces of work.

Bad Medicine

Hiring is perhaps the first means of increasing a teams capacity that comes to mind. However, hiring is expensive, both in terms of time and money². Done right, hiring is a boon, supercharging a team to deliver amazing things. In practice, 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.

Digressing

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:

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

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

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

Calling It

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.