More on variability among smart people

My entire lunch conversation today was spawned from this fascinating presentation about spaghetti sauce.  Watch the video and I’m sure you’ll be captivated for the 17-18 minutes that it runs.  I was and my peer was as well.  He’s working towards his Six Sigma black belt and we were talking about his project proposal.

My friend had long thought that we were over-extending the reach of Six Sigma by taking it into the software development world.  After all, software development is about letting smart people do what they do best, right?  Surely this was a bit like spaghetti sauce – everyone likes it a bit different.  As you may have guessed, this is where our opinions diverged.

I’ve said before that there is a difference between process and methodology and that with software we have something that’s much more of a methodology than a process.  I’ve also said that it’s a spectrum and can be more or less hand-wavy.  But does the thought worker deserve to work in complete freedom?  Are we to believe that cowboy coding or Agile can be the only way?

That’s a load of hooey.  First off, we (is it fair to quote one’s own blog entry?) have my original post on variability among smart people.  If consistent behavior is good for doctors, it can be good for developers.  Secondly, we’ll accept for the purposes of this another of my prior arguments that all development is some form of “analyze, design, code and test.”

So where does process and methodology meet?  The answer is: what can you control?

1. You can control documentation being created.  Documentation does not exist for the sake of documenting.  If you have this attitude towards document, don’t bother controlling their creation.  They exist to prove, in writing, that you know what the heck you are talking about during analysis and design.  It is a sound means of enabling (but not enforcing) peer review.  In fact, I don’t really care if it ever gets read again.  It served its purpose.
2. You cannot control the order a document is filled in.  Don’t bother trying.  It’s a document, not an on-line form which you move from screen to screen.  If you’re writing a process flow and you are showing boxes (and I’ve seen this in my office) which says “fill out section 4.1″ you are either crazy or a super control freak.  This is nuts.
3. You must control reviews and sign-off.  Peer review can only work if you can enforce it.  People throw process out the window when they get pressured and panicked whether real or perceived.  You can enforce peer review by utilizing a tool which prevents its circumvention – MKS Integrity Manager, Clearquest, Serena TeamTrack, etc.  This only works if getting to the code means going through the process.  If the two are disconnected and I don’t have to do the documentation to change the code, you can be sure it will be skipped.  And yes, in the Lean Waterfall Process I described on this site, we used the same process even in a complete panic.  You could get through the process in less than an hour with complete and correct documentation.  We didn’t roll software patches in less than a day, so an hour was reasonable.
4. You cannot control how people think, but you can check that they think things through.  A bit like #2, if you’re putting boxes on a flow chart (or lines on a project plan) which indicate what a person should think about next, you are nuts.  “Design web service then design UI” – you’ve got to be kidding me.  What you can do is utilize checklists in peer reviews to assure that common mistakes are not made.  Like documents, checklist use should be enforced or don’t bother.

This exposes an important point about process control.  It has to be easier to do the right thing than to do the wrong thing.  Technology makes this possible.  Short of that, you get to spend your time policing your employees.  And just like the real police who don’t prevent crime but instead react to it after it happens, the problem will have already been created in your organization.

Regardless, I am proposing that if you can’t control it, you don’t have a process.  You don’t even have much of a methodology.

To sub-optimize or not to sub-optimize

Six Sigma has long held that one should look at a process from the customer’s point of view, figure out what matters to the customer and fix the process from that perspective.  For example, if the customer tells you that one of their CTQs (critical to quality) is zero defects in production then you ought to look at your end-to-end software development process in order to figure out how to accomplish it.

You might naturally assume that in order to achieve zero defects that improvements in testing are going to be necessary.  Well, wait a minute.  Is your customer paying you to test software?  No, they’re paying you to develop software, testing is a non-value add activity in the sense that if you could just create software without defects in the first place you wouldn’t have to test it.  I’m not saying you can get away without testing, but it should be the goal to absolutely minimize it because it isn’t necessary.

Why then, should you ever have an improvement project that works on testing?  This is the question of sub-optimization.  On one hand, taking the broad view of the process does help you realize what your customers are really paying for.  On the other hand, more smart people than I can imagine have tried their hardest to get software to come out defect free and have failed to eliminate software testing.

