Imagine a team so motivated that they take on challenges without being asked—solving complex problems creatively and efficiently.
Imagine leaders who foster this level of autonomy, trusting their teams to take ownership.
This is the true power of self-organizing teams, and it can lead to incredible results.
Let me share with you two real tales that demonstrate how autonomy and trust can achieve the impossible.
One of the cornerstones of biology is the Latin phrase: “Omne vivum ex vivo”—all life comes from life, a rebuttal to the concept of spontaneous generation. Here’s proof that hyper-productivity in development doesn’t strictly adhere to cellular biology, but instead stems from something much more profound—something I have witnessed repeatedly in exceptional Agile teams.
Last week, a Scrum Master I mentor approached me, concerned. He was worried that his team was becoming increasingly autonomous—organizing and operating on its own. He acknowledged that Agile theory supports team autonomy, but then he said, “But Haim, be serious, you and your Agile methods… there’s no way we can manage development like this in the company!”
“Excellent!” I told him, “Agile and I are overjoyed. You are incredibly lucky. You might not realize it, but fostering true team autonomy is one of the hardest things to achieve. It can take months, years, and sometimes… it just never happens at all. So celebrate it—enjoy it!”
Still, I could sense his lingering concern. So I told him these two compelling stories about teams that self-organized for the benefit of the company.
Eric Schmidt, former Chairman and CEO of Google, shares that when they first launched AdWords, Larry Page, co-founder of Google, conducted a search for “Kawasaki H1B.” Unfortunately, the search results returned numerous ads for lawyers offering immigration services to secure the H1-B visa, completely unrelated to the motorcycle Larry was searching for. Larry continued with another search, this time for “cave paintings,” and again received irrelevant results—ads from galleries selling paintings, with no connection to caves.
These results worried Larry. If searches did not return accurate results, AdWords ads would receive fewer clicks.
A traditional manager would have convened an emergency executive meeting, assigned a task force to analyze the problem, and set up a special team to work tirelessly until the issue was resolved.
But what did Larry do?
Larry printed out the search result pages, marked the poor results with arrows, and wrote: “This is a bad result.” He then hung these pages in the office kitchen.
Three days later, Larry received an email from five developers—not even part of the AdWords development team—who saw the pages, understood the problem, and attached their analysis of the bug and suggestions for a solution. Larry decided to implement their suggestion, which continues to influence Google search results to this day.
What happened here? A group of talented people, connected to each other and aligned with the company’s interests, took it upon themselves to solve a problem. No one explicitly asked them, no one demanded it, criticized, or managed them. They saw a need, they saw a challenge, and in a fully autonomous way, they solved the problem as quickly and effectively as possible. Incredible!
Think this can only happen at Google? Well, think again…
The same happened to me at Elbit Systems in the previous century. I was a young and promising team leader. Even then, I resisted any form of authority, so naturally, I led my team in a non-traditional way, instinctively striving to build a responsible, autonomous, self-organizing team.
One day, I received a frantic call from the head manager, informing me that we needed to translate the core code of a classified system from PL/I to C. I knew it was going to be a huge challenge given the time constraints—we would need to plan the project, create the design, validate the new architecture, code, and test the entire system. In essence, it looked like two years’ worth of work. And we had just a few months for the release.
So, what did we do?
During our break (Happy Hour), I simply presented the challenge to my team: “Obviously, we can’t do this in the conventional way, but I know you and your capabilities, and I know that this challenge will push you to find creative solutions.”
I conveyed this message on a Thursday afternoon. After a long weekend, on Monday, two of my team members, Sharon and Oren, came to me. Oren said, “We have good news and bad news. The good news is that over the weekend, we thought of a solution for translating the code from PL/I to C and wrote software to translate the code automatically. The bad news is that it only achieves 80% accuracy, and we’ll need to translate the rest manually!”
“Fantastic!” I told them. “I’d love to see the code you developed!”
I didn’t demand deadlines, I didn’t assign tasks, nor did I dictate how to do it. Just responsible, challenged people who rolled up their sleeves, dedicated their time, and came up with a quick and effective solution. The project was completed successfully, well ahead of schedule.
A year later, I moved to another group where I found out they had faced a similar challenge—translating code from PL/I to C. They outsourced the translation to a company in the United States, which contractually promised to deliver the translated code in six months. Two years later, the code still wouldn’t compile!
So tell me, dear Leader, is having a responsible, self-organizing, autonomous team a good or a bad thing?
