How to Build Fantastic Engineering Teams 
I'm very lucky to manage two outstanding Engineering teams. But it's not an accident that they are outstanding - it was the result of following some basic practices (and a bit of good luck). Here's what I think lead to success:

- Hire people smarter than yourself
- Let the team participate in the hiring process
- Set the bar high - demand excellence
- Don't keep a bad fit
- Share as much information as you can
- Look out for your staff

Hire people smarter than yourself

I'm a generalist and I do admit that I think I'm brighter than average. In a few areas I'm an expert. In others I know enough to be dangerous. But I'm seasoned enough to be completely convinced that there's a LOT of people much smarter than me. I try to hire those folks. And I have to let them be smart - which means listening to them and trusting them. Not blindly trusting them - I certainly challenge them to defend their opinions and designs... but I have to trust. Sometimes I have to make the command decision and over-rule them, but when I do I try to make sure I'm clear in my own head about my reasons. If my ego is involved I'm probably making a bad decision.

Let the team participate in the hiring process

Our interviews last at least 4 hours long. We're up front with candidates to expect that, and if it's going to go through lunch we feed the candidate too (more on that in another post). Each of my senior staff get 45 minutes to an hour with the candidate, and I try to make sure I get coverage across the two teams. We ask hard questions, of course, but we're just as interested in communication skills as we are with coding and analytical skills. There really is only one of two answers from each interviewer: yes or no. The key criteria is 'can this candidate carry his/her weight on the team?' If someone on the team is thumbs down about a candidate I have to seriously agonize if I decide to hire that person. I have done that - and almost every time it did not work out. I usually justified it with the notion that some productivity was better than none but that's not all that true. When it did not work there was usually a clean up of some kind or another that wiped away the apparent gains. As the team gets experience interviewing and seeing the results over time they get pretty good at it. And they gain good skills for their future careers (see about taking care of staff below).

Set the bar high - demand excellence

Mediocrity breeds bugs. Seriously. Excellence is the best antidote. We create a culture where we expect quality code - as much quality as the time allows (sometimes schedule trumps quality). We have formal pair-programming code reviews every week where someone is assigned to look at someone else's code for that week and provide a written summary of what was good, bad and ugly. There's nothing like knowing that your peer - who you darn sure respect and admire because she's smart and skilled - is going to look at your code and share her thoughts with the whole team. We do design reviews (but not as many as I'd like - back to that schedule thing) and try really hard to get the patterns right. We encourage dissent and questions, and when the team members all respect each others skills it really drives a better product.

The important thing here is that while I as Management place high expectations that's NOT what is creating the results. It's the high standards the team is setting on each other that creates the results. I'm just the catalyst. The goal is to create a culture of excellence.

Don't keep a bad fit

It does not take long to figure out who's a bad fit. There's a lot of things that may contribute to the poor fit - performance, personality, external factors - but if someone is not working out you are not doing anyone a favor by keeping them. It's not the lost productivity of that person as much as it's the destructive force on the rest of the team. The culture of excellence and respect I discussed above depends on everyone carrying their share. When the team starts losing that because someone is not a good fit it's the sole job of Management to fix that. It's better for the person to move on to somewhere that they can be a good fit, and it's exactly what will tell the team that the high standards are being upheld.

Share as much information as you can

No one does their best work in a vacuum. A highly functional team must know about the business, the customers, and the strategy for closing the gap between those two. The more they know the better they can make good decisions. They can think 'hey, if I write this class to be extensible it will only take me a few more hours and it would make it easy to add that feature that the account team was talking about maybe needing.' If they are hidden from that information they tend to build things the simplest and fastest way possible - in ways that might not be as easy to extend later.

Some Managers prefer to not bother their teams with this 'extra' information. They think it's just distracting - or in worst case scenarios these managers think that information about the business is their currency of power somehow - as if information control was the key to how to manage. I'm the radical opposite, and I think that the more information a team has the better they perform (if used along with the culture of excellence).

A side effect of this is that I have to be radically involved in the business side of things. I have to visit customers and talk to real users. I have to listen to product management and compare what they are saying to what I heard my customers saying. I have to ask questions like 'what are your pain points and what feature would make that go away?' This increases my work, but I think it's a fundamental part of my job. Without this I don't have the information to share with the team that leads them to a clear understanding of the needs of the business.

Look out for your staff

Most folks can tell if you really have their interests at heart. I make it a point to know what the career goals of my staff are. Do they want to move on a technical track or get into management? Do they want to get a certain certification? Learn a new language? Build communication skills? It's usually possible to find assignments that will build folks towards what they want - and get them the needed exposure to the right folks in other departments in Upper Management - if you know what their goals are. I've promoted heavily from within and worked hard to build the skill sets of my staff through fomal training, paying for books, brown-bag lunches, and practical on-the-job training. Smart, capable people will respond this genuine concern in very positive ways. Today, for example, one of my staff was on PTO but he spent the morning troubleshooting a problem at a customer site. He figured he wasn't leaving town until later in the day and he wanted to see it fixed. We take care of him, and he took care of us. My staff has responded with this kind of professionalism and extra effort over and over. I believe they do it partly because that's the kind of people they are, but mostly because they believe it's a two way street.

None of this is new or unique. I've built these principles over my career both watching good managers and building other great teams (especially the one I built at Quicknet). But I've also read a lot of material, both in print and on the web. Joel Spolsky writes of some of this in his excellent Guerrilla Guide to Interviewing. I just read a short article about how Rockfish Interactive has created excellence. That's a company I'm watching closely.

I could spend 10 minutes and probably track down ten more good examples - but I bet you readers have some favorites to share. I'd sure like to read them.



[ add comment ] ( 2 views )   |  [ 0 trackbacks ]   |  permalink  |   ( 3 / 140 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | Next> Last>>