Being A World Class Software Development Manager

Over the past few years I’ve managed 3 software development teams at 2 very different companies and I’ve learned a lot in the process. I also read several blogs on software development somewhat religiously and I’ve liberally borrowed good ideas and added them to my toolbox. I’ve witnessed amazing managers as well as ineffective mangers, and I’ve spent time pondering on what differentiates the two. I don’t consider myself a guru on effective software development management or anything, but I thought I would share my thoughts on some traits that I would look for if I were hiring a software development manager to work for me because I think that a manager who exhibits these traits has the greatest chance of success.

Be a Computer Geek

Why does it matter? Because geeks are drawn to fellow geeks. Before I went into management at Microsoft I was consistently drawn to teams who were led by someone who I respected not only as a leader, but also for their technical chops. I knew that I could learn more from those sorts of people. I also felt more confident that my geek manager would understand and help contribute to the correct technical direction for a product and would be more prone to allocate time to do things the right way. I’ve always had a special respect for Scott Guthrie because he maintains a technical blog while operating as a VP. When ASP.Net MVC was new and I was searching for a tutorial I stumbled on his Nerd Dinners post which is pretty much the canonical search result for the topic and I was in shock: here’s a dude that manages more people than I ever will and he’s really taking the time to get to know the tech! That’s the kind of person I always want to work for and it’s the kind of manager that I want to be. Michael Lopp (aka Rands) does a great job providing his own thoughts on managing nerdsand providing some additional context on why it matters.

So how do you become a geek if you’re not one already? Allocate time to read nerdy stuff, every day. Keep coding, if you don’t have time for it in your daily job go take classes or work on a side project (even if it means waking up at 5am). Participate in team code reviews, I try to carefully review at least 1 out of every ~10-15 or so changes that my developers are submitting for review to let them know that I care and to encourage both thorough reviews and a high bar when it comes to code quality. Follow nerdy technocrats on Twitter or Blogs. Read a book on Operating Systems or Compilers. Technology is changing so quickly that not intentionally allocating time to immerse yourself in it will render you obsolete in a hurry. There are plenty of non-technical people who are competent managers that can lead a content team into oblivion because they can’t see the correct technical direction to follow. There are relatively few people who are both competent managers and technical rock stars who can both lead a team and provide the correct technical direction to make a team both happy and really successful.

Manage Projects that you Care Obsessively About

This one is a bit loaded because in the real world you can’t always pick what the teams that you manage are delivering, but your odds of cranking out a world class product are exponentially greater if you really believe in what you’re doing. I don’t just mean you think it’s mildly interesting, I mean you think that it has the potential to change your company (if not the world) in some tangible way that excites you. If you really buy into what your team is working on you’ll spend more time working, you’ll lay awake at night when you can’t sleep iterating on the technical vision for the product that your team is creating, and your enthusiasm will show through to the people who report to you. It sounds cheesy but it’s true, people won’t work hard for someone who doesn’t believe in what the team is doing.If you think that you’re working on something that isn’t exciting but you’re skeptical about your ability to move, you probably need to push yourself and do some shopping around. Towards the end of my time at Microsoft my team was re-org’d (and essentially re-purposed) to work on some things that I wasn’t as excited about. Despite getting good reviews my entire time at the company I had this sort of skepticism about my ability to interview well and move around either within the company or externally. It wasn’t until a recruiter contacted me randomly after stumbling across my resume on LinkedIn and described a technology that sounded exciting that I finally pulled the trigger and went through the interview process. And guess what? I didn’t end up getting an offer. In his shameless Google plug Steve Yegge does a great job describing something that he calls the “anti-loop”: an interview loop with a set of people that even the most qualified candidate will not survive, and something that I’ve personally observed while hiring. I bring up the anti-loop because it’s mere existence means that not getting an offer your very first time thru the process shouldn’t in any way discourage you from continuing to hunt. Shortly after my initial failed loop Amazon contacted me about a position to manage a team to work on something that I felt could completely change the game for how software development is done, and an interview loop later I had a job offer. Software Development is a weird industry in that the skills to be successful at the job aren’t necessarily directly related to the skills necessary to successfully interview for the job, so if you’re not interviewing at least once per year to keep your skills sharp you may want to consider doing so. Regardless of how often you’re interviewing you shouldn’t let yourself be paralyzed by fear of the unknown, it’s an eye opening experience to immerse yourself in a totally foreign team/organization/place and it’s a huge way to both promote personal growth and position yourself to work on things that excite you.

Surround Yourself with Amazing People

