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.

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:

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.

Take No Dependencies!

As a product owner and coach, one common question I often get is “how do you deal with cross team dependencies, like when Team A has to complete some work before Team B can begin theirs?”

If the room is silent after that question is asked, before too long somebody will likely suggest a “dependency matrix” or “tracker” or “gantt chart in MS Project” or the like.  Do not let the room be silent for too long.

There are many possible solutions to this problem, all of them more effective that inserting an antiquated project management tool like any of the above.

1) Team A and Team B work together to complete the work starting with the prerequisite work (originally ‘assigned’ to Team A) and then moving on the post-requisite work (originally ‘assigned’ to team B)

2) Team B goes and works on something else, and Team A communicates to Team B when the dependency has been met.  No need to “track” anything – Team A is full of smart people who will communicate their status to Team B.

3) Team B waits patiently  for Team A to finish.   They paint the office.   Stock the beer fridge.  Help on sales calls, research a new technology, put together a presentation, read a book, go to a conference, etc.   And all the managers GASP at the underutilized capacity, but you as a smart agile manager know that you may indeed be optimizing the system by not trying to optimize individual teams.

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.

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.