If you want to empower developers to make autonomous decisions, here are some ways to use success metrics to set clear expectations.
An engineer’s autonomy is directly associated with productivity, as well as having the space to create, innovate, and grow. Success metrics are a great tool for fostering autonomy, and empowering your reports to make more decisions themselves.
Many managers use success metrics for reviewing the performance of a long-term project, at the end of the process. But there are many benefits to also using these metrics earlier on in the development process. As a development manager at Shopify, leading a team of sixteen people, including managers, I’ve seen how introducing success metrics in other scenarios has helped to drive autonomy.
Here, I’ll walk through three different situations where we can use success metrics to empower teams to make smart, autonomous decisions: when appointing a champion/facilitator at the start of a new project, when managing a temporary engineer who’s supporting a team for a limited time period, and when supporting a engineer who’s making a lateral move from one team to another.
Situation #1: Using success metrics to empower a project champion to facilitate a project
A typical project starts with a product manager explaining why a new product is needed. This is normally followed by a prototype phase to explore the technical and user requirements until the scope is well defined, the risks are known, and timelines are set for the build phase. The build phase itself will then have multiple iterations and potential releases before the product reaches end users.
At Shopify, we assign a project champion who makes sure the execution cadence is met, removes blockers, looks at the big picture, and ensures the team will achieve its goals. The champion can be someone with or without a hands-on approach to engineering, but they should have some project experience and expertise, for example, a senior engineer or product manager.
Signs of lack of empowerment
Here are three examples of typical conversations that can signal the engineering team is not fully empowered, and is lacking the important, useful context to make decisions themselves:
- Should we perform load testing? What level of load should we aim for?
- Scope seems a bit much for this six-week cycle. What can we do?
- Should we build the overview screen based on technical design A or B?
The above conversations are valuable, but typically represent a dependency to engineering, user experience (UX), or product leaders. Having these conversations too often can be a sign that success metrics must be reviewed, given these decisions will already have been made if a team is empowered and aligned on success metrics from the beginning. As an engineering manager, it might be time to meet with a project’s champion.
How to empower a project champion
i. Setting expectations with the champion
Take time in a 1:1 with the champion to clarify their responsibilities. It’s important they know they must ensure decisions are made in a timely manner. Here are some examples of a champion’s responsibilities:
- Writing a project’s principles with team leads in a project brief
- Ensure UX and product alignment are given technical limitations
- Ensure the project’s final scope is given the six-week cycle constraints
- Put together a timeline and plan of deliverables
- Facilitate mapping out risks ahead of project’s build phase
- Ensure a technical design is captured by the team and reviewed by relevant stakeholders
- Coordinate dependencies with UX deliveries and other teams
- Report on the project’s progress
- Facilitate a cycle retrospective
ii. Writing project principles
The champion, and other relevant stakeholders such as product or UX leaders, should set success metrics. Here are a few examples:
We will be successful when:
- The project has been delivered by 2022-11-15 to merchants
- A six-week-cycle version of the scope has been negotiated with product and UX
- The project has gone through BFCM traffic load without problems
- We’ve used a specific new API version because the current one, although stable, is being deprecated
- Minimal technical debt has been introduced, unless we’ve had to make decisions to ensure our deadlines were met
The principles above should help to empower the whole team to make faster decisions. This guidance will help the team bypass frequent conversations with leadership to re-align direction. Reducing the time for a decision puts the team closer to delivery and impact for the final user. In addition, the principles will play a key role in identifying areas to improve in a project retrospective.
iii. Supporting the champion
As a project progresses, the engineering lead can support the champion in weekly sync meetings together with other leads, and you can check in during your 1:1s. To support the champion well, engineering leaders need to do the following:
- Provide direction and vision in the beginning of the project
- Give timely feedback about decisions and coaching throughout the process so the champion is set up for success when facing similar challenges in the future
- Collect 360º feedback about Champion’s performance by the end of a project cycle, and has a conversation on how to improve onwards
- Recognize and reinforce good decision making and impact
- And, most importantly, frequently revisits the success metrics when discussing decisions to remind the Champion that decisions must be well reasoned
Situation #2: Using success metrics to empower temporary engineers
In this scenario, your team is working toward a tough deadline and is understaffed. In order to hit the deadline, you need to bring in another data engineer with specific knowledge, from another team, to make sure timelines are met.
Signs of lack of empowerment
Here are a couple of signs your project might be at risk:
- There are no clear timelines of when the project ends and why
- The temporary data engineer doesn’t understand how joining a different team benefits their professional growth beyond ‘helping out’
How to empower a temporary engineer
In order to make this temporary journey as impactful as possible, leaders from both teams (i.e. the permanent and temporary team) must come together with the engineer to agree on success metrics. This should take place in a 1:1:1, either synchronously or asynchronously.
Let’s call our temporary engineer Billy. Here are a few examples of how to empower her:
We will be successful when:
- Billy’s temporary journey ends when the project backlog specifies feature X has been delivered (insert link to project backlog here)
- Billy has participated in project meetings with relevant stakeholders
- Billy has provided bi-weekly progress updates to the team and leadership
- Billy has delivered the project within the set deadline
Setting clear expectations from the beginning helps with mutual understanding of delivery expectations. More importantly, getting the two team leads aligned helps them deal with the change and impact to their staff. Billy feels empowered because she can now work on improving skills, making decisions herself, and using the success metrics as boundaries for the decision-making process.
Situation #3: Using success metrics to help engineers transition into new teams
In this scenario, an engineer wants to make a lateral move within the organization to join your team. Let’s call them Peter. Peter has been working in the customer support area for three years and has been quite creative with building internal software solutions. He is now interested in moving to a frontend engineering role on a different team – yours! To determine whether he’s a good fit for a new role, he must participate in a three-month trial period.
Signs of lack of empowerment
Here are a couple of signs the engineer’s probation period might be at risk:
- The engineer doesn’t have some understanding of the new team’s mission, purpose, and culture
- There’s no clear plan for how and when the probation period will end, and what comes next
How to empower an engineer making a move within the organization
Before this probation period starts, as the engineering manager on the new team, you should align with Peter’s lead in customer support on your expectations for him, and how to define his success. Here are some examples of success metrics to look for when chatting with his previous lead:.
We will be successful when:
- Peter has been integrated into the team’s culture and participated in all team rituals
- Peter has learned and navigated well with team’s codebase, and demonstrated an ability to read code
- Peter has delivered the new feature X within Y timeframe
- Peter has followed the team’s good practices on code quality, documentation and ways of working (insert the URL to the team docs here)
Peter now knows the expectations from the beginning of the probationary period, and the leads (both you and the previous lead) know how to measure his performance. Moreover, Peter feels empowered to start a probationary period because, with a narrowed-down approach to success, he knows exactly what needs to be done to succeed, and when to ask for help.
Reflections
One of the biggest lessons around using success metrics is that your definition of success might change as time passes, so it’s important to review metrics frequently, and re-align if needed.
Success metrics are often only used for project and product management, to review performance at the end of a long trajectory. But I encourage you to experiment with using success metrics in various situations where you need to set expectations. The benefits of using this tool are clear: there’s way more room for decision-making without your direct influence, allowing for more creativity, freedom, autonomy, and growth.
