The great paradox of success is that as enterprises get bigger and more established, they have a natural tendency to lose the very entrepreneurial edge that made them successful in the first place. It’s a tendency that leaders in large companies must fight hard against if we want to keep delivering innovation and growth. The best weapon in our arsenal? Autonomy.
The more an enterprise grows, the more bureaucracy it needs. This isn’t a bad thing. Well-run bureaucracies are essential to creating an employment environment that is safe, productive and efficient. The key is to make sure that many layers of leadership don’t make employees feel powerless to effect real change.
My team at Comcast develops and builds the technology that powers our entertainment experiences, and the software that supports all of our products. As a company we’ve evolved to a point where we’re doing new software releases virtually every day, and sometimes multiple times a day. Suffice to say that none of that works without a big team of motivated, entrepreneurial technologists.
Keeping that innovation engine running requires a lot of things – great people, flexible technology platforms and engaged leaders, to name a few – but the secret ingredient that keeps everything moving at a speed typically associated with much smaller startups is autonomy.
My key focus is on building a culture where we push autonomy all the way down to the individual and team level. When an engineer or a small team of engineers come up with an idea, my job is to remove the institutional inertia that keeps them from making that idea a reality.
One enormous benefit in that process is our commitment to DevOps software development. In many ways, the principles that DevOps applies to software development – end-to-end ownership, accountability and continuous delivery – are the same principles we seek to apply to all of our people, regardless of whether they are building software.
Because we hire DevOps developers, we are tapping into a talent pool that’s already used to the pace and autonomy that we’re looking to encourage, and because our engineering teams are set up according to DevOps principles, much of that autonomy is already baked into the system.
Celebrating failure
Another critical component to creating dynamic, autonomous teams, is learning to gracefully navigate failure. As a leader, you can say “autonomy” until you’re blue in the face, but if people on your team feel like they get punished when they try something new and fail, those words will ring hollow, and could do more harm than good.
If our teams aren’t failing occasionally, they aren’t taking enough risks, and if they aren’t taking enough risks – and don’t feel empowered to do so – they will never deliver the kind of powerful life-changing products and experiences we need to deliver to customers. Of course, as leaders we need to help manage risk, by helping our teams make smart bets, but we also have to be OK when some of those bets don’t pan out.
One tactic we use in our scrums is a “failure board.” Team members are encouraged and celebrated for noting on a whiteboard what didn’t work, and more importantly, what they learned. We’re not celebrating the failure, but rather celebrating what we learned from it, and how quickly we were able to correct our course. And by making it a shared experience, team members internalize the idea that failure isn’t something to fear, but a tool for growth.
Recognizing success
The obvious companion to navigating failure is recognizing success. If you’ve done your job as a leader and attracted bright, entrepreneurial people to come work with you, the real work has only just begun. Bright, entrepreneurial people need to feel like their work matters, and that the tremendous effort that they put into their jobs is appreciated and valued.
Obviously, a big part of that just comes from making sure teams have great challenges to work on, and the autonomy to develop their own approaches and solutions. But in a world where we push autonomy down to the individual and team level, you also need to take steps to push recognition and acknowledgement down to that level as well.
We do this internally of course, with a number of tools and tactics to call out the accomplishments of teams and individuals when they deliver big wins, but I think it’s important that such recognition not just be internal. We want our entrepreneurial employees to build their brands and get public recognition for their innovation.
This can be as simple as putting forth engineers who worked on projects for media interviews and blogs about new products and features, rather than having leaders take all the credit. We also have a tech blog where we encourage technologists to post. And another great tool we have is an active speaking program that encourages employees to share their work at conferences and meetups where they can gain recognition from their broader technical community.
If there’s one thing that’s become clear to me in a career that’s spanned startups and large enterprises alike it’s that entrepreneurship can thrive anywhere, so long as there are leaders and teams with the will – and a plan – to make it happen.
