Traditionally, IT has been intensely process-oriented. I imagine that's because IT organizations are usually tasked with saving the world on a budget that's only big enough for them to keep the lights on and the water running. When your team bears that kind of weighty responsibility for organizational success or failure, following tried-and-true procedures is important. Doing things "the right way"—strictly according to defined processes—can be critical.
But as the industry trends toward DevOps—where IT is increasingly responsible for generating new business value, not just keeping those proverbial lights on—it's becoming increasingly important for IT organizations to reexamine their approach to stakeholder and change management if they want to keep up. Doing things right now has to be balanced not only with doing things fast , but also with doing the right things—whatever the right things may be as the organization moves forward.
So it's time for some serious reflection: Is your group more focused on doing things right for the sake of process and consistency, doing things fast to meet arbitrary deadlines, or on doing the right thing for the customer? And what's the right balance of each of those things for you?
Defining your 'why'
At a recent conference, where I was talking about some of the positive effects of scaled agile methodology on cross-team relationships and collaboration, someone asked me how to convince others to pay more attention to doing the right thing and less attention on the processes that defined how to do things right. He told me his team had upset others in the company by experimenting with aspects of agile methodology and starting to talk directly to their customers—that is, they released more frequently (doing things fast) and used feedback loops to iterate on the product so they could deliver what the customer wanted more quickly (doing the right thing). The rest of the company, he said, was more concerned about filling out forms than on delivering what the customer wanted when they wanted it (doing things right). The company had expressed no interest in changing that process, and leadership felt this team's speed was making the rest of the company look bad. The agile team, on the other hand, grew increasingly frustrated by processes that seemed to be in place for the sake of process.
I'm sure there's another side to this story, where someone has a good reason for every form and process. But this story made me think of the message Simon Sinek shares in his 2011 book, Start With Why: Before concentrating on what you do and how you do it, you should figure out why you're doing it in the first place. What's your goal? What's your purpose? The how and the what will fall into place as soon as you define your why.
In this example are two competing goals. The majority of the company is "doing things right" because that's the way they've always done it, and they'll achieve consistency, stability (less risk), and conservation of the top-down hierarchy. Becoming more agile and focusing on "doing the right thing"—even if it runs against those entrenched processes—might introduce risk and shake up the status quo, but the results include improving development efficiency and delighting the client.
Which do you think will lead to increased business and customer loyalty? Which defines why the company is in business and inspires people? (Hint: It's not filling out forms.)
Leading by example
Once you define your why, figuring out how to do the right thing for your customers becomes easier. In our example here, the group focused on delighting the client has the right idea. Building brand loyalty and market mindshare are difficult if you're not willing to take some risks and be open to doing things differently. The world is moving too fast for us to spend months planning and years implementing; no one is going to wait for us. We have to iterate quickly and be prepared to change directions a few times along the way if we can hope to continually deliver what our customers want when they want it.
I would encourage the frustrated team in this scenario to document the business value they've seen as a result of implementing an agile methodology (increased revenue is a great motivator for everyone's boss's boss's boss). They can connect what they're doing to that overall reason why the company is in business. They could perform a retrospective to identify exactly which processes slowed them down or made delivering what the customer wanted more difficult, then work with other departments to find ways of streamlining the path to delivery. Or, if all that fails, they could try to reduce their dependencies on other teams to minimize the disruption.
Change can be uncomfortable. It can take a long time. But oftentimes, small teams like these can make the biggest impacts, leading by example. As the team learns more about why certain processes are in place and how to work more efficiently with the procedures they have to follow, hopefully, the rest of the organization will begin to see the value of focusing on doing the right thing rather than just doing things right. And as the organization begins to identify which processes are necessary and which can be changed to leave room for more flexibility, both the customer and the organization win.
This article is part of The Open Organization Guide to IT culture change.
Comments are closed.