Intrinsics and Leadership

A few months ago I wrote about Project Management vs. Project Leadership.  The dichotomy wasn’t perfect, but it can be informative.  There’s also more to discuss.  One thing that wasn’t considered in that original post was the relationship between a supervisor and the employees as intrinsic or extrinsically motivated individuals.  In Daniel H. Pink’s Book, Drive he discusses how this difference impacts performance.

Extrinsically motivated individuals looks for external stimulus (positive or negative) in order to induce action. These are often seen as the carrot or the stick, and so much of our society is based on the idea that humans are sedentary and the only way to get them to do things is with either a promised reward or punishment.

Intrinsically motivated individuals are self-motivated. They like to solve the problems and puzzles in front of them for the sake of solving the puzzles. Daniel makes a compelling case for suggesting that we’re all naturally intrinsic beings who learn to be extrinsic based upon our experiences and in contrast to our nature.

An intrinsically motivated individual is going to respond to a project leader. An extrinsically motivated individual is going to respond to a project manager.

If it is in our nature to all be intrinsically motivated and we’ve only surprised this at some point then it would make sense that this intrinsic self of ours could be reinvigorated through the practice of project leadership.

The Chicken and the Egg

Tracking and understanding dependencies is a big part of project management. There’s been quite a few times when you map out a series of steps that are dependent on one another and you end up finding a situation where two things are codependent on one another. In English we call these chicken and the egg situations, based upon the quandary, which came first, the chicken or the egg?

In project management dissecting the chicken and egg situations requires some skill. This is because in real life the chicken and egg situations often means that one person will be asked to build something without having all the information. That person will move forward into new territory knowing that a significant portion of his work will have to be redone and result in rework. That’s never a pleasant feeling and I’ve also seen it lead to people feeling like their work didn’t add value–when in reality it adds a significant value.

food healthy dirty leaf

I’m generally not very funny. If it weren’t for the fact that I put my foot in my mouth people might get the impression I’m no fun at all. So I’ve been studying jokes–bad jokes–to help me be more funny. Why bad jokes? Because even a bad joke is so funny it sticks with you and brightens your day. One of my favorites: What did the green grape say to the purple grape? Breathe you idiot, BREATHE!

Recently, I’ve come across a bad joke about the chicken and the egg. It goes like this.

I ordered a chicken and an egg from Amazon. I’ll let you know.

Turns out you can answer the age old question by shopping online. Who knew?

The Amount of Work

I had someone try to tell me thank you for my work on a project recently.  I had earned the compliment, but felt awkward accepting it. I didn’t do all the work. I was just part of a good a good team.

I needed a good response and despite how witty I might appear on this blog I’m not always quick witted. This is one of those exceptions. I actually thought of something good to say.

I told him that the amount of work I did compared to the amount of work the team did was really small and that I was grateful to be counted as a member of that team.

Project Management vs Project Leadership

I’d like to start off by pointing out this is not a true dichotomy.  Project Management and Project Leadership are not exclusively on the same spectrum, but there are differences and placing them as opposites on the same spectrum can provide some insights into the discipline and our behavior.

Transactional vs Contextual

One of the ways I’ve seen the differences is in the way PMs conduct themselves at meetings.  I’ve seen great people use meetings as control points where they’re focussed on accounting for the progress on a particular deliverable and only the progress. The dialogue usually includes something like “Tim, can you tell us the status of XYZ deliverable?”  Moving around the room they’ll use a slightly different line with the next person “what’s the progress on EFG?”  “When will this be ready to hand off?”

These are closed transactional questions that don’t lend themselves too much more information than could be achieved by a bar graph or spreadsheet.  Why pull people into a meeting for a status you could get from a website?

In contrast I’ve worked with others who don’t directly focus on the progress of the deliverable, but instead will start with focusing on the person and their team.  More than one time I’ve been a part of a meeting where a project leader will ask someone how it’s going and in the course of the response they’ll get a full status update as well as context that helps to understand the challenges that team faces.  The style that only focuses on the status loses important context.

I’ve often said that Lean can be simplified into the sentence of “making work for the next person easier at the point of hand-off.”  This is hard to do without a shared understanding among the team of the context the next person has to operate in.  Shared context helps to make the work of the team visible it’s something leaders strive for and managers miss.

Our Reality’s History

