Active Management vs. Self-Organization

I often have arguments in my head about where to draw the line between taking action and allowing self-organization.  As a manager, when is it OK to intervene or over-rule or otherwise take an active role in the team?

I think there are some no brainers we can get out of the way quickly such as situations involving obvious legal or ethical issues.  Yes, you should intervene.  Period.

For day-to-day issues, I tend to philosophically tend toward self organization.  Let the team figure it out themselves.  This helps everything from learning to morale to competency.

In practice however, my first instinct is to act.  Yup, I admit it.  It’s actually very, very difficult to take a hands-off approach.  I’m sure it has something to do with our culture, the big companies I worked for in the past, and just my type A personality.  There has been so many years of people working in environments where pit bull performance is praised, the loudest voice is singularly heard, and promotions are given on the basis of being the perceived as the smartest person with the best ideas.  So many managers of this old regime have this system built up around them and have perpetuated its construction that many companies now exist with the expectation the manager is the smartest person in the room and responsible for making most decisions.  To make matters worse, we’ve come to call much of this behavior “leadership.”  There are not enough quotations around that word to show my sense of disdain…

OK, so how did I snap out of that mindset?  And how do you get other managers to do the same?

For me, it clicked while reading about the Conant-Ashby Theorem.  Read more here: http://www.management30.com/ashby/

The basic idea is that if you accept that you are doing complex creative work within a complex system, then the best way to actually control that system is to distribute decision making to the lowest responsible/competent level possible.  Hear that?  Self-Organization and delegation of decision making authority is about control.  It isn’t about just letting people be or giving up power or becoming a laissez-faire manager.  As a manager, fostering self organization and leaving most decisions to the team is your only hope of controlling the complex system in which you exist.  This, my manager friends, is what switched the lightbulb on.

Constantly remind yourself each time you prepare to snap into action that usurping that decision, taking control in the moment, telling the team what to do, etc, is actually stripping the control of the system away from you – the exact consequence you thought you were avoiding.  You are limiting the health of the entire system to only your train of thought and decision.  Delegating decision making authority to a self-organizing team allows you to expand and grow the health of the system.

Don’t believe or don’t think this works in the real world?  Fine.  Try an experiment.  Take a common situation that presents itself often and has typically required your intervention or your decision as a manager.  Tell the team that from now on, they are solely responsible for these decisions.  Tell them they have all the skills and knowledge needed to make these decisions, and although you’d like to be informed on an ex-post-facto basis, you will not be involved in the decision making process in any way.  Try this for a while.  I’ll bet you won’t even miss that responsibility.  And I’ll bet you’re teams will surprise you with the outcome.

Advertisements

The Software Weatherman, Part 2.

Many people would answer my questions in the software weatherman, part 1 with a “yes, go for it” and many people would say “nope, not worth the risk.”  I’m not sure there is a right answer on the surface.  Perhaps it will be OK to risk it and perhaps not.  But if you are at all concerned with wasting the extremely expensive paint by taking this risk, you probably don’t go for it.

Software is developed in a similarly risk environment.  Software is painted in the outdoors, if you will.  You have to be concerned with such inherently unpredictable things as the weather.

This is good news.

If you work with your business to understand how software is created and how features grow into a product, you will create a shared understanding of the complex, creative, and at times unpredictable process of creating software.

The more they understand this, the more they understand the environment in which you create software, the more honest you can be about forecasting the work.  The business / your Product Owner / your customer already knows that they have bought some extremely expensive paint, and you can bet they do not want to waste it, or risk having something not be done and done right.

With this context in place, you’ll find it orders of magnitude easier to have those tough schedule/budget/scope conversations with stakeholders.  Your job is software weatherman, forecasting the project in an environment of uncertainty, more sure about the next day’s weather than the next month’s,  and treating your estimates as nothing more than a forecast.

Now, this doesn’t mean you are off the hook.  Even a rookie weatherman can predict the weather with some certainty.  They know it’s cold in winter and hot in summer.  You as a software weatherman have the responsibility to forecast in at least the same way.  It’s not acceptable to your stakeholders to hear things like “there’s no way to know” or “we all used the infinity card in planning poker” or “it’s so complex and there are too many unknowns.”  Even a rookie software developer can tell if something is a week or year worth of work.  Step up, and in the context of giving forecasts, give one!  You will modify it later as you learn more, do a little work, and re-evaluate.

If you’re business understands the environment in which you create software, they will behave more wisely.  You will see commitments and must-haves and multiple #1 priorities shift into ordered backlogs and agile roadmapping.  Give it a try.  Go explain to your business partners how you create software.

Hang around with people who get sh*t done.

I freely admit that in a past job I was a loser.  You know the guy in the office who gets stuff done?  Yeah, I was the other guy.  And it wasn’t that I didn’t produce anything, I did.  It wasn’t that I didn’t fulfill my job description, I did.  But that’s all I did.  For some reason it seemed OK to me to just be average.

That’s a fair picture.  But so is this:

