Heidi Helfand: commitment

Transcript context

…There's a book by William Bridges called Transitions: Managing Life's Changes. I have it right here. Making Sense of Life's Changes. He talks about endings, neutral zone, and new beginning. Ending: you're going through a change, your team is changing. Neutral zone: the period of kind of liminality where you're like, "Gosh, I don't know how this is going to go." You're not quite comfortable. You're not quite in that new reality yet. You're still thinking about what it was like before. And once you're in that new reality and leaders can paint the vision and picture about the benefits of the new reality and the purpose and why we're here and anchor to that to try to raise positivity. But once I learned about that transition framework, going through any subsequent changes myself became a lot easier to grasp and it really kind of makes changes in any part of your life. I mean, his book is not written about software development or product development. Sometimes we're going to have a say, we're going to be able to participate, sometimes we're not. And being clear on who the decision maker is in a change is really important. There's another framework that I really like. I don't think it's in my book, but I've written about it in my new book, but it's called RIDE. And we had a chief people officer at Procore and she's now at UKG, Pat Wadors. She taught us the RIDE framework for decision making clarity and it's who's requesting the change, who can give input to the change, who's the decider on the change, and who's going to execute on the change? So it's like R-I-D-E. And I googled this for a while; I couldn't find anything on it. I encouraged her to write about it and I credit her to that, Pat Wadors. She's awesome. So a lot of the times it's like, what's the problem you're going to solve? You have a current state and a future state and that future state might be up to discussion, but maybe it's not depending on what it is. You're getting acquired, you're probably not going to have a standup meeting and talk about should we get acquired or not? No, you're not part of that decision. And then how's the change going to get rolled out or how are we going to do it? In other cases at the team level, maybe you have a retrospective and you determine, "Hey, I think we'd be a bit more effective and we'd be able to deliver at a better cadence if we were two teams instead of one team." And if teams have the ability to talk about that and impact and have some agency into how their part of the org evolves and change, I think that could be really cool. I think that could be really empowering. I think that could help us feel more ownership in that company that we're in. It doesn't always have to be like decision making equals hierarchy or the person at the top. It doesn't have to be like that. But again, reteaming is hard. Reorgs are hard. You can't lump them all into one thing with, oh, it's all great all the time. No, it's not. It's not. person at the top. It doesn't have to be like that. But again, reteaming is hard. Reorgs are hard. You can't lump them all into one thing with, oh, it's all great all the time. No, it's not. It's not. But anyway, we need to focus there. We got to focus on this people layer because reteaming is inevitable. We might as well get better at it because we're going to have to deal with it. If we could just build the software, deliver to the customer, get the product market fit, hey, have we delighted them or not? If only it could be that easy. No, we have the people layer. So let's focus there too. On this transparent collaborative reteaming, final question here is just would you recommend time boxing this so that it doesn't suck up everyone's brain power for weeks and weeks and weeks? Or is it very dependent?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.