Transitioning from startup development-mode to iterating a software product

Building a new product likely means you’re building as quickly and as scrappily as possible to get to market. For a web app this is usually a short push of 2-4 months and If you’re successful you now have a product that needs to transition to a more sustainable style of development.

Here are some of the things I’ve observed or implemented to make this transition deliberately. Hopefully there are some things here you can use to prepare yourself for transitioning your next successful project!

The team needs to decompress

With any MVP or initial build there’s never enough time to get the level of fidelity you want. When an engaged team with high standards faces this problem they tend to work a bit harder to complete the work to their high standard.

In software this is called the “crunch”. Crunch varies in intensity for different orgs and projects. Crunch is usually used to refer to a management dictated crunch but in my experience there is usually an self-driven crunch in all highly engaged teams that happens with no direct management pressure. Great people will want to do great work irrespective of time constraints.

Either way, crunch is an undesirable state and you want to keep it as short as possible. If you can avoid it completely you should but that’s unlikely to happen.

If we assume that there has been some crunch by your team to get a product out then you need to let them decompress now.

You have to talk about this change and normalise it. Remember that it’s difficult for a high performing team to go from working intensely back to a more sustainable pace. Empathise with your team here, they probably feel like they’re suddenly not doing “enough”!

As a guideline it will take at least half the time again that was spent in crunch to normalise the usual pace again.

Revisit and reiterate the why with your team

Now that the MVP is in the market and you are learning from real customers it’s important to go back to the original hypothesis and measure the effectiveness of your solution. It’s very likely you had an incorrect hypothesis at this stage but that is normal and what you do have is a successful learning.

When you have a new direction or focus for the product make sure you share that with the team! Share it regularity and consistently. The team have likely been running with a mission of “get what we promised done on time”. This is only useful in the short term. You need to get the team behind a genuine mission that they are passionate about to maintain engagement.

Encourage cleanup and tidy up of the existing work

With an MVP but you actually want to take on a certain amount technical debt. This is healthy debt like a mortgage or a business loan that provides capital so you can reach the next level. It needs to be managed but it will be present in your MVP.

Specifically spend some time reassessing the technical debt you took on and align it with the new “why”, the new goal for the product. There are likely parts that the development team feel uncomfortable about and these are great little projects to let the team decompress with.

In particular look for things that affect everyone on the development team. Some examples might be rebuilding the CI CD pipeline for the next phase of a project or growing automated test coverage around tricky parts of the system that were skipped over in the rush to market.

These kinds of technical debt paybacks will amplify the productivity of every team member for the rest of the product’s lifetime and act as a solid hedge against technical debt that isn’t worth looking at yet.

Change the focus from pure output or “tickets per week”

Again, it’s likely that the team has been running to get “everything done on time”. This is a very functional output focus that is useful for a crunch type situation but it’s not good in the longer term. You want to work at changing this focus on output to the ancillary things that are important for maintaining a software product.

It’s likely that you want to re-emphasise non-functional things like quality and performance in order to balance functional and non-functional output in a team that has been focused on functional only.

Even for the functional improvements you will be making to the product you should match them back to the “why” and start there and focus on solving those problems rather than ticket throughput. Move the discussion away from working hard to working smart.

Audit your processes

The processes and norms that have developed in the team might not be suitable for longer-term success. The process used by a project team should be relevant to the factors associated with the team and the project.

If the team was building something new before then they probably need a different process if they are iterating on an existing project.

Just as an example you probably had very short time to make decisions about anything in the crunch time. So you had short meetings to make decisions or even just one person making decisions on the fly and you went with it. This is fantastic for momentum.

If you want to have higher quality decision making you might want to get more deliberate and collaborative. This could just be longer meetings with a wider set of people and knowledge available but could also extend to writing up the problems and potential solutions in a wiki document. Then sending this document out to the team to give them time to think things through before getting together around a white board.

You have time now, and although you want to maintain decision speed there are probably some topics where you would get great input and higher quality outcomes by including the entire team in decisions.

You should pay serious attention to the items discussed in retrospectives. For each item analyse the impact on the team. Identify the things that affect the entire team rather than one person and focus on those. Don’t ignore things affecting one person but for the purposes of this article just focus on the items with wider impact.

Any highly performing team should have a process for continually improving on their processes. The product and the team will always change so the processes must change with them. It’s important to show that based on retro feedback there can be genuine effort in trying new things so that there is a way out of the crunch or any other undesirable situation. Show that the team has power to change things.

Keep improving

This isn’t a once off thing to focus on. Any team and even individual team-members will bounce between “crunches”. But you should be particularly aware of this transition for greenfield projects and MVP-type projects moving into a long term development process! Good luck!

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨

Read more articles like this one...

List of article summaries


Flexible work is here to stay but you should choose an emphasis

Note: This was written in August 2022 and I assume things will change quickly. It will be interesting to look back in a couple of years to see how much of this article is still relevant!

Most tech organisations were forced to change to remote during lockdown but haven’t explicitly changed their office attendance policy.


Hiring engineers in a candidate-driven marketplace

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!


How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.


Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.