We're working through the Four roles your software team can't function without.
Last time we talked about the Bug Warden, but perhaps the most important is the "Epic Owner".
Why engineers should own epics
A software project goes through many phases with different collaborators involved in each phase:
Requirements gathering — PM leads, with user researcher supporting
Design — Designer leads with PM supporting
Technical planning — Engineer leads, designer supporting
Prioritization — PM decides when projects are ready to go into production
Development — A team of engineers lead, designer providing clarification and PM providing making strategic calls
Testing — QA leads, with engineers supporting and PM validating
Release & validation — PM leads, with engineers supporting
In theory, anyone could be the central coordinator throughout this process... you could make an argument for a PM doing it (to shepherd the business goals), a designer (to shepherd the user experience), or even a project manager.
And frankly, if someone else on your team is already doing a great job coordinating all of this stuff, let them.
But it's much more common that the individual contributors around you are focused on their... individual contributions. And there's a void for someone to step up and do some leadership.
If you're an engineer, and you want to show that you're more than just a grunt, that you're taking responsibility, and owning the outcome then you might want to take on the Epic Owner role.
Six process touchpoints the Epic Owner owns
Fundamentally, owning an epic means being there at key moments when work is handed off. We listed 7 phases of product development and not coincidentally there are 6 key handoffs that need to happen for a project to go smoothly.
1. User Story Workshop
When: The designer is picking up the project
Who: PM, Designer, Epic Owner
The designer's job is to get into the weeds of how a problem will be solved for a user. But before Engineering can start implementing a design, it's crucial that the team is aligned on what problem is being solved.
User Story Workshop Checklist:
☐ Distill project brief into concrete user stories (as a [persona] I want [scenario] so that [motivation])
☐ Propose simplifications
☐ Separate stories into P0 (hard requirements) and P1, P2, etc
Engineers can provide huge value at this stage, and get massive value in return:
✨ Engineers can propose simplifications of a concept, to avoid wasting Design time mocking up features that don't need to be built.
✨ Engineers can use stories later on to resolve ambiguities in the mockups, and to help decide between tradeoffs.
2. Design Review
When: A new set of designs is ready for feedback
Who: Designer, Epic Owner
Most engineers pride themselves on being able to build anything that is specced out for them. But Design Review is one of the places engineers ever create the most "value per hour":
Design Review Checklist:
☐ Point out any gaps in the flows that the designer may have missed
☐ Propose simplifications
The value engineers get from Design Review...
✨ Engineers save their own time avoiding building unnecessary features
✨ Engineers make sure the designs represent the full scope of work, so projects don't slip later on due to "scope creep"
3. Task-out
Who: Epic Owner
(Before development starts, or a firm estimate is needed)
Task-out means taking all of the User Stories, specifications, and mockups and planning out the sequence of tasks that need to be done for the feature to be delivered.
Task-out checklist:
☐ Break work into bite-sized tasks
☐ Ensure tickets have acceptance criteria
☐ Indicate which tickets are blocked by others
☐ Add priorities to tickets (blocker/high/low)
☐ Document questions to be resolved & decisions made
☐ Schedule additional design review if needed
Task-out provides...
✨ A way for Engineers to make reliable estimates. The simplest thing you can do is divide the number of stories by how many stories a dev typically does per week and get a pretty reasonable number of dev weeks to allocate.
✨ Proper sequencing of tasks avoids bottlenecks that cause delays and make Engineers look bad.
✨ Writing acceptance criteria often surfaces some remaining open questions. Answering those questions before development means Engineers avoid throwing away work halfway through development.
4. Kickoff
When: Engineers are ready to start development
Who: Epic Owner, Designer, implementation team
Kickoff is when you bring the implementation team into the fold and start actually building.
☐ Walk through designs
☐ Walk through task list and point out which work is out of scope for each task
☐ Talk through who will do what
☐ Move stories onto the board or into an iteration
☐ Assign a start and end date for project
☐ If questions come up, schedule additional design review
Value for Engineers:
✨ Avoid having engineers go down rabbit holes trying to do too many tasks at once.
✨ Make sure everyone understands the full scope of work.
5. Technical Design Discussion
When: Substantial questions pop up as to how to implement something
Who: Implementation team, Epic Owner
Once development has begun, one of the best things an Epic Owner can do is to pull the team together to resolve questions that come up.
Typically, there will be a specific dev who is charged with implementing something that could be done in a few different ways.
As Epic Owner, you should ask that dev to start a document with a brief overview of the problem and possible solutions.
Technical Design Discussion Checklist:
☐ Document open questions
☐ Document possible answers to those questions
☐ Document pros and cons for each possible answer
☐ Document decisions made
☐ Surface any new scope that has been added to the PM
Value for Engineers:
✨ Save time finding better, easier solutions to challenges.
✨ Avoid having the same discussions over and over again (decisions are documented!)
6. QA handoff/Bug Bash
When: A project is ready for QA
Who: Epic Owner, QA lead, PM
Finally, it's time to get a project out to your users, so we need to ensure quality. Having a Bug Warden will help, but as Epic Owner you also need to facilitate QA.
Your job as Epic Owner is to make sure important details about the changes get to the people who will be doing QA and onboarding customers.
This is also a great time to bring the PM back into the fold, when there's time to allocate final project resources and make final adjustments to scope, quality bars, etc.
QA Handoff Checklist:
☐ List new behavior that is in the release
☐ Note refactors that were done and what areas of the product they might affect
☐ List known issues
Value for Engineers:
✨ A good list of known issues means fewer duplicate bug reports the team has to triage
✨ If QA knows the full scope of changes they'll find more bugs for you sooner.
✨ Better QA means fewer embarrassing bug reports coming from customers, product demos, etc.
Quick, focused meetings
That's a lot of meetings! (you might be thinking)
And it is. But in my experience you ignore these key handoffs at your own peril. Every one of these checklists comes from actual projects that went off the rails.
But it's also important to remember that meetings don't have to be heavy or even lengthy.
To keep meetings light...
Invite as few people as possible—Try to keep out people who are "just going to listen." These meetings are for specific people to answer questions so they can get work done.
Use the checklists—I've given you a ready-made agenda for each of these handoffs.
Cut people off—If folks start discussing something that's not on the agenda, praise them for bringing up something important and tell them to put their own time on the calendar to work out the details.
Finish early—You might have 50 minutes on the calendar, but if you can let everyone go in 15, do it!
Delete process—If a meeting is not feeling critical for your team, consider removing it. And remove items from the checklists that don't feel essential too.
The goal is for these meetings to feel like like no brainers to everyone involved. I've laid out what I think is are some good starting points, but for your team to really buy in to this kind of structure, they need to feel like they are continuing to author the process.
It's better to do fewer of these meetings, but have your team really bought into the ones you do.
Be patient
Lastly, don't worry if you can't do all of these things right away.
The best time to introduce new process is when your team is struggling with a specific challenge.
Is your team struggling with buggy releases? Add QA Handoffs. Do you find your timelines keep slipping? Start doing more thorough Task-outs.
Rather than feeling like you're putting onerous process on people, it will feel like you're saving the day.
If it's still January 2025, and you are looking for an experienced Engineering Manager in San Francisco or remote... Hire me!
Part of a multi-part part series on "Software Engineering Roles"...
Follow me on LinkedIn or Twitter/X to hear when the next part is posted!
- Part 1: Four roles your software team can't function without
- Part 2: If you have bugs, you need a Bug Warden
- Part 3: How to "own" a project if you're an engineer
- Part 4: The Release Warden
- Part 5: The Program Manager
Cover image © Evgenii Naumov Dreamstime.com ID 335036916
Top comments (0)