Friday, June 27, 2008

PR, part of your complete breakfast.

No, I don't mean "Public Relations", in this case, I mean "Praise and Recognition".

We all like to be told when we are doing a good job. And a kind thank you, or a pat on the back goes a long way in making us feel as if we are appreciated. This is an important principle of leadership. But, it is something that I have noticed is becoming less prevalent. This is a big mistake.

Companies are spending millions of dollars to increase productivity, implement flexible hours, and increase health benefits, yet they still have high turn over. Why is that?

These policies get taken for granted. A company increases their benefits, attracts new people, other companies follow suit to compete. Soon these heightened benefits become the norm, now to differentiate themselves, companies need to raise their benefit packages and policies again.

I think that PR is especially important in a company where we strive for constant improvement. A culture of constant improvement can result in a culture of constant criticism. I have thoughts on that too.

Most people like to be praised and recognized for the work they are doing, most people like it a lot. A leader must strive to make their team feel important, to create environments where people are rewarded for their hard work and successes.

This is the benefit of rewarding, it is one of several ways that a leader can rely on to influence behavior. With rewarding, it is based on a leader's ability (and perceived predisposition) to praise and reward their their teams for positive behavior.

Praising/rewarding people doesn't cost anything, makes the employees feel good, and reinforces positive behavior.

So remember to say thank you, and remember to tell your team when they do a good job. It is just as important as telling them when they didn't.

Tuesday, June 24, 2008

How to be a good team member

Leadership is often discussed in terms of how to motivate your team, the principles of leadership, and all the other skills and traits that make a good leader. But, one of the most important skills of a leader is actually how to be a good team member. In other words, how to be led. This is the first (key) step in becoming an effective leader.

A bad team member really affects the esprit-de-corps of the whole team. This can lead to:
  • reduced productivity
  • an unhealthy work environment
  • high attrition rates
  • negative cliques
  • favoritism
  • etc
People who are bad team members, will become awful leaders.

So how do you work towards becoming a good team member? Follow these simple guidelines:
  • mind your manners, treat your fellow team members in a respectful manner
  • admit your mistakes, and learn from them;
  • do the right thing for the project;
  • comply with the direction set by your team leader;
  • be a positive influence on your team;
  • accept constructive feedback;
  • help your fellow team members;
  • be transparent about your status;
  • be honest about your abilities.
In reality, these could almost all be summed up by one, "Do not do unto others as you would expect they should do unto you."

Nothing in here mentions that you must mindlessly follow the directions of your project leader in an unthinking drone like manner. Just realize that there is a time and a place to question the direction of your team leader. In front of the customer, or on team call is not the time or place to do so.

Friday, June 20, 2008

Don't be a barking phone

Last night I was talking with one of the other DPMs (I shall call him Toby) here at Macadamian. We were talking about the perception the developers in our global R&D centres have of us.

Toby traveled to Romania and ended up spending nearly 2 weeks there. After he was there, peoples perceptions of him changed. The old perception was that he was an angry person, always mad at something. After Toby visited them in person, they realized hey, he is a pretty swell guy.

Why did they think he was an angry person? It was because most of their interactions with him were not very positive:
  • emails that seemed blunt
  • VoIP calls when they were not performing, or had made a mistake
  • asking them to do something
  • emails asking for status
  • etc
All these interactions where either Toby was in charge, or performing corrective actions.

So what changed on the trip? Well, Toby did these sorts of things:
In short, they realized that hey, Toby is a person, and pretty swell too! It was not that Toby was trying to butter him up, it is just how he is in person.

You as a team leader need to be seen as a person, sure, you are in charge, and you are accountable for the delivery of the projects, but your team is comprised of people and no matter how many times you tell yourself, yes, you are only human.

So, if you are leading a global team, try to visit them in person, and when you can't visit them in person, make sure to follow these simple tips:
  • Prefer voice calls over email
  • When you need to send emails, try reading them aloud to see if they seem harsh or overly critical
  • Don't talk just about business, try to have a water cooler chat every now and again
  • Ask questions like, how has your day been? I heard you were sick yesterday, are you feeling better?
  • Try and schedule the meetings in common hours, if you cannot, try to alternate the times they have to stay late versus you have to come in early
Remember, you don't have to be their friend, but it really helps for you not to be their enemy. And in your spare time, start working on the virtual foozball game for those ad-hoc games, err, I mean design sessions.

Congratulations Marc!

Last night our very own Marc Dufresne was honoured as one Ottawa’s Top 40 under 40. This is a pretty impressive achievement, great job Marc! It couldn’t have happened to a nicer guy.

In other nearly as impressive news, our table was named the best table to be stuck at a cottage for a week. Who has team spirit? We have team spirit!

Tuesday, June 17, 2008

Sales people get no respect

