So you recently volunteered or were assigned to be the project owner for a large engineering deliverable.
Here's a guide to help you succeed.
What does it mean to be a project owner? What are the expectations for the role? How to do it well?
In short:
You. Are. Responsible.
Gulp.
Requirements or outcome success metrics unclear? You must seek clarity.
Teammates blocked? You help unblock them.
Cross-team dependencies? You chase these down.
Marketing needs an estimate for when they can use the demo? Someone will ask you.
Architecture? You need to make sure it's clear and well-communicated how the project will be built.
Project running behind? Inform stakeholders and get it back on track.
End user documentation, release notes, demos, knowledge sharing? You are responsible for ensuring this happens, too. Always bring others along with you.
PR reviews? Design reviews? Testing? Compliance? Deployment? CI/CD? Production uptime? Observability? Yes, yes, all that. You are responsible for ensuring all aspects of the development lifecycle are running smoothly.
This may seem overwhelming at first. But don't worry! Although you are responsible, you aren't alone. You have a team behind you ready and willing to help.
You don't have to do all these tasks yourself, but you do have to ensure someone does them.
This seems like a lot of work. Why should I do this? What's in it for me? Shouldn't my manager be doing all this? It's taking away time from coding.
With all this responsibility comes significant influence over how the project will be designed, architected, and developed. You get to shape the project and make a significant impact. Leading and shipping a project can feel immensely rewarding. It's also a critical skill to have as you grow as an engineer. Your manager has your back and will coach you through it.
Team communications
- Consolidate long-form written artifacts, diagrams, and decisions in a project Confluence page or Google doc
- Resolve open question threads in project docs and Slack. Create new Jira tickets for larger tasks as needed.
- Communicate/document the "Why" behind decisions.
- "Links or it didn't happen." When answering questions (ideally in public channels not DMs), link to answers in the internal or external documentation.
- Schedule meetings as needed, with a clear agenda and effective meeting practices. Send out meeting notes afterwards, link to key decisions.
- Onboard new team members to the project.
- Delegate effectively
Requirements
- Clarify initial requirements and the "Why" with PM.
- Gain enough context about The Problem and share this context with the team.
- Share your own opinions with PM on requirements. Use your 49%.
Stakeholder communication
- Post frequent project updates to the project Slack channel. It's not noise, it's work.
- Post demo videos often
- Consider summarizing weekly updates in a Jira epic ticket
- Ensure Jira ticket status is correct
End user documentation
- Work with PM / tech writing to draft user facing docs
Frontend designs
- Ensure a designer is collaborating with the team on design proposals early.
- Don't wait for full high-fidelity mocks to start engaging with designers on the experience.
Backend services
- Facilitate team review of APIs. Consider opening PR review discussion of OpenAPI swagger specs.
- Thoroughly review the DB schema. This part is harder to fix after it ships.
- Keep project README.md up to date.
Productionization
- When transitioning from POCs to real features, make sure to account for hardening the solution for production.
Architecture
- Update system diagrams
- Consult other architects for reviews
- Review best practices, e.g. REST API guidelines
Security/Compliance
- Learn what the security/compliance rules are and follow them.
Observability
- Create data dog dashboards for uptime monitoring
- Write runbooks so people can diagnose critical production issues quickly in your absence
- Ensure production logs are clean and actionable
Testing
- Keep QE in the loop. Shift left.
- PMs should be trying the features, too
- Triage bugs with QE and PM.
- Load test, scale test
Sprint planning / refinement
- Help prepare tickets for refinement with clear acceptance criteria
- Work with PM to prioritize work
- Set clear incremental milestones for long running projects
Success metrics
- Ensure the "Why" behind the project is clear to all
- What outcomes is this project aiming to achieve?
- How to measure success of the project? "We shipped it" is usually not the last step.
Implementation
- Whether or not you are the primary engineer writing the code, you still have to bring others along for the ride. No knowledge silos.
- Say what you plan to do, then do it.
PR reviews
- Review all PRs to ensure alignment, even if others are reviewing them, even if they've already merged.