Building an Effective Team and Culture: Lessons from Taking a Tech Function In-House
When I joined Wagonex as Head of Engineering in January 2023, I walked into an unusual situation. The company had been around since 2016, running a B2B2C platform that lets dealerships and manufacturers offer vehicle subscriptions, alongside its own marketplace, Wagonex.com. But the entire tech function (roadmap, technical approach, standards, deployments) was run by an external agency.
In 2022, Admiral Pioneer invested, and with that came the ambition to scale. Scaling meant bringing technology in-house. My job was to make that happen without breaking what already existed.
This is what I learned along the way.
Know your starting point
Before changing anything, I needed to understand where we were. That meant learning each person’s strengths, how the external team worked, and, most importantly, the codebase.
It didn’t take long to see the problems. The team had a very particular way of building, and it wasn’t elegant. The data model got more confusing the longer you looked at it. Pipelines were constantly blocked by the processes in place. The business wanted to scale, the investors wanted to scale, and the codebase simply wouldn’t let us.
Something had to change.
Getting buy-in
Several of the external engineers had been on the project since day one. I was the new kid on the block, and I was about to disrupt everything they’d been doing. Before I could build an internal team capable of transforming the platform, I had to earn the trust of the team already there and show them I could build for scale.
Starting with a pause
The first move - a month-long code freeze.
It gave me room to find my feet in a new organisation, managing a fully remote team in a different time zone. More importantly, it let us bring the external team into the process. If they understood why things needed to change, they’d be far more likely to support it. Both myself, Wagonex’s Head of Product and the external team reviewed everything together, looking for ways to improve the platform one small step at a time.
James Clear makes the point well in Atomic Habits: improve by 1% every day for a year and you end up roughly 37 times better.
This was the mindset.
Expect pushback (a lot of it)
The external team was used to doing things their way, and I was asking them to think differently and think bigger. The biggest sticking point was moving from trunk-based development to Git Flow.
Feature branches and pull requests were new to them, and they were trying to find problems with the new process before it had even been rolled out.
So, I stopped debating and started coding. I rewrote an area of the platform using the new standards, architecture and process.
This helped show them what I could do technically, and more importantly, how the new way of working would benefit both them and product development.
Lock in the foundations
With buy-in starting to build, the next challenge was making sure the new standards stuck. I had about eight to ten weeks working solely with the external team before anyone internal joined, so the foundations had to be in place by then.
We set up CI/CD pipelines to check coding standards, style and tests, and added branch restrictions so nothing merged into develop without an approved pull request.
Even so, with me in Cardiff and the team in India, I had to trust them, the way they were learning to trust me.
This was the first offshore remote team I’d managed, and it wasn’t easy.
Things slipped through the cracks.
But over time, they started to see the benefits.
Building the internal team slowly
My approach to hiring was slow and steady. We deliberately recruited locally for the first internal team.
It narrowed the candidate pool, but we wanted a team that could collaborate closely in the office.
We also knew onboarding would take time and that we needed to absorb as much knowledge from the external team as we could.
Getting the internal and external teams to work together was its own challenge.
The time difference created a lot of disconnect.
Tuckman’s stages in practice
Whenever I am building a team, I always think about Tuckman’s stages of group development.
These are:
Forming - We hired for willingness to learn as much as for skills, and made sure people were right for a startup and that a startup was right for them.
Storming - Honestly, the code behind the product wasn’t great, and that caused friction between the teams’ approaches.
A lot of time and energy went into just understanding the existing codebase and data model.
Eventually it was clear we had to rebuild.
Norming - The more we rebuilt, the more performance took off.
The new architecture and processes let us deliver features on time, and collaboration between the teams grew stronger.
Performing - By the time I gave this talk, we were starting to reach this stage: a well-functioning team that understood each other’s strengths and weaknesses and shipped better code, faster.
One lesson stood out.
Every new team member is a new variable that can knock you back a stage, and the same is true when people leave.
We found that each new internal engineer let us remove two externals.
By the end of 2023, we’d gone from twelve external staff to a fully internal function of four engineers.
I worried that losing the external team entirely would throw us back into storming.
It didn’t.
The internal team was invested in the product and the company, and that commitment is what made them high performing.
My three non-negotiables
There are three things I look for in anyone who works with me, and that I hold myself to:
- Ownership - Own your work, your mistakes and the expectations you set. Don’t be afraid to get things wrong.
- Communication - If you say you’ll do something, do it. Under-promise and over-deliver, and if you’re struggling, speak up so we can tackle it together.
- Trust - Without trust, you’re just a group of people. Trust is what makes you a team.
We win as a team and fail as a team.
There’s no blame, just lessons.
Seven ways to build a strong team culture
To wrap up, these are the seven things I believe create a strong, positive culture:
- Define clear values and a vision. My three non-negotiables are the values I try to live by and instil in others.
- Lead by example. Roll up your sleeves and get stuck in when needed.
- Keep communication open. It’s vital to any project and to any successful team.
- Promote collaboration. We’re all working towards the same goal, so work together rather than in silos.
- Empower people. Trust your team to make decisions and be there to support them when they need it.
- Set clear roles and responsibilities. Everyone has strengths and areas to grow, so lean on those strengths when you hit blockers.
- Review and improve regularly. What works today might not work tomorrow. For us, sprint retrospectives were where that happened.
If you’d like to talk about building teams, feel free to connect with me on LinkedIn.