Let's be honest, operations (engineering, QC, IT etc) tend to have a very dim view of their company's sales force. On the totem pole, they are about 6 feet below the HTML/CSS/Javascript developers.

Why is that? Is it their cars, golf clubs, or expense accounts? Or is it just because they are misunderstood? No one really understands their role in an organization.

I was out with our excellent sales team on Friday, and really, they aren't so bad. I was at a sales seminar (no jokes about falling down the totem); the speaker was fantastic, really funny, really insightful, and not very PC. I was talking to one fellow at the seminar (sales guys call this networking) and he expressed amazement that Macadamian was as big, and as successful as we were with only 3 sales people. Kudos indeed.

If you are not in sales, you likely don't really understand. Sure, we developers put in our long hours sometimes to bring a project back to green, but the sales force is putting in those long hours to get that sale in the first place.

The sales people works odd hours, sometimes they work late afternoons, sometimes they are working nights and/or weekends. Sometimes they are flying out at 6am to go see a customer. The difference is they are not in a dimly lit cubicle pecking away at a keyboard surrounded by empty Coke cans and Oreo crumbs on their shirt.

Sure, they are in the box at the Scotia Bank place or the golf course, but they aren't there to watch the game or make a birdie or even a bogey. They are not even really there to sell per se. They are they there to build a relationship with their customer.

The speaker at the seminar had a few nuggets of advice, the one that really relates to what a good sales person does is "Make a sale, make a commission, build a relationship, earn a fortune."

When it boils right down to it, this is one of the things a good sales person is trying to do when they go golfing, or go to the game with their customers. It is with this relationship with the customer that we can get new business, fix old business (relationships) that has gone bad, and work towards becoming that trusted partner that we all want to be.

And most importantly, without our friendly neighborhood sales people, we wouldn’t get paid!

Sunday, June 15, 2008

What is the T.R.A.C.C?

"What is the T.R.A.C.C?", one of my co-workers asked, and realized I haven't explicitly mentioned what the T.R.A.C.C was. Well, no time like the present to rectify this.

T.R.A.C.C is a catchy acronym for the values here at Macadamian. These are values we try to live by. Everyone from the President, to the lowliest cubicle dweller in the dustiest part of the office. Every single employee and new hire are taught these. We are graded against these on our year end reviews. Needless to say, we take it very importantly.

Simply put, T.R.A.C.C stands for:
  • Transparency
  • Responsiveness
  • Agility
  • Constant improvement
  • Collaboration

I have talked about transparency already, and in the coming days and weeks I hope to provide real world examples of applying these values in practice, even when the project goes red. I feel that it is in these times, when the project is red, the customer is agitated, and the team is demoralized that staying true to these values, and providing strong leadership to the team that you will be able to turn that project from red, to green.

Tuesday, June 10, 2008

Toot toot!

Tooting my own horn, my article on "Global Development vs The Agile Manifesto" was published on the Agile Journal. Yay me!

Monday, June 9, 2008

What motivates you?

This weekend I was out on the year end trip with the cadet corps that I work/volunteer with. For the year end trip we went out into the Ottawa Valley to Wilderness Tours to do some adventure training. The unit did mountain biking, rock wall climbing, and whitewater rafting.

Saturday was a real scorcher, very hot, and very humid. At the end of the mountain biking and rock wall climbing, we decided to let the cadets go for a quick swim to cool off. Cool off being the operative word. As the Ottawa river is quite brisk at this time of the year.

One particular cadet, whom doesn't really like to expand his boundaries was the only one who didn't jump in. He wanted to, but couldn't bring himself to go. He would run up to the edge of the dock and stop at the last possible second. This went on for nearly an hour.

The other cadets tried to encourage him to go, offering to jump with him, or help him to the floating raft etc. I tried to encourage him to go as well. I coaxed, and prodded, and encouraged for about half an hour. Then I remembered something about him. I remembered, he loves chocolate. Well, any junk food really.

I offered to buy him a chocolate bar if he would just take the plunge. He didn't bite at the offer right away, but it opened the floodgates so to speak. Within a couple of minutes of that offer, he made the leap. I was pretty happy that he overcame his fear.

This little story underscores a key leadership principle; know your team member. In this case, I knew he loved chocolate.

You need to know the person on your team as a person. You need to take it past the simple and obvious things like know their name, or the ability to pick them out of a crowd. You should learn a bit about their:
  • family;
  • their hobbies;
  • their likes or dislikes;
  • their qualifications;
  • their career aspirations;
  • and leadership ability.
Knowing this information allows you to make informed decisions about how your team member is performing, or what will motivate them to succeed.

Knowing that your team member has an elderly and sick parent can go along way to explain why someone that was previously an excellent employee has suddenly become unmotivated, grumpy, or is out of the office at odd times.

Conversely, knowing that someone wants to be a Project Manager allows you to guide them in their career progression, you can tailor their goals and training to accomplish this. This might also explain why they work longer hours then your average employee.

