Last updated on March 20th, 2018 at 10:13 pm
A practical guide to managing agile teams
I’m thrilled to publish my book Lateral Leadership for Product Managers with Sense and Response Press. The book will be available in print, digital, and audio form in the first half of 2018. It’s aimed at product managers who have to lead teams even when that’s not their job title, specialists who must work with others outside their domain, and department managers who are faced with agile transformation at their companies.
Learn about why lateral leadership is a key discipline for product managers working in modern organizations.
Why is Lateral Leadership so important?
Agile requires a radically different approach to leadership, one that puts business, design, and engineering at equal levels-where they must work as peers.
This situation creates a challenge for team leaders. Agile leadership requires teams to align with a committed vision and support it in the best possible way. And even though agile leaders lack the expert knowledge of their new peers, they have to succeed with their mission without the traditional safety net of hierarchical power.
This sort of change is the result of agile methodologies spreading beyond the product and technology context. As individuals and departments adopt the benefits and underlying principles of agile methods, this, in turn, gives rise to entirely agile organizations.
Leading teams within these organizations without traditional hierarchical systems is called lateral leadership. It’s the most impactful way of leading agile teams and will become crucial to success in future business environments and ways of working.
Why Product Managers need to embrace Lateral Leadership
To understand why product managers are lateral leaders instead of hierarchical leaders, I want to emphasize how companies around product managers are usually structured:
What you see here, is the result of a so-called ‘matrix organization.’ Even though (SCRUM) teams are intended to work as a unit by itself, the team members taking care of engineering and design are most often only ‘led’ by the product owner within the construct of a development team.
Every team member has other people managers who are overseeing the respective departments across multiple development teams and sometimes even business units.
What that means is that your team needs to accept you as the one who defined what is done, but someone else is responsible for the how.
And that’s where the point of lateral leadership comes in. While the heads of department have managerial tools to lead people (even though that should be the exception), you have to convince your team members to follow you without administrative ‘superpowers.’
Quite the contrary, key factors for achieving lateral leadership are furthermore things like:
- Strong and explicit communication
- A clear vision
There’s an excellent book by Daniel Pink called ‘To sell is Human.’ In it, Pink even refers to this skill as the ability to “move” people from one mindset to another.
Successful product people need to spend time and effort on these ‘moving’ activities, bringing everyone together around a shared understanding of the customer or business problem. So that ultimately, everyone can be involved in helping solve it to further the business goals.
Sounds familiar? Good, then you recognized the pattern of alignment. Closing the loop on the fundamental challenge the product owner faced, a likely reason for a development team not accepting a task is the lack of context. More precisely the meaning around why this task matters in the grander scheme of things and how it’s execution moves the needle.
What to do when Lateral Leadership tools fail?
Of course, alignment and other lateral leadership techniques can only do so much. If everything fails, I recommend 1:1 discussions with the individual team members to get to the bottom of what’s causing the resistance.
Maybe you get a handle on individual factors (e.g., an unresolved conflict from a personal situation), or you just have to involve the respective heads of department for advice or even escalation.
For whom is this book?
The book is for individual contributors and managers in agile organizations alike.
For managers, it helps to deal with this challenge: They have a lateral org „below“ them working together in an agile way. How can one as a manager make them collaborate and lead each other while maintaining eye level hierarchy? Same applies to her day to day business during which she has to work with other managers who are on the same level as she is and she needs to make them follow her vision/idea/goals
For an individual contributor, it answers the following situation: “I‘m part of an agile org/environment in which everybody operates on eye level. How can I make my peers follow my goals and vision without hierarchical power (including the right moment to escalate and bring hierarchical power from
Managers into play).”