My Personal Andon Cord

April 29, 2019

Have you heard of an Andon Cord? On the assembly line it’s that cord you yank on to stop the entire line when a problem is found. The idea is to stop everything until the problem you encountered is fully understood and fixed. That way we take the time to improve the function of the assembly line so that those sorts of problems never slow us down again. It’s a little example of that “slowing down to go faster” that those crusty old software curmudgeons blather on about.

But who listens to those old cranks anyway?

I was thinking about a recent Product Owner training I was running where I was told that the product owners didn’t actually sit anywhere near the team (that was assuming they had a product owner to begin with, but I digress). It turns out that the product owner for a given team was very likely located in another building or even perhaps another state or country altogether! This kind of colocation issue is fundamental to improving a teams performance. Address it and you will see meaningful improvement quite quickly. Fail to address it and you will be wrestling with the side effects and consequences forever without dealing with the underlying problem. 

So what did I do? Well, this was just the start of a two day training, so I had at least a day and a half more of training that I was expected to deliver. So I tossed that issue on the mountain of other issues that I was uncovering and moved on. Trainers gotta train, kids gotta eat. I raised concerns, told the right people, and moved on. Everyone kept moving.

Now in hindsight, I’m not sure if I should be proud of dismissing something that important. However, I know it happens all the time. But it makes me wonder, is there an issue sufficiently important that I would call the whole class to a stop in order to address it? What would cause me to stop the line as a trainer? Where is my trainer Andon cord?

If a fist fight broke out in class, I’d certainly stop the class. So there’s that. But what else? If someone was crying, I’d stop the class. If I found out someone was being hurt, I’d stop the class. But if I found out they were doing something stupid…I wouldn’t necessarily stop the class. I might pause long enough to mention that I wouldn’t recommend doing that. Maybe I’d hand them a Darwin Award (oh, now there’s an idea…). But stop the class? No.

Let’s look at that example of the product owners in a different location than the team. Colocation of product owners or customers is pretty fundamental. You would stop the line if you found out that the car’s tires are missing. If someone told you,”It’s OK, we keep them in another building.” You would probably be well justified in insisting that the tires get brought in pronto. There’s not much point in leaving silliness like that alone. So I’m asking myself, if the customer has paid me a few thousand dollars for the training, but instead of delivering the training, I stop the training to focus on that one problem…what would happen? Fixing that problem could probably mean a huge return on investment for them. Something far beyond the paltry amount they have spent on the training. It’s food for thought. 

On the other hand, typically these types of organizations are not in a place where they are accepting or tolerant of radical change. Usually few if any folks in the room are actually empowered to do anything to change the situation. Furthermore, even the folks who hired me may not have that power. You have to have a lot of credibility in an organization before you can even start talking about that sort of change. Credibility takes time, and that’s something that most trainers don’t have. You’re in, you do the training, and you’re gone. Poof of smoke. Vanished.

So in the big picture it probably depends on your context. If you are just in for a quick one-time training, then you really don’t have the credibility to stop and attack problems like this. On the other hand, if this is part of a long term engagement, then there is the real possibility of being able to deal with problems like this in real time. To be able to pull your Andon cord and stop the line. What a marvelous thought.


A House for Hermit Crab

April 23, 2019

One of the wonderful things about being a parent is all of the children’s books you get to read. I never fail to be amazed at the simplicity, grace, and sheer storytelling genius that I find in many children’s books. I’m thinking of amazing books like Where the Wild Things Are. It’s stories like these that seem compelling no matter what your age. One of my personal favorites is a little story by Eric Carle called A House for Hermit Crab.

In this story, our hero the hermit crab has grown out of his old shell and it’s time to find a new one. So off he goes and finds himself a nice, brand-spanking new shell. He’s pretty pleased with the fit, but to be honest, it looks a little plain and could use a little decoration. So our hero ventures forth in search of a little bit here or there to decorate his new home with. Each time he meets a new character (a starfish, an anemone, a coral) he greats them with great joy, compliments them on their beauty, and invites them to share his house with him. It’s a long journey, and at the end of a year he has a magnificent shell covered with many dazzling creatures. Just as he feels happiest, he realizes he’s growing out of this shell, and with some regret moves on to a new shell.

