I used to write all the time. I used to be compelled to write. I loved to write.
Then I stopped writing.
It wasn’t that I didn’t create content. It’s just that a lot of the content I created was either audio in the form of a podcast, or video in the form on a webinar.
There is something different about writing.
Something uniquely valuable.
Sitting down to write forces you to really think. To be clear. It forces you to organize your thoughts in a way that hopping on a podcast or a webinar doesn’t.
The written word is less forgiving.
I’ve been introspecting a bit on why I stopped writing.
For the purpose of figuring out how to get back into it.
To rekindle my passion for the written word.
The easy answer is that I got super busy. While true, that answer is a bit of a cop out. I’ve been pretty busy for years, but somehow found time to write.
Why don’t I feel compelled to write in spite of being busy?
To some degree, I think my interests changed. Back in the early days of my agile journey, everything was super new and exciting. I felt compelled to share what I was learning. Through writing, I developed my unique take on our industry. This ultimately resulted in forming LeadingAgile and our point of view on Agile Transformation.
If I’m really honest, a lot of my early content was driven by friction with other people in our space. It was a response or a reaction to some of the ideas that candidly I thought were absurd. Or more generously, just wouldn’t work. I was driven to help people understand that and to show them a different way.
Nowadays, I don’t engage as much. I’m not on the ground on a daily basis figuring things out. The rate of learning in our space, for me personally, is lower. I’m not at the work surface on our engagements, I don’t read as much content, so there is less energy around those kinds of issues. What I deal with on a daily basis is organization building.
I have a ton of energy around our organizational architecture, how we tell stories in market, how we hire and recruit and onboard talent. How you maintain culture and deal with issues of scale. I’m immersed in our strategy and what we are trying to accomplish in market. While fascinating, not really on topic for the LeadingAgile blog.
There are clearly lessons learned that could benefit other fast growing companies.
Maybe I need to give that some thoughtful consideration.
Another problem is that many of our ideas, and much of what we are doing on the ground with our clients, just doesn’t lend itself to a few hundred words of written text. How do you meaningfully explore a PDO transformation, or how to orchestrate a Projects to Products engagement, in such little space?
Writing a short article on how to be a better ScrumMaster is fairly straightforward. Tips and tricks for effective sprint planning is fairly straightforward. How to assess the business architecture of a complex multi-national company and create a scaleable team formation strategy, is not quite as straightforward.
Longer form content requires more thought, takes more time, and is more difficult to produce.
I think that’s why some of these bigger ideas are showing up in video and webinars more often.
Next, and this is probably the one I find most disturbing, I think we’ve gotten afraid of being wrong. The core patterns LeadingAgile has brought to market have been incredibly resilient. The things we were writing about 10 years ago are so anchored in first principles, they have held up remarkably well. Like, remarkably well.
Much of the work we are doing with clients today is anchored in this prior art. Art that has laid a solid foundation on which we’ve built the LeadingAgile change model. There is some risk that we’ve gotten afraid to touch them. It’s a problem for me, so I can only imagine how bad it is for my team. Where do you even start?
That’s a BIG problem.
Finally, because our model is based so soundly on first principles, to have a higher level conversation, you almost have to review the foundational material every time. How do you talk about business agility without talking about enterprise agility? How do you talk about enterprise agility without understanding team agility? How do you understand team agility without understanding teaming strategies and the impact of dependencies?
When you follow the rabbit hole all the way down, it’s easy to lose sight of the original point.
Even if you hold the point, how do you maintain interest while you build the argument?
Super tough problem to solve.
But I’m going to solve it.
Anyway… I’m going to acknowledge that this post was a bit of a cheat. I wanted to write it because I wanted to think through the problem. I wanted to state clearly why this is so challenging so I could better understand and articulate how we might solve it. You see, this is the power of the written word.
Full disclosure, next post will likely be a cheat as well.
What I’m going to explore are some of the things we are doing to overcome these challenges.
I’ve got some ideas.
