Sometimes I feel like Bill Murray

What now seems like a very long time ago, Bill Murray starred in a little film called Groundhog Day. Sometimes I can really relate to that film, we keep doing things over and over.

At Macadamian, we take a lot of pride in "Constant Improvement", in fact its one of the Cs in this blog title. As part of this process, at the end of each project we do what we call a "Phoenix Session". Also known as a project post-mortem. One of the outputs of this process is what we call the "Lesson Learned". Usually, we learn at least one lesson, sometimes two.

The problem with this process is that the "Lesson Learned" gets documented in Confluence, and becomes "Yet another page no one ever seems to read". Many of these "Lesson Learned" are very insightful and useful, and while we send them now to the entire operations leadership, we fail to teach them to our project champions.

This is true for PL101 training in general. We are all so busy, we often rely on what many call OJT. Out of the most recent batch of "Lessons Learned" there was one re-learning what was actually documented in the "Client Deliverable" process. Documented on Confluence. Oh, and its actually the first page in our PL101 training.

I don't blame the champion for this, that person didn't have the knowledge or the skills. I blame us. We as an organization have to better support our champions, PLs, and new developers.

This will help them not feel isolated and left out to dry. We already have a mentoring program for new employees, now we need to extend this to new champions, PLs, and of course, PMs.

What makes a good team lead? Part Two

A week or so ago I had a post about what makes a good team lead. In this post I had a list of statements that I would look for in my team lead. Many of these statements can be derived down to base personality qualities such as being:

• Decisive - It is almost always better to take a decision with 80% of the information then it is to wait for the other 20%. Overall you will get more done faster.
  
• Enthusiastic - Enthusiasm is contagious, it will inspire your team
  
• Responsible - Do the Right Thing. It is also a mantra at Macadamian.
  
• Honest - Does this need explaining? Nothing destroys trust like not dealing with people in an honest and fair manner.
  
• Dependable - Make your commitments, be there when needed.
  
• Confident - People are more apt to follow you if you appear confident. Show confidence in your team.
  
• Courageous - This goes with "Do the Right Thing", also goes well with being "Transparent". It is hard to tell the customer that you are late, or to tell the employee that they are not meeting expectations. You should also be courageous enough to stick to your convictions, or try something new.
  
• Loyal - Always try and do the right thing for your team. Go the extra mile for them.
  
• Patient - This is one I have trouble with the odd time, but be patient to answer their questions, help them with a new technology, or to understand a new requirement.
  
• Determined - Get the job done.
  

To me, these are the 10 important qualities of a team lead. Does anybody have others to add?

Reviews should never be a surprise

Over the past few weeks I have been dealing with a yellow project of mine. The project is yellow because of the customers perceptions on the design, code quality, and general attention to detail demonstrated by the team over the 3 month project.

Now I had sought out feedback on how the team was doing several times throughout the project, but never received an answer. During the project debrief, the poor performance was brought to my attention. Unfortunately, at this point there was nothing I could do about the current project, and could only try to improve on the next project.

Like praise and recognition, being told you are not meeting expectations is very important. If you are not told otherwise, you may very well be thinking you are doing a great job.

I understand that sitting down with an under-performing team is hard, often the leader will be comfortable. It is hard to do this. However it is absolutely imperative that this be done.

If we don't take action on this right away then many bad things can happen:

• resentment builds within the rest of the team
• the leader starts to resent the under-performing team or individual
• features have to get dropped due to time constraints
• quality suffers
• etc

The top two are real team killers.

A meeting discussing the expectation gaps, and a plan to address these gaps will go along way to improving the under-performing team or individual. If they don't improve, then you have at least started the process that is required to remove them.

At the end of the day, it is a leader's responsibility to make sure all their team members always know how they are doing, whether it is good or bad. It's our job.

What makes a good team lead?

In a previous post, I talked about what I think makes a good team member, and in order to be a good leader you must be a good team member.

So as a leader, you should think about what makes a leader good from the eyes of their team. Is it their movie star good looks or their willingness to bring in donuts? I sure hope it is neither even if you like donuts.

Your team (and you) hopefully look for most of the following statements to be true when thinking about your team lead or manager:

• be an excellent communicator, and good at using the tools at their disposal to plan and organize the team's work load;
• be self-confident, and strong within their domain of knowledge;
• makes reasonable, objective, and consistent, decisions within their boundaries;
• be able to mentor and coach the team to achieve maximum performance;
• be able to inspire the members of the team;
• to understand and choose the correct style of leadership based on the situation;
• to demonstrate integrity at all times;
  
• to be trustworthy and honest;
• to be an excellent problem solver, both with anticipating and solving the problems;
• to be able to handle stressful situations
• to respect you.
  

So, can anyone think of anything else to add to the list?

T&Ms should really be called "Time for Money"

Macadamian has several engagement models, the two most common models are Fixed Bid and Time and Material (T&M). Both are relatively common. However, I have come to realize that T&M contracts don't exist. They are this mythical creature -- like the phoenix -- fabled to exist, but rarely seen in their true form.

Why are T&Ms rarely seen? Because I have rarely been able to bill any material to the customer. It is the cost of doing "business". This means that any material we need for the project comes out of project margin. On shorter projects, this can mean a significant percentage.

The only real solution to this is to make sure you have thought of this upfront, planned for it, and let the business development folks know upfront. That way they can ensure it is covered in their margins.

The other thing we can do is stop calling them T&Ms. Perhaps we should simply call these "Time for Money", "Team Extensions", "Expert Time", or something really clever that shows our expert kungfu.

Long weekends mean long work weeks

At the start of the summer, I planned to take a few Fridays off in-order to have some long weekends. After all, who doesn't want to have some long weekends in the summer?

There is just one problem with this, I ended up working quite a bit more then 40 hours in the week. I found that I would work almost a full day extra in the week I would take a long weekend.

The Thursday before and the Monday afterword were stressful as I tried to wrap up 40 hours of work in 32, and then catchup on Monday.

After a two weekends, I decided to stop. Instead, I resolved to take at least a week off from work when I take vacations. This way I can completely unwind and not stress about half finished jobs back in the office.

It is really important to unwind on your time off, and when I am off for a week, I don't worry at all about work.

9 Reasons Why Application Developers Think Their CIO Is Clueless

An interesting article describing some reasons why developers think CIOs are clueless. This can likely be extended to DPMs here at Macadamian and any management position. Luckily, at Macadamian all our DPMs are ex-technical or UX people. This means, at least we understand our respective domains :)