Now, in a prior rant I specifically argued against this kind of sub-optimizing when a broader view grants you a larger improvement opportunity.  I’ve found a reason to support optimizing a small part of the organization – span of control.  Make no mistake, if you can work broadly to solve your problem you should.  On the other hand, if you can only control the space you are in, then it makes sense to improve it as much as possible.  Just because other people suck at doing their job doesn’t mean you should have to suffer as well.

There’s an opportunity here to lead by example.  Build credibility by optimizing your process as much as you can.  Collect the data that shows the inputs are the only things holding you back.  Then use that data to beat down the people providing you the junk.  There’s someone in that organization somewhere who wants to be better and won’t like getting called on the carpet for the organization they own.

On variability and smart people

I received a great article today from my boss from the New Yorker regarding the effectiveness of checklists in intensive care.  I found it to be a really interesting article for a couple reasons.

First off, I like medical stories.  Honestly, the details of the conditions gross me out and this story was certainly no different, but most medical stories are told like a top-notch mystery.  Nobody ever writes about routine medical stories.

Secondly, and more importantly, this story stresses two activities that I’ve been an enthusiastic believer in for some time – checklists and peer review.  You’ll even see on my Lean Waterfall Process page that its design hinges on these two points.  It was just today that I was in a meeting with some of my peers that I encountered the “we’re special, we’re different” attitude that causes people to shun checklists.  While we (being my boss and I) were proposing reducing some documents to checklists, our peers were saying “no, we’ve got to get people to think!” 

Think about what exactly?  Now, that’s not to say that we don’t pay most people where I work large amounts of money to do just that, but there are certain things that don’t need thinking about.  In the article, for example, the insertion of lines was a tried and true procedure and needed to follow a rigid procedure to minimize the risk of infection.  Certainly if arguably the one of the most educated, intelligent and skilled group of individuals could benefit from a simple checklist then we all could in our more mundane work environment.

More importantly, it wasn’t that the doctors aren’t well intentioned, they just forget things under stress.  Having an independent verifier of their behavior was an ideal way to assure that the right process was followed.  The results speak for themselves as do the reactions.

The last thing I love about this article is that the barrier between where things are today and drastically reduced I.C.U. deaths is one of change management.  Doctors, like all thinking individuals, are horrified that they might be reduced to a checklist.  They believe the process of delivering care to patients is an art and not a science.  Besides being fascinated by this article, I am considerably outraged that some doctors’ egos are costing people their lives especially given that the interviewee suggests the benefits could be achieved for less than $3 million.  However, this change management issue is one which we encounter in almost every space.  People don’t like change and certainly don’t like to think that their work can be evaluated by something as mechanical as a checklist.  The reality is that much of what we do is repetitive behavior in the office.  While just like every patient a doctor sees the code is constantly changing, there are common activities that can benefit from being done in the same manner over and over.

The short story is this:  even very smart people behave inconsistently.  A simple tool like a checklist in the hands of a person tasked to make sure the process was followed consistently can create enormous change.  If you still think that the place you work at is somehow different, special or more complex than an I.C.U. then you are fooling yourself.

Corporate structure and value add

In the spirit of full disclosure, I’ve tried my hand at this post a couple of times and have not been happy with the result.  Clearly it’s not “rant-y” enough, so here’s edit #3. 

 I was thinking the other day about corporate structure and the value added to the organization for each pillar that Systems provides.  So I put together two pictures of the system structure that I thought would be interesting fodder.  My thesis is that your distance from production is an indicator of your value to the organization.

Essentially, on your way to production you are going to pass through several silos of activity.  I see production as being the seperation between the users and systems.  At the far right are the users who want to utilize the functionality created.  They are separated from the systems organization by the system acting as an interface to the functionality and data that the users want.  First in line near production is the call center.  In the company I work for, this is technically a business role, but for many things people exist here because the system does not allow the user to do what they want to do on their own.

Just to the left we have production support who doesn’t interact with the users directly typically, but they keep the servers up and running.  In the next pillar we have release management activities.  These people migrate work from development to production.  QA holds the line between the development environments and those things that release management is allowed to move into production.  Development turns ideas into reality.  And finally, furthest away from production is thought leadership, the people who come up with the ideas.  Again, this role is largely a non-systems role but I wanted to include it to make my point.

