The #1 characteristic of a great teammate #WinnipegJets #Pavelec

ondrej-pavelec-by-clint-trahan

I was watching a recent Winnipeg Jets game when I was reminded about the #1 characteristic of a great teammate.

Connor Hellebuyck was anointed as the starting goaltender for the Winnipeg Jets this year. He had a great season in the AHL last year. He had all of the great reviews as he moved through the various levels of hockey. The Winnipeg Jets had grown tired of Andrej Pavelec and his inconsistent play over the last few years. With Pavelec’s contract expiring at the end of this year, the writing was on the wall that a switch was going to be made sooner or later.

Resiliency

But we saw play from Hellebuyck that was very similar to Pavelec. Inconsistent, with a bad goal given up almost every night. Both goalies also had pure gems of games that could get you hoping of what the future could hold. But when Hellebuyck got pulled in three straight games in January, you saw a difference between the two goalies. And then when Pavelec came up to the big club and started three straight games and won you again saw the difference.

Various radio shows called it something different – ‘timely saves’ was the term most commonly used. Whatever the term, Pavelec may give up the bad goal, but then didn’t give up the next goal. He fought through the shots and kept his team in the game. And his team knew that Pavelec would fight to prevent the next goal and keep them in the game. We was a fighter and it was hard to get the ‘next’ goal on him.

Ondrej Pavelec has Resiliency that Connor Hellebuyck doesn’t have yet. The Winnipeg Jets players know that and due to that, they play better in front of Pavelec because it gives them confidence to play their game. They don’t need to worry about making a bad play, because Pavelec will overcome it if it happens. It is a larger worry making a mistake in front of a goalie where it may open the floodgates. Because of that you hold your stick a bit tighter and ironically make more mistakes.

Summary

Resiliency is the #1 characteristic of a great teammate. That trait in a teammate that they are resolute, plucky, committed, able to rebound and recover. We all make mistakes, but those people who take a shot, dust themselves off and stand tall are the special teammates we all want on our team. Give me a resilient craftsman over a fragile artisan every day.

Another example of Pavelec’s Resiliency is how he took his demotion with class and professionalism. Resilient teammates accept decisions made for the good of the team, confident in their abilities and committed to rebounding and proving themselves when the opportunity arises.

I hope Connor Hellebuyck can build these characteristics. But until then, I’d start Pavelec.

The #Agile Apprentice

I’m not sure why but I watched the Celebrity Apprentice last week. I hadn’t watched the Apprentice probably since that first season. I was quickly reminded as to why I stopped watching it. It is a show that shows all the anti-patterns to having healthy teams and projects. Their idea of the roles and responsibilities of a Project Manager is simply offensive.

The Apprentice Project Manager

So as near as I can figure it, the version of a Project Manager in Donald Trump’s world makes all the decisions, is judged solely by the success of the product and is expected to throw the weak links on his/her team under the bus. There is no mention of building teams, mentoring individuals, or collaboration. In fact, Project Managers are expected to also have the authority to make all of the decisions for the project. In short, Project Managers get to be in ‘charge’.

The Agile Project Manager

This goes totally against the concept of an Agile Project Manager. An Agile Project Manager is a servant leader who leads the facilitation and collaboration for the entire team. I have found that when I am a Project Manager on an Agile project I make very few, if any, decisions. The team members and experts make all of the decisions. The Project Manager usually just decides on how to best share progress and status with the Project sponsors.

Why?

So why then does the Apprentice have this vision of a Project Manager?

I thought about this last night and I believe it is related to what the ultimate objectives are in Donald Trump’s world. In Donald Trump’s world, projects exist to amass individual reputation and fortune. Project’s can leave a trail of bodies behind if the project results in fame and fortune. They do value the client, but as long as the client is satisfied the team members can double-cross each other. If fact, that type of behaviour seems to be rewarded.

This is the opposite of the objective of Agile Projects. The objectives of Agile Projects are to grow as a team and provide value to the client. But teams and projects need to be sustainable and repeatable. Agile Projects go to great length to discuss issues exist with systems, not individuals. We succeed and grow as a team.

Ultimately we need to treat each other with respect. The Apprentice seems to have forgotten this and eventually this pattern is not sustainable. The Good catches up…

