Don't "Good to Great" Your Dev Team

Leadership books can provide a lot of great information about how to run companies.  I’ve read a lot of great ones, some not so great ones, and some shitty ones.  The problem with most of them is they were not written by software developers, for software developers. Trying to manage a development team using the techniques in these books is a good way to end up with a team of unhappy, unmotivated developers.

The Level 5 Leader

If you’re trying to find or develop Level 5 leaders on your dev team you’re at best wasting your time, at worst mortally wounding the moral of your team.  While the Level 5 leader makes a lot of sense for the type of person you want to running your company, trying to get everyone to aspire to that or think in that mindset is a mistake.

It’s not to say developers don’t need mentorship and coaching but the one-size-fits-all approach of most leadership books can be damaging when applied to developers.  I’ve seen too many happy developers/engineers/designers/etc become frustrated due to the type of management that from the outside looks to be “textbook”.

Why is it Wrong?

With the occasional exception, most developers want to get their shit done.  Asking for status updates, commitments to deadlines, meetings to discuss progress, conference calls to discuss known issues, etc. is counterproductive.  This is especially true for your top developers that know the process, requirements, expectations, etc.

Project Leadership

Below is a simple formula for leading a development team from a project perspective.

  • Make sure your team knows what is expected up front
  • Make sure your team knows you can help them track down any questions
  • Make sure your team knows you’ll address any blocking issues

So the key here in case you couldn’t tell is clearing the path for your team.  They know what needs to be done, help them do it.

Career Leadership

“So where do you see yourself in 5 years?” Everyone’s favorite question right?  While I hate the question, the point of it is valid. You need to make sure you know you’re doing what you need to in order to support your team in their career goals.  The problem is this shouldn’t be a question you ask every 6 months in a formal review.  You should know the members of your team better than that.

You should know their strengths and weaknesses and know the direction they’re heading. You should have the conversation when it appropriate and makes sense, not when the HR department says it’s time to.


To sum all this up, your development team needs to know you have their back.  They’re going to bust their ass for you if you just let them.  So go forth and don’t be an obstruction to your team.