This story speaks to me on a couple of different levels. Like the hermit crab, I have adopted different process frameworks (call them shells) over my career. Early on it was XP. Then it was Scrum. Then SAFe…and God only knows what the next bright shiny framework is that I’ll wear. And with each one, I discovered unique practices that seemed like useful additions to my process house. These were practices like test driven development, pair programming, mob-programming, and so on. Each one I held up to the light and thought, “You’re awesome!” And invited my teams to try them. It took years, but I collected quite an array of decorations for my shell. Usually, just when I felt pretty confident with it all, I started to outgrow that shell, and with some regret, moved on to a new shell. So the process repeats itself. I know that my journey has been metaphorically very similar to that of the hermit crab. I adopt a model, modify it to make it mine, and eventually grow out of it.

There’s another reason A House for Hermit Crab speaks to me. It’s the delightful open and inviting attitude of the hermit crab as he meets each new creature. I feel the same way about a lot of the people, practices and processes in our agile community (…and beyond). I guess I tend to err on the inclusive side. I think of it as a “play first” approach. Extend the open invitation and see what happens. All too painfully often our community tends to do the opposite. There is far too much, “That’s not agile” and far too little invitation to join and explore together. I think that our little Hermit Crab has an admirable way of approaching novelty.

Ultimately, I think I like the way that A House for Hermit Crab makes me feel. Not to get too precious about it, but this feeling of open invitation is what I long for the most. It’s what originally drew me to agile in the first place. We all will likely have many different shells (or models, or frameworks) that we will inhabit at one time or another as we grow. We should invite each other to decorate those shells to reflect what we think is beautiful, and share them with others. That is what motivated me to write my recent series of articles about SAFe Mix-in’s. SAFe is the shell in this case, and we can decorate that shell any way we please with many interesting practices. If you are curious, like me, and want to decorate your own shell, check out the following Mix-ins:

Perhaps my SAFe shell is starting to feel a little cramped, so maybe it’s time I shared it with someone else.

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


SAFe Mix-in’s: Open Space

April 22, 2019

Overview

One of the interesting things about SAFe is how it has evolved over the years. The story there is very interesting. More so than any other framework that I’ve witnessed, SAFe has very definitely changed since its beginnings through what it has become today. For example, early on, it didn’t have the levels of work that it does today, and certainly the terminology has evolved. Furthermore, many of the roles have been added and changed. To a very real degree, things like DevOps and Continuous Integration and deployment have been added as well. These new additions were nowhere to be found in the early years of SAFe. 

So, all of this is to say that SAFe has evolved in terms of its framework and structure quite dramatically from its early beginnings. And in fact, it continues to do so, which is what I find so beneficial about it. Furthermore, the way that we perform certain ceremonies in SAFe has changed. For instance, a good example of this change is how we prepare for and run a PI planning event. Originally, PI planning was a very quick event. You oriented the teams in a SAFe for Teams workshop and then right after that, you started PI Planning with no other preparation than that. You could go from zero to SAFe PI Planning in a week. As a result, the planning event was very intense, open and collaborative. There was none of the long, drawn out planning cycles that you typically see in PI planning today.

Over time that has turned into a much more deliberate sort of event. So now PI planning typically involves months of preparation as you prepare initiatives, and features, and stories for use in the upcoming PI planning. There’s lots of review and refinement that goes along with that. But originally, PI planning wasn’t like that. Originally PI Planning was much simpler and was more similar to what you and I might think of as an Open Space event.

You can find out more about Open Space here:

An open space event is where we go into the event with what we hope is some sort of compelling theme that’s going to drive the conversation. That’s all we have to start with. We have a stakeholder who delivers that theme and tries to provide as much color and context as they can to make the theme as vivid as possible. Then everyone in the room is responsible for coming up with how they are going to address that theme. From there, we leave it up to them. In the case of a business, you might put a key deliverable or initiative forward as your driving theme. It could be a key set of features – whatever compelling idea that you believe the market needs. You put it in front of the group and then you leave it to the teams for those two days to figure out how to proceed and let them organize the work as they see fit. The teams are responsible for taking that initiative, breaking the features down, identifying the stories, working out the dependencies and planning the work. They keep track of their work by putting it up on a big wall which looks a lot like an open space marketplace. After two days, you review your plan and you are done and ready to get started.

