Good Engineering Manager/Bad Engineer Manager

Inspired by @bhorowitz's Good Product Manager/Bad Product Manager (go read his book, it’s excellent) here’s my take on good vs bad engineering managers:

Good engineering managers understand the problems they’re trying to solve, understand the constraints they face and look to produce a solution that is both pragmatic and as effective as possible utilising their teams skills and experience. Bad engineering managers rush into problems failing to understand the domain, washing it off as something that is “not necessary” to build software. They often can be heard complaining that the constraints are unreasonable and that team is “under resourced” or “not good enough”. They are more focussed on perfection than delivering a working solution. 

Good engineering managers are passionate about what they do, they proactively tackle situations, whether difficult or easy and ensure good communication is a central tenant to the teams operation, they ensure bad news travels fast. Bad engineering managers are reactive in the hope that hard things will go away and do their best to obfuscate any kind of bad news.

Good engineering managers work pro-actively with product management and understand the vital role they play in the delivery lifecycle, bad engineering managers feel product managers gets in the way and look to undermine the product management group at any opportunity.

Good engineering managers empowers the team to solve problems, hold them accountable for results but understand the delivery responsibility lies with them. They recognise they work for the team, not the other way round. Good engineering managers stand up for what they think is right for the team, even if it isn’t what senior management will want to hear. Bad engineer managers feel they are the only one who can solve the problems and look take all the interesting work for themselves, leaving the team to pick up the rest, they believe the team works for them. If, against the odds, delivery happens to plan, they take all the credit. If failure happens they look to pass blame.  Bad engineering managers quickly capitulate to senior management in the hope of carrying favour regardless of the impact to their team.

Good engineering managers looks to solve the problem effectively using the right tools, not necessarily the newest. A bad engineering manager looks to use the latest cool technology whether or not it is the right tool to solve the problem.

Good engineering managers have a high level of emotional intelligence and use this effectively when dealing with the varying personalities in his team. They understand when it’s necessary to deliver strong but constructive feedback and how to deliver it and equally when a softer approach is required. Bad engineering managers have a one size fits all approach in dealing with team members.

Good engineering managers understand it is vital to the business and their own success that their teams continue to grow and develop. They have a passion for learning and development and pro-actively encourages their team to learn in all scenarios. They understand the value of 1:1’s and performance reviews. Bad engineering managers feel spending time on learning is a “time waste” and the team should just focus on churning out code. Bad engineering managers feel catching up with team members formally once a year at most is fine.

Good engineering managers are organised and punctual, understand clearly what the team is working on and why and provides timely updates to business stakeholders. Bad engineering managers have little or no regard for any sort of timekeeping, don’t track what their team is working on, care little why they’re doing what they’re doing and feel it’s a waste of their time having to provide status reports to the business. 

Good engineering managers understand the importance of recruitment, and spend a good deal of their time working on the process to ensure they understand where they need to grow their teams, what skills and experience they’re looking for and deliver a interview process that supports this. Bad engineering managers feel recruiting and interviewing is time wasted away from their coding. 

Good engineering managers understand responsibility doesn’t end when the code is shipped. Bad engineering managers mentally put their feet up and relieve themselves of responsibility once the code is released.

The winning open source model turns open source 1.0 on its head. By packaging open source into a service (as in cloud computing or software-as-a-service) or as a software or hardware appliance, companies can monetize open source with a far more robust and flexible model, encouraging innovation, and on-going investment in software development.
The reason for saying we need to do ‘an exceptional, near-perfect job of execution’ is this: When you want something really bad, you will put up with a lot of flaws. But if you do not yet know you want something, your tolerance will be much lower.
organizational clarity” and “individual competence
Tags: leadership