Team Player

Is your application a good member of your team, or a horrible member? Does it let you know when it is feeling down, and can’t handle the work assigned it? Does it let you take a break, without requiring you to hold its hand all the time?

Good Team Member

How many people are on your team that you just don’t know if they are actually going to show up to work? They don’t email or call, but they just habitually don’t show up to work. Probably not very many. To be an effective team, there are certain requirements.

Trust. You must be able to trust your teammates. If they say they will get something done, you know you can trust them. They let you know when they cannot fulfill expectations, or when you are not fulfilling their expectations of you. This second one is a related requirement, accountability. Trust and accountability go hand-in-hand. If somebody is not accountable for their actions, you can rarely trust them.

Communication. The team knows, at least generally, what is being worked on. Each member likely doesn’t know the details of what everybody else is working on, but they know enough to talk coherently about it. Or at least ask the right questions. The team has a shared goal, and the communication flows out of that goal. You re-evaluate the progress towards that goal daily. You make sure the current items being worked on are moving the team closer to accomplishing the goal.

Running Software

Can you trust your application? Does it communicate well with you? How does it help you achieve your shared goal?

Does it let you know when it feels down, or does it just not show up? How well does it fulfill expectations? How does it tell you, or others, when it cannot fulfill those expectations?

Probably most importantly, does it share the same goal as you and the rest of your team does?

Inspired by Jessica Kerr and her discussions on being a symmathecist in the medium of software.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.