I thought my team was an enabler. It turned out that sometimes, we were the blocker.
We wanted to introduce a new IDE, and we didn't ask the colleagues who would have to use it. The tool wasn't the problem. The uncertainty was.
I reflected on it after a cloud governance workshop last year. Our coach Markus Junior made us look at our own decisions from the other side. It was an aha moment. Thank you so much!
As a central Data and Cloud team, we often feel we have the right to set rules and choose tools. Often we do. But a decision made without thinking about the people affected can stop them from working.
He gave us a simple format for this mindset shift, the 3 Rs:
- Rule: what it is about
- Rationale: why it matters
- Relief: how we help people through it
With the IDE, we had the Rule. We moved too fast on everything else. So we admitted the mistake at the end. The change came too fast and without good preparation, and for some colleagues we had become the blocker. We now keep both IDEs as options, and we're planning better preparation by offering training.
For me, the difference now looks like this:
Enabling looks like this:
- Training before go-live
- An alternative instead of a stop
- Documentation and checklists
Blocking:
- Enforcing some rules without explanation
- Manual work
- Missing standards
Since that workshop, we ask one question before we change something:
Are we blocking someone with this?
What does an enabler look like to you? What's one thing an enabler does that you wish more teams did?
This is part of my "100 Days of Year One" series. Follow along as I share what I've learned in my first year as Head of Data and Cloud.