Discussion about this post

User's avatar
Boyd Hemphill's avatar

While I have, for the last decade, attempted to bring Product Mgmt thinking to running infrastructure teams, I have only recently moved full time into the Product Mgmt practice.

The idea of "root cause" being too difficult - or even impossible - to find resonates deeply with me. My infrastructure teams and dev teams will attempt to find root cause, but don't chase it. Instead a wise old engineer said to me, "Boyd, let's find contributing factors and pick the most important ones to address." Ultimately this lea, in my last job, to just over a year without a SEV1 incident.

We - grumpy old engineering and I - asked ourselves, "What could we do with process evolution? Wouldn't working contributing factors to process-breakdown just be what all the cool kids call 'continuous improvement?'"

So we hit upon just putting some overly simple process in place and providing the team with a weekly way to talk about managing that process. Over time we ended up with a Confluence space of wickedly effective processes owned by the engineers for the benefit of business outcomes. None of them were perfect because ... well ... humans. But all of them were _manageable_. My engineers regularly asked for new or longer meetings, killed meetings we didn't need and reporting a high sense of ownership in team outcomes.

Simple example - Grumpy Engineer says in 1:1, "Let's change standup. Let's not go from person to person in the usual way. Lets instead go ticket by ticket on the Kanban board from right to left." I replied, "Seems trivial why bother?" He replies, "Because we talk about the work not the person." He took this to the team meeting and the team said - after some discussion and FUD, "Let's do it for 2 weeks and see what happens."

Within a week WIP decreased, deployments increased and folks were openly talking about how they felt better informed and better able to help out on the things that mattered. We never went back, though we did change things about the board, prioritizing review and deployment of work over starting and doing work, etc.

I hope this is an example of the spirit of the post or that someone will set me straight. Thanks for the inspiration regardless.

Expand full comment
Vf's avatar

An issue I have with this discourse is that the people who have to solve the mess of complex problems usually don't get a say about their feelings and stake in it. They usually lack the power to negotiate much less to influence and control the way it relates to their professional identity. The corporate world is still very much an inequitable space where powerplay still ranks supreme, top-down. In so doing are we overthinking the complicated and complex?

Expand full comment
7 more comments...

No posts