This pattern has a smell. If you're shipping continuously then your on-call engineer is going to be fixing the issues the other engineers are shipping, instead of those engineers following up on their deployments and fixing issues caused by those changes. If you're not shipping continuously, then anyway customer issues can't be fixed continuously, and your list of bugs can be prioritized by management with the rest of the work to be done. The author quotes maker vs. manager schedules, but one of the conclusions of following that is that engineers don't talk directly to customers, because "talking to customers" is another kind of meeting, which is a "manager schedule" kind of thing rather than a "maker schedule" kind of thing.
There's simply no substitute for Kanban processes and for proactive communication from engineers. In a small team without dedicated customer support, a manager takes the customer call, decides whether it's legitimately a bug, creates a ticket to track it and prioritizes it in the Kanban queue. An engineer takes the ticket, fixes it, ships it, communicates that they shipped something to the rest of their team, is responsible for monitoring it in production afterwards, and only takes a new ticket from the queue when they're satisfied that the change is working. But the proactive communication is key: other engineers on the team are also shipping, and everyone needs to understand what production looks like. Management is responsible for balancing support and feature tasks by balancing the priority of tasks in the Kanban queue.
> on-call engineer is going to be fixing the issues the other engineers are shipping, instead of those engineers following up on their deployments and fixing issues caused by those changes
Solution: don’t. If a bug has been introduced by the currently running long process, forward it back. This is not distracting, this is very much on topic.
And if a bug is discovered after the cycle ends - then the teams swap anyway and the person who introduced the issue can still work on the fix.
This is a real shortcoming, the engineers that ship feature X will not be responsible for the immediate aftermath. Currently we haven’t seen this hurt in practice, probably because we are very small and in-person, but you might be correct and it would then likely be the first thing that breaks about this as our team grows.
I commented a while back on another post about a company I worked at which actually made developers spend a few days a year taking tech support calls. This takes their responsibility for and awareness of the aftermath of their work to a whole new level and from my perspective was very effective. Could be an alternate route to address the same problem.
We often plan projects in release stages including a limited alpha to a few customers who are interested in a feature. We expect that during the alpha period, the developer who worked on the feature will need to make changes and address feedback from the users. And the same after a general release. We have longer rotations than yours so there is usually time to schedule this in around feature releases before that developer is responsible for general defensive work.
We came to this conclusion from a different direction - feature implementation teams are focused on subdomains, but defensive teams are spread across the entire ecosystem.
Additionally, defensive devs have brutal SLAs, and are frequently touching code with no prior exposure to the domain.
They got known as "platform vandals" by the feature teams, & we eventually put an end to the separation.
That sounds interesting ("platform vandals" and your solution). At what type of software company do you work? About how many are you, what type of product, if I can ask?
It really depends on the context. Some types of troubleshooting just involves a lot of time-consuming trial-and-error that doesn’t teach anything, it just rules out possibilities to diagnose the issue. Some products have a long deployment cycle or feedback loop. Some people are just more suited to or greatly prefer either low or high context switched work.
Good management means finding the right balance for the team, product, and business context that you have, rather than inflexibly trying to force one strategy to work because it’s supposedly the best.
There's simply no substitute for Kanban processes and for proactive communication from engineers. In a small team without dedicated customer support, a manager takes the customer call, decides whether it's legitimately a bug, creates a ticket to track it and prioritizes it in the Kanban queue. An engineer takes the ticket, fixes it, ships it, communicates that they shipped something to the rest of their team, is responsible for monitoring it in production afterwards, and only takes a new ticket from the queue when they're satisfied that the change is working. But the proactive communication is key: other engineers on the team are also shipping, and everyone needs to understand what production looks like. Management is responsible for balancing support and feature tasks by balancing the priority of tasks in the Kanban queue.