You need skills and vision, not quantity
This article is flow of thoughts recap based on long-term observations. No scientific facts included.
I will risk the opinion that common reason of organization failure is overgrowth. I saw it many times and suffered consequences of much too fast growth myself. It is visible in many places around us. I remember a story once told by Grzegorz Miecugow, journalist of Polish mainstream private television channel TVN when he remembered reporting a story together only with his camera man, when in the same time public TV team came with about 50 people for the same report. In perspective of time, the private station grew to serious competitor thriving, when public station TVP struggle to keep the audience and manage costs.
In three projects I joined over the years we also experienced overgrowth. It was caused by “need” to solve urgent demand. The problem was that no one had idea or experience around managing teams with such growing scale. First projects had no access yet to properly established agile techniques, second lacked transparency between levels and third was force-scaled to fight the fire (when everyone suggested regrouping).
Anyhow, I would like to recollect positive example. I could refer to some studies saying that growing team by every person adds complexity in management. Bigger teams are unmanageable and had to be divided, then overlooked by the layer above (still saw better solutions, i.e. in Facebook when teams are self-managing to extreme). But that is knowledge repeated all over case studies and I would just bore everyone to death. No, I want some great example of fewer means more in terms of team size.
In recent years I landed in very senior development environment. Established in a well managed company, with history and good practice implemented. Our department created, implemented and managed content management platform used by the main business. Well tuned, an oiled and tweaked team with amazing skills onboard. DevOps team in size of 6 tops had control over huge infrastructure just by using good tools and constant learning and validation. But they weren’t the biggest superstars (although they were the stars too).
There were two internal and one external chain of development. External combined people from all around the world to make a cutting-edge platform that should replace all other. Second were small, lean teams working on custom baked solutions tailored for a specific business case. The third chain was one shy guy, with one intern and up to two contractors to help to make very robust, clean and simplified implementation, heavily using open source but putting much effort to make it stable, tested and up to highest standards.
Long story short: external teams spent months, if not years to agree what they do and deliver anything usable. Custom teams managed to help their departments but still were quite slow in improvements. In the end, standalone hero took over the vast majority of cases and even recently (checking what’s up there) I saw it took control over part of custom ones. He was most successful of all and managed to save loads of fuss and money. Why?
He had very limited resources, so he focused only on what’s actually important (based on data, not assumptions).
He had a small team that was easy to manage, look after and train.
He didn’t reinvent the wheel, he just polished it.
He focused on making things work, not making things cool to work at (what happens often when you have way too big crowd to discuss the case).
I really appreciate this example and use as motivation for myself. When I work on own projects (where most of them fail, but as I’m learning with each of them, one may at some point workout)
I focus on what I CAN do in specific time, what EXISTING problem I have to solve and how to make it RUN so I can verify my thesis. Nothing more.
I will have time to scale it up if it goes. If not, I can learn and move forward.
But still some would hire dozens of developers just to fire them once the money runs out…
Just a random thought.
