Can influencing create action?

I was having a chat over lunch with my coworker about a situation at work that had parallels to his role as the chair of a town committee.  My friend (who incidentally is the inspiration for a lot of my comments based on our lunchtime conversations) was trying to get volunteer members of the committee he’s on to do more than just show up – to actually do something and take action.

Very much like his situation, there are some people I work with who I’d like to take some action.  And yet, because these people don’t work for us, in our respective situations, we seem to be unable to influence them to action.

Suddenly, as we were talking, I realized there was something different about these situations from other situations of influencing that I’ve ever written about.  In most of the situations I encounter, influencing has been about directing a course of action.  The person I was influencing was already on some path, spurred to activity by who-knows-what.  The path they were on either conflicted with my goals or while well intentioned wasn’t going to meet my goals.  I could effectively use influencing skills to steer someone.

But bringing someone to act isn’t the same as steering someone.  Why is it that not just me, but many of my peers, that seem to have trouble overcoming inertia?  We refer to it as the corporate “nod”, where someone says yes to you verbally, but no action actually ever comes of it.  Could it be that influencing cannot create action?

I’d liken it to trying to move a stubborn donkey.  Not that I’ve ever actually tried to move a donkey anywhere, so forgive the metaphor.  To get the donkey moving, you give it a little bit of the stick.  Once moving, steering is an easier activity, you can just pull the reins to turn his head and the body will follow.

I see two possibilities:

Option 1, there are levels of influencing skill.  No skill (a complete inability to make anyone do what you want), skill in steering (where I’m at) and skill in using influence to spur action.  If this is the case, then there’s a technique that I need to pick up to create action.  I’ve seen people try to create action by name dropping or thinly veiled threats to escalate the situation.  I don’t get the sense that these techniques are effective – we make fun of people who name drop after they leave the room.

Option 2, influencing is incapable of creating action; it can only steer.  If this is the case, then both my friend and I are out of luck.  Or are we?  If we can still steer a person, even if we can’t start them off down the path we want, what if we sense they are eager to start down a path, any path at all, that is similar to the path we want?  If they will move to act on their own, even on the “wrong” thing, help them do that and then maybe you can use steering to get them where you want them to go.

I’m grasping at straws here.  There is an answer to the conundrum, but I don’t know what it is yet.  Have any ideas?

Information control

Oh the tangled webs we weave, when first we practice to deceive…

It is true in management of projects as well.  Like manipulating the numbers rather than improving the system, we as managers always have a choice when it comes to the information we know.

Choice one, hide bad information from our partners, fool ourselves into believing we have the situation under control and hope it works out in the end.  If it does, the illusion holds up and we appear to be perfect managers who run miraculous teams.  If it doesn’t pan out, our “green” project goes “red” in an instant and we’re left with angry and confused customers.

Choice two, tell your partners that something is going wrong (or not quite right), set an expectation that we will endeavor to resolve it, call the project at risk and do our best to resolve it.  If it works out, you are rewarded for resolving the issue (provided that you didn’t create it, or sometimes even if you did) and if it doesn’t, while your customer will be unhappy at least they’ll be less surprised.

Why would anyone in their right mind go with choice one?  Well, if my conversation the other day is any indicator – because people want to avoid conflict.  “It’s not really a problem, I can handle this” is preferable in some people’s minds to “there is a problem, and I have a plan to handle it.”  Yes, it means you will get questions, tough questions, that you perhaps would have rather avoided.  Yes, it means at the end of the project people will ask you how you could avoid the same problem in the future.

But putting on a happy face and pretending nothing is wrong?!?!  STOP, STOP, STOP, please STOP!  If you can’t control the situation, it is not better to control the information.  Just look at our government, and a president with miserably low ratings.  Why?  Because the situation is NOT under control and no matter how many times anyone in the government puts on a happy face and says “the fundamentals are strong” we are not fooled.

But economics are complicated, you could argue that we “average” Americans just don’t understand.  And yet, we feel uneasy.  We know something is amiss even if we can’t put our finger on it.  But this won’t hold up at work – we DO understand!  We can put our finger on a budget that’s creeping out of control and the first missed deliverable, or the complete failure of every single test case on the first day of testing.

So keep up your information control and wait until it unravels on you.  Or, stop controlling the information and focus your efforts on where they really belong, managing the process so that the next time you do something there’s no reason to control the information.  You’ll have good information to tell, and you can just let it flow.

A single point of failure

This is a thought provoking entry from Curious Cat Management on the single point of failure.  How many days do we allow an individual to hold the company, or some part of it, hostage to his/her exclusive knowledge?  How often do you allow the performance of your team to be dictated by the individuals?

And what do you do when those same indivduals have an off day, or an off week, or a personal problem, or even the sniffles…

