The First 30 Days

The first four pieces looked at different reasons a small engineering team can struggle to ship. In practice, several can be present at once.

The system is difficult to change. Support questions keep interrupting the work. AI tools help people produce code faster, but more of it waits for the one engineer who knows enough to review it. The priorities may be clear, yet the work still takes longer than anyone expected.

Each earlier article described a way to investigate one of these problems and try an improvement over two weeks. Those efforts overlap. They draw on much of the same evidence, involve the same people, and may explain different parts of the same delay.

The first month brings them together. Use the first week to understand the main obstacles and choose a useful improvement. Deliver it in the second week. Use what you learn to plan the third, then review the results and the work ahead in the fourth.

The weekly commitment begins in week two. By the end of the month, the team has had a chance to try that rhythm and adjust it. Whether it is sustainable will take longer to establish.

In week one, start with recent work.

Choose a few changes the business needed and follow what happened to them. What was requested? What did the team build? Where did the work wait, and what happened after release?

Use the four earlier articles to guide the questions:

• Was the change harder than expected because of dependencies in the system?
• Did the work still address the customer or business problem that prompted it?
• How much time went to support, testing, incidents, or other requests?
• Could the team review and check the work at the rate it was being produced?

The tracker, code history, release records, and conversations with the team should provide an initial picture. A short record of how people spend their time can fill in work that never reached a ticket. If the information is incomplete, note what still needs checking.

The result should be a short account of the main delays, the evidence behind them, and what is worth trying first. Some teams will find one dominant problem. Others will find several that reinforce each other.

There is no need to wait until Friday to address an urgent problem. If routine requests are reaching every engineer, agree on a first contact and a backup. If changes are being released without enough checking, clarify the review arrangements and address the immediate gap. Record when you make these changes so you can distinguish what happened before and after them.

Before the week ends, choose one improvement with the people who need it. Agree on what someone should be able to do afterward, who will check it, and how much time the team can realistically give it. Include review, testing, support, and other known responsibilities in that estimate.

Week two is the first delivery cycle.

Make a modest commitment the team believes it can keep. It should describe a useful result in ordinary language: a customer can complete a particular payment, or an operations colleague no longer needs to copy an order between systems.

Reduce the scope until it is manageable while keeping that result intact. An invoice change might cover one customer type or one billing case. It may still involve several parts of the system. The important thing is that someone can use the completed change within the agreed scope.

Keep incoming requests visible and route them through the arrangements agreed in week one. The person handling them needs enough time and help to do that job. A rotation can protect other engineers' concentration, but the support work still has to be done.

As the change moves toward release, record what makes it difficult. Perhaps a reviewer needs context that isn't written down. A test environment takes too long to prepare. Several pieces of code have to change together. These observations help the team choose its next improvement.

At the end of the week, review what reached users and whether it worked as expected. If it didn't ship, examine what changed or was missed in the plan. Adjust the next commitment using that information.

Week three repeats the cycle and addresses an obstacle the team has now seen directly.

Choose the next useful piece of work based on the first delivery and the priorities agreed with the business. If a recurring obstacle needs attention, make room for fixing it within the week's commitment.

That might mean making a troublesome part of the code easier to change independently. It might mean documenting important behavior so another engineer can help review it, or automating a reliable check before release. The improvement itself takes time; it belongs in the plan alongside customer work.

Retire an old manual step when its replacement covers the need. A test or a short document may reduce dependence on one person, but the team should check that before changing the review process.

This is also a useful point to discuss work that needs dedicated attention. Bring together the time spent on support, testing, incidents, and review. Compare the current arrangement with options such as training, better tools, outside help, or a hire. Consider what requires particular experience and what the team can reasonably take on.

The purpose is to make a decision about the work that needs doing. The role, if one is needed, follows from that decision.

Week four is a chance to see what is becoming repeatable.

Continue making and reviewing a weekly commitment. Look at what the team finished, what interrupted it, and whether the changes helped the people using them. Check for problems introduced by recent releases as well as improvements in delivery time.

Some business results will take longer to show. Agree on when to check them. A feature being available and a customer benefiting from it are related, but they aren't the same observation.

Use the final days of the month to agree on the next month's priorities, the people responsible, and the time available. Keep an allowance for the work that was previously missing from the plan. Increase commitments cautiously as the team gains experience with this way of working.

By day thirty, I would aim for:

• A shared explanation of the main delays, with evidence the team recognizes.
• At least one useful improvement released, with an initial check of how it is working.
• Clearer arrangements for incoming requests, review, and release checks where those were causing problems.
• A record of the weekly commitments, what happened, and what the team changed as a result.
• An agreed next step for recurring work that needs more time, different skills, or additional people.

Those results give the next month a firmer starting point. They don't require every team to introduce the same technical changes or make the same hire.

During this first month, I would usually defer major changes such as a rewrite, a new platform, or a reorganization while the team gathers evidence. If an urgent reliability or security problem requires a different order, address it and adjust the plan. The same judgment applies to AI tools: keep the uses that help, and change or pause uses the team cannot yet check adequately.

This is how I approach the opening phase of a Team Turnaround engagement, which typically runs sixty to ninety days. The thirty-day review is a checkpoint where we decide what to continue, what still needs attention, and what the team can take forward itself.

I work alongside the team to understand the delays, help with reviews, and bring the workload into the conversation with the founder. Where useful, I help handle incoming requests so the team has time to work through an improvement. The people who will maintain the system are involved in deciding what changes.

The following weeks build on what worked: applying it to more of the product, addressing remaining weaknesses, and helping the engineering lead sustain the approach. Where ongoing technical leadership would be useful, a fractional CTO arrangement can follow.

The first month should leave the team with something useful delivered and a clearer understanding of what it takes to do that again. It gives the founder and engineers a concrete basis for the next conversation about priorities, staffing, and delivery dates.

If these patterns feel familiar, we can start by looking at one recent change and what kept it from reaching customers.