Most software teams—at least among those I’ve worked with—are product delivery teams. They add value by making the product, or by making the product more useful to people.
But there are other kinds of teams, and recently I’ve been thinking about improvement teams. These are teams whose interest is in making the software internals, or the development environment, better in some way. Their customers are not so much the external users, but rather other software developers—such as those in the product delivery teams.
The work of an improvement team is potentially broad: creating missing documentation, addressing tech debt, improving the build/test/deploy pipeline, ensuring a reliable development environment, and so on.
You might say such a team shouldn’t exist, and to some extent I would agree with you. After all, the things in that list would ideally have been done in the normal course of events. I also believe that tech debt should be tackled in the usual course of development—if you’re working in an area and see an opportunity to improve it, then you should.
However, sometimes that’s wishful thinking. Sometimes there’s too much tech debt in the current area to tackle sufficiently as a reasonable addition to current work. Sometimes there is debt in a part of the system that no-one is working in, but which everyone uses. Sometimes that’s the code, the documentation (whether code comments or a wiki page), or the environment.
But how much value does such a team add? Can it be compared to the value of a product delivery team?
Actually, I think it can add at least as much value, for two reasons.
First, the team is a multiplier. A product delivery team adds value by making the product—and hence the company—more valuable. Indirectly, they bring in revenue, because they are making the product more saleable. A improvement team doesn’t add value externally, but it makes all the other developers more effective. If one developer on the improvement team is helping ten developers elsewhere they are having a multiplier effect. They increase the speed with which others deliver the external value.
Second, they don’t add the same operational cost that product delivery teams do. From time to time someone will say that a product delivery team is adding to the company’s assets by creating more intellectual property that the company owns. And once in a while I will hear someone reply, “Ah, yes, but we’re also creating liabilities—more software that has to be maintained.” That’s not true of an improvement team. An improvement team makes the code better, not bigger. Perhaps they are addressing those liabilities.
Some might say it’s not as glamorous to work in an improvement team. You can’t say, “I built that feature”. But if you can say, “I made ten developers 20% more effective,” that’s an impressive claim of a different kind.
niksilver.com 