Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Managers That Code

DZone 's Guide to

Managers That Code

Want to inspire your team? Make sure you don't leave your coding behind. There are more benefits than you might realize.

· Agile Zone ·
Free Resource

It’s 8:30 am and most of the engineers on the team are already at their desks, coding away. It’s one of those teams, where everyone who works with them has nothing but praise to say: a commando team, can do approach! They must have a secret. Oh, it’s probably because they’re all high performers, that’s not fair, right? If all the engineers on my team were high performers, we would be killing it… Oh I know, they’re working on a new product, they don’t have any maintenance work, let’s see them take on the mountain of legacy code my team has to deal with, I’ll bet they won’t be so great then…

Like it or not, the single most important person on a team is the manager. The manager is the one who hires and fires, who sets expectations and makes sure they are met. And the best tool a manager in software development has to do all that successfully, is to code.

When I started my career as an engineer, I presented the design of some project in which we had a manager persona. Wanting to be the team jester, when I presented that persona I said, “That’s the manager, who, um, doesn’t do anything because managers are in meetings and emails all day long.” Sad but somewhat true. As an engineering manager myself I found it extremely hard to stay hands-on and code but I always valued that enormously. Today I’m responsible for several teams and I get to observe a lot of different types of managers, and I see a high correlation between managers who are hands-on and awesomeness of their teams. I’ll try to explain why that is and share with you a few tricks to help you maintain your chops, even as directors or VPs.

Why Coding Matters

One of our roles as managers is to push our teams to deliver more. The only way to push a team is to challenge them to find better ways to work, to think of better technical designs or to deliver with higher quality. How can we do that if we don’t understand what they are up against? Sure, by using our authority we might be able to force a team to consider a different approach and if we’re right, lucky us. If we’re wrong, we lose all credibility. When estimating efforts for tasks, how can we be sure the estimations given to us by our engineers make sense? Even if the engineers are spot on, who said we can’t find a way to deliver those faster? Can we really infer from the last time we took on such a task ourselves 5 years ago with a completely different toolset or programming language?

When managers are coders they become the best managers they can be. They are valued by their engineers because they know what they’re talking about. They are also more emphatic to the challenges the engineers face, like unstable dev or test environments, flaky requirements or re-writing the UI over and over again, and they will be much more invested in helping resolve these issues. When managers walk a mile in the shoes of the engineers (or write a thousand lines of code for that matter), the engineers on the team will never think of them as detached or unfair. Managers who code don’t ask their teams to do anything they wouldn’t do. That is a very powerful leadership tool.

I will acknowledge that keeping your coding chops as managers is a challenge. With new development tools, languages and practices changing at a high rate, it’s really hard to stay an expert. But the benefits are really worth it. Here are a few tips to help you get started:

  1. Start small by setting up the dev env. 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 emails 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. But if it really requires your full attention and focus, you’ll have to prioritize it on top of your day to day activities for a few days. In those times, be honest with your team about the fact you are taking some time to code and explain why are you doing that. Put on your headphones, play some good music and go for it. Your day to day activities will get impacted a bit but your team will gain so much respect for you as their manager, and you will be gain a lot of insight that can help the team run faster, that it’s completely worth it.

Simply put, our profession is software engineering. We as managers should be able to practice that profession to some extent even if we are no longer full-time coders. Do you think your VP of Sales doesn’t close deals? Or your VP of Human Resources can’t coach you on providing feedback to your engineers? Sure they can, and in most great companies they do.

Topics:
software development ,programming ,leadership ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}