I was a smart kid fresh out of college, surrounded by people with 20 years of experience but no more skills/knowledge/abilities than I.  My average was at least equal to the group’s performance, maybe a bit better due to nothing to my character’s credit but to my more recent education.  I was promoted and given raises and begged to stay when I finally quit.

That’s a fair picture too.  Both pictures were simutaneously true.

Why?  How can this be?

I stumbled across this post that I think describes what was happening fairly well:

“hanging around people who are doing amazing things makes me try harder to do amazing things”

The people I was surrounded with, in retrospect, weren’t exactly doing cool stuff.  The team wasn’t thought of as an innovative team.  The work we were doing was thought of as a necessary evil in the organization (you’re not people, you’re a cost center!).  Compared with other jobs I’ve had, it’s easy to see this truth in retrospect.  When surrounded with A players, I tend to perform better.   So that brings up two questions for me:

Q1) Why is this true?  Why do we tend to perform better when surrounded with top talent people?
Q2) Can we identify this in-the-moment or only in retrospect?  How can we evaluate our current situation and work towards bettering ourselves?

A1:  Peer Pressure?  Probably.  Intrinsic Motivation?  Probably.  Suggestive Energy?  Probably.  Behavioral Psychology?  Probably.  Regardless the means of this drive to perform better when surround with better performers, it all goes back to classic systems thinking.  That is, a person’s performance is more a product of the system in which they exist; and less a function of individual aptitude.  Sure you have to have all the requisite skills and abilities to do the job, but creating really great performers (or really poor ones) is a function of the system.  From Ackoff:

“An important aspect of a part’s performance is how it interacts with other parts to affect the performance of the whole.”

There are even been studies that show the simply thinking about smart people may make you smarter.  While that claim is  dubious at best, it’s interesting and lends itself towards the same conclusion: surround yourself with people who are smarter than you are, better performers, and doing cool things, and you will likely perform better – because the system you are part of is a better system.

A2: If we work on becoming more aware, surely we can see these truths in-the-moment.  You might need some reference, something to compare your current situation to, but maybe not.  I think a large part of this can be self-known and is as much a gut-feel-in-the-moment thing as it is a comparing-in-retrospect thing.  If you sit down and think about it – really feel – you can answer the question for yourself.  Am I doing my best work here?  Is the system I’m in helping or hurting me long term?  Is it time for a change?  Surely beware of “grass is always greener” or other pessimistic frames of reference.  But for the most part I think these answers are self evident.

Say-Do

While talking about agile metrics a while ago I was asked if I’ve ever used the “Say-Do” metric.  I had not actually heard of it.  So let’s dive in.

The Say-Do metric was explained to me as “basically that you “do” what you “say” you will do.”  Sounds like common sense so far.  Looking around the interwebs a bit revealed some more detail.  The Say-Do metric is commonly defined as a percentage of comittments met over number of committments made.  Ah, there’s the rub:

In software, the word commitment is a thinly veiled synonym for scheduled-date.  Hmmmm….I think I’ve seen this movie before (it’s called traditional project management) and I know how it ends (badly).

Two things will happen if you try using Say-Do metrics and management styles.

A) Individuals will set smaller and smaller goals, so they can achieve them more often than not.

B) The value of your product/company will not change.

Why?  Because software is a complex creative endeavor.  Say-Do works for simple and even complicated things.  I would use it for children doing chores or for landscapers building me an outdoor cream-city brick wood fired pizza oven.  It might work here.  It might increase productivity and give me something to measure performance against.  But I wouldn’t use it for complex creative tasks.  I wouldn’t ask a composer to tell me when he’ll have that opera finished and measure him against that.  I wouldn’t ask a nuclear physicist to guarantee zero defects in his first design of a cold fusion reactor.  Those requests are just silly.

The software world has been badly hurt by the “engineering” and “manufacturing” analogies.   Writing software is nothing like engineering a bridge or producing widgets on an assembly line.  Nothing alike.  OK, maybe there are similarities and parellels to be drawn upon, but at least I can say with some degree of confidence that they are not the same.

In software, it is *impossible* to accurately predict the end date when we’re talking more than a few days out.  Hours even.  There’s simply too much complexity.  Everything we’re doing in software we’re doing for the first time – we are creating – and all of our techniques for estimating engineering projects rely on recipes and past knowledge.  Sure there are typical design patterns and best practices that we use in software.  But we’re applying it in a completely different context under different circumstances and wanting different results.  Complexity matters.  There’s 30 years of grossly missed software project dates to prove this.

So when we ask for Say-Do metrics, we’ll get A and B.  “A” is due to a paradox of measuring people, the fact that the measurement is visible and people want to “achieve” it, and possible Hawthorne effect at play.  “B” is due the fact that measuring dates, even when it’s the date provided by the people who are doing the work, is a fallacy of traditional project management altogether.  Your software project will not improve because you are using Say-Do.  You will not go faster.  You will not deliver more features.  You will not increase time to market.  You have really changed nothing about the software or project itself, or reduce its complexity.

We have a professional responsibility to be aware of the complex world in which we create software products.  It’s simply niave for management to ask for dates and for developers to give them.  Perhaps even unprofessional.  Maybe even unethical.