Running PI Planning as an Open Space would have some interesting implications:

  1. Open Space makes it clear that anyone can contribute ideas, not just particular people in a given role. PI Planning depends on initiatives and features provided mainly by key stakeholders and product management. I think Open Space would promote a more democratic input process where teams, who often know a great deal about the business domain, would be more able to contribute their own ideas for features, etc.
  2. Open Space has no formal collaboration structure beyond the marketplace. Wherever you meet is the “right place” whatever time is the “right time” and whoever shows up are the “right people.” That’s terrifying level of informality for most organizations, but it also opens up a great deal of freedom for those who can own their work. There are synchronization points in Open Space, like the morning and evening “news” where everyone gets to see what others have done and see changes in direction. My intuition is that I would want to spend time getting folks used to Open Space first (on other topics), before trying to substitute it for PI Planning.
  3. Open Space has the concepts of the “Butterfly” and the “Bumble Bee” – those people who flit from group to group, perhaps pollenating an idea or two. Even if we don’t use Open Space, I think these ideas by themselves would be useful to introduce to PI Planning.
  4. Open Space does not dictate the kind of work that can be done. Teams can write code, call customers, leave the room – anything that enables them to best pursue their ideas. This form of hybrid working/planning could be much more powerful than focusing exclusively on estimation and planning. 

If you find that your PI Planning has become very rigid and stale, you could try using Open Space to free things up. You have the option of incorporating just a few of the elements of Open Space, or you can go “All in” and completely replace PI Planning with Open Space. Or, you could keep PI Planning, but introduce Open Space in a separate forum. There are a lot of great options here for us to explore.

Forces

  • PI Planning feels stale and rigid
  • You’re looking for way to foster innovation

Framework Impacts

  • Replace the PI Planning with Open Space (same time commitment as PI planning, but less structure)
  • Less pre-PI Planning effort

Benefits

  • More ownership of team direction and work
  • Potentially better plans because work can be actively investigated alongside planning (due to loose Open Space structure)

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


SAFe Mix-in’s: Radical Co-Location

April 18, 2019

Overview

One of the biggest challenges that I often encounter on SAFe transformations is dispersed teams. A dispersed team is a team that is spread across multiple locations and often across multiple time zones as well. I’m speaking specifically of dispersal within the team membership – for instance, a product owner in LA, two developers in Bangalore, three testers in Russia – that sort of thing. That’s a dispersed team. While it’s possible for team like that to get work done, it is also demonstrably one of the slower ways to get work done. In fact, it’s probably the opposite configuration of what’s needed for really high performance. There’s ample evidence to show that high performing teams perform better when co-located.

Often times, when you go into large organization you find that the product owners are in building A, the development teams are in building B, and operations is in building C (or some other horrifying configuration of the above). To make matters worse, there is typically little or no willingness to change that. It costs a lot of money to change that sort of configuration.

Normally, I wouldn’t think of co-locating teams as a big deal. It sort of comes with the territory with agility. However, the reason I’m including co-location here as a mix-in is that for big companies, it seems to be a harder challenge. So, my thought was, “Why not put focus on the co-location aspect during the transformation?” You could also argue that SAFe already encourages this behavior. I would agree, but…we still don’t do it. So, given that I’m pushing boundaries here, I call this a mix-in. You might disagree – fair enough.

You see, all too often, what we do is accept that dispersed situation as the status quo because the customer is unwilling to go any further. However, for those customers that are willing to entertain the idea of improving the performance of their teams then we should look at radical co-location. I call it radical co-location simply because for these organizations it’s a radical idea. It’s a really big deal to them. It’s a huge undertaking. But let’s face it, for those of us in the agile community, there’s nothing radical about it. We’ve been co-locating teams for decades now. So really, the only people that it’s radical for are these large, byzantine bureaucracies that we are trying to encourage, threaten or nudge towards agility. And so, if we have to describe it as something radical or new, if it gets them excited, then perhaps it’s useful. 

