Victims of Your Own Success

Slowing things down with the company’s growth

If you’ve ever worked in a small company that has grown into a big company, you may have experienced the feeling that things have slowed down as you’ve gotten bigger. The time it takes to make decisions, the time it takes to ship new features, and the time it takes to merge code and for it to be deployed to production all seem to increase.

The Mythical Man-MonthFrederick P. Brooks Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, Boston, MA, Anniversary, 1995. had this covered way back in 1975 with a concept that became known as Brooks’ Law: “adding manpower to a late software project makes it later.” In fact, this observation can be made more generally. Adding more personpower to a team, department, or company makes everything more complicated. Knowledge work cannot be easily split into discrete tasks, and there’s always communication involved. You can’t chop a programming project into two without increasing the amount of communication required to get it done. So, even if your team, department, or company has grown, you can’t expect a linear return on investment for the number of people added.

Even though this concept has been around for longer than many people have been on the planet, it still comes up time and time again:

• People within the business may be frustrated with the progress from Engineering. After all, you’re three times as big now, so why aren’t you doing three times the work?

• Your users may feel like you’ve slowed down as you’ve become more successful. You used to ship twelve big increments a year. What happened?

It’s not people, it’s productivity

As a manager, you should ensure that arguments around speed do not become ad hominem. Although people are quick to point out that those at a startup may be working ridiculously long hours, this simply isn’t sustainable or desirable at a bigger company. It should be possible to get everything that you need to be done and still have a life outside of work. A few individuals are not making the entire department or company slow. It’s a natural side effect of growth.

Your company is a victim of its own success. You now have to deal with legacy systems and increased communication overhead. The more accurate way to phrase your perceived slowness is that the productivity per head is decreasing, and this is the problem that needs addressing.

You’ll find that if you’re successful:

• Business as usual gets harder. Doing well creates more work. Customers expect better SLAs. Your application’s security needs more work. Your monitoring and alerting needs improving. Oh, and that on-call rota needs setting up. You’ll have to scale storage better. Will it need re-architecting? Just keeping the lights on takes an increasing amount of time and effort.

• You’re dealing with more and more legacy code. Yesterday’s feature is today’s technical debt. A new product direction or company pivot can introduce dirty hacks and rewrites. Even if you don’t introduce crazy hacks, the ever-increasing size of your codebase makes it take longer to work out how best to introduce new functionality then implement it.

• Communication and process overhead are ever-increasing. Startups can make unilateral decisions at speed. Large multinationals can make decisions at a glacial pace. How many people are required for consensus? How many meetings and emails does it take to get there? Communication channels far outgrow the number of staff. If there are n(n-1)/2 potential channels, a 400-person company has 79,800 of them!

The fact that productivity per head decreases as a company gets larger has allowed startups to flourishFrederick P. Brooks Jr. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, Boston, MA, Anniversary, 1995.. That feature that a large enterprise software can’t decide on or deliver quickly because of the inherent complexity of steering a large ship becomes a gap in the market that a nimble startup can begin to undercut.