Building a solid bench involves years of preparation with no immediate reward. Hiring a team from scratch is a beautiful dream. I got to do it once at a startup before I had much experience as a manager. In many ways I’d love to re-live that experience, but I haven’t worked at a startup in almost 10 years now.

If you’re not at a fast expanding startup you’re hiring opportunities are going to be an uncommon occurrence. Unfortunately they’re probably the most critical aspect of your job. Nothing is more important than building a team with the right people. Management success is all about people.

Building your bench is the process of making sure when you do get the rare open req that you have some great people just a phone call or email away.

I’m still working on techniques here and my networking skills need to grow, but this has been the tips I’ve picked up over the years:

1. Keep in touch with your high performers from previous jobs. Obvious, but this means you have to make a habit of making the occasional phone call or email and making sure you know how there career and life are going.
2. Stay in the same area. I’ve violated this one before and it can hurt. I’ve worked for some great companies in the Bay area and in Las Vegas and had a good network of people in both locations. When I moved up to Sacramento 8 years ago I still kept in touch with many of them, but a remote bench just isn’t effective compared to having a local one.
3. Attend conferences, local user groups, and meetups. Passionate software developers show up at user groups and meetups. The local java and ruby user groups have been a great source of motivated talent as well as a nice social gathering. And yes this means when the group goes out after the presentation you should tag along.
4. Keep old resumes and interview notes. I’m in a medium size city, but there are only so many software developers in a town this size. You will run into people again. Often they’ll be developers who you thought had potential 7 years ago, but were too inexperienced to bring on board. It always feels like deja-vu, but it’s happened to me more than once.
5. When opportunities arise be frank about the minuses. Good recruiters know this well. You’re dealing with a long term relationship so you don’t want to get someone excited or bring them into a situation that is too risky or just wrong for them. They need to know if the company is generally slow paced, doesn’t have that many benefits, or they’ll be working with a largely junior team that will need a lot of mentoring. Selling the upside is fine, but give them the downsides.
6. Don’t get frustrated if some of your bench turns you down. Maybe the opportunity was great, but someone’s comfort level in a downturn is to stay with their current company. The situation may be very different a few years later.

Not to long ago one of my developers came across a little mockup tool called Balsamiq and then I saw a post from Clark Ching who checked it out as well. I love the sketchy look and feel and rendering a quick mockup form was good fun. We’ll probably try it out on a future project and see if we can get some value out of it. Much like the Swing Napkin look and feel the value is from being obvious that this is not to focus on look and feel, but more on the functionality of a web site.

Denis over at One Brike At a Time recently expressed frustration at having to use low trust practices:

It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write decent unit tests.

The frustrations are real. Teams are often at many different levels of skill and experience. Even minimal unit testing is not a common practice in many shops. You can still find developers who look surprised when you ask where their code is checked in.

Lower trust practices can be a bridge:

• Source control is a given. Developers who check in bad code you might force you to lock things down for now. Continuous integration is a way to grow out of this. If all of your projects are being built with any change, you can quickly discover if someone’s injected some issues. This might mean setting up notifications for even successful builds for non-active projects.
• Code reviews don’t have to be a negative. I’ve used them and still use them more for mentoring than as an audit of bad code. Code reviews are easy to get wrong, but used safely they can improve the code base and improve your coders through sharing. And I always leave the easy out–no code reviews if you’re pair programming. *

After about 45 minutes of frustration trying to work through some maven exercises in the Sonatype book I kept arriving at the following message:

I had the sample code downloaded and got the same error, so I investigated possibly not having access to the maven repositories. I’m on my in-laws network, possibly there’s something being blocked. I tried other mirrors without any success. Finally I just deleted the local maven repository and re-ran

and everything just worked. I had forgotten how finicky the local repository can be.

It’s 3:30 on a Friday afternoon and you just got the test passing for a nasty intermittent bug after spending most of the day on it. Now you can jump back into the main code base and add that new feature. Only, that would be a bad idea.

The Friday Rule:

Try to leave every Friday with a success.

You want to head into the weekend with a win. That win can be small, but carrying frustration into the weekend means you’re less effective next Monday. You walked away frustrated and probably thought about it over the weekend. Weekends are a critical for recharging batteries, spending time on hobbies, and hanging out with friends and families. They are not a good time to mull over bits of bad code or a misconfigured server. Walk out with a win.

There are some implications worth noting:

• Say you fix the critical bug at 2:00PM on Friday. Switch your energies to something lighter like clearing your inbox, filling out release notes, updating the wiki, or completing a mandatory online training class.
• If you’ve had a really long week already now is probably a good time to head home.
• From a coding perspective leaving a good breaking point is to write one last test that fails. Then you can easily pick up where you left off.
• As a manager when a developer swings by to explain how they finally got something working and you see it’s already well into Friday afternoon encourage them to take the victory with them over the weekend and not continue to code away.
• This can apply as a daily rule, but it’s more critical on Friday where you can affect your mood for the whole weekend.