Any time you see the word management written it’s probably referring to a definition widely influenced by Frederick Taylor.  The industrial revolution moved work from disparate and disconnected environments and consolidated them in factories.  Very quickly people who went from one generation working with a handful of others in agriculture found themselves working with hundreds of others.

This drastically changed the way the work force operated.  It also mean that there was a large diversity in work ethics and work experiences.  This was especially true in the United States when immigration meant not only a workforce new to the job, but new to the language and culture of their new country as well.  Non standard processes and perspectives can lead to significant issues with production.

Frederick Taylor saw how these problems impacted the productivity of manufacturing and performed studies and wrote about the solutions he found.  His book, The Principles of Scientific Management has been widely influential, but because of his generation it contains a few flaws that encourage transactional behavior.

Taylor’s model relies very heavily on class distinctions between Management and Workers.  Managers get paid to think.  Workers get paid to do.  Ideas come from managers studying out the problems to improve progress along their measurements.

Can you see how this could lead to some issues?  Firstly, the measurements of his era where the best they had, but are clearly wrong.  Cost accounting’s flaws translate to a great deal of poor behavior and encourage waste in a system.  If no good ideas could come from the employees then how valued do you think they will be and how will their sense of value improve their performance?  One needs only read the story of the NUMMI Plant in Smarter, Faster, Better to see what a difference employee empowerment can make.

Taylor’s definition of management was highly influential during World War II when the term Project Management first appears in the literature.  Today the heritage of Project Management is the transactional manager.  PMI has made huge strides to address the issues this causes (there’s a whole section on resources now), but its literature isn’t quite divorced from the history of the transactional management style.

Moving Forward

The history lesson and meeting observations are helpful to identify and understand the issue, but they’re not terribly prescriptive on how to move forward. Here’s some additional tips that can help improve the project’s performance and your stakeholder experience:

  • Change your vocabulary.  Use the work Project Leader instead of Project Manager.  It’s amazing how powerful a word change can be.
  • See the symptoms.  If you’re frustrated then you’re managing, not leading.  Leaders help the team through their trials.
  • Practice listening.  Get to the point where you’re comfortable being quiet and asking follow up questions that show you heard the person and you care about the challenges as they see them.  “What are the obstacles you’re facing?”
  • Help create the team.  Leaders help members of a group feel like they’re part of a team.  One of the best ways to encourage this is to provide positive reinforcement.  Starting your team building by telling someone in a meeting they let the group down is not an ideal technique.  Instead help the group see that the challenges of one person are group challenges and help that person with the challenges feel they’re not alone.
Published Uses of Project Management vs Project Leadership


While it’s not true that Project Management and Project Leadership are opposites exaggerating the differences helps to illustrate that there are differences between the two. These differences are part of the heritage of the project management discipline being heavily influenced by Frederick Taylor’s scientific management.  We’ve got some practical steps we can take now to change towards project leadership and to close the gap between the use of project management and project leadership in our actions and in our prose.

Of course, you could take another route and apply the techniques in The Art of Demotivation, or follow all the examples of Dilbert’s Pointy-Haired Boss.

Tuning Past Your Optimum.

Justin is a good friend of mine at work and a Six Sigma Black Belt.  Over lunch the other day we were talking and he explained how sometimes people will tune past their optimum.  While the conversation was casual the lesson in life seems to be worth sharing.

Firstly, let’s introduce Six Sigma’s distribution curve courtesy of Michael Galarnyk’s post at drawing

What this curve does is enable the ability to predict the outcome of a particular operation.  In manufacturing that operation might be coating a particular widget.  Not all widgets get coated equally and some will fall outside of the quality specifications.  This curve would allow you to predict how much of those widgets have to get tossed due to poor quality.  Used properly you can use it to help manage the process to reduce the number of wasted widgets.  That’s a very basic description, but for this post it will need to suffice.

On the graph you can see the percentage of good output and the Greek letter Sigma symbolizing the deviation from the optimum output.  Ideally if you can manage a process down to only 6 Sigma (three plus and three minus) then the process is considered to be stable.  Stable processes can be improved.  Unstable processes cannot consistently be improved.

An optimum output would look like the graph above, but the curve would be taller and skinnier in the middle.

The time period used to create this graph also matters.  When Justin was using it for a particular part of the manufacturing process (bagging) he was taking a daily average.  This meant both shifts were combined.  He had a wide curve and wanted to make it skinnier.  When he reworked the data for each shift he noticed that neither shift was working their optimum.

Untitled drawing (2)