All we’re really talking about here is getting all the team members sitting together in the same location. For example, getting the product owner sitting with the team. All of the team members in the same building, on the same floor, in the same pod. This enables them to work together on a day to day basis with no delays in communication at all. That’s it, no tricks, no stunts, just getting everyone together. If that means that some sort temporary seating arrangement needs to be made, whether folding chairs or folding tables, so be it. The communication overhead goes down, delays go down, feedback loops improve. So, with all of that in mind, it really is essential that if a company is willing to go along with this, that we get it in place as quickly as we can. In terms of performance improvement, it would be nearly number one of the things to do in any transformation. 

Let’s take this radical co-location idea a little bit further. After all, SAFe is all about scaling, so the question is, how can we use co-location outside the team? How about a co-located release train? A co-located solution? The same issues with communication delays apply with cross team communication as they do with intra-team communication. 

At the end of the day, it’s important to acknowledge that there are a lot of very legitimate reasons that people can’t all be co-located. This isn’t for everyone. Folks have different learning styles, and different comfort levels with personal proximity. I want to acknowledge that those things are important…and for those who can tolerate it, let’s lean hard on co-location.

Forces

  • Teams are dispersed across geographic and time zone boundaries
  • There is pressure for faster team performance/feedback

Framework Impacts

  • None

Benefits

  • Faster feedback
  • Faster team performance
  • Higher quality (fewer handoffs)

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


SAFe Mix-in’s: The Core Protocols

April 17, 2019

Overview

For some organizations that prefer to have things really well explicitly defined or proscribed, especially if they are in a SAFe transformation, they might want to consider taking a long look at Jim McCarthy’s Core Protocols. To me at least, there is a very natural fit between the Core Protocols and SAFe. The Core Protocols define the kind of interpersonal interactions that you have on a team and SAFe defines the interactions that you have at a cross-team level and above. So, to a certain degree, especially for organization that are really seeking a highly proscribed picture of what to do next, it seems that the Core Protocols and SAFe might be well suited to each other. 

In fact, you might find that you can even evolve the core protocols to some degree. So how would this look? Well, Core Protocols specify, step-by-step, how to define major team interactions. An example is the Core Protocols Check In, where at the start of a meeting you will go around the group and have every person tell you what their current emotional state is, in terms of being mad, sad, glad, etc. Simple attributes. By doing this we get an emotional check-in and a starting point for everyone in the room, and we make it visible. So, it aligns with our need to keep things visible and transparent within the team. It also makes it clear where people are coming from. This Check In, could easily be incorporated into any meeting that you are using in SAFe, whether that is a team level meeting, or a scrum of scrums, PI Planning, any of your higher level meetings across the board. 

That’s just one example. There are about a dozen different protocols within the Core Protocols that could be incorporated in a variety of places. Here’s a short list:

  • Pass(Unpass)
  • Check In
  • Check Out
  • Ask for Help
  • Protocol Check
  • Intention Check
  • Decider
  • Resolution
  • Perfection Game (I love this one)
  • Personal Alignment
  • Investigate

Another example of a Core Protocol that we might use is the Perfection Game, which again can be used in many places in SAFe. It’s a wonderful way of providing feedback and you could incorporate it anywhere that you have reviews or retrospectives. Basically, you give feedback starting with a score of 1 to 10 (10 being perfect). Then you provide examples of what it would take for them to make that score a 10. So, for example, I love the new widget feature and I would give it an 8 out of 10. To get to a 10, I would change the widget so that it takes 1 mouse click instead of 2 to perform that action. That’s pretty much all there is to it. You let the person know how it rates, and then you provide the feedback to help them get to great. If you can’t think of anything to improve it, then you should probably give them a 10. I use this feedback mechanism all the time and folks really seem to appreciate it.

The more I think about this particular mix-in, the more I think there is a small bit of genius to it – at least for some organizations. I think there are some places where it might be very popular. We might also discover along the way that there are a few protocols that can be used at higher levels when having strategic discussions and at the portfolio level or solution level in SAFe. My belief is that there is actually a fair amount of room for creative interpretation and mixing of Core Protocols with SAFe.  