Project Manager’s #1 Challenge #PMOT

risk-vs-reward1-e1330209788902

One thing that has always perplexed me on projects is how poorly we as Project Managers and project teams manage risk. All of us have the initial Risk Management meeting and try to capture the risks and mitigations required. But even in that first meeting, we fall short in identifying and planning how we are going to address the risks on the project.

Why?

At one time I had thought it was just because we as Project Managers got busy with the work on managing the project and forgot about scheduling follow-up Risk sessions. But that wasn’t it, even when the Risk items were incorporated into weekly status reporting, the effort and attention paid to risk management was just ceremonial. There was something else at play.

I was working on another long project and we were discussing the challenges with the issues and risks encountered. In a retrospective we discussed how we managed the issues and risks looser and looser as the project executed. We did this as we became more comfortable with the client and they became more comfortable with us. Unfortunately new players came onto the project later and changed characteristics of the project. This changed the issues and risks but we were not managing them as formally as before as we became comfortable with the issues, risks, client, and the project.

One person summed this situation up perfectly. “On projects it is natural for the project team to become the project. This eventually happens with the Project Manager.”

This is where the lack of formality and process can be a problem for the Project Manager and the project.

Become the Project

“Become the Project” – sounds rather Zen-like doesn’t it?

Become the Project to me means that you have somewhat lost your objectivity and like the rest of the team you are thinking in a positive and trusting manner. You start to expect issues to be resolved very soon, that risks will not happen, and that if things happen we will address them as one homogeneous team. Well it turns out that perspective is valuable and required by some of the team members as they are working through deliverables, the Project Management and leadership need to be careful to not fall into this lack of formality.

So what to do?

What can we do? As much as we say not to do it, it is human nature. Trust will be built up and used after working with the same people for months and years.

This is where your Project Management Office or Deliver Management Team needs to help your project team by providing the independent 3rd party or sober second thought perspective. The Project Management Office or Delivery Management Team’s role is not to own the risks and issues but to facilitate the review and consult on them as an independent 3rd party. In this way, we ensure the review happens and we make decisions based on all the most current data from the project balanced with objectivity and experience.

Ultimately you want your team and Project Manager to be the project, we just need to add a check and balance to ensure issues and risks aren’t overlooked.

What a Project Manager does #PMOT

I often get questioned by my kids on what exactly I do in my job. I tell my kids that I am a Project Manager and I work on teams that create web sites but that still seems to not convey ‘what’ exactly I do on a daily basis. Then last weekend I had an experience that I was able to point at to show my kids what I do at work. So what was that experience?

Building one of those metal storage sheds.

Construction

Turns out it was my wife’s idea to get a metal shed. We needed to get it to store bikes and softball gear in it. I’m usually the person to put these types of items together but this time we had a lot of things going on during the weekend so my wife got our two nephews to help. Things were going well and the floor got put together well. The shed started to take shape with the walls and frame being put together. The top frame went into place as did the middle frame that re-inforced all of the walls.

Looking back this probably was the early part of development projects where everything is going swimmingly as components haven’t been integrated and tested yet. But very soon, we were going to experience our first integration test.

Testing, Testing, 1-2-3

I hardly provided any assistance during the development, like a good Project Manager. Just let the team go. But then I was starting to hear some frustrated tones from the back yard. The last panel on the back yard wasn’t lining-up. No matter what they did, the screw holes were a centimetre apart.

They finally came in complaining about the stupid shed kit and I came out to see if I could help. I walked around and looked at the instructions and asked them to describe how they put it together and how they had tried to fix it. I checked the schematics and then they noticed that in one corner the two pieces were not flush against each other like the other three corners.

We then tried to line up the panels but the screw holes were still half a centimetre apart. sigh.

Back to the drawing board.

We then walked around the shed inside and out looking for something else that was out of line. By now we had the experience that one corner or side was probably larger than another. My nephews got the idea to measure all of the sides and sure enough one of the braces was too long. We shortened the brace and the screw hole lined up perfectly.

Summary

Over dinner that night I said to my kids that what I did on the shed was exactly what I do at work. I help project teams plan, but most importantly I help them resolve issues. Most of the time they resolve the issues themselves, I just facilitate the process.

