What's the most important responsibility for a software manager?

I'll probably ask and answer this question many times over the course of this blog because, as I've said, there are many very important aspects to software management.  But for today, I'll say "the most important responsibility is: recruiting."

I used to work for a guy who would say "Hire people who are smarter than you" and "fill your team with superstars and your job will be easy."  I couldn't agree more, but man, what a challenge this is!

As a manager, your job becomes less about your own coding skills and more about your ability to leverage your team.  Simply put, you are responsible for more than you can do yourself, and the quality of your help is of paramount importance.

Recruiting is a huge time sink, and often feels like a burden because we all have "real work" that needs to get done.  But its much worse to recruit poorly and end up with engineers that don't produce good results or need too much hand-holding.  These things become a long-term (and often hidden or intangible) time sink, whereas the recruiting burden is only temporary.

So when I'm in recruiting mode, I maintain a couple key principles:

1. Invest a lot of time, especially in preparing for the interview
2. Keep your standards high...don't settle!

Invest the time

Strategies for the interviewer are a topic for another post, although Joel Spolsky's article is a good start when it comes to good advice.  The point I want to stress here is that interviews are an extremely brief opportunity to get to know someone well enough to make the hiring decision.  You had better make every second of the end-to-end interview process count.


To that end, I always do the following...

• Write a concise but detailed job posting.   Think a lot about words and style and how it will attract the type of person you're looking for, as well as scare away the ones you don't want anyway.
• If you have a recruitier on the front lines, give them a list of pre-qualification questions and insist on seeing a write-up with the answers before you'll consider a candidate.
• Read every resume thoroughly (until you can safely conclude "no thanks").  I don't buy the old adage that a hiring manager only spends 30 seconds on a resume.  I spend a good five minutes or more.
• Treat every candidate differently.  They all have unique histories, strengths, and weaknesses.  A boiler plate set of questions won't give you as much info as questions you tailor based on what you already know about the candidate.
• Prepare for the phone screen, for at least half the time of the phone screen itself.  You don't want to get stumped by the awkwardness of the first encounter and waste that time.  You should have a script going in that is tailored to the uniqueness's of the individual.   Ask them questions about their resume, know what you want to hear, anticipate the responses and have follow-up questions prepared, so that no line of questioning is wasted.
• Do the same for the interview itself:  Prepare.  I have a library of several dozen questions I am constantly revising.  There's never time to ask them all, so before each interview I read through it and pick the ones that are best for this particular candidate.
• Make sure your interview team all does the same.  You may only have 45 minutes with this person, but they'll probably spend 4-5 hours or more in the total interview.  If any of that time is wasted by too many softball questions from inexperienced or ill-prepared interviewers, your risk of a bad decision is increased.

Keep your standard's high

I agree again with Joel here:  "If there's any doubt, say no."   You may feel that you really want to be done with recruiting and get back to developing product, and hence be tempted to compromise.  You may see some really positive attributes of the candidate, but "just one red flag".  But imagine if that red flag turns out to be the dominating attribute of the candidate....  Sure, you've lost a couple hours on this person so far, but if you hire them you'll be regretting it for months or years to come.


In writing this post I thought of many aspects of recruiting and interviewing worth discussing, but I'll have to save the rest for later posts.  The bottom line for today is:  Recruiting is serious business.  Spend the time to do it right!

How did you make the transition from software engineer to manager?

Like most career-minded folks, I've never been willing to say "I'm happy where I'm at, and I'm not interested in further career growth". With that in mind, I've had to constantly examine my limits, my talents, and my passions to figure out my direction.

My limits: I love Computer Science. I got my BS and MS degrees in Computer Science. But I don't identify myself as a "Computer Scientist." That, to me, is a much more intense title. I don't have the patience or the mental capacity to solve the hardest problems in my field. I find complex problems like search algorithms, frameworks, or massive scalability to be intellectually fascinating, and I love learning how they were solved, but I'm not the guy who's going to solve them myself. This is why I chose not to follow a purely technical ladder beyond the level of Senior Software Engineer, or go for a PhD.