Sounds obvious, but I really can’t overstate the point. One of the most important assets that you have as a manager is your network of connections in the industry. LinkedIn and the competitive nature of talent acquisition in the industry has changed the game, and if you’re not adding talented people to your network that you can call on when your team needs to quickly staff up then you’re putting yourself in a hole. Talented people change teams and even companies fairly frequently today and as a manager you will be faced with situations where you have to hire on a time crunch. Even the greatest sourcing strategies can’t substitute for firsthand knowledge of how good someone is and having a rapport in place, which means you need rock stars in your network that enjoy working for you and may be willing to follow you to work on new things. A side effect of this phenomenon is that if you’re not changing teams/jobs every several years then you’re probably not adding new talented folks to your network as quickly as you could be, and you may either want to look around at other opportunities or consciously try put yourself in positions to regularly form relationships with people outside your network.

The ability to build a good team and hire effectively is the single most important trait in a software development manager and it requires both a solid network and being a great interviewer, a separate topic that has been covered in a lot of detail all over the place and that I will likely touch on in a separate post. The best manager in the world cannot succeed without an amazing team, and a bad manager who inherits a good team will do better than a good manager who can’t hire (in the short haul, until the talent leaves).

Clear a Path for Those People

After building a great team a manager’s job comes down to clearing a path for those people to succeed. Think of your team as a pipeline for delivering goodness, and your job is to point the pipe in the right direction and remove friction that can slow the speed of the goodness. Aiming the pipeline requires crafting clear and concise vision documents that the team buys into within the parameters of the organization. There is no substitute for being able to write great documents, they are one of the primary deliverables of any good manager. Documents stand the test of time in a way that a Power Point presentation doesn’t because it can’t be read by anyone in any situation without the context of the presenter. If you can write an effective document to describe what your team will be working on over the next 12 months with specific dates for delieverables that both meet customer requirements and are realistic based on team bandwidth then you already possess an underrated skill that many managers lack.

Removing friction from the pipeline means a variety of things depending on the team, organization, and product. It doesn’t necessarily mean getting rid of as many meetings or as much process as possible. It does generally mean things like putting an effective process in place, weighing in on technical design, and providing motivation to folks on your team. There are plenty of articles discussing why money doesn’tnecessarily directly contribute to job satisfaction or effectiveness over the long run, as a manager it’s your responsibility to know how to keep your employees satisfied and motivated. Let your employees know that you genuinely care about them by asking them how life is going outside of work. Setup effective 1:1’s on a weekly basis, and be sure that you’re not just covering things that are tactical. Be invested in your employees career growth. Setup bi-weekly staff meetings where employees can comfortably ask questions about the direction of the team or provide feedback on the process.

Install a Lightweight Process and be Flexible

One of the most common mistakes that I see managers make is a “my way or the highway” type approach when it comes to team process. Scrum has obviously become the hawtness that many teams use today. Scrum was developed for manufacturing. Software development is not manufacturing. I don’t mean to say that scrum is bad by any stretch of the imagination, but it works well in some situations and fails miserably in others. On the last team that I managed at Microsoft we operated on a fairly strict scrum model. We kept a super detailed product backlog that we groomed regularly. When we pulled items from the product backlog into the sprint backlog during sprint planning we had a great idea of how much bandwidth we had, what load factor we were operating at, and exactly what we could get accomplished. We did a pretty good job scheduling demos at the end of sprints, and we always held retrospective meetings and carefully considered and integrated feedback from the team. In the context of our organization we were operating as model citizens, and it worked well.

The first thing I realized when I came to Amazon is that if I ran my team the same way my developers would probably all commit mutiny and the team wouldn’t run effectively. The culture is different and the product that we’re working on happens to be in a very early “protype-ish” phase so requirements are changing very rapidly. It’s taken a bit of trial and error but we’re starting to really hit our stride on a hybrid scrum model with mini weekly iterations within each sprint. The scrum purists would roll over in their grave, but I’m alright with that.

When a manager takes over a new team the first step should be observing how the team has run in the past (unless it’s a brand new team). The next step should be investigating how other effective teams within the organization are operating. The last question they should ask themselves is how their past experiences can play into the process within the context of the new team. The goal in the entire excercise should be to build a process that is as lightweight as possible while effectively meeting the requirements for partners and customers and keeping engineers happy. If it sounds like a lot to ask, it is. The odds that you’ll get it right on your first try for any team are low, which is why it’s important to approach new team processes with humility and a willingness to be flexible. The last thing you want to do is create what Jeff Atwood aptly describes as micromanagement zombies by installing an over restrictive process just because it worked at your last gig.

If you’re nailing everything mentioned in that list I’m willing to bet that you’re enjoying work and leading a highly effective software development team, and that you’re probably a better manager than I am. Alternatively if you disagree I would certainly love to hear your feedback so that I can be convinced and update my list accordingly.