I’m not even gonna talk about how hard the roof was to get on….

#Agile Team building by Gary Doer

It was very nice to read a story in the Winnipeg Free Press about former Premier Doer completing his tour of duty as ambassador to the United States. You can find the story here.

Gary Doer

Anyone who knows me knows I am a pretty apolitical beast. There are components I love in every political party’s platform. Truth be known, I am more a centrist than anything. Why then would I say that Gary Doer taught me how to build Agile Teams?

I always saw Gary Doer do three things to build consensus and relationships.

  1. Find commonalities first

Ex-Premier Doer is an accomplished team builder. He perhaps understood people and the power of a metaphor to bring people together better than anyone. Instead of trying to specify a solution or tell people what to do, Gary Doer usually found a metaphor or story that allowed people to get excited about the problem and solution. This metaphor then allowed each individual to interpret the metaphor and find commonality on their own. Many times I witnessed ex-Premier Doer find the only commonality that existed between the two sides and used that commonality to build a bridge to a solution. Usually this resulted in metaphors that were grounded in Hockey or Beer. 🙂 Both are sure to be winners north of the 49th parallel.

      2. No Ego

Gary Doer also had the charisma and modesty to be self-effacing and have a friendly conversation on the issue. He really understood that all progress comes through building relationships and that authority is lost once you have to use it. Never once did I see him upset or rankled, directive or flustered, he was always even keel and building bridges. This lack of Ego really did allow people to understand that he truly was interested in your position and he cared. He also understood he couldn’t just tell you what to do and usually had a suitcase full of facts to share with you.

      3. Walk the middle of the road

Then when it came down to the issue, Gary Doer was always able to walk the middle of the road and not appear overly partisan. (Maybe I have this view because I like the middle of the road) 🙂 But whatever the reason, Gary Doer was an expert in building compromises and solutions in the middle of the road. On a team, you usually have to walk the middle of the road. If you always swing to the extreme of one side of the team, you will eventually lose the other parts of your team.

Summary

I wish Gary Doer all the best in his next challenge. If he needs a new challenge, the political scene in Manitoba could always use another good person. 🙂 Or I could always use a good Agile Project Manager.

5 Books that changed the way I think

Over the years I have been lucky enough to find books that have profoundly changed the way I perceive the world and the way I think. I usually know when I have found one of these books when I read the book over and over. This is a list of those top 5 books in chronological order of when I read them. I’ve also included how I became aware of the book.

  1. Lord of the Rings – John Ronald Reuel Tolkien

Like most young adults I was a bit of a grazer when it came to reading. I was reading enough at school that I really wasn’t looking for books to lose myself in outside of school. And then I found Lord of the Rings. Funny enough, I actually stopped reading the first time in the Council of Elrond chapter. The book didn’t really grab me up to that point. The second time I read the book I made it past that chapter and I was hooked. I think I have read the book at least 6 times now. The book really taught me how important stories and the stories behind the stories are. In many ways Lord of the Rings taught me how to also be thoughtful. Great Book.

I became aware of Lord of the Rings just from other students in my classes. Funny enough, my brother was not a Lord of the Rings fan. I remember he was a fan of the Dune series. I think this was a generational thing,

2. Godel, Escher, Bach – Douglas Hofstadter

I still remember spending weekends cycling to the park and reading this 700 page tome on formal systems. This is perhaps where I really fell in love with Computer Science. This was probably the height of being a geek as well. For the love of me, I can’t remember how I became aware of this book.

This book really did teach me how to analyze and create formal systems and in many ways how to code. It also caused me to think at a higher level about intelligence and consciousness. Great book to think about big thoughts.

3. Zen and the Art of Motorcycle Maintenance – Robert Pirsig

One of the books I first spotted in my brother’s library. I picked it up and was hooked immediately. Zen taught me the beauty of introspection and thought. It also taught me to be respectful of people who may have psychological issues. This book explained the emotion and heartache of mental issues as I read. I found the entire book and story fascinating. To this day it probably is my favourite book and the first one I reach out to when I have spare time. Robert Pirsig’s second book Lila is equally good.

Under the covers the book also spoke to me a lot on Quality and what quality is. This has been very helpful in my work life.

4. Iron John – Robert Bly

