←back to thread

210 points dakshgupta | 1 comments | | HN request time: 0.205s | source
Show context
solatic ◴[] No.41845515[source]
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.

replies(5): >>41845627 #>>41845956 #>>41849083 #>>41852256 #>>41860978 #
dakshgupta ◴[] No.41845627[source]
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.
replies(2): >>41846050 #>>41847818 #
1. crabmusket ◴[] No.41847818[source]
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.