ProductFTW #20: The Challenges of Context Shifts

ProductFTW is about the skills and challenges of building software products. We can learn a lot from other types of work. A lesson from my mechanic inspired today's post about how PMs manage workloads and development cycles for their development teams.

A few years ago, my mechanic told me about his plan to buy the building next to his current shop. I asked if he would have trouble hiring more mechanics–he has previously told me that was a challenge. He surprised me by saying that although he was doubling his shop space, he was keeping his crew the same size. I asked him to explain.

He told me that in the current shop, each mechanic has a single bay, including a lift for working on the car's underside. What often happens in their business of diagnosis and repair is that a car is brought into the bay, lifted up, diagnosed, and then work stops. There are two reasons work stops:

  1. The customer needs to be called with an estimate and to approve the work
  2. Parts need to be acquired, some of which can be delivered on the same day, but others may take longer

As a result of the stop, the mechanic will bring the car down, including putting some things back together (e.g., putting a wheel back on), the car is moved to the yard, and a new car is brought into the bay. Later, when the customer approves of the repair, and all the repair parts are in, the mechanic can put the car up and finish the job (or hit a new block and wait all over again).

By adding a second bay for each mechanic, the crew can work on two cars at once. Leaving a car up on the lift reduces effort in the swapping, and enables faster shifts to the second job, while the first job is in a wait mode. Brilliant (and maybe obvious to people who repair cars for a living).

The entire concept had me thinking about the stops, starts, and context flows in software development. There are two types of context-shifting problems that I see in front of development teams:

  1. Waiting for approval or feedback
  2. Solution design challenges

When PMs design a cycle, they are often focused on pure priority and do not consider what approval flows may exist mid-cycle (e.g., after a solution is designed, what the engineer is doing during testing/feedback/approval). Software development is a creative pursuit, and sometimes engineers hit a block when thinking about how to solve something. Giving any engineer a couple of different tasks to work on can enable them to set aside a problem for a day until a solution comes to mind while not losing productivity.

In poorly run cycles, there are a lot of mid-cycle disruptions, such as shifts in priorities, urgent customer fixes, etc. Each of these creates a context shift, akin to pulling a car off the lift, putting a new one in there for different work, returning to the other car later. That can disrupt the coding flow leading to real challenges in productivity.

Overall, focus is beneficial to productivity. Once you are stuck waiting for approvals, feedback, or inspiration, switching contexts can also be positive when you have something new to work on to fill time or spark creativity.

How can software development teams handle this? There are a number of solutions:

  1. Two Bays, or big rock/small rock: Each developer gets a meaty project per cycle, plus some small ones, allowing them to manage these shifts as they get stuck or simply desire new work
  2. Rotating Kanban Duty: Most developers on the team are focused on core development, with one developer taking duty each cycle for the interrupt-heavy urgent fixes run on a separate Kanban board. The developer on duty rotates throughout the team
  3. Concentrated Cycles: Thoughtfully ensure all tickets in a cycle have a similar theme so that interruptions and shifts are not very large. In our car analogy, this would mean giving the same mechanic two Honda brake projects at a time instead of one Honda brake project and one diesel engine rebuild.

What works for you and your team to manage the interruptions and context shifts of modern software development?

About ProductFTW

ProductFTW is a weekly newsletter about product management with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.


Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]