My talents: What I bring to the table is a healthy mix of technical and architectural skills coupled with organization, communication, and interpersonal skills. I have a strong sense of the "keep it simple" design philosophy, and I'm unlike many engineers in that I see value in and am good at writing clear specs, diagrams, e-mails, plans, and other forms of engineering beyond code. As I like to say "Even a simple e-mail has a user experience that needs to be considered." Also, over time, I've gotten good at paying attention to more work going on around me, but at a higher level. This is a key function of a manager, but not so much a requirement for an engineer.

My passions: I a nutshell, my passion is for seeing ideas turn into applications in an elegant way. As an engineer, I got to do just that pretty much on my own, and it was rewarding. But I was often frustrated that the coding process just took too long. As a manager, I get to do it with leverage. I get to be involved in more projects coming to fruition. As long as I'm involved, I don't feel the need to be the actual coder. Quite often I'm heavily involved in conceptualizing requirements and creating high level design (like, for instance, the data model), but then leaving the coding to one of my engineers.

Anyhow, to answer the question, my transition to management happened in my current job, where I hired on as an engineer six years ago and gradually became more and more of a manager. Yes, there was a specific moment early on when my job title changed, but the mental transition was much more gradual, and in some sense is still not finished. With a team size that has grown from 2 to 9, my hand was somewhat forced, and I've had to learn to resist the inclination to just "do it myself." Its been a good learning experience.

At one point a couple years in, my boss said to me point blank "I value your management skills much more than I do your technical skills." That was a real eye opener, since at that point I still identified myself as an engineer, and a good one at that. It was hard not to take it as a put down.

But I've come to realize that good engineering skills are a required part of a bigger package that makes a good engineering manager. At this point in my career I'm cultivating the rest of the package.

Tell me more about this marbles analogy...

Sure. And please note its not that I'm calling the folks on my team a bunch of marbles. Rather, the marbles are the issues a manager has to deal with every day. The point is, there's no focus on one single thing, like there is for an engineer. A manager has to be able to deal with a little bit of everything, and context switch almost constantly. One moment you're advising product management on the feasibility of a new feature, and the next you're deciding if a bug should be fixed or deferred, or being asked for advice on a topic you may know little about. Then, you've got recruiting to do, performance reviews to think about, and perhaps an action item or two you took in your last meeting. Sometimes you're reacting to a fire, and other times you're thinking proactively about change. For the manager, responsibilities are all over the map.

For the engineers that you manage, it should ideally be the opposite. Their job is to take on a coding project and get deep into the weeds with it. The more minutiae and boring (in their mind) meetings you can shield them from, the more the good engineers will thank you, and the more productive they will be. They don't want to be discussing the requirements...they want to be coding them.

If I were to title a different blog about the mindset of an engineer, it might be called "Getting the real work done." In fact, letting go of that mentality, that feeling of "I'm not being useful unless I'm coding," was one of my biggest struggles when I transitioned into management, but that's a story for another post.

About Loose Marbles...What's with the name?

Loose Marbles is a blog about my experiences as a software engineering manager. Throughout my career, even when I'm not looking for a new opportunity, I'm always thinking about the experiences I'm having on the job, and specifically how I would talk about them when asked in my next job interview. In part, this is because I'm not very good at thinking on my feet, so I prefer to anticipate questions and have an answer in my pocket. But also, I just feel that constant introspection is a good learning experience. We should always be thinking about the takeaways from our experiences as they happen, and recording them in "permanent storage". A perpetual post-mortem, if you will.

So the first question I expect to be asked in any future interview is "What does management mean to you?"

I'll answer with an analogy: "Its like somebody dumps a bag of marbles on a flat table, and your job is to make sure none of them rolls off the edge."