Project Leadership and Collaboration
I’ve been recently discussing creating effective teams as Engineering Managers (EMs) and wanted to touch on an important principle: Collaboration. And how current project leadership practices make collaborating in software teams more challenging.
Collaboration is key to creating an effective team. The reason for a team to exist is the belief that a group of individuals will deliver better results than the sum of their individuals. Therefore, we need to find ways for a group of engineers to deliver value consistently.
A significant part of that question is answered by how companies organize their project and how engineers work together during execution. In many companies today, this is heavily influenced by project leads.
The project leadership challenge
As with anything in our industry, organizing projects has evolved significantly throughout time. It is currently owned mainly by individual contributors that hold the position of project leads (it’s the big tech way). There is a great deep dive on why we got to this practice here, which highlights a few points that are important to remember:
- Imposing heavyweight processes in teams is usually counterproductive. Teams need to be able to have the agility to operate.
- Team autonomy is key to success. Both in product direction and process definition, the benefits of adapting to the current challenge easily outweigh the cost of duplication that is inevitably incurred.
- Engineering should lead the execution of projects. EMs and engineers have more context on the day-to-day challenges to decide how to work more effectively.
- Teams and projects should focus on business impact. While it’s sometimes inevitable, introducing indirection will increase inefficiency every time.
However, one crucial aspect missing is how excessive delegation of work management creates more siloed and less efficient teams. Engineers leading projects are now de facto project managers, which is a real problem.
Effective collaboration is not simple to achieve
The common anti-pattern is an individual contributor engineer solely responsible for project management. In some cases, they are not only responsible for managing the project but also for finding a need, getting buy-in for the initiative, and then leading execution.
This pattern is usually justified by the goal of freedom and individual impact. The belief is that engineers should manage themselves and find their path to prove their value to the business.
However, finding effective ways for a group of people to work should not be a side-hustle. While empowerment and incentivizing leadership are admirable goals, in practice, the result is:
- Work management is improvised and ineffective, which seems expected since we are asking people without experience to do it and not providing any training.
- Teams become more susceptible to informal authority and power dynamics. Engineers with more influence decide which projects to run and how their projects should work, which impacts not only them but others in the team as well.
- Engineers have less time to focus on engineering. So how do you find time for deep technical work when you manage projects and end up in a manager’s schedule?
Ultimately, it harms collaboration.
In reality, good teamwork is not always free or pleasant. For example, anyone who has done pairing for a few hours can tell you how energy-consuming and sometimes uncomfortable it is. But, at the same time, it is a very effective way to reduce bottlenecks and share knowledge within a group. Similarly, being particular about acceptance criteria in your cards is time-consuming and tedious, but also the best way to avoid engineers entangled in scope creep.
There is a better path
Fortunately, there are plenty of ways to create a productive system — where engineers have opportunities to lead others and grow with support. And where teams can iterate and become more effective as a group as they keep working together.
In practice, engineering managers should lead the conversation on how their team works, aiming to create a productive system for everyone. And while execution of that system can be delegated, it should be done consciously not to remove engineers’ focus from technical work. This can be illustrated by a simple version of the now typical collaboration diagram.
Here are some principles that a manager can apply to create a healthy collaboration environment in their team:
- Understand and create an open process for execution in your team, focused on the work, not the people.
- Provide support to engineers leading projects. While delegation is possible and wortwhile, project leads should focus their time on technical leadership instead of team organization and task management. If delegation is the preferred approach, create frameworks and tools to make it less time-consuming.
- Actively reduce the possibility of individual work. For example, reduce the number of projects in flight and incentivize engineers to collaborate instead of work alone.
- Have a process to determine how leadership is assigned to projects, making it clear to everyone how to get that opportunity.
- While having engineers discover project opportunities is healthy, it should not be the only path to leadership. Some individuals won’t excel at it and should be provided a way to leadership focused on their technical leadership skills and not only business acumen.
These high-level principles must be adapted to specific situations but should lead to a more productive environment, where engineers can lead and still be engineers, not project managers. Ultimately, a more effective group of people.
If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.
