Great piece! most managers hoard decision making without realizing it.. Hard realisation that giving someone a microservice to own with actual authority to fix tech debt is way different than asking them to maintain it when you tell them to.
The tool kingdom concept really resontes with me, especially for something like Datadog. In my experiance, what usually happens is everyone uses the tool superficially and nobody really owns it until there's a problem. Then suddenly you're scrambling to figure out why costs exploded or why you're not getting the alerts you need. Having an engineer who actually becomes the expert and champion makes so much sense, especially for observability tools where the setup complexity can be massive. The point about working across teams to create common guidelines is particularly important becuase otherwise you end up with each team instrumenting their services differently and making the whole platform less useful.
The 'kingdom' framing is spot on - it transforms ownership from a chore into something engineers actually want! I particularly liked the tool kingdom example with Datadog/Sentry. In my experience, having a champion who monitors health metrics, tracks new features, and creates guidelines is the difference between just 'having observability' and actually using it effectively. The warning about not spreading too thin (1-2 kingdoms per engineer) is crucial - I've seen teams try to assign ownership of everything and it becomes meaningless. One question: how do you handle kingdom transitions when someone leaves or changes roles? Is there a structured knowlege transfer process or more organic?
“A kingdom per engineer”, simple but brilliant framework.
Great piece! most managers hoard decision making without realizing it.. Hard realisation that giving someone a microservice to own with actual authority to fix tech debt is way different than asking them to maintain it when you tell them to.
The tool kingdom concept really resontes with me, especially for something like Datadog. In my experiance, what usually happens is everyone uses the tool superficially and nobody really owns it until there's a problem. Then suddenly you're scrambling to figure out why costs exploded or why you're not getting the alerts you need. Having an engineer who actually becomes the expert and champion makes so much sense, especially for observability tools where the setup complexity can be massive. The point about working across teams to create common guidelines is particularly important becuase otherwise you end up with each team instrumenting their services differently and making the whole platform less useful.
The 'kingdom' framing is spot on - it transforms ownership from a chore into something engineers actually want! I particularly liked the tool kingdom example with Datadog/Sentry. In my experience, having a champion who monitors health metrics, tracks new features, and creates guidelines is the difference between just 'having observability' and actually using it effectively. The warning about not spreading too thin (1-2 kingdoms per engineer) is crucial - I've seen teams try to assign ownership of everything and it becomes meaningless. One question: how do you handle kingdom transitions when someone leaves or changes roles? Is there a structured knowlege transfer process or more organic?
Nice. Giving ownership is giving growth opportunities and sense of achievement!
And thanks for the shoutout :)