Shape Up, Project Leadership and Project Roles
It is one of the articles in the Shape Up series. For Table of Contents go to: Shape Up, Introduction
There is no definition of the project roles within’ Shape Up book - everyone is a team member. What’s happening in the world is that most people follow the book and do not add additional elements.
I encourage you to add Project Roles to your implementation of Shape Up.
By roles, I do not mean the specializations like Backend Developer, Frontend Developer, or UX Designer. When I say roles, I mean project length-long responsibility assigned to the team member to help the team be successful.
Leadership modes
Let’s discuss the topic based on the leadership model within the Shape Up project. Leadership might be organized in four different ways:
- No one is a leader
- Everyone is a leader
- Pitch Owner is a leader
- Choose the Project Lead
No one is a leader
For me, this is an anti-pattern, but this is the default approach of the newly founded Shape Up teams.
When our team works with no plan, we will continue pushing our little parts of the job forward and eventually believe that these parts will work together after integrating at some point.
Most likely, no one will take care of uncertainties and risks, looking at the big picture. Focus on end-user value will go away, and every single part will get prioritized separately over the shared success.
An alternative to this approach is to grant leadership to all people explicitly.
Everyone’s a leader
What’s the difference between this and the previous approach? Just in saying it out loud - you are all accountable for the successful delivery of the project.
When we assume everyone’s a leader, we believe everyone will be proactive enough to volunteer to take care of all unmanaged aspects of the project, or all people collaboratively will be able to manage it together.
The approach is brilliant, but it requires lots of experience from the team members to raise this highest level of flat leadership structure while still sharing all accountabilities and not skipping one.
To make this leadership mode successful, first, you need to define what it means to be a leader, then help them learn to do it and finally, you’ll have this spread leadership mode.
The most important thing is to find your way to deal with the areas that no one is volunteering to lead. This problem is usually solved by grouping leadership areas, writing them down and making them visible on the single screen, assuring all areas are covered.
Just remember… it requires a lot of training and maturity to make this leadership mode very successful.
Pitch owner is the leader
Another strategy is to give a Pitch Owner the accountability of project leadership.
A single person is our primary source of knowledge of the problems which must be solved by delivering on the pitch. In parallel, this person is responsible for making the project delivery successful.
This approach is similar to making one person a Product Owner and Scrum Master simultaneously in a Scrum environment. There’ll be times when both decisions will be correct. One will push toward the business value and the other towards technical excellence, people safety or growth. It is possible to manage it for a single person, but it requires a lot of maturity and calm to find the right balance.
Often this person will feel caught between a rock and a hard place. Usually, having a counterpart to the Pitch Owner would be a better option.
Choose the Project Lead
My favourite approach.
During the kickoff, we ask one person to become a Project Lead for the project length. Usually, this is an engineer, but it might also be a designer, researcher, actually anyone.
The Project Lead is a counterpart for the discussions for the Pitch Owner. This is the setup that I find the most effective and the easiest to implement.
This approach perfectly matches the cultural approach for building a company where everyone might be a leader. As this is a project-length role, various team members will volunteer for it in the following projects. It creates a safe environment to grow new leaders, which your team members will like. Project length-long commitment is much easier to make than changing the job title.
Project Lead becomes accountable for the delivery of the whole project. It is their job to delegate all the responsibilities and manage the not delegated ones.
If you are an Engineering Manager, your job is to support Project Leads along the way.
What’s the job of a Project Lead?
In short, it is making sure that all pieces work together.
I may point to a few basic aspects like making sure the team is aligned, a scope if not forgotten, risks are visible, questions do not remain unanswered, the team thinks about releasing the project early enough and not on the last day of the project, the team focuses on the project delivery instead of single-task-delivery.
However, I recommend you perform the Impact Mapping exercise with the goal of “Being the best Project Lead” and then find the areas which impact the Project Lead and which are being impacted by the Project Lead in your context. This exercise will make your team aligned on the understanding of this role.
After clarifying it, you are ready to start using this role in Shape Up. When to assign the role? Do you remember two questions we had during the kickoff?
- What’s your role in the team, and what can you bring?
- What kind of project leadership do we use in this project?.
What are the other roles?
Depending on the complexity, size of your organization/team, the roles may differ. You need to find the right balance and explicitly name the roles to give the team total confidence on the kickoff on who will take care of which aspects.
Let me give you a few random examples:
- Decision Log Hero
- External Blockers & Dependencies Synchronizer
- Docs & Meeting Notes Keeper
- Deployment & Release Strategist
- API Contracts Architect
- Domain Architect
- Credit Card Holder
- Keep The Lights On Engineer
Then the job of a person with a role is not to do everything with their own hands. Their job is to make sure that something happens. In the terminology of RACI, this person is Accountable for something, not necessarily Responsible.
Some examples above might sound like an anti-pattern, but at many points in a team’s lifetime, it is simply more practical to delegate 1 person to take care of something than assuming that our ways of working are mature enough to make these areas tidy magically.
Let me give you one more extreme example if you work in a startup with no UX Designers. How about asking 1 engineer to take the role of “Seeing the new feature from the user’s perspective”?
What’s next?
Suppose a project is not trivial. The time for project planning may come.