Happy Friday!

First, I want to share some fairly exciting personal news. In 2013 my wife gave me a gift that was to take beekeeping classes. I've always been fascinated by bees, so this class was wonderful.

Sadly, I never got to apply that knowledge.

Until this week!

This week I set up my first two beehives. I'll be obsessing about them for the next few months as they get established and make their first bit of honey for themselves.

Anyway, let's talk about a really common scenario that individual developers feel as do engineering leaders. Product folk want to add more and more features, faster and faster. Meanwhile, engineering sees the cracks in their code and infrastructure and asks to slow down so they can address the issues.

I've seen a few variations of what happens next.

1. A budget is set for teams for how much capacity they can spend fixing things or cleaning up. I think most groups manage to negotiate 20-30%.
2. Engineering negotiates whole blocks of time. This could be like a hardening sprint, holiday cleanup, or some variation where time is fully dedicated to tech.
3. A separate team forms whose job it is to clean things up and focus on tech while another focuses on product.

Now, each of these may be an improvement to a group that has neglected its code and infrastructure, but there are two underlying problems that none of these address.

• The habits and practices that created the problems still exist.
• Product and engineering aren't partners.

To the first point, getting time is only part of the equation. That time has to similarly meet with new practices and habits. Test differently, design differently, monitor differently, etc. Time by itself tends to create more of what already exists, and in this case, that means more problems.

For the second point, when I work with groups in this situation I spend a lot of time working with engineering and product to expose all the invisible stuff that is often discussed but never seen. I do this, so that when the product wants more and engineering needs to address issues this feels less like a surprise and more like a discussion on the approach.

Too often each side lets the problems fester with their arms crossed because the other side, "Just doesn't get it."

Google made waves a while ago when they shared how they have conversations about error budgets. While I'm not endorsing that specific technique, it does show a way to have a discussion about trade-offs in a material and responsible way.

If you want to be a jerk about it, the conversation goes like this: "I can get you whatever you want as fast as you want, but it has a 0% chance of working." This absurdity is the springboard to talking about what it takes to deliver and what quality might actually look like and the risk both sides will accept.

My main point here is that while the numbered approaches might provide some relief, they don't remove the cause of damage. So, while you get your relief, focus on the relationships and habits to remove the problem forever.

Sincerely,

Ryan