We've all seen it go both ways:
Company A: Has no real structure in place, just a bunch of stuff that tends to happen because specific individuals care about it, and make it happen.
Company B: Puts structure around everything. Everyone has strictly defined responsibilities. Doing anything across multiple roles requires navigating a byzantine maze of personalities and processes. So people just focus on their job description and block everything else out.
One of the pieces of feedback I got at Spaero Bio that made me incredibly proud: a frontend dev told me that because of my leadership, this was the first company he worked at that struck the right balance between process and freedom.
So let's talk about the structure that a software engineering team can't do without.
Solid engineering, every time
When you look closely at the key contributors at companies in that "Company A" category, you will see passionate people taking responsibility for critical work:
- An engineer who was driven to drive out bugs
- A tech lead who made sure that estimations were done reliably
- A designer who sought out blunt feedback from engineers, business, and sales people
- A PM that diligently tracks progress against key product milestones
- And so-on...
But in the end, you can't clone these people. And half of your teams will be missing half of these passions. All the key skills are represented on your team, and yet these critical work pieces of "side work" are not done consistently.
I have found that the way to turn a team of productive, passionate engineers into a steady, trusted unit that the entire organization can rely on, is to introduce rotating roles that go beyond the core engineering responsibilities.
"Roles" = people know what today's job is
The foundational role on an engineering team is of course "Engineer". Every engineer knows the basics of what this job entails: You grab up some kind of spec, you write the code, and you deploy it.
But left to their own devices, software engineers will run into a number of classic roadblocks:
A smart engineer spends lots of time building beautiful code that wasn't necessary in the first place.
"Trickle requirements" cause expensive rebuilds of the same features over and over again.
Bug reports pile up with the Product team thinking Engineering will handle it and Engineering thinking Product will handle it.
Releases are going out but no one knows exactly when features go live.
Embarrassing bugs appear during a key demo or customer onboarding.
Projects have "two weeks left"... for two months.
And most of us know some ways to avoid these problems. It's not that we want these things to happen.
The challenge is the typical engineer has so many demands on their time, it's impossible for them to do everything at once.
That's where my four roles come in:
👉 If you know you're taking the Release Warden role for the next release, you know to focus on the work that is wrapping up, not upcoming work.
👉 If you are the Epic Owner for an epic that's about to have a kickoff next week, you know to focus on planning that work, not fixing bugs.
👉 If you're Bug Warden for the current release, you know that triaging bug reports quickly takes precedence over finishing that new feature.
👉 If you're the Program Manager you know that shipping is not your first priority. You're make sure information is flowing between stakeholders so the best possible decisions are getting made.
... and if you are not in any of those roles this week, you know that it's the perfect time to be heads down on a project, cranking out that sweet, sweet engineering.
Roles the rest of the organization can trust
I won't pretend these came out of a principled analysis—they didn't.
But they did come out of a decade or two of trial and error... Seeing projects get jammed up, adding process to smooth things out, removing process that was being skipped, refining responsibilities in response to retrospectives, and so-on.
And in hindsight, I think this kind of heavier process works best near key inputs and outputs between Engineering and other parts of the organization:
Inputs to Engineering:
- Bug reports (from QA)
- Product specifications (from PMs)
- Designs (from designers)
- Business priorities (from PMs)
Outputs of Engineering:
- New features (for QA, Sales)
- Bug fixes (for QA)
- Roadmaps (for PMs)
- Status updates (for Management)
- Design feedback (for Designers)
These are moments where some information has been generated that is either going to inform the engineering work, or will inform the decisions the rest of the organization is making around that work.
As few roles as possible, as little process as could work
One final note, on taking in too far...
It can be tempting to just document "all the roles!" and give people a checklist for every situation. But there's a very specific reason why this post is four roles your team can't function without and not ten roles.
If you introduce too much process, it starts to feel very heavy. People start skipping steps, and you lose the whole "trusted unit that the entire organization can rely on" thing.
If you're a senior engineer, or an engineering mananger, or a product manager who is trying to introduce this kind of process to your team, you can only introduce one process step at a time.
Your team needs time to digest these processes. To integrate them into their existing habits. And to begin to trust that 1) they're really necessary, and 2) they're really going to be happening from now on.
There will be areas where your team is limping along, and you know how to fix it, and you don't. Because you are still building trust somewhere else in the process.
Let's do the work
We can talk all day about roles and responsibilities in the abstract. But these are production-oriented roles with very specific things for an engineer to do, and specific things they won't do.
So in the next series of posts, I'll dive into each one of these roles in detail: The decisions that each role gets to make, the meetings that need to happen, the communication that needs to occur.
Follow me on X/Twitter to hear when the next part is posted!
Part of a multi-part part series on "Software Engineering Roles"...
- Part 1: Four roles your software team can't function without
- Part 2: The Epic Owner Role
- Part 3: The Release Warden Role
- Part 4: The Bug Warden Role
- Part 5: The Program Manager Role
- Part 6: Checklists: How team process evolves
- Part 7: Evaluating Engineer Performance: Roles and influence
Cover image copyright © Ominaesi | Dreamstime.com
Top comments (0)