More on Management
I’ve managed and led software engineers, technical writers, IT developers, project managers, program managers, sysops engineers, business systems analysts, and marketing content editors. Every discipline has its own culture and particular challenges.
I’m glad to have led so many functions: By bringing direct experience to interactions across an organization, and empathy for the challenges and incentives each group has, it’s easier to make sure everyone feels heard as we negotiate for mutual success.
The two things I examine every time I’ve entered a team are prioritization and roles & responsibilities: One or the other (but often both) are usually at the root of any conflict or anxiety the team’s experiencing in the wake of a transition.
If you’re in a fast-paced startup trying to choose which problems to go after, or a more mature company that has to make tradeoffs, good prioritization separates capable leaders from managers who think every problem can be solved with more headcount.
I’ve led small teams in a high-growth environment where it was a challenge to pick just one thing and do it well, and I’ve led larger groups dealing with what it means to live under budgets and ratios. What they all share in common is a need to prioritize their work.
Early on I adopted an exercise to use with my teams and with my own manager to make sure everyone agrees on what matters, and ensure that the things we say are our highest priorities are treated that way. Thinking About Priorities describes why prioritization is important and walks through a prioritization exercise I developed for my teams.
I also wrote a prioritization app to help with both the exercise, and socializing a team’s priorities in an accessible manner. You can follow that link to create your own account and give it a spin.
Roles and responsibilities
People in younger companies often get nervous when decision-making frameworks start coming into play. They’re a sign that more and more functions are maturing, that people are becoming more specialized, and that roles and responsibilities are becoming harder to keep track of and respect.
I was introduced to my first RACI matrix with the ominous phrase “this is not a land-grab.” It felt a little like one, because I wasn’t used to people being clear about roles and responsibilities: We were working in a young company that had just crossed 200 employees, and everyone was still used to doing a little bit of everything.
Of the assorted decision-making frameworks, I’ve come to favor DACI (Driver/Approver/Consulted/Informed). It tends to be a little easier to pick up for everyone concerned because the “driver” and “approver” roles are more intuitive than “responsible” and “accountable.” When I come across teams that use another framework, though, it’s still a good sign.
As part of my role as the chief of staff in an R&D organization, I wrote a guide to DACI meant to help leaders and managers across product, engineering, UX, program management, technical publications, and operations work more smoothly together as the group looked ahead to growing over 30 percent in the coming year.
Building on DACIs with RFCs
Once you’ve got the hang of DACI, the “request for comment” or RFC is a good second tool to pick up.
Where a well-written DACI ensures everybody understands their roles and responsibilities, RFCs allow you to apply a DACI to a shared challenge of some kind. I’ve used RFCs to:
- Make technical decisions
- Design projects
- Create working groups
People often do that kind of thing face to face, but as more companies go hybrid-remote it becomes important to look for ways to help people work asynchronously. One way to do that is to lean in to writing things down and collaborating on a written document over a period of time, instead of trying to wrangle meetings across timezones and geographies. That lets everybody work at the time of day when they best work, it can help teams become better at setting and observing deadlines, and it often leaves less room for ambiguity than a meeting.
It’s important to remember that people have all kinds of styles of interacting, so the guide I wrote (linked at the bottom of this section), leaves room for in-person interactions. As a leader introducing this kind of tool for the first time, it’s important to remember that not everybody is comfortable working in the open like this, or in writing, so be ready to show some patience and leave slack in the schedule to help people along. If you have access to a technical writing team, you may find that one of the writers is eager to offer small business writing classes to your team, which can do a lot to increase confidence.
When it comes to actually writing an RFC, I really like Hashicorp’s RFC template, which is freely downloadable. I also made my own version in Markdown for use with my preferred text editor, tweaked for my own context (and friendlier to tech types).
I also have my own process for driving an RFC along, and wrote a guide to writing and wrangling RFCs that I use across my teams.