“We used to deliver more when we were smaller”
No matter who you are or where you are in the team, this hurts. It hits you hard in the gut and triggers the introspection that forces you to look at the why in how you got to where you are today.
In working with software teams over the years I’ve generally found it boils down to a few inconsistent “growth strategies” that inevitably serve to stagnate growth rather than encourage when applied incorrectly.
As teams grow quickly in the early days, the quick wins that can help a team become more efficient are easy to spot and can be addressed with a few small changes.
It’s when we take these small changes and apply them to a grandeur approach of thinking that we hurt ourselves.
For example – “Jay is always missing the steps that Hannah does in packaging up the build. Let’s go buy a tool to automate this whole process to stop Jay from doing it wrong.”
The first part is good – Identification of the Problem – the follow up is the wrong step as it seeks to solve that problem with the purchase of a tool that might solve your problem but also might introduce some unneeded complexity into your environment.
So what do you do?
Build it, yes, build the goofy little console app that you need, take two days and build it if you think it will save you five. Get Hannah involved and have her duplicate her perfect processes into a script that the rest of the team can use. If it can’t be built, look at the cost of having Hannah prepare for and run a meeting outlining what everyone should be doing as part of that process.
When you are growing, you don’t need the fancy dashboards and reports, what you need are the hacked little apps that get you over Hump A and into Promised Land B. If you can’t build it, the act of Hannah preparing for and running the meeting will allow her to spread her leadership wings while also infusing the team with a sense of ownership and accountability that they must work together to be a success. As longs it’s not a thirty-eight step plan, they should be able to do this.
And therein starts the seeds of foundation that will kickstart your team’s culture.
Start small, prove out what you need, iterate and move on.
Know thy MVP, Don’t Assume One
One of the main reasons that projects can take longer to complete is a psychological one rooted within us all but often ignored. When a team knows what they are delivering, what the vision behind the delivery is and what the end goal is – their productivity will instantly jump as they know the destination.
When you are small, everyone shares in this understanding as they all sit elbow-to-elbow from each other. Everyone is privvy to all the details and know where the company is headed. But as the company grows, so do their goals and perhaps their vision evolves to include more objectives then previously defined that everyone no longer knows all about.
If you’re wavering on this, think about when you are on a long car ride. When you know what the end destination is, how long it will take to get there and approximately when you’ll arrive – you’ll have your music and podcasts laid out, you’ll know when you’re stopping and how much time you can stop for and invariably you’ll push to get there sooner because you know your MVP.
But if you don’t know where you are going to end up – what’s the rush? You’ll get there eventually, no one has told you that the hotel might not be open or the theme park might be closed.
The Leader on your team emerges by defining the team’s MVP (Minimum Viable Product) for the current release, deconstructing the minimum criteria to deliver the product and rallying the team around that delivery to align with the company’s vision and goals.
As teams grow, one of the worst assumptions that can be made is for Managers to assume that the team “must know” the end goal, because they have “been here” for so long, “how could they not” know the end goal.
They don’t, they won’t until you align them to it.
Sometimes you need to Add more Memory
When doing performance tuning, you’re always looking at the code to see how it can be made more efficient, how the threads can be better optimized, the packets made smaller, the execution plans better aligned. It never ends as you try to squeeze every last iota of performance goodness out of your code like juice from an orange.
But sometimes, the server simply needs more memory, you’ve done everything you can and now it’s time to add more capacity.
Same with your team, teams stagnate because the workload to team ratio hasn’t been kept up. Customers have grown, complexity has increased, but the team hasn’t kept pace to meet the demand. Or even worst, you’ve kept the same leadership and team structure whilst hiring and hiring new team members and assigning them to the same groups.
Like adding memory to a server, you constantly need to be re-evaluating your team structure with each new hire by asking yourself the following questions.
Will we need to break out teams if we need to hire one more person?
Who should we start training to take on that role or do we need to look elsewhere?
How are my current leads doing with this added pressure?
And just like adding memory to a server, sometimes you simply need a new server.
The goal is to never use the following phrase – “We used to deliver more when we were smaller”, the achievement of that goal is accomplished by not overcomplicating your processes, ensuring everyone knows what they are focused on and always re-evaluating your internal leadership and team structure with each new hire so you properly scale as you grow and not slow down as a result of trying to grow.