Getting The Team Into The Narrative

So far we’ve talked about the importance of stories in the context of business, how we can understand the story the business tells about itself (and to itself), how we verify our understanding using the company’s mission statement, and how we can offer technology capabilities that advance the narrative and give companies the outcomes they desire.

Unfortunately, all too often in companies large and small this kind of thinking and understanding is confined to the senior leaders within the technology organization (or even just to the CIO or CTO). But if we allow this to happen, we are short-changing ourselves and the business. Teams who grasp the plot of the story can help drive it.

Every person on the team should be able to tell the story of the company, and explain their role in the story. Here’s an example of why this is important: In the past I was brought in to revitalize the commercial technology organization for a power company that had just emerged from bankruptcy. One of the things I found when I got there was that the infrastructure team did not have a particularly strong sense of how their day to day jobs impacted the lives of people in the real world. As a result, systems (or the network) would sometimes be taken down for maintenance with little or no notice.

Why does system reliability matter when you work at a power company? Because the systems control the power plants, and if they go down, power isn’t generated. If that happens, people, especially vulnerable people, are at risk. To get the team to understand that viscerally, I had to ask them some questions.

For example:

“Who here has grandparents living in or near Dallas?”

(several people said they did)

“Well, if we drop the network without enough planning and notice, we leave our north Texas power plants without the connectivity which means they cannot know how much power to generate. This means that we might cause local outages that cause people to lose air conditioning during this, the hottest part of the summer. Now think about your grandparents sitting at home in that heat. And next time, let’s plan this maintenance window more thoroughly.”

Heavy handed? Sure. But it worked. The team understood: uptime for the systems and network meant keeping people safe. Unplanned and poorly planned outages stopped, and the team had a much better sense of who they were ultimately serving.

This is what I meant at the start of the series when I talked about developing a commercial sense. Getting the team to understand that what they do has an effect out in the world is important. Our business may not be a part of the nation’s critical infrastructure, but the principle is the same: the team needs to understand why what they are doing matters. And that means they need to know what the company is trying to do, and how they fit in.

How would this look on, say, a software development team in our organization? It would mean that a developer on the team could say something like, “I am working on streamlining the order process in our mobile app so that our customers can place orders with us in less than 30 seconds on average. This will mean an increase in sales volume due to convenience, which will help us hit our annual sales plan.”

That’s a lot of context for a developer to have, and is pretty uncommon in large organizations. But this kind of knowledge will pay off, as the developers will be able to make better decisions and design solutions that better meet the needs of the business.

Ultimately, if we get teams on board in this way and develop that commercial sense and commitment within our organization, we will be well on our way to blurring the lines between our technology organization and the business, and will be seen as a competitive advantage rather than simply a necessary evil.

And that’s a win for the entire organization.