This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen:
* Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient
* Startup is growing users/revenue very fast, attracts big VC investment
* Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers
* There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before
* Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity
* Teams know that only predictability matters, so they start making really conservative estimates, just to be safe
* If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm
* Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates
You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.
It's also about the kind of features you implement. At the start you implement all the easy features, that's no problem. Once you mature and want to get B2B sales, you need to start supporting all kinds of connectors to legacy Enterprise software, networking stacks and environments. That's much harder and much more frustrating than building a simple ticketing system.
As an example, supporting OAuth is easy. But making sure your software works with all kinds of on prem LDAP for authentication is much harder.
Yeah totally. I think most feature work at a B2B SaaS company can be classified as either trying to drive retention, or trying to drive new sales. The “new sales” features are often focused on one or a handful of potential large customers with very specific needs, who won’t buy without feature X. This kind of work is basically invisible to almost all of your customers, but is necessary to close the largest deals.
I would argue that some of that baggage doesn't make you less efficient. I mean it makes you less efficient at the features per hour metric, but what about the business value metric? If you have meetings to really think things through and plan, maybe whole areas of sterile development work are avoided and that is valuable.
Remember there are businesses that do well writing no code at all! Code or features isn't what it is al about, but in a tech company it is somewhere between nothing and everything.
Yeah, fair point. This is more an answer to “how can you have such a large product/development team, and ship so few new features”, as I believe that’s a natural consequence of having a larger business, with far more communication overhead, far more focus on planning and predictability, etc. That’s not necessarily bad for the business, but it does mean you have a lot of people shipping a relatively small number of features, especially compared with your velocity in your startup days.
Yes companies definitely get more inefficient as they grow, for all the reasons you cite and more. I've experienced it first-hand.
Adding an engineer to a team slows down the whole team a little. There comes a point where adding head count actually results in less productivity overall. This is typically countered by splitting up work into various teams with minimal interaction between them. Like Amazon's famous two-pizza team strategy. This is the main attraction of microservices, each team can own their own piece of the code and change it and deploy it without (ideally) having to consult with anyone else.
* Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient
* Startup is growing users/revenue very fast, attracts big VC investment
* Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers
* There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before
* Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity
* Teams know that only predictability matters, so they start making really conservative estimates, just to be safe
* If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm
* Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates
You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.