Or, the small crisis with engineering management
In 2018, Honeycomb co-founder & CTO Charity Majors wrote a blog post titled, “An Engineer’s Bill of Rights (and Responsibilities).” We’ve recently updated and reposted it. The post describes how, in most software engineering organizations, power naturally accrues to managers—and also makes the case that it’s important to limit this accrual in some ways, guaranteeing certain conditions for engineering ICs, rather than leaving every aspect of their experience up to the whims of (often inexperienced, sometimes power-hungry) engineering managers.
When it was originally posted, back in 2018, it was timely. It came just a year after Charity’s blog post about returning from manager to IC that resonated with a huge number of people (and is still frequently referenced today). The software engineering community was rethinking some long-held ideas about engineering career paths. There was fresh momentum around the idea that engineering ICs should be able to progress up a dedicated technical career ladder—one that didn’t top out where management levels began, or push ICs on an up-or-out path into management. And in a moment where it was as hard as ever to hire and retain talented software engineers, our software systems also continued to grow more and more complicated. These constraints incentivized managers to think hard about how to retain and grow their best senior engineers.
I was one of Honeycomb’s engineering managers at the time, and while I enjoyed the post, something about it struck me funny: a certain lack of parallel structure. You might even be able to spot it if you scroll the post quickly. That’s right: engineers have rights and responsibilities. But in this post, managers only have responsibilities! No rights for them. I raised this observation with Charity at the time, but we mostly laughed it off. The truth was, management roles came with plenty of power. I could see why enumerating their various rights didn’t seem illuminating. Still, something about the post made me itchy, and I had been trying to put my finger on why ever since.
Fast-forward to 2022
Four years later, in 2022, it feels like the landscape has changed. I no longer spend as many late nights worried about how we craft a compelling career ladder and set of roles for senior engineering ICs. Riding the pendulum from manager back to IC is common, and there are even high-quality books, websites, and conferences about navigating the upper echelons of the IC ladder.
I’m also no longer primarily a line manager myself. My current role as VP of Engineering has me managing a few senior ICs, but I am mostly managing other managers and directors now. And these days, I am up late at night thinking about how to retain and craft a compelling path less for ICs than for managers—especially line managers.
Why? Admittedly, partly for crass practical reasons: so many of the best and most promising managers I know have left management roles for senior IC roles since 2018, and as someone who has to hire managers, this creates a supply problem for me. Sincerely though, I also observe that a truly staggering number of Honeycomb’s most effective, most admired senior ICs are former managers, and while they seem quite happy and I wouldn’t wish them back to their old roles, the fact that all of these smart, thoughtful, driven, emotionally intelligent people all chose to leave the same high-paying, respectable role must mean something (yes, respectable—it is unfortunately a fact universally acknowledged that every in-law is more impressed by “Engineering Manager” or “Director of Engineering” than “Senior Software Engineer” or “Staff Engineer”).
Partly, this is just a sign that we’ve made senior IC roles more appealing—more lucrative, more autonomous, with clearer career progression—as we intended to do! This is good. But I think it is also a sign that the job of engineering manager has gotten harder, and in many organizations, it can now feel like an unwinnable game, caught between two distinct and sometimes conflicting generations of expectations.
New expectations for managers
Community conversations over the past five years have emphasized a whole new set of traits and responsibilities in engineering managers.
- Emotional intelligence
- Creating psychological safety
- Supporting employees in crises (pandemic, wildfires, extreme heat, epic storms, consumer goods shortages)
- Responding with care and empathy to horrifying current events in the news
- Coaching, mentoring, and career development—all while balancing the needs of the business against those of the employee, and sometimes putting the needs of the business first.
Managers who match the classic bad boss stereotypes of the prior era—managing by fiat, feeding their own ego, giving orders with no context, seagulling with unexpected changes, treating employees like “resources”—will often see their teams evaporate quickly out from under them, or even find their own job at risk.
These changes are all categorically good for our teams, but we have to acknowledge that in many cases, they represent a dramatic increase in the scope of expectations for managers—and most of our organizations are poorly prepared to provide any kind of support in helping new managers learn how to fulfill these lofty expectations. Many people stepping into these roles will also have never had a manager in their own past successfully model how to do any of this.
These cultural changes that have led us to shift our expectations for managers have traveled from the bottom up. We’ve revised how we think about IC and manager roles, but what’s happening at the tops of our organizations hasn’t changed. The pressures creating those conditions also haven’t changed (e.g. how companies are funded, who our leaders must answer to, and what incentives the business as a whole has).
This means this new set of responsibilities for managers is today purely additive. From the perspective of most of our businesses, the exact same imperatives for managers exist as did 50 years ago, the same imperatives that allowed that generation of terrible bosses to flourish and be stereotyped everywhere from The Office to Office Space.
Ironically, now that we have retooled our expectations for this role (and made it harder!), it has become more essential than ever. At Honeycomb and elsewhere, good engineering managers are often some of the most essential glue holding software teams together and helping employees feel a sense of belonging and purpose at work. The (good) changing expectations we’ve brought to this role will need to eventually permeate our entire organizations, if we are serious about evolving our workplaces for the better.
To help protect our engineering managers and support them in some of the challenges of this changing role, I propose the following contract.
Engineering manager’s Bill of Rights
Our organizations will build a culture of respect for both management and IC work.
This sounds odd to say, because the historical norm was disproportionate respect for managers and not enough for everyone else. But a backlash in recent years has sometimes swung the pendulum all the way toward disdain for the management function—especially as engineering management has diversified and some key management skills are now coded as “feminine” work. Just as we want to build organizations that don’t tolerate dunking on marketing, recruiting, support, or engineering IC work, we should cultivate the same respect for management.
We’ll provide a career path within management that has multiple ways to advance.
At many software companies, the average manager is relatively inexperienced. Talented, mostly-competent managers are often given opportunities to move into impressive-sounding manager-of-managers roles quickly—and they’ll usually choose to do so, since progression within the same type of role can be limited. But many companies can benefit hugely from having experienced, long-tenured line managers. Just as in engineering IC roles, you can continue to build your management skills for many years before topping out or hitting a ceiling on your potential organizational impact. People who choose to specialize in line management roles are often an incredible gift to our organizations, and we should incentivize this by allowing for a range of levels within each management role type and not forcing people to move higher in meta-management to progress.
We’ll be straight with our teams about what managers are there to do.
So much of the conversation about engineering managers in recent years has focused on what it feels like to interact with your manager: as a coach, as a mentor, as a confidant, and as a general-purpose liaison to the company. In all of this, it’s easy to forget that we have hired managers to provide business value to the company. We owe it to our managers to remind our teams what they are held accountable for, even when these goals are not the ones that resonate most with individuals on the team.
We’ll cultivate the flow of feedback in all directions—and remind ICs that they should expect to give feedback to their managers, not just receive it.
We often talk about the imperative to give feedback in organizations as though it only flows down and sideways—our managers owe us feedback, and we owe it to our peers. But if we are sincere about wanting to create more inclusive, equitable organizations with more empowered employees, something is clearly missing from this equation. We want managers to be incredibly emotionally intelligent and intimately familiar with their team members’ dreams, preferences, and experiences. This doesn’t happen without a two-way communication conduit—one that involves positive and constructive feedback flowing in both directions.
In particular, plenty of line managers rarely get positive feedback from their teams—even when they’re doing tons of things their teams like! I’m not arguing for kissing your manager’s butt, but sharing context with them about what is working will help them know which things to keep investing in as priorities shift around them. And every job can become a grind when the people working most closely with you never acknowledge the things you do right, regardless of how they relate to you in the org chart.
This particular point about giving managers feedback is easy to say but often hard to do in practice. The power dynamic between managers and reports often makes a two-way flow of feedback extremely challenging. A precondition for this has to be that managers create an environment with a high degree of psychological safety and show a genuine interest in accepting feedback gracefully and taking action on it. This won’t be the case at every company or for many reports, so this obligation is explicitly conditional. But after all the conditions are met, that two-way flow of feedback is a critical ingredient for building a management team that can adapt to employees’ needs as the company grows and changes. We can’t ask managers to be mind-readers (even though some of them are pretty good at this).
We’ll allow manager & IC compensation to move independently with the market.
This might be the most controversial thing on this list, and it’s not even something we do today at Honeycomb. It may also feel like a hard pill to swallow, given how hard we all pushed to make IC compensation equivalent to manager compensation at many of our companies. But when I look at the steady drip of extraordinary talent out of management and into other roles, and so often the reasoning for leaving boils down to, “The extra cognitive (and emotional) overhead and energy drain compared to an IC role just wasn’t worth it,” well, using market signals to help set compensation for managers would give us a time-honored way to help make these roles more “worth it.”
To be clear, I don’t think we should backslide on the other great changes to how IC roles stack up. ICs should still have a ladder that includes a parallel, equal track to management. We should not require that two equivalent ladders on the IC and management tracks use the exact same comp bands; we can use market data to help us understand whether one should be higher than the other or vice versa, as we do for other roles.
We’ll provide transparency and guarantee a response to our teams even when the answer isn’t easy.
Transparency is often a centerpiece of the new expectations for today’s engineering managers. More and more, our ICs have the (good and fair) expectation that we’ll be straight with them about what is happening in our organizations, and why—in fact, they need this to do their jobs well when we entrust them with more decision-making power.
But this expectation of transparency hasn’t always made it all the way up the chain. If we want our engineers to operate with autonomy and ownership and our engineering managers to be successful, we must arm them with real information about what’s happening at the highest levels of the company, and why. Too often, transparency stops at the EM and they’re stonewalled by upper management, who neither loop them into what’s really happening, nor feel accountable for accepting feedback from the team or providing a response.
In organizations that operate this way, the EM is destined to be crushed between upper management’s silence and these very legitimate new expectations from their teams. We have to recognize that transparency for our managers—and a response to team feedback, even if it’s “no, and here’s why”—are essential to allowing managers to deliver on this new bargain their teams are asking for.
Engineering manager’s responsibilities
The engineering manager’s responsibilities enumerated in Charity’s 2018 post are:
- Recruit and hire and train your team. Foster a sense of solidarity and “teaminess” as well as real emotional safety.
- Care for every engineer on your team. Support them in their career trajectory, personal goals, work/life balance, and inter- and intra-team dynamics.
- Give feedback early and often. Receive feedback gracefully. Always say the hard things, but say them with love.
- Move us relentlessly forward, watching out for overengineering and work that doesn’t contribute to our goals. Ensure redundancy/coverage of critical areas.
- Own the quarterly planning process for your team, and be accountable for the goals you set. Allocate resources by communicating priorities and recruiting eng leads. Add focus or urgency where needed.
- Own your time and attention. Be accessible. Actively manage your calendar. Try not to make your emotions everyone else’s problems (but do lean on your own manager and your peers for support).
- Make your own personal growth and self-care a priority. Model the values and traits we want our engineers to pattern themselves after.
- Stay vulnerable.
These were important to enumerate then (and many of them felt less self-evident than they do today), and I would still double down on most of them. The changing landscape of 2022 inspires me to add a few more to the list:
- Put on your own oxygen mask first. This is a stronger variant of Charity’s “Make your own personal growth and self-care a priority.“ So many crises have landed at our feet over the past two years, and I know a number of engineering managers who have stretched themselves incredibly thin attempting to support, care for, and cover for their teams. It’s lovely when managers can play this role for their teams, but we also have to remember that they are humans with their own problems who are not trained as therapists or even coaches. It’s essential to set boundaries around what we can and will do to support our teammates’ personal needs. Managers can often help employees seek out the additional support they need from a coach, a mentor, a therapist—but sometimes there are problems we can’t reasonably solve for our team members, and that’s ok. It’s also ok for the bandwidth we have for these problems to fluctuate based on what’s happening in our own lives.
- Share the weight of accountability with others. Managers have traditionally been the conduit through which accountability flows in our organizations. But this idea that managers bear all accountability for team performance is rooted in the older world of management, where ICs are fungible “resources” who can’t be trusted to be accountable themselves.
If we are serious about having high-autonomy ICs, we have to share the burdens of accountability with them and not just share the credit when things go well. We have to be honest with them about the impact of their work and where the whole team’s performance sits relative to expectations—and bring them along with us when we need to fix problems. Autonomy is a form of power, and as Karla Monterroso wrote, “You can’t have power and low cognitive load.”
Conclusion
While I’m writing this post as a counterpoint to many conversations I’ve seen on social media about the changing nature of engineering management, all of these conversations also have made me feel genuinely hopeful. It’s inspiring to see so many of us deeply invested in this meta-mission to have more equitable, more humane, more sustainable organizations. But as we raise our expectations for our leadership and our institutions, our managers’ and leaders’ jobs get harder than ever.
Each time we make things better for one role (recently senior ICs) we risk shifting that burden to other roles (now EMs). Many of our engineering managers are the people leading the charge toward better, more humane practices—and we have to make sure we’re not burning them out in the process as we strive to make our whole organizations better.
If you missed Charity’s post, you can find it here.
Acknowledgements: The ideas in this post are indebted to two years of Twitter conversations from and between Karla Monterroso and Marco Rogers about our changing expectations for leaders & managers and the evolving needs of organizations and teams today, especially as they push to become more diverse and equitable. I strongly recommend Karla’s blog post, “When We Get Power” to anyone in a leadership role hoping to build a better and more equitable organization.
