Lead by Coding: A Hands-on Approach to Managing Development Teams

The fire chief never goes near a burning building. The wing commander doesn't fly. The ER surgeon faints at the sight of blood.

Who would respect any of these people?

So what about the leader of a software development team who doesn't code?

Yoav Cohen, SVP of product development at Imperva, the cybersecurity company, thinks that is not a good idea. If you are going to lead a team of developers and earn their respect you can't just go to meetings with executives and tell the people working for you that you have a high concept view of coding.

Managers and even senior vice presidents need to be able to pull up a notebook and dig into the code to help solve a problem their team is working on. When Cohen was a young developer, he watched his manager do just that and it made a huge impression on him.

"This is something I'm passionate about," he says when asked to explain his lead-by-coding philosophy. "Ever since I was an engineer, the first time I saw my manager start coding and dig into a technical problem and bringing it to a conclusion, it really did something for how I think about managers and their role in how the team is doing and how they are building their team."

If managers want to earn that kind of respect from their development teams, Cohen recommends they keep up-to-date with the latest tools, programming languages and practices rather than referencing dated expertise with old technology. He says keeping their coding skills sharp enhances their leadership qualities because:

  • Managers that code have a greater understanding of challenges engineers face and how to resolve them
  • Managers that code don't ask their teams to do anything they wouldn't do
  • Engineers are more likely to value -- and take encouragement from -- managers that code

Following this management approach prevents the kind of disconnect that happens when the supervisor doesn't understand what the developers are doing.

"I think that in our line of business," Cohen explains, "people who spend years studying and building a wide skill set, and taking pride in our craft, it's important for us to look up to our supervisors. We need to know that they understand what we have to go through to get to the level we're at and what are the potential challenges that we face in our day-to-day job."

If supervisors can get their hands dirty fixing a bug it goes a long way to enhancing their credibility with the developers who work for them.

"I think it makes managers a lot more credible when they can demonstrate to the team that they understand what the team is going through," Cohen says. "With software today, delivery times are getting shorter and pressure is at an all-time high to get things out to the market, out to production fast. Managers who cannot internalize the challenges the team faces with this increased level of pressure, risk losing the respect of the team, and not being able to motivate the team to go above and beyond when needed."

These leadership qualities go beyond coding and can apply to life in general. Cohen, who is from Israel, drew on his experience in the military there when crafting his management strategy.

"One of the things I picked up in my military service was seeing commanders and knowing whatever they asked me or instructed me to do, were things that they could do," he explains. "It gives them a very high level of credibility and the ability to motivate the team to do incredible things."

For those managers and supervisors wanting to develop the skills to lead by coding, Cohen recommends starting small and building up. In an article he wrote on DZone outlining his management practices, he acknowledged that with development tools, languages and practices changing rapidly, it can be a challenge for managers to keep up. Here are some tips he offers:

  1. Start small by setting up the dev environment. That alone will surface all the issues new engineers face when they join your team or when someone needs to start from scratch. It's usually where you'll learn about all sorts of nasty workarounds and tribal knowledge that's not documented anywhere.
  2. Take the simplest bug and fix it -- like that typo in the UI, or the missing piece of info in a log print. Don't try to fix that nasty concurrency bug that your 10x engineers can't solve. Baby steps!
  3. Make it a habit to pick the simplest task possible and get it done -- something that you can get done in at most a day's work. Obviously, it will take you longer with all the e-mails and meetings. I would recommend to managers to do that once a month and for directors and above about once per quarter.
  4. Take a dive -- if you are a true coder, you'll get the urge to take on something really meaningful once in a while. It might even be as seldom as once a year.

This will take time but Cohen strongly believes it is worth the effort.