When, and how to change your apps team
Today’s video is aimed at founders who are frustrated with their development team. There are a number of things that can go wrong with a software project, let’s start with some high level categories:
The first is executional problems, where the team is missing deadlines or delivering low quality work. There are a lot of things that could be going on there and we’ll break that down in a moment.
The other type of problem is relationship issues and a deterioration of trust between you and the team. I’ll go over some blind spots for both founders and engineering teams, and see if we can get to the end of this video with a clearer idea of what you might be struggling with. See you on the other side.
The productivity curve
OK, first - executional problems. Let’s think of our app as a tower of blocks, building towards a target in the sky. Each block is something your engineers need to build to reach your goal. So let’s talk about how productivity changes over the course of building this tower.
When we first start putting down blocks, writing those first functions and features of our app, the complexity of how to place your blocks tends to be trivial. There’s not much for that code to interact with, so reasoning about it is easy. As we add more blocks to the tower, the shape and position of those blocks increasingly depends on the strength, robustness and position of the blocks below. That means the same quantity of software tends to be delivered slower in mature projects compared to when they start, because the more complex the system, the harder it is to reason about it, and the longer it takes to change it safely.
Here’s how this looks on a graph. You can see at the beginning we have stable high productivity, during that period when we’re just laying our foundation and it’s easy to reason about the work. Then velocity gradually drops as the complexity of adding code increases. Eventually the project should reach a point where making changes is always round about the same level of complexity, and output stabilizes. The level it stabilizes at depends on how thoughtful your development team has been about their software architecture.
This can be a blind spot for founders. It can feel like work is slowing down and it’s hard to understand why if your apps team hasn’t done a great job of setting expectations. If progress is slowing down, what you need to assess is whether output is stabilizing at a healthy level given the complexity of the work, or if your team is simply out of their depth and their net productivity is unacceptable.
To figure that out, let’s come back to our tower. We’re aiming for the target, the target’s in the clouds, we’re not on track to hit it. What’s happening?
Possibility 1: You built too fast
Maybe your team didn’t lay foundation well early on, and they’re just using a minimum number of blocks to get as high as they can as fast as possible. This feels good early on to everyone, but the poor foundation ultimately limits how high you can build.
If your team hit or beat their early milestones, and are consistently missing their later ones, that can be a sign that this is happening, especially if the level of experience on the team is generally low.
Or it might be happening because expectations weren’t set right early on - the development team underestimated the work so now they’re rushing to finish on time and budget.
An app that is rushed early on can become a money pit later because the whole thing has become fragile. Changes to the foundational early work leads to whack-a-mole for bugs, and there’s a decent chance that the rushed work will just have to be thrown out and rebuilt.
If you’re in this situation, the best thing to do is find someone you trust and get them access to the code. An experienced engineer should be able to take a look at the project and get a sense of what shortcuts are being taken, or where your apps team may be over complicating the work and getting bogged down in that complexity.
If that second opinion comes back fairly positive, then you may just be on the downslope of that productivity curve.
Possibility 2: Poorly understood target
Another possibility is that your target isn’t well understood. If you aren’t building in the right direction and need to course correct, there’s a cost to that and it can manifest as slower progress or a buggier app.
Or maybe it’s that your priorities are poorly understood. How confident are you that everyone in your team understands not just what they’re building, but why they’re building it, and who they’re building for. These sorts of problems are more likely to happen with offshore teams where cultural values and communication styles differ.
Your job as a founder is to clearly communicate the business goals of the work, and it’s your app team’s job to translate those business goals into actionable tasks for the team. It’s not enough to just describe the app you want - your team should understand clearly who the users are. Some companies create fictional users with names and back stories, regardless of how you do it, try to make sure your team really gets who they’re building this for and why.
Possibility 3: Poor cross-team communication
Another thing to watch out for is how your different sub-teams are making decisions. If your back end, web and apps teams are communicating poorly with each other, that might lead to one team making changes that have a high impact on another team’s work. For example your back end team might decide to change how a customer is represented in the database, which might be trivial on their end, but lead to substantial changes throughout your apps.
Having one person responsible for overall technical efficiency across the teams, whether that’s a CTO or a technical project manager, can help mitigate these problems.
4: Bad early decisions
Sometimes your early choices of technology limit your ability to progress. This can be a really frustrating scenario if you’ve made a bold technical commitment like a hybrid framework and it’s often hard to recover from. Try to make sure that the technologies used have been around for a while, are being chosen for more than just their shiny newness, and make sure they’re widely used with apps that you’d be proud to call your own. Again, having someone you trust be the technical liaison between the business goals and the technical team is important here.
Transitioning to a new team
OK things aren’t going well, you’re frustrated, and you’ve decided that something needs to change.
Your big decision is going to be whether or not to keep your existing team. Switching teams is expensive, because software projects are complex and it takes a long time before a new team is ramped up on the code base. Often weeks or months. This means two things: 1) try to keep your team if you think they’re capable of the work and still motivated. And 2) Try not to burn bridges if you do change teams. It’s so much easier for the incoming team if they can ask the original engineers how things work. You’ll save money and time if you can hold on to that relationship.
Managing the transition
In the codebase the new team inherits, they need to put everything into four buckets:
- What works well
- What remains to be done
- What need to be thrown out
- What can be lived with for now
Because understanding someone else’s code is time consuming, difficult, and less fun than building new things, engineering teams tend to have a bias towards throwing work out before they understand it. That’s wasteful, so during the transition it’s important you let the new team evaluate and understand the work done so far.
If you’ve preserved the relationship with the original apps team, one approach is to have the new team assess the state of the project, prepare a plan for what needs to get done, and then hold a meeting with you and the original team on the same call. The original team has an incentive to defend existing work that can counterbalance the tendency to rebuild things that are hard to understand. That tension between the old team and the new team is a useful tool for figuring out what truly needs to get done which is why it’s so useful to preserve that relationship.
If you’ve come this far, then you are probably in this situation, and I’m sorry if that’s the case it’s not a fun place to be. Reach out to me if you’re still having trouble figuring it all out, and good luck.
