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.

Sensical

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.

• Don’t guess - know
• Don’t know? - Ask!

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

Accountability

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.

• Make a mistake, let me know — no matter how serious
• Come armed with a solution, if at all possible — it helps correct the mistake
• If you made the mistake, do not point fingers at others
• If someone else made a mistake and isn’t coming forth, encourage them to do so; otherwise, tell me
• Don’t tell me that software “works on my computer” if it doesn’t work on any other environment, you’re just telling me that you haven’t tried to solve the problem or care to try
• Trust those around you implicity — they were hired for a reason
• If you’re made the lead of a project, you’re the lead until you’re told otherwise
• Never, ever walk away from a project and expect that it will somehow run itself

Communication

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.

• No man is an island, and no-one can function without support
• Raise issues the moment you think it’s an issue; in many ways, crying wolf is better than not crying at all
• If it’s going to take a week, say so — “two days” only digs everyone deeper into a hole
• Speak up in meetings, even if you have nothing else to say than agreement to a point
• There is no such thing as a bad idea — any idea is valid and all deserve to be heard
• Speak clearly, think clearly: if you can’t express yourself then no-one will understand you
• I would rather spend a whole day answering questions than having to find out why a question was never asked
• Similarly, there is no such thing as a dumb question
• When you’re reassigned to another project, make sure that the person taking over for you understands what’s going on and how to handle the situation
• If someone asks you for help, don’t brush them off — one day, you might need to ask them

Honesty

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.

• Do as you say you’ll do
• Tell me the moment you can’t do what you said you would, and tell me why
• I have no qualms about having people who actively misdirect my team or myself permanently removed from Critical Mass
• Tell me when you think I’m making a mistake — I would rather find out directly from a stranger than indirectly from a friend

Consistency

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.

• Chain of command is there not to impede you, but to ease your path
• Follow the standards so you don’t have to guess what to do when developing a solution
• If you have to break a standard, document the reasons why
• If you need to regularly deviate from a normal process, then you should stop and ask why the process is not being followed
• Developers develop. Quality Assurance validates. Release Engineers configure, deploy, and maintain. Project Managers control and approve. Any mismatch should be questioned.

Competancy

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.

• Hacks = evil; don’t do evil
• If you feel the need to use a hack, talk to your Tech Lead to ensure there is no other way
• Don’t reinvent the wheel — if the method, library, technology, or technique already exists, use it
• When a lead gives you a direction, you may argue your point; if your lead tells you to follow direction afterwards, stop arguing

Documentation

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.

• All standards should be clearly documented in the Wiki
• Articles and discussions regarding standards and best practices should be in the Blogs
• Comment your code, with at least a block at the top of each page, and before each method to briefly describe what it does, and inputs/outputs
• Write your code so it is inherently understandable — it will cut down on your need for comments

Innovation

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.

• Challenge the status quo, including standards, management, process, technology
• Never feel ashamed or scared about presenting ideas
• The best way to present an argument is to demonstrate your point clearly

Teamwork

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.

• Work with a team, not against it (there is no “I” in team, though there are two in “suicide”)
• If you’re packing up to go home and most of your team is still sitting working away, ask yourself if you can do something to help them. It prevents resentment, makes you look like a superstar, and helps the work move faster
• PMs do all resourcing, working with the Tech Lead; assignments are based on technical skills and availability
• Support your team, and your team will support you
• Desire to go above and beyond. There’s a lot of people who want that Sr. position — you don’t get it by punching in and out. You get it by going beyond your job to help others finish theirs.