Freedom!!! (and feeding the system)

About a month ago, my engagement at a client ended.  This is a good thing.  Being a consultant before and working for some very traditional companies, this lead me to believe that the next thing on my desk would be another client engagement.

I mean, if I’m billing, I’m costing, right?

Well, it turns out this is a very narrow view of value.  Having freedom in your job and autonomy over your work can produce value also.

The upside:

Feeding the System.  If we take a wider look at value, a more holistic systems view of what value is, we can see that a healthy and productive system is valuable in and of itself.  We can even start to trace the health of the system to direct profits (maybe, we’ll leave this for another time).  In any case, if we want a healthy system, we have to work at that, we have to feed the system.  How?  In my context it’s run the gambit from discussing our companies benefit packages, to looking at speakers for an upcoming conference, to helping out a few colleagues with their work, to simply taking some time to talk with and listen to colleagues having work issues.

Another upside is that creativity is trending upwards.  Outside the walls of the 8-5 gig, I have so many reflections, new ideas, and energy to pursue them.  I’ve done some writing and researching that needed doing.  I’ve had the opportunity to learn from my colleagues and attend some workshops.

The downside:

This.  Is.  Hard.  It is mentally challenging to control your own destiny.  Exciting, sure, but also exhausting at times.  Creativity ebbs and flows, and there are more “good days” and “bad days” further out on the good/bad spectrum compared to clocking it in from 8-5.  And there is no denying that, largely due to my past work history, there is that voice in the back of my mind saying “this isn’t sustainable, watch for pink-slips.”  Freedom can be paralyzing.  Autonomy requires practice.

Final thoughts:

I’m not going to try to equate this type of value to profit.  I know I’m providing value, and I know I’m not providing profit.  Surely this isn’t a permanent configuration, and I’ll be back teaching and coaching soon.  But a “balanced approach” (thank goodness I’m not a politician, I may be actually able to do this) to work that splits time between direct-profit-producing-activities and feeding-the-system-value-producing-activities is, in my opinion, exactly what is necessary for a high performance organization.

Advertisements

The Role of Empowerment in Self-Organization

Intelligent control appears as uncontrol or freedom. And for that reason it is genuinely intelligent control. Unintelligent control appears as external domination. And for that reason it is really unintelligent control. Intelligent control exerts influence without appearing to do so. Unintelligent control tries to influence by making a show of force.
~Laozi, 600 BC

The industrial revolution brought about some great ideas on how to make people and machines incredibly efficient.  When we’re doing task work, repetitive work, or any type of work that is algorithmic (can be done by following a set of rules, even extremely complicated ones), then traditional management reigns.  When we’re doing knowledge work, creative work, or any type of work that is heuristic (cannot be done via algorithm, requires trial&error to produce learning and doing), then traditional management starts to break down.

Most of us do heuristic work.  Most of our managers use algorithmic management techniques.  This is incongruous.

The manager’s role in a complex, creative, heuristic environment is to foster self-organization.  One way to jump-start this is through serious empowerment.  From the start the word “empowerment” is bothersome, implying that by default we aren’t empowered.  I think the key to empowering your people is to realize that you have to do almost nothing.  They are empowered.  More than you know.  All you really have to do is get out of their way.  Let them make 98% of the decisions.*

*A well researched statistic I made up for the purposes of this blog post.

By letting go and getting out of their way, the heuristic work being done will flourish.  More ideas will be generated, more creative solutions will be sought after, more results will flow in.  Your bottom line will improve.  As a manager all you need to do is present the vision for your team.  What problem are you trying to solve, and how do you see it affecting your customers?  Let everyone around you take care of the rest.

Isn’t it funny that we had this figured out in 600BC?  Becoming agile is as much about unlearning the ways of the industrial revolution as it is about learning the ways of agile management.

The quote above and most of the ideas in this post can be credited to Chapter 6 of Management 3.0, by Jurgen Appelo.  http://www.management30.com/

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.