We’ve all seen the news about tech layoffs.
If you’re an engineering manager, are you having to squeeze more out of existing teams, because adding staff anytime soon is unlikely?
Maybe you’re tempted to micromanage your developers, thinking that if you know every aspect of their work, it’ll boost productivity.
But, that approach doesn’t feel right, and you know your devs would hate you for it. What’s an engineering manager to do?
We asked our own engineering manager, Kate Bierbaum, to offer some effective ways to lead software teams while managing up during economic volatility.
Is it natural to want to micromanage developers in this economic environment?
Kate: The economic environment absolutely leads to a desire to increase efficiency and productivity on software engineering teams. Throughput of the team that could previously be increased by hiring now needs to be resolved in other ways. In this situation, the natural reflex to micromanage comes from the coupling of the pressure to deliver and feeling a lack of control.
When I feel these pressures start to build for me, I remind myself of the times I’ve done my best work — when I was aligned on the results and risks of a project, when I was trusted, and when I had the autonomy to deliver in a way that worked best for me and the team.
Engineering is a creative discipline and giving folks the autonomy to manage their work leads to better outcomes.
Teams that I have seen micromanaged and unempowered for the long term share a few common unfortunate traits: higher turnover, blame rather than looking for creative solutions, high levels of stress, lack of innovation due to fear of failure, and a culture of helplessness.
In the face of limited hiring, what so-called 'efficiency' tactics should engineering managers avoid?
Kate: In order to maximize the efforts and effectiveness of the team you currently have, it can be tempting to fall into these four short-sighted patterns with unintended consequences.
Increasing time spent on feature work by deprioritizing technical debt or “keep the lights on” measures.
Engineering teams spend a decent amount of time outside of feature work — customer support escalations, tech debt, tooling enhancements, system operations, etc. When resources are tight, there’s a temptation to underestimate the time these activities take, or deprioritize them altogether. This can play out in a couple ways.
First, some people will burn out because they’ll still take on the responsibilities, but without time allocated for them. The team can experience morale and efficiency problems because the buildup of these items is effectively paper cuts everywhere in their workflow.
Second, the team could lose trust in management and become less engaged. As an engineer, when you see items that would increase your individual productivity and product health disregarded in the name of efficiency, resentment can build.
Teams usually know what is holding them back, so ask them! Then, build trust with them by allowing them space to make some of those changes.
Not setting realistic expectations based on team velocity.
There is a very real pressure to deliver on goals created with certain staffing levels in mind, despite the hiring plans being adjusted. It is critical that engineering managers have honest conversations with stakeholders to ensure the team is working at a sustainable pace. Being a yes-manager will lead the team on a path straight to burnout.
Hyper-owning all aspects of delivery to get your very important feature across the line.
As the team’s manager, you may feel if you know and own every aspect of various projects, you can own the outcomes. While it’s absolutely true that part of a manager’s job is to ensure the projects are successful, taking on everything yourself can stifle a team’s creativity because they’re responding to directives rather than considering the entirety of the problem.
The manager owning the whole project can also lead to bottlenecks and gate-keeping, such as asking for signoff on technical decisions. These bottlenecks don’t allow the team to build a strong muscle around internal collaboration, which will hamper them in the long term.
Conveying an overly high sense of urgency through frequent communication.
When there’s a high sense of urgency around a new feature or bug in progress, it’s difficult to find the balance of getting the information you need as a manager (timelines, etc.), and allowing the team to continue to focus on delivery.
Asking for updates multiple times per day leads to interruption of work, context switching, and can contribute to lack of trust between the team and stakeholders.
What should engineering managers do instead to maximize efficiency?
Kate: What does it look like to build the kind of environment where people can accomplish their best work? Align your team to the mission — what are you trying to accomplish? What is the reason behind what they are doing? How will it further the company?
Teams that see the value in what they’re trying to accomplish naturally show ownership over their work and a drive to bring it to the customer.
Instead of using directive tactics, try guiding questions to make critical points. For example, ask the team how they are considering the non-functional requirements of a new feature, like performance, observability, etc. This can lead to brainstorming around solutions that may not have been considered.
Also, support your team in meaningful ways. Celebrate their wins, evangelize the hard behind-the-scenes work that keeps the systems running, have the hard tradeoff conversations that keep their workload manageable, and make sure they are working on the most impactful and highest priority work.
What do you think teams need most from managers during economic uncertainty?
Kate: I think teams need transparency the most. People want to know how their work is contributing to the larger picture. They want to know about the company’s performance, and where they stand against your expectations. They want to know what is top of mind for you — what excites you, what challenges you expect, and how they can contribute.