Effective delegation: Assign ownership

It’s October, and many engineers are settling into expanded roles due to promotions, reorgs, and transfers. Those roles often involve delegation since you can’t accomplish your expanded scope of work by yourself and must entrust portions of it to others. That’s what delegation is: trusting others to take on a portion of your responsibility.

Delegating poorly comes naturally to many engineers. Power-hungry engineers order others around, ignoring people’s capabilities and capacities. Overly rational engineers treat everyone interchangeably, assigning the next item to the next available individual with robotic consistency. Engineers eager to please let folks work on whatever they want, dealing with the unwanted yet critical work themselves. Those are all terrible delegation strategies.

Ordering people around makes them feel disrespected, angry, and burnt out. Treating everyone interchangeably reduces mastery and autonomy and ignores people’s strengths and weaknesses. Letting folks work on whatever they want ignores business and customer priorities, leading to bad outcomes and poor rewards. Dealing with unwanted yet critical work yourself is unsustainable and denies others the opportunity to deliver those crucial items. There’s a better way to delegate: assign ownership. Read on to learn about the why, what, and how of assigning ownership.

Tell me why

Don’t delegate tasks. No one brags about individual tasks in performance reviews or to their family and friends. Tasks are one and done. There’s no mastery—you only do it once. And there’s no autonomy—you aren’t the owner of the area. Ordering people to do individual tasks or assigning the next task to the next available person is uninspiring at best and demeaning at worst. It’s also inefficient and anti-growth since no one gets good at anything, just mediocre at everything. Because individual engineers don’t own anything, leadership must make decisions and quickly becomes a bottleneck, slowing progress further. Even worse, every engineer touching every code file adds inconsistency, churn, and excessive bugs.

Instead, assign ownership. Ownership of classes, areas, and/or scenarios. Ownership of relationships with partner teams and v-teams. Ownership of decision making. Assigning ownership has long-lasting benefits. It fosters mastery and autonomy, which results in higher quality and efficiency. It builds trust and respect, which strengthens teams and relationships. It generates personal growth, which results in better engineers and better engineering. Last but not least, people take pride in ownership, touting their achievements in reviews and to their family and friends.

What is hip?

Perhaps you’re convinced you should assign ownership instead of delegating tasks. What should people own? Should it be scenarios or subsystems? Should it align with their interests or with business and customer priorities? The answer is yes, it should.

The saying that too many cooks spoil the broth has been verified for software quality by Microsoft Research. In a 2008 paper, the researchers found that failure prone code was better identified by the number of different groups contributing to the code than other stalwart predictors such as code churn and code complexity. You want subsystems (classes, files, components, areas) to be owned by just a few people—ideally one person and their backup—who review every pull request for their subsystem.

However, owning a subsystem sometimes disconnects you from customer experiences driven by scenarios. Fortunately, a subset of scenarios focuses on particular subsystems. Thus, the owners of those subsystems should also own those scenarios. Scenarios that cut across subsystems can be delegated separately (to the same or other people), with subsystem owners advising and reviewing cross-system scenario contributions.

As for alignment, it’s ideal to align ownership with people’s interests and strengths. However, professional engineers don’t write software for their personal amusement. We write software to enhance our business and benefit our customers. Thus, you start with business and customer priorities and assign ownership of the associated work based on people’s interests and strengths. If new owners aren’t familiar with the area, provide guidance and identify mentors. If no one is captivated by a particular business or customer priority, convince them otherwise. After all, it’s a business and customer priority—that’s what people get rewarded and promoted for delivering.

How do you do that?

Let’s talk through a few examples to better understand how to assign ownership effectively.

• You need to meet with a partner and resolve their needs. You’re busy, but instead of delegating the meeting, you delegate the entire relationship. Assign ownership of the interface, class, and/or component associated with the partner to an individual interested in that technical area or seeking to improve their leadership skills. You’ve now delegated the upcoming and all future partner meetings while making it easier for the new owner to act on your behalf because they own the relationship.
• A team member wants to own a particular shiny new technology, but it’s not currently a priority for customers or the business. Consider the skills necessary to master that shiny new technology, and assign the team member ownership of an area that has priority work and will develop those skills.
• Two people both want to own the same new subsystem or scenario. Make one of them the owner and the other the backup. Then give the backup ownership of a related subsystem or scenario, unless they’d prefer a different assignment.
• A legacy system that customers depend upon needs to be updated for security reasons. At the daily standup meeting, ask for a hero to step forward and own this critical work for our customers. Sure, you could do it and take the glory, but everyone deserves a chance to shine.
• A new compliance alert for your service needs attention. Instead of assigning someone to resolve the specific alert, you assign ownership of the associated compliance area. Now that alert will be addressed along with every other related alert by someone expert in that area.

In each case, you are assigning ownership instead of delegating individual tasks. Even though you assign ownership, you still need keep track of design choices, progress, and code quality to ensure everyone is aligned and can take pride in the value they’re delivering. It’s also a good idea to assign backup ownership to cover when the primary owner is sick, takes a vacation, switches teams, or is otherwise unavailable.

I can’t handle it

Assigning ownership is great, but how do you handle emergency items, inexperienced team members, and questionable choices people make?

Let’s say you’ve got a new work item that needs immediate attention, but the owner and backup aren’t available. In that case, assign the item to another team member and have the owner and backup provide advice and review the design and code. Teams win together; save one-off task assignments for emergencies.

Let’s say you’ve got a new team member. Perhaps he’s a new college hire. Perhaps she’s a transfer from another team unfamiliar with your codebase and org connections. Either way, giving that new team member ownership of a critical area is risky. Do it anyway. How else are you going to get critical work done with limited resources while helping your new team member learn, grow, and gain mastery and autonomy? The problem isn’t assigning ownership—it’s mitigating risk. Assign ownership as usual, but choose a backup that’s available to mentor the new team member, review designs and pull requests, and lend their org network to assist with questions and context. (New team members can also be effectively onboarded by being the backup for experienced owners.)

Let’s say you assign ownership of business and customer priorities, and then your owners make different choices than you would. Honestly, it’s rare when they don’t. What do you do? Trust but verify. Trust that your owners are capable professionals who know more details about their areas than you and are making good choices, even if they don’t match your instincts. Then verify that your owners’ choices result in iterations of delivered value that match customer requirements and your expectations around quality, timeliness, and scale. Provide appropriate feedback to owners whenever their choices demonstrably fall short of those requirements and expectations. Trusting owners helps them learn and grow—you might even learn a bit yourself.

You’re behind the wheel

Congratulations on your expanded role. Other people are now counting on you for direction, and you’re counting on them to deliver greater value than you could by yourself. Delegating effectively is key to getting the best results with the least effort.

Instead of delegating tasks, assign ownership. Start with business and customer priorities, determine the subsystems impacted, and then assign ownership of those subsystems (and their associated scenarios) to teammates based on those people’s interests and strengths.

Whenever new work arrives, consider its larger scope and assign ownership for that scope. For example, if there’s a meeting with a new partner, assign someone to own the associated interface and partner relationship. If a legacy system needs an update, assign someone to own that system. If there’s a new compliance alert, assign someone to own the compliance area.

Ensure owners have backups to cover during vacations and sick days. Backups can also mentor new team members who lack experience and contacts in the areas they own. Finally, trust your owners’ decisions while verifying their design choices, progress, and code quality to ensure everyone is aligned and delivering great value for customers. It’s how big things get done, and you’re ready for big things.