All companies have one thing in common: they’re going through a large amount of change.
Part of my role at Atlassian involves me traveling around the world and not only doing talks at conferences, but actually meeting our customers at their offices to learn about the challenges they face. I see organizations of all shapes and sizes (but especially the older, larger ones) having to reinvent themselves and find new ways of working in order to stay relevant. There’s increased competition. There’s disruption in every industry. Customers want more innovation, faster. And employees want the freedom to dig in and make it happen.
As I’ve listened to customers explain what will make the difference between success and failure for them, some common themes have emerged. They’ll sound familiar to you because they’re all popular buzzwords.
I hate every one of these words. They kill a small piece of me every time I hear them. What’s more, they’re silently killing your ability to innovate and thrive in the long term.
“Growth” is not the same as “scaling”
The word “scaling” gets used an awful lot, but mostly what I see organizations do is grow. They get bigger, but bigger doesn’t necessarily make you better. More likely, you’re just adding more people to the same problems. When you’re focused on adding those people, you’re distracted from the hard work of uncovering the root of the problem and solving it.
An org that is truly scaling, however, is becoming more effective as it gets bigger. The difference is purpose. When you know why you’re doing what you’re doing, you make better choices about allocating resources and saying “yes” vs. saying “no”. Scaling enables you to stop doing one thing so you can start doing something new.
A great example comes from a customer I visited last year. Their IT help desk team stayed the same size while the organization around them doubled. No joke. They did that by analyzing the tickets coming through, finding patterns, then educating people to solve the most common problems on their own through knowledge bases, brownbag lunches, etc.
Scaling enables you to stop doing one thing so you can start doing something else.
Now, that’s all very forward-thinking. But the best part is that when I met the people on that team, they all had big beaming smiles on their faces. Why? Because their work was changing every single day. They were taking away the mundane aspects of their role and using that time to grow new skills.
“Transformation” is not the same as “evolution”
Virtually every organization I speak with is going through some type of digital, cultural, or agile transformation. I appreciate that. I don’t necessarily think it’s a bad idea. But here’s the thing: in the majority of cases, they’re going through a transformation because they’ve been caught with their trousers down.
They’ve relied on heritage, history, and old ways of operating. They’ve enjoyed big margins in their business, and it wasn’t until someone came along and did it better that they reacted. The reaction is, “Shit. We’re far behind where our customers expect us to be. We need to transform.” And they’re right! But they can’t treat the transformation like a project with a defined end date when they wipe their hands and go “Right. Glad that’s all sorted.”
That’s because the transformation is never really complete – kind of like how learning is something we do our whole lives. In the context of a business, you move from the (really hard, really big) initial phase to a model of agility. This is different to “Agile with a capital A”. Agility is about adapting to your customers’ and employees’ needs.
At a minimum, we need to unlearn what I call the Agile Compliance Regime™. It’s where a senior executive decides that agile is the latest thing because they’ve read a bit about it or heard a podcast and insist that everyone does it. When I ask the teams whether they’re getting value out of their standups and retrospectives and planning poker, they’re like “No. But we’re very compliant.”
Contrast that with companies that give their teams the autonomy to make as many of the decisions about their work as possible. The fewer outside approvals they need, the faster they can respond to changes in the marketplace and act on their ideas. Plus, they’re able to change how they work. Their agility actually removes the need for “transformation” because they’re evolving every day.
“Disrupting” is not the same as “disrupted”
I have a binary view on this that might be right or might be wrong, but just roll with me: if you’re not the disruptor, you’re being disrupted. The incumbents in any industry really struggle with this. They know all the industry norms, but often don’t realize when those norms change.
Take Blockbuster Video. You’ve heard how they laughed Netflix out of the room when Netflix offered to be acquired for $50 million. (Oops.) But did you know Blockbuster was actually developing their own streaming service at the time? Thing is, streaming videos means no late fees. And they’d been collecting around $800 million per year in late fees. Who can say no to that much free money? So they killed the project. (Double oops.)
If you’re the disruptor, either you’re the disruptor because you’re the brand new cool-kids company on the block, or you’re one of the small minority of enterprises that are genuinely reinventing themselves. ANZ Bank is a great example of disrupting yourself from within. They’ve given their teams the freedom to change the way they work, and as a result, they’re more effective and more satisfied than before.
“Tenure” is not the same as “initiative”
Many organizations look to their most senior people when they’re going through change, the people with the most amount of experience. They want to pay homage to that. But if you’ve got 50 years’ experience and you’re operating today the same way you did 50 years ago, well… Heritage and history can be good launch pads, but you need to achieve lift-off at some point, or you’ll find yourself wandering the halls talking about how good things used to be.
Initiative is about listening to the people with the smartest ideas wherever they are in the organization and letting them rise. It’s based on smarts, curiosity, and creativity. It has nothing to do with tenure. The thing I love about entry-level employees is they don’t know what they don’t know. They break down walls because they can’t see them yet. The last thing you should do is hire a smart person, then kill their mojo by sitting them down and explaining “That’s just not the way we do things here.” Your job as a leader is to nurture, amplify, and protect those ideas as they evolve.
One of the best pieces of advice I ever got came from Dan Pink: “Argue like you’re right, but listen like you’re wrong.” I found this very confronting. It’s so completely obvious, for one thing. But it also made me realize I’d not been listening well. I’d been hearing others disagree with me, but then reinterpreting their words in my head until it sounded like we were aligned – and doing both them and myself a massive disservice.
Listening like you’re wrong means saying, “I might be right, but if I keep listening with an open mind, I have a chance to benefit from the different ways of thinking and make my idea even better.” Having come to Atlassian from a company where collaboration meant agreeing to bad ideas for political reasons, it took me a while to get used to this. What I eventually realized is that people aren’t trying to shoot down my ideas when they give me feedback. They’re trying to improve them.
Good ideas can come from anywhere, so you need to be listening everywhere. That means leaving your ego at the door. Even “your” ideas aren’t really yours, per se. They’re just ideas, which will be improved upon by your collaborators – but only if you listen with an open mind.
“Outputs” are not the same as “outcomes”
We are addicted to outputs. They’re tangible. They’re instantly gratifying. On Friday when our partner/friend/dog asks us how the week went, we’re like “Busy. I’m in a guild and a tribe and a cohort. I’m on a steering committee and a program and I’m looking after some big bets. So, I’m really busy.” But were you effective? (The answer is “I don’t know… just busy, mainly.”)
Outcomes are what happens when you’ve actually had an impact. A few years ago, Atlassian switched from using KPIs to a goal-setting framework called OKRs. For the uninitiated, that stands for “objectives and key results”. Instead of prescribing yourself a list of tasks to complete (i.e., outputs) you articulate your goal in terms of the outcome you want to achieve. As you work toward it, you learn and course-correct. It’s the essence of agility.
We learned there was no such thing as “business as usual” or “keeping the lights on”. That was just our way of getting slow and complacent. So now, we challenge all of ourselves to work toward ambitious and innovative ideas – and evolve along the way.
Efficiency is ok… but effectiveness is better
If you go through any airport lounge, most management books still talk about efficiency. But that just means doing the same thing faster. What we need is to be more effective. Now, the smart people know that you need both in order to bring fresh ideas to life. But most organizations are heavily indexed on efficiency. So my suggestion is to swing the pendulum hard over to effectiveness because the natural tendencies of your organization will swing it back.
This is the point where you might think you’ll need to hire a Head of Evolution to help you get there. But it’s not someone else’s job. It’s your job. You are a role model for those around you.
If you want to do the right things around initiative, outcomes, having an organization and team that evolves every single day, the challenge is very simple. You have to lead by example. You have to adapt. You have to create an environment where everyone gets to share their ideas. You have to demonstrate a willingness to be wrong and be ok with the fact you were wrong.
These are the changes you can make that will drive innovation – not only for your teams, but for your customers.
Get stories like this in your inbox
Special thanks to Sarah Goff-Dupont for her contribution to this article.