The second book I spotted in my brother’s library. The perfect book for a man in his 30’s to read to find guidance on the changes a man will experience growing up. A great book that balanced embracing what it means to be a man in the face of much bashing of masculinity in the 90’s. This book gave me great confidence. Perhaps a little too much.

5. Epistulae morales ad Lucilium – Seneca the Younger

I think I found this book when I kept on seeing Seneca being quoted in other books. This is a philosophy book composed of letters from Seneca. I loved how the letters were grounded in reality and in actual stories. This combined with the Stoic philosophy really spoke to me and resonated with my beliefs. I found more confidence in aligning myself with the Stoic principles as I went through some challenges at work in and my personal life.

Best Work Book

The best work books I have read comes down to a choice between two:

  1. Beautiful Teams

Beautiful Teams is a wonderful book with each chapter describing a situation and how a team was structured to help address the situation. Great book with a lot of real world examples of what great teams can do.

2. Leading Geeks

Awesome book providing insight on how leading Software Development professionals is different from leading anyone else. A must read for any Software Development professional. Even if you are not leading other geeks, chances are your manager will have read this book!

Creativity, Inc. and #1 reason why projects struggle

I just recently finished reading Creativity, Inc by Ed Catmull. It is undoubtedly one of the best books I have ever read. The book provides a history of how Pixar came about and how Pixar has managed to maintain their culture of creativity and innovation. There are many poignant lessons that I took away from the book, but perhaps the one that resounded the most was the use of what they termed the ‘braintrust’ team.

BTW, I hate the term Braintrust – I would rather just use a term without any implied hierarchy.

Braintrust

The concept behind the Braintrust team is that it is a team made up of their most senior writers and creative minds that can help to review the status of the movies on a regular basis. The objective behind these meetings are that these senior team members have a wealth of experience they can pass on to the team currently working on the movie on how the movie might be missing the mark.

There are a couple of simple rules:

  1. The feedback is not personal and it given in the spirit of making the movie the best in can possibly be.
  2. The feedback does not include the solution to the perceived issues and the Braintrust team has no authority to get the team to implement a certain solution.

The goal of the Braintrust is to highlight opportunities and then let the movie team determine the best solution. Questions may be raised in the next Braintrust review if nothing has been done since the last meeting, but there is no direction that they give the team on how problems should be solved.

Why?

Why do I like this model? On many projects I have been on we have tried to have some level of review and governance to help the project teams. But like many other people I know we have always struggled to get to the real issues that the project is encountering. Our checkpoints just didn’t highlight the areas of concern. So what was Pixar doing that we weren’t?

One thing I thought initially was that Pixar had their Braintrust be a team of 4-5 people. This is ideal as it brings a wealth of experience and also balances the project team and Braintrust out in terms of numbers. I think when an entire project team reviews their project with one person, the difference in numbers could allow for a pro-project point of view. This is not done intentionally, but could lead to the dismissal of ideas just due to the difference in numbers.

Culture

The project culture at Pixar is profoundly grounded in their culture. It can be summed up simply as:

“Projects are expected to struggle, a project running smoothly is not a goal”

Let’s think about that for a second. Management’s job is not to limit risk but to build the ability to recover. Management is doing their job when their teams are able to solve problems. I haven’t found this perspective in many software shops. In Software Development companies the goal is to have a smoothly running project.

This is quite different that the traditional approach where we have project checkpoints and see our role as management to try to solve the problems the team have and get the project to run smoothly again.

This approach frees the team up to be creative and try new approaches knowing management doesn’t view problems as some fault of the team. Pixar understands that the project team must become the ‘project’ they are working on to be able to achieve the objectives of the project. The downside of this is that the project team then loses some of their objectivity to be able to achieve the objectives of the project. The Braintrust can then assist in that regard to provide an unbiased view to help the project achieve all of the project’s objectives.

Summary

I think the Braintrust model has a lot of promise. I hope to try something similar in the future. If you haven’t yet read Creativity, Inc, do yourself a favor and pick it up.

Oh yeah and what is the #1 reason project struggle? They struggle because they are supposed to. Having a project without struggles means the project probably didn’t do much that was new or different or complex. Have a lot of those projects and your company isn’t moving forward any more.