Forces

  • You are seeking more proscriptive guidance for certain team level interactions

Framework Impacts

  • None

Benefits

  • More explicit guidance for healthy team-level interactions

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


SAFe Mix-in’s: Sociocracy

April 16, 2019

Overview

What if you are a big fan of sociocracy or holocracy? Can you combine those practices with SAFe? Right now, when you look at SAFe you see teams at the team level (of course), programs at the program level (or release trains anyway). However, at the executive or portfolio level you don’t see any specific recommendations for how to organize into teams or groupings or aggregations. I think the portfolio level is where sociacracy or sociacractic methods might come in handy in SAFe. So perhaps it’s time for a brief overview of sociocracy. 

Basically, there are two key attributes of sociocracy as I understand it. First sociocracy involves a hierarchical arrangement of people into circles or groups. I don’t think there are any strong definitions around how those groups are composed. In essence, you have the people who are doing the work, or those closest to the work, in a group or team or circle. You have group appointed representatives that will be representatives at the next level or circle up in the hierarchy. So that next level up is perhaps a group of related teams or teams working on a similar product or effort of some sort. That higher group is your next sociocratic circle. That circle, in turn will have members that represent it at the next circle up, yet again, to some top tier circle that would represent the executive team or directors, depending on the scope and scale of the organization in question. There’s no real limit to the number of levels of circles in this hierarchy. So it’s a hierarchy of circles.

The other key attribute is that decision making is made by consensus within each circle, not majority voting. Decision making is something where we are seeking everyone to come to the point where they understand the problem and they believe it is the best possible solution, even if it is not their favorite, among all the solutions presented. This is very different from an in-or-out roman voting system, where the majority wins. In roman voting there are winners and losers. The losers think the winners are idiots and the winners think the losers are whiners. Using roman voting you only get partial commitment from the winners and zero engagement from the losers. Consensus, on the other hand, has commitment from everyone. With Consensus everyone agrees this is the best path forward, even it isn’t their favorite. Frankly, it’s a much higher standard of agreement to try and achieve.

You can find out more about Sociocracy here:

With these the two key attributes of sociocracy: the hierarchy of circles and consensus-based decision making within circles, the question is, within SAFe how do we apply this? Well, we already have consensus-based decision making using the “Fist of Five” technique in SAFe. We don’t use it everywhere in SAFe, but it is used prominently at events like PI Planning. It’s certainly something that people are familiar with and comfortable with and it would be easy to incorporate into other areas within their organization. So, if we are going to apply sociocracy and one of the elements we are going to use is consensus-based decision making, then we can assume SAFe will have no problem with that, and we can call that a win. 

How about all those crazy hierarchies of circles that sociocracy has? Well that’s where we might have to change SAFe a little bit. Now if you look at the team level it’s quite clear that SAFe already has “circles” at this level. If you go up to the next level, the program level, and look at the release trains, again, the people are participating in things like the scrum-of-scrums, those people are basically forming your next level up of circles. So, so far, our hierarchy of circles that we might see in sociocracy is well represented already within SAFe with no changes. 

So, let’s go one more level up. At the top level this is where we might have to introduce change, because as far as I know, SAFe has no guidance for what kind of teams or organization should be used here. In fact, SAFe says little or nothing at all on this topic. It’s at the portfolio level where we would be asking the management teams, the executives, to form circles of their own. How many circles is going to vary depending on the size and scale of the organization. For instance, if we are looking at multiple divisions, there might be circle for each division and then a circle above that with representatives from each division…and then a circle above that representing some larger organizational context. That in and of itself is not a particularly challenging thing to define. Actually, I think many organizations implicitly do that in one form or another. 

However, I think it’s important to keep in mind that the idea of having representation from lower circles has to be captured here. That’s where I think that introducing and formalizing these teams and groups is important. You could use something as simple as executive scrum teams (or something of that sort). It would be useful for executives to walk the walk and talk the talk the same way everyone else in the organization may already be doing. So, to some degree it’s just a natural way of taking scrum and spreading it throughout an organization. Or Kanban, or whatever team-based organization tickles your fancy. The underlying idea: to use the circle model to spread the team behavior at the team and program level upwards to the executive level.

