Having worked in many industries, usually in some kind of 'project' based business, I have learnt one key thing; the bigger the team the worse they will perform. In this vlog I look at the reasons behind this and why a smaller app dev team is going to be the best choice for your project...
Full video transcript
I have worked on 100s of projects in my career… Including theatrical productions, corporate events, community events and obviously software projects.
One key thing I have learnt over the last 25 years is that it’s not the size of the project that causes issues during delivery, but the size and makeup of the core delivery team which dictates how the project is going to go…
For example, when I was in my late teens I worked as a waiter at a restaurant (which was a crazy idea as I am clumsy and forgetful…).
When I first started there were about 5 new staff (myself included) and we were in on a Saturday which turned out to be unusually busy - within 5 minutes I was in the ‘weeds’ (overwhelmed and didn’t know what I was doing) things quickly turned to chaos as the green staff forgot orders, spilled coke and were left weeping quietly in the corner looking pathetic in their soggy branded apron.
Thankfully, the manger on duty that day knew his stuff and did not waste time sending the junior team home (or to the kitchens to help with the washing up) and using a smaller but vastly more experienced contingent of the team to run the restaurant on that super busy day.
And it was the right call - they had a bumper day with loads of happy customers. Sure the team that was asked to take on twice the work was tired, but they kicked arse and took names.
And this is pretty much always the way of things. Use a small handful of skilled and motivated people who work amazingly well together, The A Team, and you will achieve significantly more than a much larger team.
And there is an important note here - a larger team would still be worse even if it included that core A team. If you add good or average personnel to an outstanding team you will reduce it’s efficiency and not add hinder its output.
In fact put too many outstanding people into a team and a strange dumbing down occurs… your reach a critical mass and all of a sudden your stella performers start to look average due to inefficiency.
Fast forward to my days in theatre when I did everything working as a stage hand, carpenter, crew chief and automation designer (it turned out was much better suited to my skillsets and my general campness) Fast forward to this time and the same pattern emerged with some telling differences.
When you are doing the set up Miss Saigon and need to unload four articulated trucks - for this a huge team of burley and eager ‘humpers’ works a treat.
The simple macro task of getting stuff from A to B can absolutely be done by a giant team, providing it is being overseen by the core A team.
But the macro task has to be simple, predefined with few variables and small chance that there can be a problem.
When you come to set it all up and get ready to drop a helicopter? When you are ready to do the tricky stuff which needs to be done in a certain order, with a certain amount of control and thought?
That’s when you send the humpers home, switch to the core ‘A’ team to get shizzle done. This team was super skilled in their speciality (lighting, sound, set building, organising, shouting ‘mind your backs!, ho there’, ‘back that thing up you muppet you’re gonna crush Brandon’).
The key characteristics of this team will be intelligence, the ability to problem solve, works amazingly well together and a work ethic which is second to none.
With this A team you can move mountains. Actually humpers would be better for moving mountains - this small A team can build mountains out of champagne flutes and fish forks.
Fast forward again and I see the same things in software. I have worked on projects with budgets of a few thousand pounds to millions - with a team of me, a designer and a developer to multiple teams across a broad skill set and more stakeholders than you can wave a fiery stick at.
What I have seen time and time again is that when the teams are smaller and focused, both smaller and larger projects are much more successful.
I have worked with Blue Chip companies which cannot get out of their own way, that are hamstrung by their own processes, that have chosen large development partners who are inflexible and slow and whose output can be poor because not all of their staff are stella.
When you are sitting in on one of those big ‘project meetings’ which make you want to top yourself, you can tell the folks who ‘get it’ they’re the ones catching each other’s eye and silently communicating ‘shall we catch up after this and sort this sucka out?’.
Then you have your peripheral conversations where the real decisions get made and you decide how the A team can offset the incompetence, the inflexibility, glacial slowness of the others involved.
The problem is in this situation, the A Team has no freedom and it’s influence on the project is severely hampered
The worry is often that this somewhat Rambo / Maverick approach will compromise security or due diligence or in some way upset some regulator somewhere. But this is nonsense, building well architected, well thought through secure systems does not take an army, in fact you are more likely to have holes in your solution of you have 100s of individuals burrowing away at it!!
It’s in the news all the time, massive monolith projects running late, spectacularly over budget and ultimately blowing up in a very public way… I promise you, your carefully selected A team will get the job done far more effectively than the mediocre masses.
We here at Compsoft Creative are an A Team and can really help you out with your project, so do get in touch.
Got a project? Let's work together
Compsoft is a remote working company except for Thursdays when we work together from the Alton Maltings in Alton, Hampshire (UK). Our registered address is detailed below. We'd be delighted to have either a virtual chat with you or to make arrangements to meet in person.