Adaptive Process

My dad’s family had a chain of men’s clothing stores. It wasn’t the highest margin business, but it provided a very comfortable living for several families – and ensured my brother and I were probably the best dressed boys in our high school class.

(Having worked in the stores during Christmas, I learned I I never wanted to work directly with consumers. But I digress). 

My family sold a lot of men’s suits. Because off-the-rack men’s suits need to be adjusted, at the company’s height, my dad employed over a dozen tailors, tucking in, letting out, shortening, and lengthening.

What does this possibly have to do with software development?

Read more…

Last week, I was working on a project for a client and thinking about how we needed to get the technical team to endorse “best practices.” 

Meaning, that any technology you use, there are folks out there who’ve been there, done that, thought about it, written about, and spoken about it at conferences. It makes a lot of sense to learn from what they’ve done. Or, as I learned long ago, creativity is great, but plagiarism is faster.

But, this weekend, it occurred to me that, for most of my career, I’ve avoided using the term “best practices” – because I’d witnessed how many clients were ready to kill other consultants who were more interested in talking about “best practices” than actually listening to what their particular company needed. 

Read more…

A friend of mine is an executive at a smaller non-profit healthcare provider. We’ve been speaking informally about the various data and reporting challenges his agency is facing.

Here are the key facts:

1. The organization relies on multiple software systems, some in the cloud and others server-based.
2. The organization has several folks who develop reports in the different systems. Each person develops reports as they see fit, generally upon request from others in the organization.
3. There is no CIO or CDO. Various other executives (including my friend, who has no technical background) have responsibility for managing technical folks.
4. An executive with extensive experience in larger, more sophisticated organizations wants the organization to become more sophisticated. He would like them to develop a data warehouse to centralize all their data so they can better develop metrics that would drive the business forward.
5. The organization has not been successful in the past when they have attempted to execute large projects.

What do I recommend? Should they be strategic, develop a data warehouse, create metrics and distribute? Or should they go tactical and identify all current data demands and knock them out one by one?

Read more…

In my introduction to this new blog, “Back to Where I Started,” I wrote about moving beyond “technical consulting.”

One idea that’s helped me formulate my new direction is learning the difference between “technical” and “adaptive” challenges. 

I came across the idea first in Immunity to Change by Robert Kegan and Lisa Laskow Lahey. The authors cite Ronald Heifetz’s classic work, Leadership without Easy Answers.

No blog post can do justice to these two complex books¹. But the key distinction between technical and adaptive change is key to how I see my work going forward.

I’d put the distinction this way. If you have a technical challenge, you can hire someone to fix the problem and you don’t have to change who you are or how you work. Examples abound. A surgeon can remove your appendix. A CPA can file your taxes. Or a data consultant can make your reports run faster.

Clear problems. Known solutions. Fixed pricing. No personal growth required. 

Adaptive challenges are much more complicated – because you can’t just throw money at the problem. 

Read more…