Well Oiled Machine

As a leader, I am always looking at situations to find the lessons that are hiding.  The other day I watched a team of engineers working together and it was inspiring.  Here are some of my observations and commentary.

Over the last several weeks, the team has been working on refactoring some of the code that is deep within the bowels of our infrastructure. There has been no shortage of challenges in making these changes.

The code was refactored with backwards compatibility in mind, but that doesn’t always work out so nicely.  It was decided to only retrofit the systems that were in their domain since they are closer and have more intimate knowledge.  They started out strong, but the challenges started to pile up.

There were issues with namespaces, assembly references and code that was removed that needed to be swapped out.  Once the new assemblies were referenced the scope of the issues started to be clear.  One interesting issue that cropped up was a ghost assembly that was somehow being inserted back into the project.  The problem is that was the one library that is getting ripped out.  I blame NuGet (easy target).

We are big fans of swarming our work, but work like this refactoring didn’t seem to lend it self to a swarm.  For those of you who are not familiar with swarming, it is where the entire team works together on a single work item until it is complete.  We have found that in many situations this works well, but that is a topic for another day.

Back to the inspiration.

I walked out of my office and I notice a huddle around one of the engineers cube.  I was curious so I hung out listening and watching, and I was very impressed.  This team was swarming together to help one of the engineers with their refactoring task.

What I saw was an even playing field.  There were no pretenses of superiority and no egos.  Just four engineers working together to solve a problem.  It was a beautiful thing to see!

All to often I see the game of “it was his code” or “that is her PBI”.  That doesn’t sound very teamish (feel free to use that word) to me.  You maybe thinking that all engineers should work together to deliver business value, right?  Unfortunately that is the exception and not the rule in my experience.

It is not often that I get to see that level of team work within a team.  These engineers are some of the most professional teammates that I have had the pleasure to work with.  The interesting piece is that half of the team members are junior, but they operate as a well oiled machine.  I was inspired by their cohesion around the problem, it was awesome!  I was so inspired, I took a photo (pixelated for security 🙂 ).

IMG_3524

Cheers

 

Hero Complex

I want to spend a minute expounding on a previous post where I talked about having (past tense) a hero complex.  I guess the logical place to start is with a definition (albeit, mine) of hero complex.

It is similar in context to the arsonist firefighter lighting fires and then serving as a first responder.  Now to be fair, the arsonist firefighter has a much more negative connotation.  The hero complex is where you need to be the one who solves the hard problems and saves the day.  There are a few problems with this.

At face value, the hero is the one that everyone can depend on to solve the problems and put out fires.  This sounds like a great thing to have someone so dependable, but…  The team dynamic, when there is a hero, can turn ugly.

If there is always someone there to do for you what you can do yourself, you are then robbed of the ability to be accountable.  It also robs you of the glory of saving the day on your own.

I previously held the opinion that this is what a servant leader is.  Shielding the team from the stuff that was less fun aka site down.  That was something that I thought made a good leader.

In the Marine Corps, we were taught that you shouldn’t ask someone to do something that you were unwilling to do yourself.  I think that is a good starting point, but it will not win the race on its own.

When I reflect on those days, I realize that I had an issue because the people were not meeting my expectation.  This was not because they weren’t capable, but rather because I expected that they would be me.  Do things the way I would do it.  Looking back, I can say that this was pretty dumb.

The fact is they were all very talented engineers who could have solved any one of the many problems in an equal number of ways, and maybe one of them was my way.  The important piece is that they solved the problem and not how it was solved.

Now I can take another look at the servant leader and it’s role.  How can a leader best serve the team that he is responsible for?  That begs another question to be asked.  What is the team responsible for?  Your job as a leader is to make sure that they can do their job!  Get them the tools, training, extra help, etc. that is needed to get the job done.

It is a wise leader who can spot and draw out what the team needs to help them achieve their goals.  It is a wise leader who can inspire the team to improve and solve impossible problems.  Sorry, but it is time for a Simon Sinek quote.

It is the leader who should help the team develop why they do what they do instead of what they do.  It is the why they do what they do that will inspire them to come to work, login and do great things.

I started this post talking about the hero complex and how I was once afflicted with that disease.  I can say that I am hero free.  My focus now is to help my team develop our “Why” so that we can inspire each other.  Cheers…