Forces

  • You are seeking ways to further empower teams
  • The executive team is willing to structure themselves in the same fashion as everyone else

Framework Impacts

  • At the portfolio level, we introduce circles

Benefits

  • More ownership of team/circle direction and work
  • Executives tied into the same process the rest of the organization uses, with the associated benefits

Did I mention sociocracy probably isn’t for everyone? Because it’s definitely not. But it could be really cool to integrate elements of sociocracy in organizations where the culture is a good match.

Interested in more Mix-ins? Join Ron Quartel and I for a 3 day workshop on SAFe+FAST Agile. Combine the 2 to get max value from your agile transformation. It’s an opportunity to explore the latest scaled agile processes and practices with other agile innovators on May 15, 16, 17. ‪https://bit.ly/2HXCcKD ‬


One Step Back, Two Steps Forward

April 15, 2019

I was confronted with a bit of a dilemma the other day. I was working out and reaching the limits of what I could lift. I could tell, because as I prepared for each lift, I was a little bit scared. I didn’t really know if I could do it or not. Then I would perform the lift, and barely, just barely, make it. It wasn’t pretty, but I did it. Afterward, as I lay on the floor hyperventilating, I had a lot of conflicting thoughts running through my mind. I’ve been working toward a lifting goal for a long time now. I’m getting tantalizingly close. I can’t stop now. I’m not getting any younger. Time is short. If I keep this up I’m going to seriously injure myself. This is really painful. It’s no fun being terrified of the weight. I can’t stop now. I don’t know if I can do it again. Dear God, I hurt.

I don’t want to make too much out of it, but suffice it to say that I was seriously conflicted. I’ve literally invested years in getting my lifts to where they are today. It’s hard to step back with that kind of investment behind me. On the other hand, that’s a lot of investment to waste by injuring myself. So it’s a real dilemma, especially when I feel like I’m so tantalizingly close to my goals. Part of me is screaming, you’re almost there! And the other part is begging, pleading to back off.

Where else do we see this kind of goal oriented struggle? Developing and releasing a product? Getting a promotion? Saving up for something big like a new house? We see it anywhere there is a large investment over time toward a meaningful goal. The danger is that if we over reach, we may lose the opportunity entirely.

In my case, I decided that the prudent thing to do would be to take a few steps back. So I rolled back the weights and the intensity a few notches and started over again. I was back to lifting weights that I had been lifting nearly 3 months earlier. Three months is a lot of time to lose! However, I noticed a few things:

  1. It was so easy! I felt my confidence come roaring back.
  2. I was so much stronger than I had been. Where before it had been a challenge, now it was second nature.
  3. I was performing cleanly and confidently, not scrabbling to survive the experience.
  4. I no longer feared injury.

The road has gotten a little longer, but now each step I take feels more confident and certain. This is where having a coach can make a really big difference. They can act as that voice of reason that will help to steer you through these decision points. They act as a relatively unbiased party that is invested in your success. They need to know the domain really well – I would never take a coach who didn’t know about weightlifting. They need to have an experimental mindset: everybody is different, things that work for one customer won’t work for another. And they need to be able to firmly give constructive advice for change, even when the customer really, really, really, doesn’t want to hear it. Perhaps then most of all.

I don’t have a coach right now (perhaps I should take my own advice). I know that if a coach had told me that I needed to go backward three months in my training, I would have resisted. That would be crazy talk. And yet here I am. I think I now appreciate it a little bit more when I work with managers. I often recommend that they do things that would appear to be backward steps. For example, I might recommend pair programming for their teams. I often get the horrified reaction, “You mean twice the number of people doing half the work?” Uh, yes. That’s a giant step backward. Especially when you feel as though your teams are performing at what may be the best they have ever done. I think I get it now. That’s not an easy sell.

But a good coach knows that a few steps backward can lead to later leaps forward. A good coach is invested in getting you there. A good coach knows you will build confidence and capability, and that has value too. And a good coach won’t back down when they know it will help you reach your goals.

Oh, and if you are looking for a good coach, I’m available.