Shipping to production faster (?)

2022-10-07 10:28:13 +0200 +0200

Shipping to production faster unconference proposal

Earlier this week I facilitated an impromptu “unconference” session at my team’s offsite: Shipping to production faster: can we? should we? how?!?.


I wanted to discuss this topic because I felt we could be shipping at a quicker cadence and the benefits of processes we could use to ship faster are self-evident and worth the effort:


What I realized in facilitating the discussion is that 1) my assumptions about what “shipping to production faster” means are not necessarily correct nor shared across the team and 2) shipping faster as a goal is counter-balanced by some equally, if not more important, goals for the team.1


For each discussion question, I asked participants to find a place along a wall in the room, with two corners indicating the ends of a spectrum. My questions were:

For each question, participants on either side of the spectrum as well as in the middle gave their perspectives. I found it to be a useful way for us to see who stands where on an issue as well as see that in some cases perhaps we are not so far apart.

One interesting take-away for me (perhaps self-evident to others) is that there was overall satisfaction with the status quo and generally a lower level of tolerance for risk and breakages.

Another point that was interesting: when a production error occurs, engineers see the technical side of it, e.g. widget X broke with error Y, this was the number of errors, that is the code that caused the breakage, here’s the patch to fix it, etc. But as our community relations specialist observed: there is a high social cost to these breakages; it requires diplomacy and explanation to justify to a community why we have broken something, and if you do not manage this well or continue to break things often, you eventually lose their trust.

Action items

Towards the end of the session, we split up into groups focused loosely on “engineering”, “design / product / data”, and “team practices” to come up with action items that we could take based on the previous discussion, then voted on these items as a group to further narrow down what we could focus on next. Based on that, it looks like there’s interest to:


While I expected the team to want to push for shipping more, faster, with higher tolerance for risk, we collectively focused on reducing errors, proactively addressing maintenance, and simplifying contexts to tone down multi-tasking.

tl;dr talk to your team so you know how people feel and what matters to them.

  1. Side note: this is why it’s good to have these more abstract discussions about priorities and principles with your team. If you only ever talk about specific projects in regular meetings, it’s hard to step back and have a broader view of what you’re doing, why, and whether you want to change the “how”. ↩︎