Where the Week Went

Six engineers, a full week, and very little progress on the features everyone agreed were important.

The checks from Part 1 don't reveal an obvious explanation. Changes stay reasonably contained, the team understands the system, and releases are predictable. The priorities from Part 2 are clear too. Yet when you ask what happened this week, each engineer can describe a full schedule of work and almost no time for the planned changes.

The hours went to customer support, testing releases, handling incidents, joining sales calls, and preparing data for a business deadline.

All of that work matters. It also needs room in the week. When the company plans as though engineers have none of those responsibilities, the delivery dates become difficult to believe.

In a small company, sharing these jobs can work well. The engineer who wrote the code may be the best person to explain it to a customer or investigate a problem. There are few requests, the context is fresh, and everyone learns from the contact with customers.

Then the business grows. An arrangement that worked with forty customers may be much harder to sustain with four hundred. The team has added a couple of engineers, but the questions, release checks, and incidents have grown faster.

Each responsibility has a reasonable explanation for staying where it is.

"Engineers should own quality." They should care about what they release. Testing still needs time, tools, and someone responsible for making sure it happens. That may involve a dedicated tester, better automation, or clearer responsibilities within the team.

"Everyone does support here." That can keep the team close to customers. It can also turn the engineer who answers fastest into the person everyone asks, especially once customers and colleagues know their name.

"We're too small for someone dedicated to keeping the service running." Perhaps. But someone still needs to respond when it fails, with the knowledge and backup to do so.

Other responsibilities never had a staffing discussion. A sales demo needed technical help. A customer needed someone to walk them through setup. The founder needed figures for Thursday's board presentation. Each request arrived as a message and looked manageable on its own.

Much of this work may never reach the tracker. Support is in Slack, release checks happen between other tasks, and the request for data is in a private message. At the end of the week, the feature is late, but the work that displaced it is scattered across several places.

The disruption matters as well as the time. A twenty-minute support question means putting down one problem, working through another, and finding your place again. A day full of short requests can leave very little uninterrupted time for a difficult change.

In a laboratory study, Gloria Mark and her colleagues found that people worked faster on an email task when interrupted, but reported more stress, frustration, and effort. That helps explain why a busy day can feel so draining, even when the requests get answered. The Cost of Interrupted Work.

This can be hard to recognize when the founder remembers doing all these jobs personally. The early arrangement may have served the company well. It needs revisiting as the volume changes, even if nobody has stopped to ask for a different one.

A few signs are worth looking for:

• The engineer assigned to a feature is also answering support questions, responding to alerts, and joining sales demos.
• An experienced engineer has become the default person for customer problems, leaving little time for the work they were hired to lead.
• Customers regularly find problems the team wishes it had caught before release.
• Plans assume most of the week is available, while the explanation for unfinished work is repeatedly "got pulled onto something."
• People say they want more time to build or improve the system, but their week keeps filling with immediate requests.

I would start with a short record of how the team actually spends its time. Five days is enough for an initial picture, though an unusually busy or quiet week may need a longer look.

1. Record the work in rough categories. Use feature work, bug fixes, support and customer questions, testing and release checks, incidents and infrastructure, and other work such as demos, data requests, and meetings. A few minutes at the end of each day, with estimates to the nearest half hour, is enough to start. I've seen teams where features and bug fixes accounted for only about a quarter of the week. The useful comparison is with what the plan assumed was available.

2. Note where requests arrive. Include shared channels, private messages, email, alerts, and conversations. Record the type of request, who needed help, and whether it needed an immediate response. This helps explain why work bypasses the plan and where a shared place for requests could help.

3. Group the recurring responsibilities. Who is doing customer support, testing, production support, sales assistance, and reporting today? Estimate the time each takes. Compare the current arrangement with options such as dedicated time, training, automation, outside help, or a hire. Include employment costs and the practical limits of what each option can cover.

4. Review recent bugs and incidents. For the last twenty bugs, note who found them and which could reasonably have been caught before release. For incidents, look at the hours involved, who was called, and whether they could resolve the problem or needed to wake someone else. Repeated problems may point to a missing check, unclear instructions, or too little time to fix the cause.

5. Compare the plan with what shipped. Look at the last three planning periods and the reasons work moved. If support and incidents repeatedly displaced planned changes, allow for that work in the next plan. If something else explains the delays, follow that evidence too.

Google's guidance on repetitive operational work makes a useful recommendation: measure it before deciding what to improve. The practical question is which recurring problems are taking enough time to justify a better way of handling them. Google's Site Reliability Workbook, Eliminating Toil.

Use the first two weeks to make the work visible and try a more deliberate way of sharing it.

Keep that record in the existing tracker, including work that would otherwise stay in messages. Record urgent issues after responding.

During the second week, try giving routine incoming requests a named first contact. That person can answer, investigate, or bring in the right colleague. Agree on a backup and how urgent problems reach the people who can help. Adjust their planned feature work to reflect the responsibility.

Google's guidance on interruptions recommends separating periods spent handling incoming issues from periods spent on project work. A small team can try that principle without copying Google's staffing model. The aim is to give people longer stretches on one kind of work. Google's Site Reliability Engineering book, Dealing with Interrupts.

For a six-person team, a weekly rotation may be a useful starting point. It needs a short handover, shared notes, and enough coverage for the volume of requests. If one person cannot keep up, the rotation has revealed a staffing or workload problem that still needs attention.

The founder and other leaders need to use the agreed route too. A rotation won't help much if routine requests continue going directly to the person who usually answers fastest.

Then use the record to decide what needs dedicated attention. A discussion about testing or support becomes more concrete when everyone can see the hours being spent, the repeated problems, and the planned work being delayed. A hire may be justified. So may better tools, clearer ownership, or scheduled help from someone with the right experience. Make the role match the work the company actually needs done.

There are smaller improvements worth trying while those decisions are being made. Clear answers to the most common support questions can reduce repeat requests. Automated checks of important behavior can reduce some manual release testing. A saved report with the right access can let someone get recurring figures without asking an engineer each time.

Choose one of these based on what the record shows, and check whether it helps. It will need maintenance, and it may solve only part of the problem. That is still useful progress.

Simply asking engineers to protect their time leaves them to negotiate each request individually. The company needs to agree on how requests are handled, what can wait, and how much planned work fits around those responsibilities.

At the end of two weeks, review whether requests received timely help, whether the person handling them had enough support, and whether the rest of the team had more uninterrupted time. Use that information to set the next plan and decide what still needs staffing or improvement.

The next piece, Who Reviews the Machine, looks at how AI coding tools change this picture, including which responsibilities remain even when writing code and tests becomes faster.

Related service: Team Turnaround