The paradox of slowing down while growing
You might have been there yourself.
You start out in a small company and that very company has grown into a very big one over time. Things start to feel slow. And you wonder why. Or you are late with a project and need to add more workpower to it, so you get one or two people in. You think, can I still make it in time? Well, that depends.
Chances are, you will not be as fast as you think. And that’s barely news, in fact this has been observed as early as 1975 in software projects and been called Brooks’ Law:
Adding manpower to a late software project will make it later
The more people there are, the more complicated it gets. It’s that easy.
Why do we get slow, when we grow?
Whatever you work on, you won’t do it alone in most modern day working environments. And splitting work means more communication to be able to do it, no matter what fancy tools 2021 gave you at hand.
Have you ever thought about how many possible connections there are in a group of four people? Six. Now make that grow to six people and you already have fifteen possible connections. Okay. When I think about how many developers there were when I joined the company versus how many our Engineering department has now, we go from 190 to a 1225 possible interactions. Wow. That’s just the devs.
And the bad news is, is just doesn’t stop there. There will be more legacy code, there will be higher expectations of customers, you name it.
What can we do about it?
Unfortunately there is not much that can be done about it. The per head productivity will decrease in any growing company, so we simply have to accept that as a fact. But the good news is, you can learn to live with it.
Expose the hidden complexity, for example when sales is asking for a new feature explain the string of requirements and technical changes that would be necessary to deliver it.
Show the progress to remind everyone of the actual work that is being done and how it brings to the code base and business forward.
Develop software pragramatically by making pragmatic decisions and focusing on only adding value for the user and living boyscout principles to prevent or at least slow down technical debt.
We want it all
Sales people want it now! Product managers want all of the features! The engineers want to build it right!
In an ideal world, we would be able to satisfy all. But there is no such thing (yet?) and that’s where the tension starts to rise and decisions have to be made.
Scope
What are we going to do and how are we going to do it? This would typically entail to break the product or feature into smaller work packages like epics and stories that deliver value to the application and then prioritize them.
Resources
How many people do we need to get the work done? This is about the people that are interested to get involved and how many it would require to deliver this in…
Time
There will always be a deadline. One cannot change the time, but the magic trick is to work it with good prioritization, milestones, minimum viable products and the likes.
Current challenges at COYO
One of the biggest challenges we experience right now at COYO is the alignment of our product and technical roadmaps.
I personally imagine it like a good zipper. There comes a product epic from the left, here a technical one from the right. And swoosh! goes the zipper, creating seemless alignment between them and a strong bond. Ladies and gentleman, we now have a picture perfect roadmap, providing great new features to the users but also addressing necessary changes like migrations, updates and refactorings, essentially removing technical debt.
But the reality is more complex. Of course there are also needs from customer support and sales, we have an ever-growing QA team and increased focus on delivering a high quality product to an ever growing amount of customers.
We are victims of our own success, so to say.
But that will only motivate us even more to work on the current technical stand-out topics. Just to name a few, these are for example:
- Angular migration
- Modularization of our backend
- Moving to a different cloud provider
- Test automatisation
And referring back to the three boundaries I mentioned earlier:
We are somewhat flexible about the required time for these long-running topics. But we will never compromise on vision, execution and delivering the highest quality product possible.
That’s all, folks, thanks for your interest!
