Effective Leaders Get Out Of Their Peoples Way
A good friend had been working for a startup company for about 6 months. He had been very excited about it initially. It involved robots, artificial intelligence, and some large scale computing problems. It was right up his alley. We’d gone out celebrating when he’d got the job, and he’d gushed about how cutting edge their technology was.
Now he was six months in and things were starting to lose their initial luster. The company had amassed an impressive amount of venture capital, and had poured it into developing their cutting edge product. Yet, despite having what my friend described as “some of the smartest people I have ever worked with” on their team, they had yet to ship a single unit. They had a demo scheduled for their first customer in six weeks and they were way behind.
I was out in my yard on a Saturday, cleaning up some leaves, when I got my friend’s text. He’d planned to come by for lunch and a relaxing afternoon walk around the neighborhood. We rarely see each other, so it was special.
“The CEO wants us to come in every Saturday for the next 6 weeks to finish the product. Starting today. Sorry, I have to miss lunch.”
I didn’t see my friend during any of the following 6 weeks. What I now know was happening was that the previous round of funding was running out fast. The next round depended on getting this first customer on board. Things were looking precarious, and so the CEO, having lead the team into this valley of despair, was putting all of the pressure and responsibility on the team to lead themselves out.
There followed some heroic but futile efforts from some of the smartest engineers in San Francisco to dead-lift an impossible product in an impossible time-frame for a CEO who was completely out of touch with both the customer and the team.
When I talked to my friend by phone on the final Saturday, he was at home. He was supposed to be at the office with the team.
“Screw it,” he said. “I called in sick. On Monday, I am giving my notice.”
I don’t blame him one bit. And he was neither the first nor the last to quit during that 6 week blitz. That was over a year ago. My friend is now happily self-employed as an independent technology consultant, and that startup company has since gone out of business.
Why are there so few good startup CEOs?
My friend’s story is hardly unique. In fact, it’s so common as to be almost cliché. A couple times a week, I talk to someone who tells me a startup CEO bad behavior story. I have begun to collect these anecdotes so I can include them as anti-patterns in my public talks. Heck, maybe it’ll become a book.
Startup CEOs seem to come in two flavors. There are former employees of other companies, usually either tech or salespeople. They are tired of working for someone else, so they strike out on their own. If they have any leadership skill at all, it’s usually because they held some management position in their last company. That helps them as a startup CEO exactly not at all.
And then there are the MBAs. Fresh out of business school, they come armed with marketing and finance knowledge. They can certainly run a P&L, but are often horrible managers. (To my friends who are MBAs, I don’t mean you guys of course!)
Neither of these two typical CEO flavors comes equipped inherently with the capability to lead other humans. Leadership is a discrete skill. It must be sought out through coaches, mentors, and advisors. It’s not something that one just “knows”, nor is it taught (at least not effectively) in business school. And it certainly doesn’t emanate organically from anyone’s middle management experience.
Talk Less, Listen More
For starters, leadership requires a great deal of empathy with your people. And to build empathy you need to learn how to listen effectively. Nearly every CEO horror story I have encountered over the years has started with a CEO who doesn’t really know how to listen.
In his seminal work, “Seven Habits of Highly Effective People”, Steven Covey elevated the importance of empathy as a core principle of leadership. Specifically, Habit 5: “Seek first to understand, then to be understood,” clearly lays out a case for why leaders must be prepared to ask the right questions, and then really open their hearts and minds to the answers coming from their subordinates. Far too many CEOs and managers still believe their job is to answer questions, rather than ask them.
Listening is a skill that can be learned. Many years ago, I participated in a 3-day training on conflict resolution. It had nothing to do with work; it was just something I was interested in. It turned out that much of conflict resolution emerges from a failure to genuinely listen to the other party. Listening is different from letting them talk while just thinking about what you’re going to say once they stop talking. You should be prepared to not know what you’re going to say in advance, and simply be open to hearing their point of view. If more CEOs had this skill, the world would already be a better place.
Empower Your People To Think, Not Just Do
Traditionally, leadership has been taught as a means of compelling people to do what they are told. The old definitions assume the leader has all the answers and makes all the decisions. The staff simply execute those decisions. In the stochastic environment of business, however, this type of leadership is becoming increasingly impossible — if it was even ever desirable or effective in the first place.
As he relates the story in “Turn the Ship Around”, nuclear submarine Capt. David Marquet developed a very counterintuitive leadership method when he was forced to adapt to a new situation in which he had little control or advanced knowledge. Assigned to an unfamiliar submarine at the last minute, with a crew that was struggling to perform, he had to toss out the traditional leadership method and try something new.
Through a series of experiments, Marquet and his leadership team were able to transform a ship full of under-performers into one of the best crews in the Navy. They managed to push authority and responsibility down the chain of command to where the work was being done. Teams were able to make their own decisions based on immediately available information in the field, and adjust to new conditions on the fly, without having to escalate every decision up to the Captain. As a result, ship operations were much more flexible and adaptive to changing environments.
In “Flow: Principles of Lean Product Development”, Don Reinertsen teaches us that there is a cost associated with every decision. Further, that cost can be increased dramatically by the delays incurred in escalating it up the chain of command. This is probably nowhere more clear than on a nuclear submarine. But it is just as true in startups or large corporations.
For example, consider Reinertsen’s principle D8: “The Principle of Mission: Specify the end state, its purpose, and the minimal possible constraints.” For decisions that have an urgency associated with them, there is a strong case to be made for letting the team on the ground make that decision. Reinertsen advocates giving product teams in particular, as much autonomy as possible in order to reduce the cost of delay associated with escalating key decisions.
Very few leaders that I have met, however, are mature enough to enable this principle. It requires letting go of control, trusting your people, and basically getting out of their way.
Compose Your Organization Out Of Small Autonomous Units
But in order for this type of trusting delegation to work, you have to structure your teams in such a way that they can move autonomously. And they have to have the tools and systems in place that support that autonomy. Without both of these in place, they’ll be mired in constraints that undermine their effectiveness.
In the newest book by “The Lean Startup” author Eric Ries, “The Startup Way,” he makes a suggestion that will seem quite radical to corporate managers: organize teams within large companies as if they were internal startups.
The rationale here is actually quite straight forward. Teams need the freedom to experiment quickly, and every constraint that requires them to check-in with management slows them down. Ries advocates creating structures within the organization that are akin to a venture model, including metered funding, a board with oversight responsibility, and regular cadences of reporting to them. But beyond that, the team is free to spend the allocated budget however they see fit.
Daniel Pink would likely agree with this approach. His book on motivation, “Drive”, is packed with case studies and research, many based on the work of psychologist Edward Deci, illustrating the importance of intrinsic motivation for high-performance and success in organizations. Pink’s emphasis on the three pillars of intrinsic motivation, Autonomy, Mastery, and Purpose, in providing the sustainable motivation for teams to execute in creative and uncertain domains strongly supports the notion that leaders should delegate, with clear mission and constraints, and then get out of the way.
But this idea of organizing teams as autonomous units has technical merit as well. Randy Shoup, VP of Engineering at StitchFix, is practically a fixture at technology conferences. In talks like the one I just watched last week, Shoup too urges us to compose large organizations from a set of small, autonomous teams.
Shoup references Conway’s Law, which readers of this space will remember from my other writing (I first learned it from him, by the way). Mel Conway’s theorem about systems, originally printed in the April 1968 edition of Datamation magazine, was coined “Conway’s Law” by the legendary Fred Brooks who cited it in his seminal engineering management book “Mythical Man-Month”.
Put simply, Conway’s Law reads as follows:
“Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”
Shoup reminds us that the leading technology giants like Amazon and Netflix have leveraged Conway’s Law by designing their teams and organization structure first to reflect the kind of technical architecture they want to produce for web-scale operations.
Structures To Support Autonomy
What Captain Marquet and his crew came up with, through trial and error, was truly revolutionary. But it cut against the grain of what most of the crew were used to. One of the ways this was achieved was through mechanisms, essentially protocols that helped to reinforce new behaviors. Mechanisms could be anything from the format of a form to a phrase uttered before an action. These mechanisms served as guides or reminders to help the team adopt the changes and make them into well-worn habits.
In digital product development, technology infrastructure and capabilities, such as continuous deployment, can serve as a set of mechanisms. Co-located, cross-functional, dedicated teams need the necessary technical infrastructure to rapidly prototype and run experiments in production. So what is required is a cooperation of technology (IT), organization (HR), and funding (Finance) to produce teams with the autonomy, mastery and purpose to innovate and execute effectively. But IT, HR, and Finance aren’t going to come around to this point of view on their own.
All of which points back to the leadership of the organization, and ultimately to the CEO. Companies and institutions that succeed in this increasingly dynamic economy will be those that are unafraid to abandon the tired and worn top-down management styles of the 20th century. They will be effective listeners who enable their people to self-organize, and support them with the right structures and tools for them to succeed.
Action Items
In conclusion, leaders should focus on the following steps:
Develop empathy with teams and individuals by listening and asking questions more than you give orders.
Enable your teams to be dedicated, cross-functional, and co-located, and give them autonomy, mastery, and purpose.
Develop technical, financial, and HR processes that help them to achieve an experiment-focused product development approach.