The top graphic represents the current reality while the bottom graphic represents an ideal model.  Here’s my argument.  Within each pillar of the organization, there are doers (individual contributors) and there are managers of various levels.  Color in the graphic represents the value of that role to the organization (green is good, red is bad).  For example, doers in the call center are clearly not value add to the organization.  They exist because preceding pillars created a system that did not solve all the users needs.  But, you also see that management in that pillar is also not value add.  They are in some ways worse than the resources they manage because they are overhead on top of non value added workers.

Essentially, the resources on top of the pillars to the right exist only because of the necessary resources on the bottom.  As you move further to the left (away from production) both the entire pillar and especially the resources on top become more valuable to the organization.  In effect, the pillars turn upside-down with the top of the pillars being more important than the resources that support their needs.  Were there a theoretically perfect world, the ideas created by thought leadership would magically become production and the users would simply access it. 

So why does my graphic matter?  Making improvements to the organization pillars on the far right is a waste of money.  Having people towards the far right is a waste of money.  These are resources you don’t need.  Instead, if you focused your efforts around the middle pillars you could substantially reduce the need for everyone to the right.  In today’s reality, I doubt you could do much to eliminate the development pillar since we don’t have a software language where the computer will just do what you tell it to.  There is a need to translate ideas into software.  But that’s where it ends.  I’d love to see an organization which had less tech support than developers.  There’s an organization who’s doing a good job developing software.  How is it we accept that we have to carry the burden of one or more additional resources to support the work of one developer?

On being intrinsically motivated

So, I took this “quiz” from a book called Strengths Finder 2.0 which my boss recommended and kindly purchased for me.  I like the concept of the book, which is that people spend their lives patching up shortcomings rather than focusing on optimizing their strengths.  It’s a point well taken, if you suck at something and keep working at it, you’re probably only ever going to become mediocre at best.  But, that wasn’t really what I wanted to write about.  I only bring it up because after taking the quiz it spits out 5 top strengths for you.  One of my top strengths was competitiveness.

OK, first off I have to say I have issues with the book on a couple fronts.  Why does everyone get 5 strengths?  One has to assume that of the 34 or so things they call strengths that maybe I’m really, really strong in one or two and so-so in the other three they propose or maybe I’m equally strong but not exceptional in any of the 5.  There’s no perspective at all so I’m left wondering if my lowest ranked strength is really just a borderline competency or really a strength.  Secondly, I’m horrified that one of my “strengths” listed is Significance.  Essentially, this means that I have a need to be recognized as being the best.  It’s true, I’ll grant you that.  But more importantly, I consider this a weakness of my character, not a strength.  Why is it that I cannot just be happy with the fact that I’m good at what I do and why do I need the validation from everyone else?  Alas, I digress again, I wanted to talk about being competitive.

My particular observation is that being competitive does generate great outputs in the presence of competition, but what happens when there is nobody to compete against?  What if you are in an organization where the vast majority of your subordinates and peers can barely keep their head above water?  Surely, you have no need to compete on being better than these folks because there simply isn’t a challenge being presented.  This type of external motivation is great in situations where it can be leveraged to drive yourself or others to exceed.  The need to win can be powerful, but only when there’s some competition to win.  So what happens in all the other situations?

I believe that this may be where that weakness of mine (Significance) comes in.  Self-competition is more powerful in many situations than a competitive attitude.  This is certainly true of my own nature.  I am not satisfied until I have outdone myself.  I can beat everyone else and still be unhappy with my own results.  I am disappointed if I compete a project on time and on budget but the results aren’t up to my own standards.  Standards, I suspect, that I perceive exist based on needing to be recognized as being far better at whatever it is than my peers.

I know corporations create competition to motivate employees.  It is common among sales teams, for sure.  We should be focusing on individuals who exhibit this intrinsic motivation to be the best as a better way to achieve stellar results.  Not only do we not need to create competition to make folks like me work harder, but we can get results even in spaces where competition might be impossible to create at all.

Desperate employees are good employees

Is it just me or does it always seem to you that the best employees are those young, hungry “kids” who just work their tails off for a pittance.  I mean in terms of output per dollar spent, they are clearly far more valuable than their more highly paid peers.  They’re usually as good as the more experienced folks yet they cost less, sometimes significantly so.

