Coach yourself out of the job

 

I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 

 

When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.

 

When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.

 

I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.

 

Agile maturity of organizations

I recently had a thought that I'd like to share with others regarding agile thinking.  

 

I believe that agile maturity can be thought of in three levels:

1) Level 1 is where agile is thought of as a way to allow change through adaption and inspection.

2) Level 2 sees agile as proactive in it's ability to change:  it not only allows change, but proactively positions the organization to expect and anticipate changes, in part by actively deferring constraining commitments.

3) The most mature agile organizations must seek out change, not just passively await it.  The example is organizations that foster change through techniques such as hack-a-thons or innovation days.

 

I've come to see these levels by watching multiple companies introduce Scrum and the supporting agile mindset without seeing product innovation.  They simply wander to the same general destination as they always have, minimizing risk and reducing waste, the only innovation being in the minor details. That’s a pity, but often the best you can hope for until the organization matures.

 

These levels are not meant to relate to Shu-Ha-Ri nor the Dreyfus model of skill acquisition.  It’s just way of progressing a company to higher levels of empirical processes based on their attitudes of change.  It works for me.

 

Have you experienced the same?