Simple questions can sometimes be challenging to answer. (As a new parent, I am mentally preparing myself for a barrage of such questions as Madeleine grows older.) "What is your management style?" is one such question that was recently asked to me by a colleague and I was surprised to find myself caught off-guard and struggling to come up with a substantive answer to it.
In terms of style, I like to listen, ask questions, and let engineers arrive at their own solutions to technical problems. Of course, this approach depends highly on the specific engineers with whom you're working. Some value independence more than others. Knowing when to be hands-on and when to back-off is an important skill for a technical manager. It's one that I'm still developing.
Related to management style, there are a few principles and practices in particular that stick out in my mind.
For the attention challenged or those pressed for time, here's the short list:
- Learn what motivates your engineers and try to align their interests with the goals of your organization.
- Keep your mind and ears open, and teach those with less experience than you. In other words, be helpful and don't be a prick.
- Choose technologies because they solve a problem and not because they're trendy.
- Have regularly scheduled, uninterrupted 1:1 meetings.
Learn what motivates your engineers and try to align their interests with the goals of your organization.
Motivated engineers do good work. Engineers are motivated when they get to work on things that interest them. Know your management goals and always be on the look-out for ways to line up individual and organizational interests.
Keep an open mind and take the time to listen to and teach those who ask questions, especially those with less experience than you.
Back
in the year 2000 when I was a web developer using PHP and the usual trio of client-side web techs to turn Photoshop mockups into real, working web pages, I had the good fortune to work with a number of software engineers who had been around the block a few times. I admired their ability to patiently listen to my programming questions and then respond with thoughtful and helpful answers.
These guys easily could have shooed me away or given me abrupt, half-assed answers. Instead they chose to take time out of their busy schedules to help teach me about the craft of engineering software. I'm grateful to these developers and, because of the profound effect their attitudes had on me, I try to follow their example and use my experience to help those who have less.
Use technology to solve problems and be wary of trendy tech.
The technology industry is rife with hype. Engineers love new technology. Be judicious in how your team chooses technologies and make sure your choices help solve real problems. It's also important to be mindful of other technologies in use within your organization as well as organizational expertise. Don't choose a technology just because it's trendy or different. Rather, choose technology that fits your problem space well and can be managed by your team.
Also, you should be aware of how many different technologies you're using. For example, if you have a PHP application that uses Ruby for deployment and Perl for tests then you might want to take a step back and examine why you're using 3 similar but different scripting languages. This may or may not make sense. It really depends on your organization, who's doing the work, and how experienced they are.
Bad technology choices can make things a lot harder than they should be. One recent bad choice I was involved with was deciding to use Apache Jackrabbit as the storage system in a high write, high read CMS. It was a seemingly good choice since Jackrabbit is pretty much meant to be used in a CMS. However (and this was a couple of years ago so Jackrabbit might be a lot better these days), we had concurrency problems with the application code and management tools for querying the underlying content store just weren't really good enough. We ended up migrating all of our data to MySQL and it was a good learning experience, but we could have saved ourselves a lot of trouble if we had decided to not use Jackrabbit in the first place.
Make time for your engineers. Have regularly scheduled, uninterrupted 1:1 meetings.
This is cited as a recommended practice in pretty much any management book out there. It just makes sense. You should give your engineers an opportunity to speak candidly with you on a regular basis. During this time, don't take phone calls, carry-on IM conversations, or check your email. Turn your monitor off or close your laptop if you have to but keep the focus on the conversation between you and your engineer. This is a pet peeve of mine and is something of which I'm keenly aware.
Managers owe it to their employees to give them their full attention during 1:1s. Things come up and interruptions might sometimes be necessary, but they should be a rare occurrence.
So, looking back on being a manager for a little while, these are the things that jump out at me as being a part of my management foundation. I'm looking forward to adding to it in the coming months.
