Entrepreneurial Leadership

The Wikipedia article on Entrepreneurial Leadership defines the attributes of an entrepreneurial leader in this way:

The entrepreneurial leader will work within a formalized organizational structure, but use the approaches normally expected of an entrepreneur to identify opportunities to gain advantage. They also have the ability to then manage change to deliver that advantage. Key to this is the effective management of risk rather than the minimization of risk often sought within corporate environments. The entrepreneurial leader must have the ability to learn fast and within environments of ambiguity and change, while providing clarity and coherence for those around them.

Software development projects almost always require entrepreneurial leadership because, by nature, they are developing something new, involve significant degrees of risk and uncertainty, and must learn quickly within environments of ambiguity and change.

Peter Block, in The Empowered Manager, describes two different paths of leadership.

The Bureaucratic Path is characterized by:

  • Maintenance
  • Caution
  • Dependency

On the other hand, the Entrepreneurial Path requires:

  • Greatness
  • Courage
  • Autonomy

Let’s look at each of these three areas in more detail.

  • Greatness vs. Maintenance: Steve Jobs used the phrase “insanely great” to describe Apple products. By taking the path of greatness, a leader sets a high bar for his development team, as well as providing them with a strong sense of purpose. For more on this topic, see the Pagan Tuna post, “Thinking Differently about Perfectionism.”

  • Courage vs. Caution: Developing a new software product always involves some significant level of risk. A leader should certainly not be foolhardy, but neither should his goal be to avoid all risk, for in so doing he is not likely to achieve anything of lasting value.

  • Autonomy vs. Dependency: A software development team and its leader should be able to make most important decisions without constantly having to go back to a Program Management Office or a project Steering Committee for direction.

Note that for a leader to exercise these three traits – Greatness, Courage and Autonomy – he or she must be willing to engage meaningfully with the development team, and not just stay comfortably above the fray.

Morgan and Liker describe the leader’s role this way, in their book the book The Toyota Product Development System: Integrating People, Process and Technology:

Unfortunately, many modern-day engineering managers believe their role in an organization is to attend meetings, keep abreast of the latest organizational policies, make the tough decisions about the big problems in the company, and generally look upward and outward. The philosophy seems to be that a good manager is good at delegating, and good engineers should work autonomously.

In the United States, ‘nosing around’ is being a busy body. It is a form of micromanagement. An effective manager should delegate and then stay out of the engineer’s way. For a Toyota manager, this is abdicating responsibility. How can you consult and advise if you do not know what is going on? If you have no more information about what is going on across the organization than any other engineer, then what is your value?

Michael Lopp says something similar in his book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

The act of delegation is a slippery slope for managers. Yes, you want to figure out how not to be a bottleneck in your organization and, yes, you want to figure out how to scale, but you also want to continue to get your hands dirty. Members Only’s problem was he believed his job was purely strategic. Think big thoughts; delegate the results of those thoughts to minions. He was a pure delegator and he’d forgotten how to do real work.

Pure delegators are slowly becoming irrelevant to their organizations.

And, in his extensive article about Jony Ive in The New Yorker, Ian Parker makes this observation about Apple’s chief design officer:

Ive describes his role as lying between two extremes of design leadership: he is not the source of all creativity, nor does he merely assess the proposals of colleagues. The big ideas are often his, and he has an opinion about every detail.

For more on the topic of entrepreneurial leadership, see the Pagan Tuna post, “The Watery Ketchup Stops Here.”

Next: Build Great Teams