To be clear, this doesn't mean that you have to be their friend, but it doesn't hurt either.

Wednesday, June 4, 2008

The 3rd Party Bait and Switch Game

Macadamian is a service company. We bid on projects with one of several models. The two most common ones are "Time and Material" and "Fixed Bid". Fixed Bid projects often are high risk, the customer knows this, which is why they want a fixed bid. It allows them to fix their costs and content, if not necessarily their quality.

While we sometimes estimate the work in a Time and Materials engagement, it is obviously mandatory when we do a Fixed Bid. When I do estimation, I don't have 80 hours to do it in; I often have less then 8 hours spread over a week or even longer. Couple that with the fact that estimation feels more likes an art then a science and you can see how we get into trouble.

A good practice when doing estimation is to look for 3rd party tools you can buy or license that will save time and effort (and hence money) during the project.

In one particular web application we researched what was supposed to be a top of the line product for charting and other UI widgets. The "marketing brochure" looked really good, it had all the features we were looking for, and the customer has used the desktop version of the controls for years to great effect. And we bought the support agreement! What could go wrong? Ha, famous last words.

It turned out that the 3rd party control did in fact do everything almost it advertised, just not at the same time. The 3rd party code was a complete and utter mess, and parameters, methods, and attributes for the widgets changed between the different versions, or were not supported in our version.

We ended up "creatively" working around a lot of the issues, but it added a lot of time and complexity to the project, and ended up making the code more fragile then it had to be.

The moral of this story is before you choose any 3rd party tool to solve that problem, spend some time and use it. And I mean, really use it. Don't just run some of their canned sample code; spend at least a full day making a proof of concept on one of your most complex pages (or uses cases) to see if it will work as advertised. If it's a web tool kit, look at its source. Is the source clean, well commented, and designed? Review the developer documentation in some detail, and "Google" the developer groups to see what people are saying about it.

It's the least you can do when your entire development plan hinges on it.

Tuesday, June 3, 2008

Just make a decision

I am pretty big on leadership, and I stress the importance of it whenever I can. This isn’t to say that I am the perfect leader, far from it. I make mistakes, and through these mistakes I hope to improve.

I once told a young cadet that was facing some difficult leadership issues at the unit that the mark of a good leader isn’t in the mistakes you don’t make, but how you learn from the ones you do. It seemed really profound when I told this to the cadet at 3am one cold winter night, and in the light of day, it still seems pretty good.

At Macadamian, this concept of constant improvement is enshrined in our values; in fact it’s the last “C” in “TRACC”. It permeates everything that we do and every aspect of our company. Every new hire goes through training that discusses our values, and we discuss that as part of the employee review.

However, you can’t make mistakes if you never make a decision. A person who never makes a decision is pretty common affair, but they are not really a leader no matter what their business card says.

A leader must be confident, and make sound and timely decisions, you can of course rely on experts in your team for information, but in the end it’s YOUR decision to make.

In almost every case, it is better to make a decision when you have 70% of the information then to make the decision when you have 100%. You will never get 100% of the information, and if you make that decision at 70%, most of the time you will be right. Trying to wait until you get 100% of the information will lead to unnecessary delays, team stoppages and wasted effort.

So just make a decision.

Monday, June 2, 2008

Tasks aren't underwear, they shouldn't be changed daily

I was talking to one of my leads (I shall call him Percy) the other day and he mentioned he was having some troubles with his lead at the customer's site.

One of the challenges Percy is facing are constantly changing tasks. It seemed like everyday Percy and his team’s tasks were getting switched out from under them. This was done with the best of intentions; however we all know what the road to hell is paved with.

The environment that Percy and the team work in is very fast paced, and quite ad-hoc. Everyone is working really hard, and very often I will see emails from them at all hours of the night. Many of these emails directed at the global team. The tasks are switched in the name of efficiency; however it has quite the opposite effect.

There are quite a few hidden costs to this, such as:

- reduced individual morale;
- reduced espirit-de-corps
- wasted effort as team members context switch;
- confusion between who is supposed to work on what;
- wasted effort as multiple people do the same ramp up on the same task
- no sense of accomplishment
- etc

This is especially true in the context of a global team. The biggest drawback to this approach is that the team will begin to doubt the leader; they will lose faith in their leader’s ability to lead. The leader begins to look indecisive, unsure and hesitant.

Constantly changing tasks is never a good idea for the reasons mentioned above, but at least when it happens with local team members, it is easier to explain the rational and do the hand off. With global teams this is harder as the lines of communication are much longer.

In this case, the key to success is to set your objectives at the start of the week or milestone. Have the team take their assigned tasks and get started. If you keep your milestones short then at worst you may lose only a few days of development, but the team will still have their confidence. Weekly objectives are just that, weekly.