When you talk to 20-year-olds (I have one) you get a chance to see the world through a really different lens. If you apply this lens to the business you run, things get even more interesting. For example, how does a 20-year-old think about software? They expect it to be simple, easy, free, always on – and most importantly, “it should just work.” But here’s something even more interesting: if you ask them about games, the focus completely changes. Suddenly, they’re willing to pay (sometimes a lot) for quality software; and complexity and configurability become front-and-center concerns.
We face a very similar disconnect when it comes to the technology choices we make in our businesses: a disconnect between the complex realities of consumer technology use, and the insistence on specific solutions long familiar in business environments.
When we work with teams composed of people from multiple generations, we managers often find ourselves working to build effective bridges between different modes of thinking. It’s important for everyone on the team to use compatible tools – but should that stop more forward-thinking team members from using the solutions they know will work best?
If your most forward-thinking employees don’t feel empowered to make changes that’ll help them do their jobs better, they’ll lose their drive to stay agile and think creatively. To solve your industry’s challenges, your team members have to be empowered to create their own solutions.
Here’s how businesses often lose their flexibility around employee-driven solutions – along with some ideas about how to regain flexibility.
The real problem with approval chains
During the startup phase, employee-driven innovation is a given. All hands are on deck. Results are the only thing that matters; and any team member who can propose a solution – even if it’s only a stopgap one – will usually end up defining the protocol in the area they’ve helped sort out.
Somewhere along the road to midsize or enterprise level, though, that tight-knit, self-reliant team gives way to a culture of approval chains. In some circumstances, that’s a good thing, preventing individual team members from sidestepping or ignoring practices that have been put in place to protect the company as a whole.
But as we all know, approval chains create backlogs. At one of my previous jobs, every sentence in our marketing materials had to be reviewed by leadership – which meant we had to wait weeks for approval on our copy. This policy turned out to be a relic of the company’s early days, when the copy printed on a product box was impossible to fix or take back once it was shipped out. Thanks to lots of push-back from several junior team members who craved a more agile way of working, the leadership finally acknowledged how outdated this policy was, and replaced the review process with a set of key guidelines we had to follow – hugely speeding up our copywriting process.
The real problem, though, lies not with that specific approval chain, but with the underlying assumption that change can (and should) only be driven from the top down. When applied too broadly, this assumption creates delays and friction throughout an organization. Worse yet, it prevents faulty processes from being improved as long as they don’t inconvenience upper management. A new employee may have to wait three days for their company laptop – but as long as the new employee is the only one inconvenienced, that policy is unlikely to change.
And while this top-down model may have worked reasonably well in the past, it’s going to become increasingly impractical in the very near future.
Stop restricting; start managing
If your company hires new employees fresh out of college, you know they think about software in a completely different way than my generation typically does. Much as we work to stay on the cutting edge of technology, we grew up in a world where we’d drive to the software store, buy the “official” software for the job at hand, and install that software on each computer that needed it. That whole paradigm is alien to anyone under 20, who grew up with a fast-changing ecosystem of specialized services and apps, which they can download instantly to any device, then discard at a moment’s notice when better apps come along. Asking them not to use the latest, most versatile software at work – solely because we’re not familiar or comfortable with it – is like asking you not to use email. It sounds nonsensical, because they know full well what the right tool for the job is.
Quite a few IT departments have started to realize this and their solution is to move from restriction toward management. If everybody’s going to use Dropbox and Google Drive anyway, regardless of whether you try to steer them in the direction of the corporate tool-of-record, then you might as well make sure they use those tools consistently and securely. And by all indications, the future is only headed further in this direction. Today’s preferred tool is tomorrow’s relic – and the most helpful thing IT can do is keep up.
This attitude shift is tricky enough to manage internally, in terms of productivity – but it’s equally crucial to turn it outward, and make sure this attitude permeates all the experiences you give your customers. They know which tools and approaches work for them. Your job, from a user experience perspective, is to find out what those preferred tools are, and keep up with them. In a world where, say, Snapchat is your customers’ support platform of choice, it’ll no longer make sense to restrict access at the office – any more than you’d restrict your team’s email access today.
Of course, the big question is, how and where does that change begin?
It’s all too easy to avoid addressing labyrinthine approval processes, because doing so can feel like yelling at a brick wall. We see requirements like, “Fill out five versions of this. Talk to 12 people. Get at least six signatures,” and we think, “I’m never going to be able to solve that.” But I know from personal experience that these processes can change, if you speak up about the broader benefits. Instead of arguing, “This change would make this process better,” tell your team about specific improvements this change will achieve for the business.
I once worked for a company that used a grid system for approvals – you didn’t get a document approved until two other people’s stamps were on it. Then someone came up with a digital way to handle this process. But that idea was dead on arrival, because the person at the top of the pyramid kept forgetting to check his approval queue. Upper management agreed that the approval system needed to change, because they saw that nothing would ever get approved otherwise.
The purpose of departmental guidelines and best practices is to give people the ability to solve problems, and automate things themselves – even if their solutions won’t always be the ones you’re most comfortable with. That’s OK. The future isn’t going to be built by upper management, and it’s probably not going to be built by you. It’ll be built by the fresh young talent you empower to disrupt and fix outdated policies. Your job is to keep up.