My Expectations of a Technology Team

I’m a tough person. I don’t settle for mediocrity in my own work, or in the work of those who work with me. There are the minimum height bars, and then there are the ones I set. Knee-capping height, some even high enough to deliver serious abdominal or even cranial damage if you’re not careful. Normally, I subject only myself to these standards, and beat myself up when I don’t achieve them. But as I’m also a manager, they do creep into others’ reviews.

In 2005, I think many people thought I was an outright ass for marking people as hard as I did. I gave “average” marks to otherwise outstanding people who made one or two mistakes. I considered them serious mistakes. Not ones that would get people fired, but ones that I really felt needed direct attention. There were repercussions to myself though, and I was brought to task for those marks. Not for the marks themselves, but for the way it was communicated. How are people to know what they’re being evaluated against?

To avoid the old “pot calling kettle black” situation, I’m taking direction I got during my own review, and stating my expectations for my technology team. These are the actions, behaviours, thoughts, considerations, and qualities I want to see from those I work with directly. The expectations are high, but I know the people on my team — and they’re not afraid of pushing themselves. Some of these come right out of Critical Mass’ own core qualities. The wording is my own.


Common sense is often one of the first victims when pressure kicks in. It’s tough to overcome — too many things on the go causes confusion, and confusion almost invariably leads to trouble.

That’s the only thing we need for common sense. Keep those two rules in mind, and the rest goes much more easily.


People make mistakes. They happen. People aren’t perfect, and people are prone to error. (And as the saying goes: To err is human, to really foul things up you need a computer.) I want people to own up for the mistakes they make, be it in a decision they’ve made or a glitch in their software. It’s a learning experience for all, and standing up for that mistake earns points in my books.


Without communication, any team comes to a grinding halt. It is the cornerstone of any well-functioning team. This enables not only knowledge-sharing for skills development, but also ensures that the team is pulling stroke at the same pace, and that we’re all going in the same direction.


I’m beginning to develop a distrust of some types of people because I continue to see the same shifty behaviour: tell me one thing, and do something else. That level of dishonesty is reason enough for me to have someone removed from Critical Mass. I don’t care if you’re the best programmer we’ve seen (and in all honesty, you’re not — the best were always honest), if you’re purposely trying to misdirect me, chances are your software follows the same poor patterns.


Patterns and process are what help us do our jobs quickly and efficiently. If there is inconsistency, then there is trouble — an inability to properly address situations that are common and regular. And there is nothing to fall back on in the event of trouble.


We believe that Critical Mass hires the best people for the job. That does not discount the human equation however, and some developers have their own way of doing things.


One thing that most developers are poor at (and I freely admit to the same thing in my earlier development career) is documenting what they do. Not just the code (comments are a good thing), but also writing down standards, techniques, things we’ve read in articles, new libraries, and gotchas that we come across in our daily work.


Nothing gets better without change. That means people need to make change by finding better ways of doing things. The past is a great foundation, but we can always be better than we were.


Most of the topics tie in with each other. Some need to be called out specifically, and one of them ensures that everyone is playing on the same team, and not just their own.