Being an engineering manager can be a huge challenge. One day you’re developing and reviewing code. The next day, you’re responsible for not just individuals, but multiple teams. And the ultimate goal is to not only complete the project successfully, but to maintain productivity among your teams and make your people feel good.
Every engineering manager is different, as are their roles, responsibilities, and ideas for improving their teams. However, across the spectrum, there are a few common challenges that every manager faces when entering the software industry.
The Biggest Challenges for the Engineering Manager
High SDLC Blockers, and Low Workflow Visibility
Today’s SDLC is driven by the culture of continuous improvement and ongoing iterations. It is an engineering manager’s role to figure out the impediments their devs face, challenges in delivering results, or the processes needing some optimization. A weak SDLC is a silent velocity killer, yet most managers find it challenging to know the ‘what’ and ‘why’ behind it. While talking to 100s of EM, we found that managers do know something in their present process is lagging, and have metrics results as north-stars; they just don’t have the right indicators or approach to move forward. One reason behind the persistent manager conundrum is limited visibility.
Most managers we talked to struggled because their teams were not making enough deliveries, and deemed ‘slow’. Looking at the cycle time metric gave them limited value, however, after centralizing all process indicators in one place, they could see that devs were working outside work hours, and the workload became unendurable. Only when managers got full-fledged visibility into the issue, they could create a plan of action, reconfigure the team’s time and tasks, and earn trust of teammates.
Broken Communication
Alignment issues and context switching between software teams are real, and most engineering managers have largely recognized the persistent issue. And that’s where the second top challenge of an engineering manager lies- to resolve communication debts stemming out of the two.
Engineering managers need to be constantly updated with their dev’s work items. The idea is to take stock of the present team status: what the engineers are doing, their blockers, and how to move forward. That’s why standups were originally invented. But, most standups today are more or less about status updates and rarely end with some constructive feedback, or discussing blockers.
Even after hour-long calls, devs might not have clarity over how to resolve their blockers. Ever happened to know that your devs are frustrated because of work, but couldn’t figure out why? Pining devs for constant updates might alienate them from managers- their best buddies/mentors/support system at work. Ongoingly, it can hurt the team’s focus hours irrevocably, even hurting developer productivity. EMs now need to find a balance between taking status updates, and ‘qualitatively’ resolving dev barriers.
Developer Burnout
When it comes to the developer ecosystem, everything is related and interconnected. Developer burnout has become a common workplace phenomenon, with over 82% of developers going through reversal burnout symptoms. An engineering manager is considered a pillar of support for their devs and is expected to help navigate the crisis with much empathy, and a plan of action to get them back in shape, and spirits.
However, managers cannot be of much help to devs if they don’t know what causes this alienation in the first place. Figuring out the reasons for your dev’s withdrawal, and lacking enthusiasm is a key priority challenge for leaders today. In the same survey above, 77% of developers have accepted that their managers are not aware of what’s happening. The causes could be anything; from overwhelming adhoc requests to dysfunctional work conditions, incident alerts, and debugging outside work hours. Since EMs are already dealing with work visibility challenges, these signs often come too late to them. By then, either their high-performing devs quit, become disengaged, or face a powerful loss in their productivity.
Unsustainable Workload
Workload distribution among members may sound like a direct task, but it’s complicated and hands down, one of the hardest for an engineering manager. In a SmartBrief survey, only 29% of engineering leaders were fairly confident of their workload distribution. The issue rapidly snowballs into frustrated devs if managers have low visibility into the engineering workloads (the big deal about visibility, eh?). Sometimes, the work allotment is done without accounting for geographical barriers, past trends of progress, and existing work share. Your next sprints are destined to go down if devs are not able to clear their previous backlogs owing to overburdening work.
Poor Developer Experience
Devs are good at switching teams, based on their career progress, happiness, or overall satisfaction. However, for EMs, this transition is like a double-edged sword- core hours devoted by devs per project are decreasing, while the training, and recruiting time keeps increasing. And that’s why protecting developer experience by managers becomes vital to the future of a company.
Good DX doesn’t necessarily have to follow Steve Jobs’ come-make-it-your-world approach, so much as it’s about improving a developer’s involvement, and satisfaction with the current workflow. If your current process has long code review periods, workload imbalance, security issues, frequent firefighting, flaky builds, high incident and interview workloads, and devs had to undergo frequent context switching and technical debt; then your life as an engineering manager might take a lot of toils.
