Engineering Management and The Law of Diminishing Returns
Diminishing returns, also called law of diminishing returns or principle of diminishing marginal productivity, economic law stating that if one input in the production of a commodity is increased while all other inputs are held fixed, a point will eventually be reached at which additions of the input yield progressively smaller, or diminishing, increases in output.
The job of anyone who leads Engineering at a company, is to collaborate with the business to use technology to build solutions and make profit in the most sustainable way possible. That said, one of the major struggles Engineering Managers face is summarised in one question: “How can we move faster?”
As an Engineering Manager, you may be pressured to “scale up” your team by hiring more people to match the workload, so that you can get more done quickly in less time than it currently takes. This articles seeks to help you ask another question before you determine that growing your team 3x in 5 months is the way to go, because you really shouldn’t be scaling up human teams like they are servers. Also, by hiring, you’ll be significantly raising the company’s expense on salaries. You have to be absolutely sure that it’s an expense that needs to be made and justified by the output.
How many business-critical features are currently in development?
Based on my experience, you definitely should limit work in progress as much as possible if you’re more interested in getting things done quicker than being/looking busy. This article by Will Larson, author of the Elegant Puzzle (a book which I recommend) does a good job explaining why it is necessary, but I’ll like to add two more things:
- Engineering doesn’t stop after active development: Imagine that to implement a new feature, you had to create 3 new database tables, 2 new consumers and one cron job (this example is non-fiction lmao). The feature is tested, works well and is deployed. Everyone is excited. But before you jump on the next thing, you have to think about maintaining that system. The new feature comes with its maintenance burden which isn’t trivial. Now, multiply this by 4 and you can easily see how you have exponentially increased the team’s workload if those 4 systems were deployed at once. What about making changes to those systems as you get user feedback or changing business requirements? Add this to the burden of implementing another 4 of this system and you can see how quickly life can spin out of control for the team.
- Documentation isn’t a silver bullet: While documentation is great and necessary, it becomes useless if not consistently updated. If you have so many things going on at once, it becomes increasingly difficult to keep documentation up to date as multiple changes occur at once and different scopes of work intersect with one another.
- Hiring is expensive: This isn’t only financially, but even in the context of speed. Onboarding people takes time, and has to be done by someone on the team who already has the burden of features to build or maintain. Every new addition to the team increases communication lines, and this will need to be accounted for.
Maybe what you should manage is speed
The layman understanding of the Law of Diminishing Returns is “too much of anything is bad for you”. It’s good to move fast, but not too fast. It’s good to grow, but not too quickly. In this “fast-paced” world, what many people are trying to achieve with Engineering is impregnating 9 people in the hope that they’ll be able to produce a baby in 1month. It is why whole systems are oversimplified and presented as “simple integrations” or “plugins”.
If you hire too quickly, you’ll be slower.
If work grows too quickly, you’ll be slower.
If you push people to work long hours till they burnout, you’ll be slower.
You’re better off with 4 people working on 2 things, than 6 people working on 6 things.
Your best shot at greater speed is doing work in sizeable chunks and growing sustainably.
Selah.