Each shift would tune this particular machine to where they knew the performance was good enough.  In the process they would inadvertently tune past where the machine could work at its optimum performance.

Justin explained how the machine was complex and each shift had recorded different settings in their notebooks to know how to set it for good-enough performance.  You could image that after fiddling with the machine for hours on a difficult shift that once you finally figured out settings that worked for you, you stuck with those settings.  Think of the pressure.  All the other parts of the manufacturing are stopped because the thing you’re working on isn’t performing right.  Everyone on your team would know you (rather your machine–but sometimes it’s hard to separate people from the problem) were the one holding things up.  Once you finally got it *working* you’d probably feel relieved and just want to move on.

While we don’t all work in manufacturing we’ve probably all had those experiences where others were waiting on us and the pressure that comes from that attention.  Inevitably we do have those parts of our personality and how we perform that are based on experiences that were hard–experiences that we don’t want to live again.  What if those experiences taught/encouraged us to tune our habits close to our optimum while still missing it entirely?

Six Sigma falls in the discipline of continuous improvement and while we may get some things right or right enough to succeed I’d like to believe that all of us in some ways have tuned our habits and processes past our optimum.  As challenging as it was to get to your comfort zone, maybe it’s time to step out of it to see if good enough really is how you want to operate going forward.

Pull Request

Pull Request (1)

I’ve been around software guys for years and have heard the phrase pull request long enough that I was embarrassed I didn’t exactly know what it meant.  I had a general idea, but not one that was clear in my mind.  I also knew that this was one of those technical questions where I would grok it better if I talked to someone in person.   So, I found one of the smartest guys in the building when few people were around, drew out a kanban board (above) and asked him how a pull request was done.

I got my answer, but to my surprise when I searched for images none of them had anything to do with kanban boards.  They viewed pull requests as off-track activities that needed to get pulled back into the main branch.

That’s interesting, I thought, because that understanding means that items on the main branch wouldn’t go through the review process that is a pull request.  That doesn’t jive with the reality that I’ve heard pull requests being used on main branches and appendages of software development for some time.  I think the definition needs to be updated, and the diagrams need some competition.  So, here’s my contribution.  It’s a kanban board view of a pull request.

Illogical Behavior ≈ Illogical Measurements

Tell me how you measure me and I’ll tell you how I behave.  If you measure me illogical way. . . do not complain about illogical behavior.

This past week I got to meet someone who I’d instantly consider a friend of mine.  She works as a continuous improvement engineer for a potato manufacturing company in China.  She was communicating her observations of the behavior of the workers in the plant and how it impacted production.  As I was listening (which I’m still not as good as I’d like to be) I remembered this quote from Eliyahu Goldratt’s book, The Haystack Syndrome.

The behavior she was describing was illogical and while there’s not a direct correlation between illogical behavior and measurements, Goldratt is generally correct that there is a correlation!  I asked her what her mepotatoes fun knife forkmeasurements were and she explained that each shift is currently measured on their output.  Output is defined as the amount of product produced during their shift.

Output and throughput are two different things.  Output is the amount of product regardless of quality.  Throughput is the amount of value of the product to the business as determined by the customer.  Customers tend to care about quality, and so while a shift may have high output if that output is of a lower quality than customer specifications it will not meet throughput requirements.  It is wasted effort.

It’s easy to see how this happens, the measurements are designed to encourage a particular type of behavior, but that behavior doesn’t translate to added value.

One way to expose this is to ask yourself if the work your doing is value added or if the work you’re doing is simply to satisfy a measurement?  If you’r work is value add, great!  Keep going.  If it’s to satisfy a measurement then please, question the assumptions of the measurement.

Notice I said, question the assumptions of the measurement, not the calculations.  Generally, people get the calculations right (with some exceptions), but it’s the assumptions that are really dangerous.  The leadership at my friend’s work had made the assumption that output and throughput were the same thing and that measurements based upon output would suffice to encourage the behavior they wanted.

That assumption appears wrong.  It should be tested and if found false, corrected.

Making and operating on assumptions doesn’t make you a bad leader or a bad person.  We all do it.  There’s just not enough time in our lives to fully research every decision (See Thomas Sowell’s Knowledge and Decisions).  We have to use good-enough information when we make our choices.  Once a system is established it’s a good idea to review those choices to see which assumptions can be challenged to find greater opportunities to improvement.

Are you ready to challenge your assumptions?