How wonderful is it when your key employee comes through for you in fighting the hundred new fires that came up today?  Did you ever stop to think that the hundred fires might have been set ablaze by the same individual?

True, there’s nothing exciting about adherence to a process.  There’s nothing exciting or remarkable about any individual when a well designed process eliminates the art from regular high performance.  What is left to differentiate someone if they are not the lynch pin in your system – your single point of failure.

Instead of rewarding the individual for a stellar performance, how about you reward the individual for bringing up the entire team’s performance.  It reminds me of the activities of World War II, when the leaders looked to the individuals in the trenches for ingenious solutions to the things that stood in their way.  While individually recognized for their contributions to the war effort, the benefit was not in the individual working harder or faster, but in making it possible for everyone around him or her to be more productive.

Don’t reward people for standing out above their peers, reward them for not standing out above their peers because they’ve brought their peers up to their level.

How to gut process improvements

I sat through a very long, very boring meeting the other day on a set of process improvements.  In the room were about a dozen practitioners of software development.  All of them are experienced developers and in that capacity probably capable people.  That does not make them good process people.

For one, there are about a million ways to do software development in a capable manner.  It’s great that there are so many options for people, but it is unreasonable to think that a group of people with such disparate opinions are going to come together and decide on a standard for the entire company.

The problem comes from the fact that there are so many good opportunities to do software development capably. All of the methods are acceptable, and all of them produce about the same results.  If no methodology stands out above the rest, then why change?  It’s a fair question to ask every person in that room.

That wasn’t the point of my post, however.  The point was to show how all of those good methodologies can be combined into a poor compromise.  While each practitioner had assembled a hodge-podge of mechanisms which resulted in software that was on par with his/her peers, they didn’t understand why they got the results they did.  I say hodge-podge because I don’t want to suggest that their decisions were deliberate.  For the most part, whether they followed Agile or strict waterfall or spiral or whatever, they probably learned it from someone who understood far better why they were using that process.  The particular folks in the room were just mimicking the people they learned from.

Oh, how the speculations flew about the room as to why one methodology was working well.  “Let’s take this feature” or “how about that feature” and suddenly we have a proposed list of process features to become a new standard that is probably collectively worse than the individuals.

And what about the rest of the features that each methodology had?  We were making “progress” when the team agreed to defer dozens of aspects of each…

Yes, the team had been tasked with assembling a list of features to become the new standard.  But when did it become acceptable to defer large sections of the process design?  The absence of any robust debate gave away the lack of understanding on how any of the processes truly worked.

Sure, we got through the meeting, but at what cost to the company?  I wouldn’t want to adopt the end result.  As far as I can tell, it is inferior to all the alternatives we started with.

If you want to gut process improvement work, allow a team of well intentioned individuals to assemble the process themselves.  If making processes were easy, companies wouldn’t achieve a competitive advantage from doing things well.  And doing things well is all about the process, isn’t it?

A process without decisions

Maybe this is a rule of good process design that I’d never heard of, because it seemed suddenly obvious to me when I thought about it today, but I’m going to write about it anyway.

I’m going to propose that a key feature of a good process is one that has no decision points in the process flow.  That’s right, no decision points.  A decision equals an opportunity to make the wrong decision and therefore the opportunity to waste time or jeopardize quality.

If a process is to be consistently good, then the last thing you want to do is give an individual (especially software developers) the opportunity to make the wrong decision.

I’ll give you an example – the creation of an analysis document.  Let’s say you have a process which allows the developer to choose either the long (and therefore rigorous) format or the short format for the document.  The decision you want the developer to make is “select the format appropriate for the scale of the change.”  Which one would you choose as a developer?  If you were well intentioned, you might really consider the question.  Still, it’s the kind of question you could screw up.  The decision is based on judgement and maybe your developer judges it incorrectly.  The developer chooses the long form when the short form would have been acceptable and wastes all kinds of time filling out an unecessarily complex document.  Or, the developer chooses the short form and thus misses the necessary rigor and inserts a major design defect into production.  Either way, the decision allows for the wrong choice to be made some of the time.

What about a not so well intentioned developer?  A lazy developer, perhaps.  Not that those kind of people exist at your company.  Oh no, all your employees are well intentioned all the time…

A lazy developer would always opt for the short form.  Maybe s/he doesn’t value analysis or maybe s/he does but thinks writing things down is silly.  Who knows, who cares.  The short form isn’t always appropriate.

Here’s what I’m proposing.  No short form, no long form, and certainly no choice about whether or not to fill out the form at all.  NO DECISION!  Just have one form that scales to meet the need automatically.  I know what you’re thinking.  How can that work, we have 246 sections to our standard design document and a developer needs to make a decision about whether each section is appropriate or not.  WRONG!  Why do you need 246 sections to your document?  Do you think each of those sections is critical to success?  Have you bothered to figure out which sections, if done well or not well actually affect performance?  Probably not.  You probably like lengthy forms with nice headers and sections and instructions in each section about how each section should be filled out.  You’ve ignored the idea of the critical few – and there are a critical few – that really affect process performance.  Everything else is noise.

