Give Your Engineers a Kingdom: A Guide to Empowering Ownership

In many teams, the Engineering Manager often becomes the central bottleneck, with everything flowing through them. You're the one prioritizing tasks, triaging issues, and making all key decisions. You divide the work, and your team members simply execute.

This operational model might be suitable under two specific conditions:

• You've grown within the team and possess comprehensive knowledge of every detail.
• Your team is relatively junior or new to the company.

I’m not assigning blame here; this is how I’ve operated for a significant portion of my career. However, as time passes and your engineers develop their skills, it's crucial to evolve your team’s operating mode.

It's time to give your engineers a kingdom!

Thanks to Unblocked for sponsoring today’s article!

In my previous Engineering Manager role, roughly 50% of my non-meeting time was spent on Slack. Having been with the company for over four years, I had accumulated extensive context that proved invaluable to Support, Customer Success, Product Managers, Designers, and my engineers.

The frustrating aspect was the constant recurrence of the same questions. Answers would get lost in various channels and threads. While I'd write Confluence articles, they often became outdated or were simply hard for people to find when needed.

A tool like Unblocked would have saved everyone a tremendous amount of time. It efficiently retrieves accurate answers from all your team’s code, discussions, and documentation across platforms such as Slack, GitHub, Confluence, and Jira.

Check out Unblocked for yourself

What exactly is a “kingdom”?

Essentially, it's a broader term for responsibility and ownership within the team.

A "kingdom" can represent:

• An Application/System: Something larger than a single feature, for which your team holds primary responsibility.
• A Microservice: Particularly relevant if your team manages several of them.
• A 3rd-Party Integration: A significant external service your team heavily relies on.
• An Integral Tool: A critical internal tool your team uses extensively, such as a workflow orchestrator, a queuing system, or monitoring tools.

What "owning" a kingdom entails

The core principle here is decision-making and prioritization. The engineer responsible for a particular kingdom should be the primary decision-maker for it!

Here are some practical examples:

An Application Kingdom This concept is often more applicable in smaller startups where each team might oversee multiple applications or systems. In larger organizations, it could relate to a significant, ongoing feature rather than a one-off effort.

Owning an application kingdom might involve:

• Working closely with the Product Manager and Designer, understanding the roadmap, and helping them prioritize (trusting their decisions here is key!).
• Staying informed about customer usage, collaborating with analysts to create appropriate dashboards, and diligently monitoring them.
• Monitoring the application's health and serving as the primary point of contact during any incidents.
• Collaborating closely with the Quality Assurance specialist for that application.
• Participating in relevant customer calls.
• Being the technical go-to person for the application, both for fellow engineers and external stakeholders.

A Microservice Kingdom This makes sense if your team manages 3-4 microservices, perhaps inherited or developed due to multiple responsibilities.

Owning a microservice kingdom might involve:

• Monitoring its ongoing health (e.g., latency, memory leaks, dependencies).
• Deciding on the technical debt roadmap: identifying what's critical and what should be improved next.
• Being responsible for contributing guidelines and relevant documentation.
• Serving as the go-to person for other engineers with questions about that microservice.

A 3rd-Party Kingdom Imagine your systems depend heavily on a weather API. Many features rely on it, making it a critical component of your offering.

Owning a 3rd-party kingdom might involve:

• Leading joint work with the external company (often through weekly status meetings), estimating efforts, and setting milestones.
• Staying informed about release notes and upgrades (e.g., new APIs, potential uses).
• Monitoring the health and metrics of the integration and proactively raising any concerns.

A Tool Kingdom This could be Datadog/Sentry, Kafka/PubSub, Argo Workflows, or any other tool your team heavily relies on.

Owning such a tool might involve:

• Becoming the expert in its usage and disseminating knowledge within the team.
• Staying abreast of new releases and features.
• Collaborating with relevant individuals from other teams (product and platform teams) to establish common guidelines and championing the tool's best practices.
• Monitoring the tool's health and performance metrics.

How to Implement It Effectively

You should NOT aim to have 100+ kingdoms within your team, dividing every single task. Spreading your people too thin will undermine the entire purpose. It's perfectly acceptable to leave many areas as "gray" and collectively owned by the whole team.

The primary goal is to instill pride in your team members and provide them with the time to genuinely care for their kingdom(s).

My recommendation is to assign one or two kingdoms per engineer. Choose the ones that make the most sense, starting with those that currently consume most of your own time.

Final Thoughts

While "kingdom" is simply another term for "ownership areas," I believe its use has a positive psychological effect. Often, being an 'owner' is perceived as a chore, something engineers might prefer to avoid. When framed as a 'kingdom,' it can be perceived much more favorably.

Of course, the method of implementation is critical. If you merely assign engineers responsibility for undesirable tasks, they will resent it. However, if you provide them with a dedicated development time budget and the authority to make decisions, everyone involved will benefit significantly.

Discover Weekly

• Leveling Up Teams Fast and Slow by Stay SaaSy. A superb article on improving engineering departments and the two modes to achieve it (I'm a huge fan of the fast mode).
• What Keeps You “Not Quite Senior Yet” by Adler Hsieh. A valuable read for managers of mid-level engineers, offering insights into helping them take the next career step.
• The Pulse: AWS takes down a good part of the internet by Gergely Orosz. I've been a paid subscriber for over a year and highly recommend it. The Pragmatic Engineer is genuinely the newsletter for engineers and an excellent way to stay current (not sponsored/affiliated!).