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.
Get the free AI Agent Building Blocks ebook when you subscribe:
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.
