Scaling Your Tech Team – Every Growth Stage Startup NEEDS this
You’ve found the product-market fit for your MVP. Your Startup has entered the Growth stage. Congratulations, you’ve almost made it.
How about your engineering team? Does it hold up to the rapidly growing customer base? It needs to grow too, perhaps not just as fast. You have to be smart about it.
Tech scaling can be a major headache. Panaxeo has worked with dozens of Growth Stage Startups and I want to share with you the lessons learned.
Use this knowledge to make your growth as smooth as possible.
01.
Switch to a Team Ownership Mindset
You’re probably tempted to scale your dev team right away. After all, they must catch up to the staggering and growing number of users. Not so fast!
You can’t scale a team that’s running on an MVP-based mentality. First, change the way your current dev team works and thinks.
Get rid of the Rock Star mindset
In the early stages of any Startup, Rock Star developers are a necessity. They know how to make difficult decisions and often have to invent and build stuff from the ground up. They naturally become the focal points of all the tech knowledge.
What was necessary in the early stages becomes a major hindrance in the growth stage.
Imagine this – your development team of three is carried by a single specialist who knows ABSOLUTELY EVERYTHING about the codebase, the processes, etc.
That specialist gets nicked by a headhunter.
The Rock Star is gone, and all the technical knowledge of your product vanishes with them.
Sure, I might be taking it too far here. But the point still stands. Plus, Rock Stars become bottlenecks. The team lacks information and is not empowered to make decisions without one key person.
Remember this when entering the growth stage and start sharing knowledge within the team early. Don’t fire the Rock Stars, though! They’ll help you in the next stretch.
Turn the Rock Stars into Dev Leads
A great way to build team-wide knowledge and foster team ownership is to have Dev Leads.
When creating an MVP, 2 or 3 highly skilled engineers are usually enough.
However, once you start scaling, expect an influx of newcomer engineers. Dev Leads can help them feel at home, get quickly acquainted with the tech, and feel a sense of ownership for their delivered work.
The good news is that you already have your amazing Dev Leads – it’s the Rock Star developers that have embraced the Team Ownership mindset.
That’s easier said than done, of course. The MVP is like their child, and nobody lets others do weird stuff to their children. It’s your job to ensure your Dev Leads understand why that’s vital for the company’s survival.
02.
Start Scaling
Has your current team’s mindset been dialed into Team Ownership? Great. Now is the time to grow your Startup into a Scale-up.
Body Shops vs. Development Partners
At this point, most Scale-ups grow so fast that they need to turn to external vendors to augment their engineering teams.
That’s okay. However, if you’re serious about sustainable growth, find a development partner and NOT a body shop. There is a time and place for body shops, but long-term engineering scaling is not it.
How can you tell the difference?
A body shop will give you a developer, and you’ll only hear from them again when it’s time to pay for the invoice.
A development partner will be familiar with the Team Ownership concept and will pour in their own expertise to help your team grow.
On top of that, they:
Fully manage the team they’re responsible for.
Keep adjusting the team’s structure optimal to your needs.
Build relationships and bridges.
Care about your customers’ well-being.
Are interested in your product and its roadmap.
Understand symbiosis.
8 Crucial First Steps
Once you’ve found your ideal development partner, establish healthy working relationships. This is how:
Draft a contract and a business agreement with your Development Partner.
Work together to decide on the right people your Scale-up needs at the moment.
Set up the communication process. A well-adjusted asynchronous communication is king.
Decide how you expect your partner to hand over any work outputs.
Get to work. Tweak processes on the go as required.
Expect 2–6 weeks for everything to fall into place.
Act on the first increment. Review the processes and implement necessary changes.
Give your partner some leeway in decisions about the team’s setup and how it operates. Your partner knows the people they work with the best. It’s also in their best interest to make this partnership work because a good development partner will always look for long-term relationships.
At this point, the cooperation should be running like a well-oiled machine. You must keep up the pace and keep communicating with your development partner!
03.
Set up a Solid Communications Structure
It’s useful to work with Scrum from the get-go. It lets you put new releases to the test regularly, and it provides an inherent meeting structure designed to remove obstacles in development.
Time Zone Differences
Your Development Partner will often be in a very different time zone. The best approach is to have them provide you with a full Scrum Team or two. Have the teams communicate with you as the Product Owner.
Integrating separate developers into your in-house Scrum Teams across time zones fails 90% of the time. Somebody is bound to feel left out, not to mention the inevitable conflict of cultural/sociological backgrounds.
Master Asynchronous Communication
The concept is very easy: When you need something, send a message and wait.
Don’t expect an instant reply. Don’t expect them to leave everything they were doing and immediately turn to your request.
Don’t force anyone into instant replies. That’s just needless pressure.
As I said, the concept is easy, but applying it is hard. It just needs a bit of practice.
Fixed Meetings Are For the Developers
They should help identify and move past obstacles. That’s it.
They are NOT status reports for the managers; keep that in mind. That’s what the sprint review is for.
So, aim for as few fixed meetings per week as possible. Ideally, only stick to the necessities – Daily Scrums, Retrospectives, Sprint Plannings. Ad hoc meetings are fine.
You see, it’s easy for fixed meetings to creep up on you, and your developers quickly end up in nightmare scenarios. Imagine them spending 40% of their time in meetings. That’s tons of context switching. Context switching kills productivity.
Switch to asynchronous communication instead. That means sending a message and doing something useful, not waiting for an immediate response. It needs a bit of planning, but it’s doable.
How do you retain a sense of control with so few meetings?
I believe a sense of being informed is enough. To achieve that, I combine meeting outputs with outputs from the tools we use.
Let’s say I want to know what’s been built. First, I look into Jira, then GitHub. If I feel something should’ve been done differently, as a last resort, I ask the engineer for more information, forcing them to switch contexts.
Additionally, since engineers know that I regularly check Jira and GitHub, they keep it well-maintained and up-to-date.
When informed, I can react to both the customer’s and the dev team’s questions. That’s enough for me; there's no need to feel in control.
04.
The Right Tools for the Job
Jira/Asana/Trello, etc. In my opinion, when scaling your dev team, they all serve three main purposes:
Order
Efficiency
Visibility
Order
These tools will help you and your team understand what you’re currently working on, what the deadline is, and what inputs you need to consider.
It’s also a time machine to the past so that you understand why you did that particular thing in this particular way back then.
Efficiency
These tools are meant for asynchronous communication. In an ideal world, they are also relatively easy to use.
People sometimes complain about Jira. But try sticking PostIt notes to the wall and sending a photo of that wall back and forth. Jira is much more efficient.
Visibility
If your Jira is well managed, your managers don’t need to bother anyone – they know precisely what the developers are doing.
Developers, on the other hand, see what other developers are currently working on.
All of them together get to manage dependencies, priorities, and expectations. Asynchronously.
It’s almost magical.
05.
Wrapping It All Up
It’s a lot to keep in mind, isn’t it? This is just to get your team ready for scaling, and we haven’t even touched upon Code Quality! You’ll have to scale that, too.
Don’t worry, though. With the correct mindset and proper preparation, you’ll be ready to enter the growth stage and start making money.
Here’s a checklist of what your dev team needs when becoming a Growth Stage Startup:
Switch to a Team Ownership mindset.
Turn your Rock Star developers into Dev Leads.
Find a good Development Partner and set up your cooperation.
Learn about asynchronous communication and master it. (This is important!)
Aim for as few fixed meetings as possible.
Get the right tools for the job (Jira, Asana, Trello, GitHub, etc.)
Good luck! And if you’re wondering how to scale your team right or how to dial in your Scrum setup, shoot me a message.
Igor Liška
Co-Founder/Co-CEO
Let’s connect on LinkedIn →
I like building software just as much as I like building Legos.
Throughout the 14+ years of my engineering career, I’ve been a developer, an architect, a manager… Right now, I’m the Co-CEO of Panaxeo – the kind of company I’d always wanted to work for but couldn’t find any like it.
