In too many teams, everything goes through the Engineering Manager. You are the one prioritizing, triaging, deciding. You divide the work, and your people execute.
This mode might be suitable in 2 conditions:
You grew within the team and know everything
Your team is relatively junior/new to the company
Not blaming here - this is how I worked for most of my career.
When some time passes and your engineers grow, it’s time to change the operation mode.
It’s time to give your engineers a kingdom!
Thanks Unblocked for sponsoring today’s article!
In my last EM role, ~50% of my time outside meetings was spent on Slack. I’ve been in the company for 4+ years, so I had lots of context that was useful to Support, CS, PMs, Designers, and my engineers.
The annoying thing was that the same questions kept coming up. Answers got buried in channels and threads. I’d write a Confluence article, but then it would get outdated, or people couldn’t find it when they needed it.
Using a tool like Unblocked would’ve saved everyone tons of time. It pulls accurate answers from all of your team’s code, discussions, and documentation across tools like Slack, GitHub, Confluence and Jira.
What the hell is a “kingdom”
It’s basically a bit broader term for responsibility/ownership.
A kingdom can be:
An application/system - something bigger than a feature that your team is responsible for.
A microservice - in case your team has a couple.
A 3rd party integration - something signigicant your team depends on.
An integral tool - that your team has heavy usage of. Like a workflow orchestrator, a queuing tool, monitoring tools, etc.
What “owning” a kingdom looks like
The key point here is decision-making and prioritizing.
The engineer who is responsible for the kingdom should be the one making the decisions about it!
Some practical examples:
An application kingdom
This one is probably more relevant in smaller startups, where each team might be responsible for multiple applications/systems. In bigger companies, it can be about a feature - but something big and juicy, not just a one-time effort.
Owning an application kingdom could mean:
Closely working with the PM+designer. Understanding the roadmap and helping them prioritize (you trust their decisions here!)
Being on top of the customer usage - working with analysts to create the right dashboards, and closely monitoring them.
Monitoring the health of the app, and being the point of contact during any incident.
Closely collaborating with the QA person on that app.
Joining relevant customer calls!
Being the technical go-to person for that app - both for other engineers and for outside stakeholders.
A microservice kingdom
This one makes sense if your team is working on 3-4 microservices (maybe you inherited some from other teams, or have multiple responsibilities).
Owning a microservice kingdom could mean:
Monitoring the ongoing health (latency? memory leaks? dependencies?)
Deciding on a technical-debt roadmap. What’s critical, what should we improve next.
Being responsible for contributing guidelines and relevant docs.
The go-to person for other engineers who have any questions about that microservice.
A 3rd party kingdom
Let’s say you depend on a weather API in your systems. You have many features that rely on it, and it is a critical part of your offering.
Owning a 3rd party kingdom could mean:
Leading the joint work with the other company (often in weekly ‘status’ meetings). Estimating and setting milestones.
Being on top of the release notes and upgrades (is there a new API? How could we use it?)
Monitoring the health and metrics of the integration and raising any flags.
A tool kingdom
It can be Datadog/Sentry, Kafka/PubSub, Argo Workflows, or whatever tool you heavily depend on.
Owning such a tool could mean:
Being the expert on using the tool and spreading the knowledge within the team.
Being on top of release news/features.
Working with relevant people from other teams (product AND platform teams), to create common guidelines. Being the ‘champion’ for that tool.
Monitoring the health and metrics of the tool.
How to do it right
You should NOT have 100+ kingdoms in your team, dividing every single thing. Spreading your people too thin will hurt the whole point, it’s ok to leave many areas as ‘gray’ and owned by the whole team.
The goal here is to give your people pride and time to actually take care of their kingdom(s).
My recommendation is to have 1 or 2 per engineer. Choose the ones that make the most sense - I would start with those that take the most time from you.
Final words
A kingdom is just another term for “ownership areas”, but I believe using it has some positive effect. Usually being an ‘owner’ is seen as a chore, something engineers prefer to avoid. When you talk about a kingdom, it can be perceived better.
Of course, the way you do it matters a lot - if you just ask the ‘owners’ to be responsible for the shitty things, people will hate it. If you give them some development time budget and the ability to make decisions, everyone will benefit.
Discover Weekly
Leveling Up Teams Fast and Slow by
. A superb article on improving engineering departments, and the 2 modes to do 2 (a huge fan of the fast mode).What Keeps You “Not Quite Senior Yet” by
. A good read for managers of mid-level engineers, might help you communicate to them how to take the next step.The Pulse: AWS takes down a good part of the internet by
. I’ve been a paid subscriber for more than a year, and I highly recommend it. is really THE newsletter for engineers, and a great way to stay on top of things (not sponsored/affiliated!!)
“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.