👔 5 types of engineers in corporate jobs (and which types to avoid)
The 5 common engineer types in corporate bureaucracy, their work habits, and learn which approach boosts productivity and helps navigate corporate challenges effectively.
In any corporate job, dealing with bureaucracy is part of your contract.
This bureaucracy often leads to engineers adopting different tactics when handling tasks.
Some approaches are more effective than others. Over the years, I’ve observed them all and decided to give them names.
⭐ What you’ll learn
Identify these tactics, avoid the bad ones pitfalls, and choose the best approach to adopt.
🫣 The Avoider
The Avoider allows tasks to pile up on their plate.
They don’t even glance at their assignments to make a plan, letting the work sit until it becomes urgent.
When they finally begin, they’re already behind schedule.
These are the engineers who claim unexpected work caused delays, but in reality, they failed to manage their workload.
💡 Is it useful? Not at all. It’s understandable that some tasks can’t be started immediately. But leaving them unattended indefinitely is unproductive. Better to block time on your calendar to plan them than allow deadlines to sneak up on you.
🔥 The Blamer
Blamers aren’t interested in completing the work.
Their energy goes into finding someone else to blame for what went wrong. Whether it’s a colleague’s mistake or a miscommunication between teams, Blamers focus on pointing fingers instead of fixing the issue.
This tactic serves as a distraction. The more dramatic they are, the easier it becomes for others to lose focus on the real problem.
💡 Is it useful? Absolutely not. Blaming others won’t solve the problem or move the task forward. It may briefly shift attention away from the blamer, but ultimately, it damages performance and career growth.
🎾 The Responsibility Tennis Player
These engineers spot any input required from others and use this to offload the “hot potato” onto another team or colleague.
They don’t realize this work will return to their plate once the other parties have completed their contributions.
In many cases, they block entire projects over minor, noncritical details, switching to something else to avoid the problem.
💡 Is it useful? No. Like in a system design scenario, this creates a "thundering herd" problem. Delaying responsibility will only cause a flood of tasks to come back to them, overwhelming their capacity.
🔃 The Router
The Router’s main function isn’t to solve problems, but to act as a connector.
When a task lands on their plate, their reflex isn’t to dive into the work but to direct the requester to someone else who might have the answer.
Typically, this role is seen in management or senior engineers who are well-connected across multiple teams.
They know who to involve.
💡 Is it useful? Yes, but only for those focused on the bigger picture. If you are the owner of a certain domain, routing requests about that instead of solving them may simply be a way to push off responsibility.
💼 The Professional Software Engineer
The Professional Software Engineer tackles tasks head-on, working diligently until there’s nothing more they can do on their own.
When they need input from others, they don’t just pass off the task
They communicate clearly, create a plan, and establish ownership for every part of the process. They stay focused on completing the task for the benefit of the team and the company, not just to reduce their own workload.
💡 Is it useful? Absolutely! These engineers are not only able to take credit for task completion, but they also reduce the communication overhead by being proactive. This leads to faster task resolution, both in calendar time and in effort.
🎯 Conclusion
Different situations call for different approaches to handling bureaucracy in a corporate environment.
However, the most effective approaches are those that simplify task completion—either by involving the right people or making progress yourself. Simply pushing tasks off your plate doesn’t contribute to moving the work forward.
The goal is to stay productive, whether that means taking initiative yourself or collaborating effectively with others.
Remember, being proactive always wins over avoidance, blame, or deflection.
🗞️ Other articles people like
👏 Weekly applause
These are some great reads from my last week:
How Facebook Was Able to Support a Billion Users via Software Load Balancer ⚡ by
. Step by step growth of load balancing at facebook, from 1 server to 1 billion users. Only add layers of load balancing mechanisms as you need themHow to Stay Calm Under Pressure? by
. Breath-assess-act framework on different situations at work.Love or Hate Leetcode, but do not Ignore by
. Intead of complaining about the rules of the game of hiring in big tech, either choose to play the game with those rules or play a different gameSome important learnings from my 20 years of engineering life by
. I love these posts, they contain learnings from many years of experience condensed into a few minutes of read time. The lessons of time management and communication is what I’ve found most important in this post5 Keys to the Hiring Manager Interview from a Meta Senior Manager by
and . The interviewer didn’t see with their own eyes what you did. They only see your impact through your communication. So better to learn how to frame your annecdotes.
Thanks for your support growing strategize your career to 12.5k subscribers.
Share the newsletter in your socials to earn for free multiple months of the paid tier
> until there’s nothing more they can do on their own.
Even after 10 years, half of it working freelancing and the other half working for companies, I feel I still can't judge when this moment is... Especially with huge codebases, when there are layers and layers of complexity to making a simple HTTP call.
So I'd say I'm a 90% Professional Software Engineer. 😃