As a software developer, you may often feel like engineering managers are blocking you with bureaucracy and pointless work rather than helping you do your job. I get it — I’ve been there too! But as someone who has worked on both sides, I want to provide some insight from the other side. Software developers need processes, documentation, and risk aversion as much as managers.
Just Let Me Code
You roll your eyes as the Slack notifications pour in again, asking for yet another status update. “It’s barely been a week since the last one,” you think. You click open the latest message from Steve, your engineering manager, asking how things are progressing on the new API endpoints for the file uploads.
You rub your temples, feeling a headache coming on as you think about the long to-do list ahead. You’ve been itching to refactor the file storage module and optimize the retrieval and download parts. But you know Steve will remind you to stick to the “add basic functionality first, polish later” plan.
“We can get to the advanced features later, “ he says predictably. “Let’s focus on nailing the basics for the initial release.” Logically, you understand his rationale for prioritizing a smooth launch. But you wish you had more of a say in planning the order of things since you directly deal with the clunky legacy systems daily.
You hesitate for a moment, then paste in the same vague status update as last week — the backend API integrations are still in progress. Thanks to the glitchy internal file streaming system, they’re dragging on longer than you had estimated. But you know, if you reveal that, Steve will rapidly pull you into rounds of risk analysis meetings.
You hesitate a little more before clicking send on the carefully worded status update. Then you brace yourself for the inevitable barrage of pings as Steve contacts the whole team, asking them to “dig into these backend delays.” You sigh, thinking of all the productive work you could get done in the time it takes to listen to everyone’s concerns about potential timeline slips.
You lean back, letting yourself daydream about the flexibility of working at some hot new startup. No bothersome bureaucratic processes clogging up your days. Just the autonomy to build solid features at your own pace. It’s too bad that these startups are so unpredictable and can cease to exist the next year — they’re so fun to work at.
The fantasy ends abruptly, though, as a new Slack notification reminds you about the next sprint planning meeting. You turn your attention back to providing yet another round of project updates rather than making actual progress on this rebuild.
Too Much Processes
Needing a few people to approve your approach to implementing a feature or navigating complex workflows in project management tools to just report your work seems ridiculous. In a perfect world, developers should just build whatever they want without needing approvals and jumping through the bureaucratic hoops.
However, those bureaucratic processes are there for a reason. Getting proper approvals protects companies from building parts of the applications whose architecture is incoherent with the rest of the system. The workflows give management visibility and control to see where you get stuck and steer the work in the right direction.
Too Much Meetings and Documentation
No developer wants to spend more time writing docs than code. I’m with you — meetings should be relevant, and documentation should have clear goals. Even better — there should be no meetings except those you call for, and documentation should be created by someone else. For engineers, it should be just heads-down coding all day.
From a manager’s standpoint, documentation is crucial for continuity because developers switch projects or leave companies. Often, it’s just more efficient for you to write it since you’re the one building the part that needs to be documented. When run efficiently, meetings help align people and identify potential issues early. The key part is “efficient” — engineering managers should have clear meeting agendas and summaries. In reality, they’re often as overwhelmed as you are and don’t have the energy to run the meetings perfectly.
Lack of Technical Understanding
It’s frustrating when the people making decisions don’t understand the underlying technology and make unrealistic demands. You wish they’d just trust the developers to make all the calls.
Engineering managers look across the whole product lifecycle, including business needs. Relying just on technical perspectives can miss the big picture, which can cause serious delays or completely steer the project in the wrong direction. As managers, we need to work closer with engineering leads to constantly improve our technical literacy while providing important business context to make decisions. But it’s highly unlikely that even the engineering manager with a technical background will understand technical details on the same level as you — it’s just a different job.
Risk Aversion
I understand why the heavy bureaucracy adopted by large companies is frustrating. As developers, we want to iterate quickly and ship often. Developers should have full autonomy to make decisions, fail fast, and learn. But we get paid by the money made by the business. And often, if something goes wrong because of a risky engineering decision, the company loses money it uses to pay you your lucrative salary.
Organizations have higher costs of failure — delays, outages, or security issues can literally cost millions. So, it’s important for managers responsible for the outcome to move carefully. Of course, bureaucracy should be gradually reduced as the tolerance for risk improves.
Focus on Metrics Over Quality
It’s demotivating when your performance is judged by metrics like delivery time rather than work quality. You wish decisions would be made based on what’s best for the product. There may be a company where incentives and metrics are designed solely to reward engineering excellence and product quality.
In the real world, things like predictability, velocity, and budget matter too, not just quality. Managers obsess over metrics because they’re trying to balance the demands of the business world and the engineering world. It doesn’t mean that we should write spaghetti code just because it’s fast to do so. Instead, we must balance quality and other business needs while articulating tradeoffs to executives.
Lack of Autonomy
No one likes being micromanaged. As an experienced developer, you want to have the expertise to choose technical solutions without oversight.
However, company standards exist for many good reasons — security, stability, and hiring. For example, that new shiny framework you want to try out might not be a good option in the long term because it’s easier to hire people who are familiar with industry standards but not the new shiny toys. As a consequence, engineering managers must define project goals with you collaboratively and then give reasonable autonomy within agreed-upon boundaries.
Technical Debt Neglect
You wish you could allocate dedicated sprints to refactoring, upgrading libraries, performance tuning, etc. Everyone does, me included. But you’re pressured to meet near-term feature goals and never have time to address problems that keep piling up.
Of course, refactoring should be built into every sprint with no pressure on feature velocity. In a perfect world, it probably is. However, resources are limited even in large teams, and not all technical debt is equal. Rapid iterating is what brings value to the business and makes stakeholders happy. As engineering managers, we need your help to have better visibility into the development process to understand when technical debt poses significant issues. Then, we can allocate resources properly.
Originally published on Medium.com