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/

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.

Scaling Scrum – Team Ownership

I’ve been practicing the Product Owner role at a large fortune 100 company, on a program that has massive potential.  One effect at a large fortune 100 company at least, is that bodies get thrown at it.  In the course of not even a year, we’ve gone from 3 Scrum teams to 11 Scrum teams, 5 Scrum teams not in the same building, plus a customer support team, a massive dev-ops team and an operations center.  Wheh.  Plenty to discuss here in future blog posts.  Let me know if scaling scrum issues are of interest to you.

Today I’ll keep it focused at the team level.  Take this situation: Team A works on a specific feature for a few sprints.  Something new pops to the top f the backlog which Team A is uniquely qualified for, and they suggest going for it next sprint.  They talk with Team B and product ownership and everyone agrees that Team B will pick up the remaining work on Team A’s feature and make a few enhancements and add a few new features. I would suspect this is a common occurrence in large programs.  Probably sometimes in command-and-control ways (listen up people, we’re going to re-org these teams to work on different things….)  But even in a good self organizing system, this can create issues.

What responsibilities does Team A have to Team B while Team B is working on the codebase Team A originally created?

The perfect world answer is that Team A is responsible for knowledge-share, a few Q&A sessions, and nothing more.  Team A has left their codebase in good shape, with low technical debt, and plenty of artifacts that explain what’s going on and how to get work to done in this particular codebase.  They’ve showed their working software every few weeks and been transparent about what’s done and what’s not.  Team B has all the necessary skills needed to turn backlog items related to this feature into done software.  Team B does all the design, coding, testing, etc, etc, etc needed to produce done increments.  They rely on Team A only for the occasional question and explanation.  In the perfect world, both Team A and Team B can make progress simultaneously.

In the real world, this probably isn’t the case.  There is likely going to be significant drag on both teams for quite a long time.  Mangers like to call this a “transition period.”  Developers and teams like to call this “hell.”  The teams will fight over the state of the codebase “you’re handing this crap over to me?!!?!” and quarrel over getting help “can’t you just spend a few days [doing our work for us]?!?”

Scrum will make this very, very apparent (this is a good thing!)  It will not fix this for you.  (what’d you expect?)

As a manager, you want the team to own their work, even if they didn’t create it from the get-go.  A team that is whole-owner of their work is a team that learns.  They are a team that is solely responsible for quality.  They are a team that has all the power to create great products.  You want this.  Don’t get sucked into the short-term tactic of having “all teams help each other” and having alot of cross-team dependencies and other teams to parts of features or parts of development, etc.  It’s a short term tactic that optimizes the struggling team at the expense of all teams.

It’s not an easy choice.  It takes courage and vision to wait while a team struggles for a bit to find its way.  But it will.  It will learn and organize and grow and come out the other side all the better for it.