Scaling ownership
A major challenge in building a team is balancing career development and execution speed. Simple problems can be solved quickly by senior engineers, but won’t help them learn new things. Junior engineers may be slower to handle complex projects, but learning to tackle them is critical to their career growth. For an engineer at any level, handling familiar tasks quickly becomes boring, and bored engineers are more likely to jump ship, so finding new problems for engineers to tackle keeps them around.
Even if they are assigned an interesting problem, an engineer won’t get far without lots of context. Without a deep understanding of every part of the system and the product, it is impossible to assess tradeoffs and make good decisions. An engineer can only effectively develop a system over which they have full context and “ownership”. Gaining that context and moving from “contributor” to “owner” is a crucial part of an engineer’s growth so that they can tackle complex problems.
Ownership confers many benefits to a developer, so it is critical to make sure there is room for a junior engineer to own a system. When the senior engineers on a team have strong ownership of the system, it can feel like there is no space for other team members. To combat that, it is important to set up a culture where ownership is not exclusive to one person. Instead, ownership should be shared among multiple people, and the process of sharing ownership should be a key mechanism for learning and growth.
Scaling Ownership
Here are some of the benefits of ownership that I think are important, and how they can each be adapted to allow both junior and senior engineers to become owners and reap those benefits:
Codebase familiarity
This is usually the first step to owning a codebase. An engineer is “familiar” with a codebase if they know where all the code lives and what it does, they can answer questions about the system, and they can debug things in a pinch.
It is easy to set up processes so that multiple people know where the code lives: have a junior engineer start with a code walkthrough with an existing owner, and then work on a small project to get familiar with it. To help distribute debugging and investigation opportunities, an on-call rotation is an effective tool: for one week at a time, each team member is solely responsible for looking into bugs with that system or answering questions. Senior engineers can be brought in to help when teammates are stuck, but problems should never be handed off wholesale; everyone on the team should strive to be a resource.
Technological Stewardship
Once an engineer knows how a system is built, they can form opinions on where it needs to go next. They should know why technologies were chosen, and at what point they should be scrapped and replaced with the next thing. They should have a clear idea of the highest-priority tech debt.
The existing backlog is a great place for an aspiring owner to start. From there, they can find the improvements that they care about and begin to shepherd them along. On larger systems, multiple improvements can be driven at once to scale “ownership.” Bringing on new owners is also beneficial for existing senior engineers: collaborating with junior engineers on technical improvements is a fantastic learning opportunity that is missed when an existing owner does makes fixes alone.
Architecture
System design can be one of the most interesting engineering challenges for an owner. Important decisions must be made to accommodate a new feature, and even larger decisions must be made if a system needs to be rebuilt wholesale.
To make architecture decisions available to new owners, rotate the “project technical lead” role among team members so that junior engineers have a chance to think about design from the ground up. In order to facilitate learning and make sure the decisions are correct, an RFC process for new features gives new engineers support from across the organization so they can find the best possible solution.
Development Process
An owner also understands the nuts and bolts of contributing to the system. A codebase should have clear coding best practices, as well as a standard for testing and a simple local setup for development of new code.
A great tool for maintaining best practices and standards is code review. Encourage aspiring owners to take on as many code reviews as they can. Junior engineers should also be responsible for keeping the local development setup in shape. A good policy is to always invest in your toolchain: if any engineer encounters a problem, regardless of of their seniority, they should take it upon themself to fix it.
System Champion
Major changes happen when senior leadership understands the impact of technology, and invests in it strategically. As a result, if an owner can articulate a vision for their system to non-technical folks, they can truly define its direction.
A vision for the system should be shared by the entire team, so make sure that there is a forum to actively and openly discuss technical changes in business terms. Junior and senior engineers should collaborate frequently to bounce ideas around, collaboratively develop plans, and coalesce on the best direction for development. When junior and senior engineers are aligned on the strategic direction for a team, good things happen quickly.
Everyone As The Primary Owner
Collaboration is the common thread through all paths toward shared ownership. People drive each other to be better when working together, and everyone should be encouraged to include others when solving interesting problems. This should be reflected in goals, promotion rubrics, and even compensation discussions: current owners should be rewarded for developing future owners. Constantly working with senior developers helps junior developers to grow, and forges connections that last for the rest of their career.
