Image: Dmitry Dzhus, creative commons

In part 1 of this series, we looked at productivity as the first point of the team triangle – three essential considerations when building and maintaining healthy teams (particularly in startups).

In this piece, part 2, we’ll look at reliability as the second point of the team triangle.  My team is currently on a hiring mission again, and spread across four time zones. So reliability is going to be a key factor for this hire, especially since the person will be a department of one for the time being.

Reliability

Slow and steady wins the race and all that. If someone is rock solid reliable, team and management will likely be more accepting if the person gets things done a bit more slowly, or doesn’t always have the most brilliant ideas or all the answers. This will most likely describe new team members who are eager and who have skills and expertise, but aren’t fully up to speed yet.

However, if the person says something will get done, it will, and the person doesn’t require a lot of management to get there. The person will also ask for help if he/she gets stuck, and tends to be pretty good about checking in, making deadlines, etc., even if it requires extra hours. Especially for newer team members, they’re still working to prove themselves (hopefully).

The drive to be reliable will also often help with communications and a good team vibe, as in order to get things done, the person will be more inclined to reach out in a timely way with questions, or when stuck. The team member may not know the exact right person to ask a specific question, but will likely make educated guesses, and in the process will develop relationships with a variety of team members and an understanding of who is in charge of what (or at least most knowledgeable about it).

If the team member happens to be a bit rough to deal with, though, people will mostly be inclined to just leave them be as much as possible. If a team member is crazily productive but not reliable, it negates much of the productivity, since it hamstrings entire teams or projects. An amazing new feature is a lot less amazing if it wasn’t in the spec and was developed instead of what was assigned, or if it is delivered after the ship date.

You know that if the person delivers, it will be amazing. If the person delivers… And if he/she doesn’t, everyone suffers. In the grand scheme, the person can’t be trusted to get things done, and so backup resources better used elsewhere need to be kept available. People who don’t deserve extra work getting dumped on them get it anyway. This builds resentment and kills trust.

Particularly in small and/or remote-working teams, reliability is key, because the resources to cover a lack of it are very limited, and, with things like disparate time zones, if something important doesn’t get done when it needs to be, the rest of the team may not know about it for hours. On the Internet, hours can be a very, very long time.

Next time we’ll look at fit, which can be the most nebulous to describe, but felt most strongly. It can also be the most uncomfortable to deal with, since it can affect people who are otherwise excellent – reliable, productive, etc. – but who nonetheless just aren’t going to work out for your team.

 

About The Author

Melanie Baker

M-Theory is a guest column by Melanie Baker, who is a big fan of building communities and working with geeks. She spends her days fixing the internets (in a way), writing, chasing her puppy, and creating fanciful beasts out of socks.