It was just the other day that I was reading about cognitive dissonance and a particularly interesting experiment.  Cognitive dissonance proposes that if you experience two things that cause a conflict in your thinking that you’ll adjust your thinking about one of the things to bring it closer to the other.  To my point, I’ll quote wikipedia, and Leo Festinger’s experiment noted therein.  In that experiment, a group of subjects was given a boring task to work on which they “correctly” rated as boring.  Then, they were offered a small amount of money to tell someone else that the task was interesting.  Another group was offered a significant amount of money to tell someone else that the task was interesting.  The group that was paid a pittance, when asked to rate the task again, rated it more highly than they did originally.  And, in fact, the group that got the larger amount of money did not change their opinion of the task.  From this experiment, he concluded, the poorly paid group having no motivation (like a large amount of money) to lie about the entertainment value of the task rated the task more interesting after they had to tell someone else it was interesting.  Clearly the task wasn’t interesting, which created cognitive dissonance.  They resolved it, he proposed, by changing their own belief about how interesting the task was.

Anyway, so that made me wonder about the young high-performers.  Could it be that the work which is generally dull and oft repetitive is made interesting because a) we often lie to these folks and tell them they’ve got a “great job” and b) since they’re not actually making good money and know that the job is actually boring the cognitive dissonance causes them to think that the job is better than it is and thus they work harder at it?  Am I over-extending the value of Festinger’s study?  Perhaps, but it seems to me that it’s the highly paid workers who always complain about how their job sucks and that they don’t make enough money to put up with this crap.  I think once you pay people enough it allows them to see the job for what it really is.

Could it be we could improve employee performance simply by paying people less rather than more?  Anecdotally, I suspect the answer is yes.  I used to work for a company that paid (relatively speaking) quite poorly.  There, more than anywhere I had been before, that company had instilled a crazy loyalty among their employees despite it being one of the more dysfunctional places that I’ve worked.  With a complete lack of valid reasons to really like the job, did cognitive dissonance kick in to make it a great place to be?  Dysfunctional companies – the new way to be more functional.

Project plans are for the birds

Just because you love your project plan doesn’t mean I have to like it.  I can’t say that I encountered anything worse than going from being a manager (and yes, this was a deliberate choice of mine) back to being an individual contributor some days.  Today was one of those days when I realized a core truth about employees.  Namely, just because you as a manager love your project plan doesn’t mean that your employees care in the slightest what’s on it.

There’s nothing worse than having to sit down with a manager and review his/her project plan.  Why?  Well, as an individual contributor I just don’t care.  Some managers write project plans at a very high level (this was definitely me).  I put on a plan things like Analysis, Design, Code and Test and who was assigned to it.  If the project had multiple deliverables I might repeat those rows on the plan for each project.  If I was feeling sophisticated I might add milestone tasks for the review dates of the various documents, but generally not.  That level of detail worked for me, mainly because I believed it is the employee’s job to get from an assigned task to the completion of that assigned task and I don’t need to lay out for them how to do it.

Later on, especially where I am now, I found that as a manager that my superiors would want to review the project plan with me and always complained about my lack of detail.  They’d point me towards the template project plan they had for the team, which was some one thousand lines long and didn’t even represent a project yet.  It was full of reminders to do this or that thing.  In my opinion it was the worst project plan ever.  It didn’t work for me.  If I have a task to do, I put it in my outlook task list because that’s where I remember to do things.  My project plans are about deliverables, not the steps to get to a deliverable.  Because frankly, it doesn’t matter that you’ve held 226 status meetings that I can check off on my project plan if the analysis document isn’t done, then it isn’t done.  By the way, I also never use the percent complete column on a project plan unless it is to indicate 0% or 100%.  Either something is done or it isn’t.

So I guess my philosophy is generally this:  an item only belongs on the project plan if it represents a discrete deliverable that you could take and hand off to someone else to work from.  If you can’t, you’re probably delving too deeply into how someone does his or her job rather than giving them the appropriate level of freedom to make decisions.  Again, this goes to process vs. methodology.  Software development is a methodology so you have to accept that some level of variability in behavior is going to occur at some level. (Now I’m going to have to go back and look to see if that conflicts with any of my prior posts.  I don’t think it does…)  Below that level of detail, if as a manager you are listing the tiny little tasks you want to have done then you are imposing your view of the world on your supposedly intelligent individual who you pay a lot of money to with the assumption that s/he is capable of getting that larger task done by himself/herself.

Don’t do it.  I really don’t care about what your project plan looks like, just give me something to get done and let me take care of it.  If I flop at it, and you expected that I should have been able to handle it, bring it up on my review rather than hand-holding me through it so nobody ever fails.  Nobody ever learns, either.