Recently, the topic of Leadership without Authority came up time and again in my various conversations, so I thought to write about some thoughts and learnings in having these conversations.
I believe most people need to practice Leadership without Authority at some point in their professional and personal lives. Product managers is a good case in point, as they lead cross-functional teams to achieve product success (in most cases, these collaborators do not report to them). Generally, Leadership without Authority happens when we need to lead our peers or even those senior to us to achieve some shared goals. This may seem paradoxical; after all, many workplaces are organized by Report-To relations, so we naturally look at them when we think about the source of leadership. How could we lead someone without official authority over them bestowed upon us?
To answer this question, I look at the definition of “leadership”. This word means different things in different contexts: it could refer to a management team (“the company leadership”), a type of authority (“under someone’s leadership”), or the general action of leading (“leadership skills”). For the context of this discourse, I am using the last definition, and more specifically, I am referring to the action of helping a group of people finding directions.
In other words, for this article, to lead means to take on the task and responsibility of finding the direction the group should take — what tasks the group should take on, short or long term. Using this definition, two corollaries easily and immediately follow. First, leading (or direction-finding) is simply to one of the many tasks that a team needs to perform. Second, in this definition, leadership does not imply superiority or prestige.
Hopefully, this definition makes the idea of leadership without authority a lot more intuitive. Every team inherently has many functions, leadership (again, direction-finding) being one of them. Taking a software scrum team as an example: product managers are responsible for product direction and requirements; designers own the user experience; software engineers turn these requirements into code; quality assurance (QA) engineers ensures the final deliverable matches the original spec… In this context, the product manager may indeed “lead” the team in finding its direction — this can take on the form of product vision, product roadmap, creating and prioritizing product backlog, etc., all aimed at answering the question of “what to do”. Clearly, this type of leadership does not require the product manager to have official authority over the rest of the team.
But that is not to say this leadership can take place for free; the leader without authority (“LWA”) still has several principles to follow in order to make the team work effective and build trust in their leadership. After all, why should they follow your leadership? (This question probably also applies to leadership WITH authority… but that’s out of scope for this article.)
The first principle for building trust is to always be sure of the why and communicate it. Sure, the team will look to the LWA for directions, but they will also want to know why the LWA is leading them into any particular direction. The why needs to be an integral, inseparable part of the LWA’s work output. In other words, leadership without authority can be thought of as a kind of “research job”. The LWA can’t just pull directions and requirements out of thin air; they need to be the fruit of data gathering, analysis and deduction — just like a math problem solution is much more trustworthy when the work is shown, compared to a standalone numeric answer. For a product manager, this usually looks like using data-back insights, abundant communication of business needs, detailed explanation of how a product roadmap contributes to business success, or clearly defined criteria for prioritization.
Second, willingness to iterate (you could kinda also use the word “growth mindset” but that term often has a larger surface area). The circumstances that the team is navigating can be constantly changing and so must the team’s direction constantly adjust. When parameters change, it is the responsibility of the LWA to put in the effort of research and helping the team with the course-correction. Taking the product manager as example again, this could mean regular customer interviews and research, iterations on product features and requirements, recurring roadmap check-ins, etc.
Last but definitely not least, is practicing empathy. To generalize it more, I believe this is true for any teamwork: empathy is the oil that makes a team a well-oiled machine. Specific to LWAs, I believe empathy goes a long way in building trust because our ability to build alignment drastically increases when we seek to empathetically understand and communicate. As a product manager, I often remind myself to always make an effort to understand my teammates’ perspectives on our endeavor: are they unsure about our roadmap priorities? They may not speak of it, but it’s crucial to proactively communicate the prioritization criteria. Is it possible they don’t yet have the full picture of the value of a feature we’re developing? That possibility should be prevented from the get-go in the feature requirements document. Putting ourselves into other people’s shoes is a muscle that requires constant workout, but for leadership without authority, it is one of the best investments of our time.