Busy Is Not Shipping

The founder says the team has stopped shipping. The engineers point to four features released last month, with demo recordings to prove it.

The team has finished work, but the problems people expected that work to solve are still there.

A chart of completed tickets won't explain the gap. It can show that the team is getting through work without showing whether customers can pay their invoices or operations can stop copying orders between systems. Hiring more engineers may increase the amount being built while leaving those questions unanswered.

Research on developer productivity supports taking a broader view. Nicole Forsgren and her coauthors argue that productivity extends beyond activity levels and cannot be captured by a single measure. A count of tickets or releases gives you only part of the picture. The SPACE of Developer Productivity.

Some valuable work will always be less visible. Maintenance, security fixes, and improvements to reliability deserve time even when there is little to show in a demo. The concern here is when the team keeps delivering and the needs everyone agreed were important keep waiting.

A new screen is easy to show on Friday. People can react to it, ask for changes, and mention it in an investor update. Fixing a billing error affecting four customers, or connecting the product to a warehouse system, may attract less attention. If most feedback happens in the demo, visible changes can gradually take more of the team's time.

The difficulty of the existing system matters too. As Part 1 discussed, a seemingly small change can involve several services and people. A new dashboard may be easier to finish than the billing change that prompted it. An admin panel can give someone another way to inspect an order while the steps needed to fulfill it remain manual.

Part 1 described changing how different parts of the software connect so they can be improved one at a time. With a new dashboard or admin screen, ask what someone will be able to do that they couldn't do before. Will it remove a workaround, or give them another place to manage it?

Unclear priorities leave more room for this drift. A roadmap might list screens and features without explaining what needs to improve: getting a customer started, taking payment, fulfilling an order, resolving a support request, or closing the books. The team then has to fill in the gaps using the information it has. Interesting ideas and work that looks achievable can become the plan by default.

The pattern I see most often starts with a team that used to have a clear connection to customers. Early on, the founder knew every customer and could explain why each request mattered. Then fundraising, sales, or the demands of a growing company took more of their attention. Nobody clearly took over the regular conversations and decisions that had guided the work.

From the founder's side, it can feel as though the team has changed. From the team's side, the context for choosing what to build has become harder to get.

Teresa Torres describes setting a team's intended result as a conversation in both directions: leaders bring business priorities, while the team brings customer and technical knowledge. Both are needed to decide what is worth pursuing. Shifting from Outputs to Outcomes.

When that connection weakens, the examples can be quite specific:

• The demo looks good, but operations still relies on a spreadsheet to finish the job.
• A dashboard, an admin panel, and a customer portal show different answers for the same order.
• An important integration has sat in the backlog for months without anyone assigned to it.
• "Let customers pay by invoice" becomes an invoice settings page, but customers still cannot complete the payment.
• Sales understands a feature to be ready, while engineering has finished only part of what a customer needs to use it.

These problems can exist alongside the complexity described in Part 1. A steady rate of completed tickets doesn't rule either one out.

To understand what's happening, I would spend the first week looking at five things:

1. Write down the main activities the business depends on. Start with five to eight, such as onboarding, billing, fulfillment, and support. For each, identify who understands how it works today, where people still need workarounds, and what engineering last changed. This gives the team and the rest of the business something concrete to discuss.

2. Connect recent work to those activities. Review the last sixty days of completed tickets and code changes. What was each piece intended to improve? Include maintenance and work that supports future changes. Where the connection is unclear, ask about it. Counting tickets alone won't tell you how much effort went into each area.

3. Look at the tools that handle the same information. Different people may need different views of a customer, order, or account. Check whether those tools agree, whether they duplicate the same rules, and what it takes to change them together. The number of screens matters less than the repeated work behind them.

4. Compare the request, the ticket, and the result. Take five important requests in the words of the person who made them. Find the related work and check what someone can actually do now. The original request may need refining, but the customer or business problem should remain clear as the team works out the solution.

5. Find out how priorities are decided. Who chooses what comes next, and how do those choices reach the people writing tickets? Ask what was deferred or declined, and why. If every request remains a priority, the team still has to make those choices somewhere, often without enough context.

Use that first week to choose one important process and agree on a useful improvement the team can reasonably deliver in the second week.

Start by describing the problem in ordinary language. "Customers need help completing setup" gives the team something to investigate. "Build a new onboarding screen" has already chosen an answer.

Agree on how you will tell whether the work helped. That might be fewer customers needing assistance or less time spent correcting invoices. Choose something the team can influence. Hope Gurion makes this distinction in her guidance on product outcomes: broad goals such as revenue need to be connected to observable changes in how people use the product. Product outcomes and business outcomes.

Name the person responsible for that part of the business and have them work with the team on the improvement. Put the problem, the intended result, and the way you'll check it in the existing tracker. If you don't yet have a useful measure, agree on what evidence you need to collect.

Then follow the change all the way through to use. For invoice payments, a first release might cover one customer type or one billing case. Within that scope, the customer should be able to receive and pay the invoice, and the person handling billing should be able to see that it was paid. Walk through it with the people who will use it and check again after release.

Before starting another screen or tool, ask whether it helps complete that process. It may be exactly what's needed. If an existing tool can do the job with a small change, use that. If the underlying system needs work, make that work part of the plan, using the clearer boundaries discussed in Part 1 where they help.

A product hire or a change in team structure may still be useful. You can begin this work while making those decisions. The immediate need is for people to agree on the problem, make room for it, and see a useful change through.

At the end of the two weeks, review both what shipped and what happened when people used it. Some results will take longer to show. Set a time to check those, and use what you've learned to decide the next change.

Next in the series: Where the Week Went.

Related service: Team Turnaround