What Does It Mean to Be a “Thought Leader”?


“In the beginner’s mind there are many possibilities, but in the expert’s there are few.”
— Shunryu Suzuki
I was recently given the opportunity to present myself as a “thought leader for my industry.” I’ve been pondering this. What do I know? What do I know so deeply and fully that others might want to hear my opinions about it? Not much, it seems. Actually, I don’t have nearly as many answers as I have questions. But more than this, it’s the questions that really keep me interested.
Here’s an example. My company designs and implements software systems for our clients. Some of our relationships are great. When a thorny technical problem arises, as they often do in custom software development, we work as a team to explore our options, resolve the challenge, and keep going. There’s space in the client/developer relationship for frustration and uncertainty, but it’s characterized by mutual respect and cooperation.
Other relationships don’t feel as healthy and robust. Maybe we’re seen in an adversarial light. A bump in the road brings out anger in our client. We might be doubted, scapegoated, and even insulted. And it goes both ways. For our part, although we do a good job of remaining professional and polite, we might also harbor resentment, feel unjustly accused, and have that sense of “us” vs. “them”.
Why does this happen? That’s a good question. I found a lot of articles about how to improve relationships between contractors and clients. There are a lot of good ideas, from a lot of thought leaders, and they look pretty useful. Somehow though I don’t really want to resolve my question, at least not with someone else’s advice. Maybe in some cases, like the richly complex world of human relations, the questions are more important than the answers.
I do think I have a lot of good questions about this situation. One is “How do I feel about this relationship?” That leads to “How does my client feel about this relationship?” And then, “How might I find out?”
As a software developer, I’m used to finding answers. If I find enough of them I can build an expert system; automate the responses. I could say, “Jim is a little skittish about trusting a contractor. How can we respect that and provide some reassurance?” That seems like a useful question. Then an answer: “Let’s be sure to send weekly status reports, so he’s in the loop.” This might work for months. The relationship might seem great, and I don’t have to worry about the (sometimes uncomfortable) sense of having an unanswered question hanging over my head.
Then one day we find out that Jim had an assumption that we hadn’t fully extracted, and the project scope expands by a couple of weeks. Maybe the status reports aren’t enough now. Our relationship is facing a crisis of confidence. Maybe we need daily stand-ups with Jim, a face-to-face meeting, something else. I don’t know. If I’m still asking questions like, “What does our relationship need today” I think our chances of getting through gracefully, and as a team, are better.
I love this quote, by A.H. Almaas: “Your mind is full of ideas and dreams and plans … But these ideas silence the question, comfort your mind, and put out the flame.”
A little discomfort of mind can be a good thing. A little bit of “not knowing” can be a good thing. A lot of “not knowing” might be pretty helpful too.
I think the best mentors don’t supply answers, they stimulate questions and keep that search alive in their mentees. The best students I’ve seen are the ones who keep asking questions. Maybe the same is true for the best project managers.
Being a “thought leader” doesn’t really sound that appealing to me after all. If there were a job to apply for, I think I’d prefer that of “question leader”. Because I think the healthiest and most exciting relationships are the ones that we keep showing up to with freshness, and “not knowing”, and the sense of possibility that each of us might be someone new, each time we meet.

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more