A note on software teams and individuals
I'm currently running a loosely coupled team of people all working on a common initiative. While this is not my first time running a team, the same set of things seem to happen with all 'new' teams. Here's a quick set of observations.
The first major observation is that teams of engineers can quickly fall into operating like a "golf team" versus a "football team". In Golf, each team member generally competes against all other players (and their different teams) as an individual. A given team wins if it's individual players collectively do better than some other team's players. Football (or Soccer or Basketball) is very different. A team wins in the face of good opposition only if it plays as a team.
For software teams, done means one thing: the team is done with the milestone or project. Done means finished, tested and shipped code. Does does not mean "my part works", or "my tasks are done".
IMO each team member should answer these questions to the group every day:
- What direction I am going relative to team goals.
- What specific items I am working on today.
- Does anyone need any help from me?
- Do I need any help with my work?
Team managers, both the overall and functional leads, should ask or answer these questions for the group every day:
- Are we as a group going the right direction (towards the goal)?
- Will we meet the timeline and/or functional goals?
- Is there any functional or task ambiguity that needs working out?
- Are any course corrections needed?
The second observation is that there are two major indicators of if a given individual is a good addition to the team:
- Does this person communicate well and often?
- Does this person have the capability and desire to resolve ambiguity on their own when possible?
The second skill, resolving ambiguity, is in my opinion the primary question that a software hiring manager needs to answer in the affirmative about a given candidate... assuming of course the candidate has the needed skills.
Much of this also circles back on a blog post that Jordan Mitchell wrote years ago when I was hip-deep in code at Others Online.
