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.