HEAR: the human side of transformation

I usually spend my first few months at a new company meeting people, learning about them and their problems, and mapping how the work connects across the business. I had done the same at the company I was with when I gave the MoreSteam talk. It was one example of an approach I had been using throughout my career.

Those conversations help me understand both the people and the system they are working in. I can prepare tools that might help without immediately turning every conversation into a proposal to fix something.

Trust equity comes from caring about people's futures, showing up for them and delivering on what we commit to. Over time, those experiences give someone a reason to believe that we can help and that we have their interests in mind.

Having a good answer is useful. Having a good answer from someone you trust enough to work with is a different starting point.

I also don't want the first time someone hears from me to be when I need something from them. Learning about people has value before there is a project attached to it. Their priorities, frustrations and hopes help me understand what a useful change would look like.

You cannot fake that interest and expect it to hold up. People will eventually experience the difference between being listened to and being managed toward an answer you already chose.

Sometimes the first useful thing you can do is a little ashy.

An ashy win may be rough around the edges. It may not be the complete solution you would design with unlimited time, sponsorship and attention. But it helps someone with a problem they have right now, and gives you something useful to build on together.

In one of the examples from my talk, a team asked for help with a specific value stream. I tried to introduce strategy planning, but they weren't ready for that. What helped was creating a user-experience survey that made the issues visible and brought the voice of the customer into the conversation.

The survey gave us a clearer understanding of the problem and a starting point the team was ready to work with.

There is an ego check in this phase. Am I holding out for a perfect solution because the problem requires it, or because I want to do it my preferred way?

When people need help, they need help. I have to be willing to adapt the parts of my approach that can change and explain the parts that cannot. I can keep standards without insisting that every team learn my entire playbook before I do anything useful.

Those early wins also teach me. I learn which tools fit, where the friction is, and what people actually find valuable. That makes the next recommendation better informed.

Eventually, I will want to try something that the people I'm working with haven't tried before.

This is where the trust we've built starts to matter in a very practical way. Someone may not fully understand the framework yet, but they know how I've shown up so far. They are willing to give the idea a chance.

I've called this a “just trust me bro” moment. There is still work behind that ask.

I need to explain what I believe will happen, what could go wrong, and what we will do if it doesn't work. If I believe in the idea enough to ask people to spend their time on it, I should be willing to put my reputation behind it too.

That doesn't make the outcome certain. Being honest about uncertainty is part of the commitment.

Delivering on the gamble can mean getting a solution that helps. It can also mean following through on the exit plan we discussed at the beginning. If I said we would stop under certain conditions, then I need to be willing to stop.

The relationship takes a different hit when people discover risks they were never told about, or when the person who asked for trust disappears after things go wrong.

I want people to know what they are agreeing to and know that I will still be there when we find out how it goes.

As those experiences repeat, people have something concrete to connect the methods to. They have helped solve a problem, seen a useful result and tried an unfamiliar approach with support.

That gives training, tools and templates a better place to land.

In the journey I shared with MoreSteam, early conversations and small wins helped create opportunities for a training and certification program. The point of that program was to equip people to solve their own problems. As the work expanded, I kept meeting people, earning trust and learning what they needed.

The phases overlap. A successful project with one group doesn't mean a new group owes me the same trust. Expansion means starting those relationships too.

Champions at different levels and senior sponsorship matter here. So does making the training fit the work people are trying to do. I want people to recognize how the methods can help them, rather than feel that their problems have to be reshaped to fit my training materials.

The culture becomes visible in what people do with that support: whether they raise problems, help each other understand them, try improvements and keep learning from the results. Sustaining it means continuing to support those habits and relationships after we reach that point.