It is possible, I have done it, to have a single document format, nay a single process, which you follow unwaveringly through new development, enhancements and even simple bug fixes.  The fewer decisions in the process, the better.

With that in mind, I propose this measurement of the goodness of your process.  To figure this out, you have to get down to the micro level.  If associates are making decisions about which sections of a document to fill in, that’s a decision you should count.

Decision density = 1 – (# of decisions in a process / # of steps in a process).

For example: 

• analysis
• analysis review
• decision: analysis OK?
• design
• design review
• decision: design OK?
• code
• code review
• decision: code OK?
• test
• decision: test OK?

That would have a decision density of 4 decisions / 7 steps = 42.85%.  I’d say that decision density of less than 50% is a good start.  The lower the better.  There’s probably a better way to look at it, since you might want to weight micro decisions (those decisions made without consultation with a peer or group) as being worse than bigger decisions in the process (like the decisions made after an inspection step). 

The short story is: avoid decisions in the process.  More decisions means more of a hand-wavy methodology than process.

People as a factor of process capability

I got into an interesting conversation with one of my friends the other evening over dinner.  He had been reading my blog and, not being a process type himself, questioned how I could enjoy it so much.  Fair enough… I know this is a niche blog topic.  I’m OK with that.

More importantly, the conversation turned to his years as a manger.  He is, in fact, the kind of person whose opinion I greatly respect and I’m certain a very strong manager.  His argument against all the process work, when it came to software development, was that knowledge workers are not mindless automata turning out widgets.

In my opinion, that’s true.  Software development is much more like a custom job shop than an assembly line.  We do expect that our employees are intelligent and skilled at the job they do.  A standard management philosophy has been to select the right people, put them in the right jobs and then get obstacles out of their way.

So, where in all this is a place for process?  If this philosophy were the only one needed, I could see two kinds of fallout.  For one, there aren’t enough “right people” to go around.  So, unless “right” equals “average” then at best some companies will be winners and some will be losers.  More likely, all of them will have their fair share of not-quite-right employees.  As good of a philosophy as it is, we struggle to select the right people, leaving a great deal (in most companies) up to the opinions of folks in the company over whether a given candidate is right or not.

The second issue is, even the right people are variable.  Everyone has an off day and draws an incorrect conclusion from the data now and again.  My friend is right, and people are not mindless automata who turn out the same result over and over.  We all vary.

So, where does this leave us with process?  Well, I’d argue that people’s intrinsic ability to perform varies.  There are people out there who even on their very best days will not produce a result as good as other people on their very worst days.  And the company you are in probably has a range of these people.  At least one study I have read about found that the productivity of the best developer was 2 1/2 times greater than that of the least productive.  It seems fair to think that quality probably varies a great deal between the best and worst developers as well.

What can we hope to accomplish under these circumstances?  Each individual producing software at some level of capability contributes to the overall distribution of quality that we see.  While very good people will produce generally good results, average people produce, well, average results and the below average live up to their name as well.

I did a funny little data experiment.  I created 10 imaginary individuals who each had a different mean performance (normally distributed).  Then, I generated 20 random performances off each of their mean performance, also normally distributed with a standard deviation of 1.

Here’s what the population looks like when you add up all their performances:

Interestingly enough, the composite of a bunch of normal distributions is also a normal distribution.  I have no idea if that’s the result of my data choices or if there’s some theory that proves that will always happen, but notice that the mean performance is 1.73 and the standard deviation is 0.97.

If we then believe that using a process can control variation for all parties involved, what happens?  Well, the low performers become less variable, so the downside damage gets limited.  On the flip side, the variability of our top performers is also squeezed, so some of their exceptional performances are pulled in.  Yes, the process could potentially constrain the fluke really high end performances.  Not necessarily a desired effect of reducing variation…

So, what happened?  Well, the data is still normally distributed, but the mean stayed about the same 1.7544 vs. 1.7130.  What’s better though, is that the standard deviation dropped to .5514.  So sure, we trimmed some high end performance but we also eliminated low end performance.

If our customer has set a spec limit for us, having a smaller standard deviation is a good thing.  Yes, we may not produce some of those magical performances from one individual, but we will also avoid the horrific performances from others.  If the result of this is that a significantly greater percentage of all associate performances end up within spec, I’d say it is a worthwhile trade off.

What can we conclude from this?  The intrinsic ability of an individual may control the centering of their capability, but since you may be challenged to get all above-average workers, the overall process capability is dragged down by the poorer performers.  Enforcing a process that reduces variability may constrain top performers, but it’s still a good thing overall.