Transitioning to a managerial role could be hard. One day, you are developing and reviewing code. The next day, you are handling not just individuals, but a multitude of teams, evolving into a people person and leading your squad toward maximum productivity. Each engineering manager is different, and so are their roles, responsibilities, and ideas to better their teams. However, across the spectrum, here are the common challenges every engineering manager faces as they step up their software journey.

What Does an Engineering Manager Do?

Apart from what an EM's JD says, the ultimate goal of the position is the same throughout: helping devs become masters of their work. However, as a manager, the results and work items are not as tangible as an engineer's. An EM ideally spends time leading retros, mentoring, and managing the well-being of team members. It is not easy to create a direct commit log for managers, much like engineers. Yet, there are some common grounds for most engineering managers across three categories:

• Technical

• Team management

• Administration

Engineering managers usually don't develop much code themselves but manage SDLC, work on best team practices, read software updates, and pair teammates for projects. On the managerial side, they lead strategic meetings, coordinate with product and business teams, create project-specific timelines, and ensure team happiness and vitality. Another focus area for engineering managers is recruiting new team leads, meeting job candidates, and attending conferences. Now that we know what engineering managers do, let's figure out the common challenges faced by them.

1. 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 are facing 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.

Visibility is important, (we know) but what is the big deal about it? Visibility has a straight away correlation with agility and helps managers to stay on top of everything happening within their dev teams. Having visibility challenges can cause unsustainable prioritization, a high release backlog for EMs, an ambiguous SDLC process, and broken dev workflows. Only looking at north-star metrics might not help engineering managers in gauging the next steps; what they need is a clear picture of each phase of the software development- right from what's happening in planning (sprint-over-sprint trends), execution (lead time, deployment size), to final customer deliveries (software stability) to gauge where the real issue lies.

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.

2. 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 that you know 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. How? Automated standup tools for your communication stack (Slack, Teams, Emails) can help engineering leaders in knowing the daily work tasks, and progress made, and even identify blockers on the go.

3. 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.

4. 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.

Engineering managers need to figure out achievable (and practical) ways to distribute work, especially by keeping all members on the same page. One way is to use data-driven visibility for managing your dev's workplate: PR reviews, interview load, WIP tasks, and more. It is easier to plan productive work this way, and even create happy developers as an added outcome.

5. 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.

Most of these listed aspects are overlooked because they’re either not easy to detect, or measured, termed complex, and even messy. What engineering managers need to understand is how ignoring these indicators can hurt your devs in the long run. A Great DX is your 'silver bullet' to keep your devs happy, mitigate burnout tendencies among members, and create lasting value out of your dev's work. 10x engineers are not a myth anymore; sustaining DX over time can help you build one.

Getting to the Bottom of an Engineering Manager's Challenges

The developer ecosystem is not a tough nut to crack; most engineering managers start as devs and understand the pain points of inefficient processes. However, without the right visibility into a dev's whereabouts, managers will have a hard time building a productive, burnout-free, cohesive team. Team synergy, happy developers, and a self-sufficient team that works without blockers (or rectifies one easily), are hallmarks of an engineering manager’s success at work.

Using an engineering management platform can help managers to be on top of dev workflows, and even take the right set of actions to mitigate the challenges discussed above.

As teams become more complex, and distributed, sync meetings shouldn’t have to stay as the go-to place for collaboration, rather it's time for managers to build a data-driven culture that fosters bonding and ease of work equally.

With over 130+ engineering metrics, Hatica is an engineering management platform that equips engineering managers with visibility into their team’s workload, contributions, and processes to help them manage work effectively without burnout. Request a demo and explore Hatica further, and last but not the least, don't forget to drive your decisions with data, a pinch of compassion, and team satisfaction.