I’ve been speaking at conferences and training technology folks for over 20 years. During that time, I’ve probably delivered over a thousand talks and hundreds of workshops.
Early on, I cared deeply about the scores I received from attendees. Of course, I was always looking for perfect 10s from everyone. But an average score in the 9s was usually ok with me.
I would review all of the feedback forms as well. And, if I saw an outlier, such as a 3 or 4, I’d become obsessed. It would influence how I felt about the whole class. A few times I tracked down the person giving me the low score and interrogated them as to why. I even tried to negotiate a higher score with them right there on the spot.
You get the idea. I was incredibly focused on the grades as a measure of the value delivered in the class.
Fast Forward
Over time, I’ve softened on grades. I’m not going to say I don’t care anymore, but I’ve come to realize that there is more to each of my classes then a numeric valuation. I also realize that no class, and I mean no class, can make everyone happy. That is, perfect 10s are virtually not achievable AND they’re not a good goal.
So, I began to reframe my focus on each class.
In 2017 I shared an article on Pair-Coaching. In it, I shared some ideas & experiences around pair-coaching.
Now in 2020, I’ve had a bit more experience doing it. Not as much as I’d like, but more experience.
This article is inspired by an Agile Moose Herd conversation we had around the idea of – what would an apprenticeship program look like for coaching? And the notion of pair-coaching came up as a part of that activity. As would doing Dojo-based coaching simulations.
Questions from the Herd…
Do you have to work in pairs all the time?
Of course not. I think that’s probably the equivalent of mandatory pair-programming for every line of code. It simply doesn’t make sense.
In fact, there are some days when I’m “pair-coaching” where I/we don’t pair at all from a client coaching perspective. That being said, we do pair to prepare for coaching, debrief coaching, and strategize for upcoming coaching.
What are some of the “dynamics” of pairing?
There are a couple of things that come to my mind…
First, who will take the “lead coaching role” needs to be established before the pair engages in each direct coaching situation. The lead then does exactly that…lead or drive. They are the coaching voice for the coaching session.
To say that I’m a Kim Scott fan is an understatement. I’m truly in love with her work around Radical Candor and her blogging in clarifying and providing stories of RC in action.
She recently published an article entitled—The Emotional Labor of Being the Boss. It was a story around her learnings of the importance of establishing relationships as a leader/boss. The topic was outside the bounds of what she typically shares, but it resonated with me just as strongly.
To give you a sense of it, here’s a snippet—
“Is my job to build a great company,” I asked, “or am I really just some sort of emotional babysitter?”
Leslie, a fiercely opinionated ex-Microsoft executive, could barely contain herself. “This is not babysitting,” she said. “It’s called management, and it is your job!”
Now, every time I feel I have something more “important” to do than listen to people, I remember Leslie’s words: “It is your job!” I’ve used her line on dozens of new managers who’ve come to me after a few weeks in their new role, moaning that they feel like “babysitters” or “shrinks.” We undervalue the emotional labor of being the boss. But this emotional labor is not just part of the job; it’s the key to being a good boss.
I’m writing this around the time when businesses are essentially locked down by Covid-19 and everyone is working virtually. It remains to be seen what types of working habits and new norms will emerge and stick after we recover from this viral attack.
Here I’d like to explore SAFe PI Planning as a planning construct or pattern. Talk about the origination of the idea. Then explore remote PI planning as something that we could do virtually.
But what I really want to focus on is an extension to PI Planning that could nearly negate the need to do it either face-to-face or virtually.
PI Planning – The Intent
The intent of PI Planning is to get a number of teams together for face-to-face planning once a quarter to commit to a body of collaborative work. It’s a scaling tactic that has its roots well before agile hit the mainstream. For example, a similar pattern was shared by Dwayne Phillips in his book The Software Project Managers Handbook, published in 1998. Dwayne called it Cards-on-a-Wall planning. I’ve used the technique to plan larger-scale waterfall projects with 100+ participants.
A long time ago, in a galaxy far, far away…
I was visiting a client over the course of a 12-18-month period for some agile coaching when I discovered an interesting pattern. It seemed as if every quarter (3-4 months) or so they would reorganize their organization. Sometimes it was an overhaul reorg, with a massive shift for most folks. And other times, it was just a fine-tuning reorg, affecting only a small percentage. But on aggregate, it seemed as if everyone would get a “new boss” at least once a year.
Of course, there were different reasons for each reorg. Here are some of the drivers that were mentioned in passing—
We need to shift from a Project-based organization to more of a Product-based one.
We lack accountability and ownership within our teams. We’re going to shift management around and declare a “Team Lead” for each team.
We’re adopting LeSS (or Spotify, or fill in your agile scaling framework), which recommends flattening management layers within the organization.
We just merged with/we acquired by (Company x) and we need to aggregate our two groups into one unified team.
We’re simply not getting enough done. We wonder if a reorg will help? Shaking things up a bit if you will.
Now that we’ve “gone Agile” we have far too many of this “role” and need to flatten things out a bit.
We’re not happy with the results from the last reorg. Things are still not getting done and we want to further streamline the organization.
Change happens. Shift happens. So, get over it.
All of which gives you a flavor for the very typical rationale for reorgs that I’ve seen across my 20 years of coaching experience.
I don’t believe I’ve ever read any guidance around ENTERING a coach. Well, other than “plopping” (parachuting, dropping, etc.) them into a situation and telling them…
Go Coach!
And this is less about how the coach enters, but more about how the organization’s leaders explain things before the coaches engage.
For example, the following questions need to be answered and communicated before the coaches ever enter the engagement—
Have you ever worked with a person who simply never turned off? They’re constantly moving, ideating, suggesting, working on projects, email/texting/slacking all at the same time, etc.?
Also, they’re often talkers. And I mean, hard to get a word in, talkers.
Thoughts like –
Energizer Bunny!
Could I get me some of whatever is helping you do that?
I can’t take it anymore, please sit down!
I’m exhausted just being around you.
My goodness, go take a nap…
Run through your head.
In organizations, these people are often highly regarded. In corporate speak, they get shit done. They’re often the fire-fighters who are “assigned” to problem areas, projects, or difficult tasks. They’re go-getters and doers.
And, to contradict what you might be thinking, I don’t have a problem with these folks. At all.
This post is inspired by one from John Cutler.
I want to take a diversion a bit on John. I was talking about his article at our Agile Moose Herd the other morning. I shared that he is one of the “Top 10” folks in our industry (agile, products, transformation, culture, etc.) that makes me think more deeply with everything he writes. John is a thought-provoker, a leading-edge thinker, and a courageous writer. He often says, what needs to be said, before anyone else is saying it. I truly appreciate his voice!
Now, back to the post. It was fairly short and entitled—Kryptonite and Curiosity.
John started out by exploring common organizational phrases that can be kryptonite in nature. That is, they can trigger a negative response in us. For example—Bring solutions, not problems, was one of them. You get the idea.
I’ve been thinking a lot lately about critical aspects of folks going down an agile transformation. For example, I recently delivered a lightning talk at a local group focused on well-being indicators in agile organizations. I was intentional in not saying the word “metrics” or “maturity” in the talk, as they imply some sort of range or specificity that I didn’t want to imply.
Related to that talk is this post. I wanted to think hard about the most critical leadership patterns (habits, tendencies, attributes) that stand between leaders effectively and personally adopting and supporting an agile mindset. Anf four critical areas came to mind as anti-patterns, horsemen if you will, that need to be avoided…
Perhaps you’ve heard some of these statements from your leadership teams over the years? I certainly have…
Bring me sufficient data to convince me of your idea
I have information you don’t have that is driving my decisions
Don’t think, just do your job
It’s above your pay grade
You don’t have a need to know
I get paid to make these decisions, you don’t
Don’t bring me problems, bring me solutions
You’re either part of the solution or part of the problem…
I was in a conference session a few weeks ago. We were talking about the balance many agile organizations struggle with between investing in—
