The Project Owner Role

You work on a dev team that owns a slice of a product at Unicorn Ltd 🦄. Your Product Manager / Owner has reviewed the latest batch of user research and she found out that a statistically significant amount of customers would be very interested in feature X. How do you go about it? Chances are you need a project.

Some companies have dedicated project managers for this kind of thing. Others rely on engineering managers to fill the role. But, a more interesting approach in my opinion, and also the way many tech companies go about it, is to give the ownership of a project to an engineer in the team.

A couple of reasons why this is great:

• It’s an opportunity to learn skills that would be hard to be exposed to otherwise e.g. stakeholder management, communication, delegation, leadership.
• It’s easier to put together a back-up plan if the engineer in charge needs to disappear for a long time (or leaves) when everybody in the team is used to leading projects.

So Bob will lead the project, but what does that entail?

I’m a big fan of documenting everything. Committing to paper makes it easier to clarify expectations with the team. It’s also easier to gather comments and suggestions that will help to continuously improve.

Here is an example of a set of expectations I used and refined with some teams in the past, that will help Bob succeed as the project owner for feature X. They are heavily based on a similar resource by Gergely Orosz, author of The Pragmatic Engineer.

TL;DR

Project Owners have end-to-end responsibility for the execution of the project and are expected to do the following:

• Set up a framework for collaboration
• Manage risks
• Communicate project status to stakeholders
• Help the team ship and delegate
• Inspire the team

Project Owners are NOT:

• The only person that works on the project
• The silo of information or domain knowledge
• The gatekeeper to the code
• Solely responsible for the delivery and success of the product / feature

🤝 Set up a framework for collaboration

Initial setup

• Review and complete a feature spec / project brief. For product-led projects, the person creating the document will likely be the Product Manager. For engineering-led projects, this will likely be the Engineering Manager. As a Project Owner, you will ask clarifying questions and make sure nothing important is missing.
• Agree on success metrics for the project from the start.
• Complete an initial spike to get an overview of the project and explore unknowns and areas of ambiguity.
• Create a list of stakeholders, with a clear contact person and make sure they are included in regular updates.
• Schedule a kick off with the team including all relevant stakeholders. This addresses the “why” of the project and ensures alignment and common understanding.
• Ensure feedback from stakeholders is captured, aim for feedback / awareness from at least one person from each stakeholder group.

Design and documentation

• Set up and maintain documentation for the project. Start with a design document, and use it to capture others’ input and build up alignment. Supplementary information can be nested as required. This document will be the main artifact to inform decisions down the line. Run one or multiple “design review” sessions as appropriate.
• Set up team collaboration tools (when not available), e.g. dedicated Slack channel, digital whiteboards.

Planning and execution

• Break down the project into milestones, and milestones into tickets; consider scheduling a 3 amigos session where appropriate.
• Work with other team members to ensure proper planning and successful delivery of the project.
• Meet with other teams if necessary.
• Explain your tickets and answer questions during planning and refinement sessions.

Day to day project management

• Get frequent updates across the team, typically (but not limited to) stand-ups.
• Demo progress regularly, typically (but not limited to) show & tells. Proactively delegate to team members where relevant.
• Document decisions e.g. using decision logs.
• Suggest sprint / weekly goals to build alignment and track dependability.
• Ensure basic ticket hygiene (epics, labels, descriptions, estimates).
• Encourage face to face information exchange where appropriate. Studies have shown that face to face communication is generally more effective, but it’s ultimately a team decision and depends on the context.
• Do a project retrospective, at the very least, at the end of the project / significant milestone. Please note that this is different from (and complementary to) the regular team retrospectives.
• Gather feedback. When appropriate, send out a form to gather feedback regarding cross team collaboration. You may want to use more informal methods if the scope of the collaboration was small.

🚨 Manage risks

• Understand all parts of the project at a high level, from mobile to back-end to business impact. If you are a mobile engineer, get familiar with the back-end stack. If you are a back-end engineer, get familiar with the mobile release process. You will be the person with the most context on the project, make sure you know what the top issues on each stack are.
• Call out risks honestly as they arise. If time, scope or people change, escalate to your Engineering Manager to decide what to do and how it affects the project.
• Keep the project on track, across all stacks. You own communicating the status of the project proactively, may it be off track or going well. Ensure blockers are removed and discussions are effective. In those areas where ambiguity slows us down, drive resolution. Watch out for recurrent discussions that don’t take anywhere.
• Ensure proper monitoring and alerting from the start, those must not be an afterthought.

📣 Communicate project status to stakeholders

• Communicate progress in relation to success metrics, quarterly goals and the project itself e.g. are we 20% done? or 80%?
• Keep a status tracking register up to date where appropriate, to help others get an idea of the project progress on demand.
• Help identify “hidden” stakeholders, anyone not obvious that needs to be updated as well, typically discovered during the execution phase.
• Escalate issues swiftly and collaboratively where appropriate.

🚀 Help the team ship and delegate

• Help engineers focus on the next important thing, one step at a time. Frequently remind the team what milestone you need to ship next.
• Delegate where it makes sense. You can delegate upwards (e.g. to your Engineering Manager) as well as to team members. It can be a win-win to share some of your responsibilities, others learn and grow while you have more time to focus on what’s more important to you next. Be clear that you’re delegating or asking for help and what your expectations are for the person taking this on.

🎉Inspire the team

• Keep it fun!
• Celebrate the small wins, hitting milestones and people who help others.
• Involve team members in the running of the project, and be open and welcoming to suggestions.
• Over-communicate milestones with the wider team.

There you have it. Feel free to come up with your own version, adapt to your environment and empower your engineers by setting clear expectations. Autonomous project owners that can drive success for the team is what you’ll get. Thanks for reading!