Any Engineer in the team can lead a project. Any project should have a technical lead.
| Purpose | Empower team members |
|---|---|
| Situation | A stable team with a lot of responsibilities on manager(s), and team members eager to take ownership |
| Outcomes | - Reduced load on manager |
| - Increased ownership | |
| - Fast-track career growth | |
| Effort | Medium |
| Scope | Long-term |
Typically in many teams an Engineering Manager is responsible, among other things, for collecting technical requirements for initiatives, making high level technical decisions, documenting solutions, setting up communication within the team and with external stakeholders, addressing risks, etc.
While this approach creates rather comfortable conditions for engineers to focus on getting their tasks done, there is a problem: this model doesn't scale. And it doesn't scale in multiple ways:
- The higher the potential throughput of the team, the more the Engineering Manager becomes a bottle neck.
- Knowledge gets concentrated in one head which can be easily hit by a bus one day. Or may simply be unavailable when needed (e.g. vacation).
- Engineers tend to own tasks, not user experiences. Task done? Who cares what happens next. At least, until the next bug report.
- The Engineering Manager becomes better at leading projects, while other team members don't have this opportunity.
The Project Tech Leads technique addresses these problems by empowering all Engineers in the team to take leadership responsibilities. Thus the benefits be:
- Engineering Manager is not a bottle neck anymore, team's projects can be run more concurrently.
- Project Leads have an opportunity to have broader knowledge of what the team is building, we get more experts in the team.
- Leading a project implies ownership of the thing the project is building. Ownership leads to higher quality.
- Everyone practices their leadership skills, while the Engineering Manager can finally focus on strategy for the team and career development for their direct reports.
Any Engineer or Test Analyst can be a Tech Lead for a project. Here are a few basic criteria for choosing a Tech Lead for a specific project. A potential lead should be:
- Willing to take a lead or at least to try
- Involved in the major part of technical/quality work for a given initiative
- Available for the whole duration of the project during working hours
- Not the same person all the time
It is highly recommended to rotate the role of the Tech Lead from project to project, so that everyone gets a chance to get more confidence in the role and regular leads don't get overloaded. More experienced leads should help new joiners by supporting them. This also means that the Engineering Manager, by default, provides support to all Project Leads, and is a default Project Lead if nobody else was assigned or the project is too complex.
The role comes with a set of responsibilities or expectations. In a nutshell those include:
- 🙌 Collaborate to collect all required information
- 📑 Document the solutions and decisions
- 🎫 Structure the tasks and provide estimates
- 👩💻 Implement their part of work or delegate it
- 🔄 Update the team on the status of the project and risks
- 🚜 Unblock all participants by finding answers
- 💕 Involve others to achieve all these things!
Let's elaborate on each of these responsibilities to make them more clear.
Project Lead is a driver of project-related conversations, as their goal is to ensure that all information required for the project to succeed is collected and shared among all the participants.
In practice this may include setting up a Slack channel for the project, reaching out to external stakeholders, updating the team on recent advancements, as well as being available to answer the questions. Proactivity is key to successful collaboration!
Needless to say that verbal or temporal communication is only part of success, which cannot be achieved without documentation.
A Project Lead is not necessarily the only person taking notes and updating the documentation. But it's their responsibility to encourage the team to do so.
The set of technical documentation any project needs includes:
- Technical requirements and implementation details - e.g. in the Epic
- Meeting notes and decision log - e.g. in the Epic, comments to the Epic, or in the Wiki. All participants should be notified about the changes, e.g. via a message in project's Slack channel
- Comprehensive documentation on the feature - in the Wiki
A Project Lead can probably only break down tasks and give estimates for their discipline of expertise. If possible they should do it together with their peers rather than all alone.
What can be done for the other disciplines is to nudge them and help with the process if the other engineers are stuck.
Any project needs clear, small, and predictable tasks to be successful. That's what this is all about.
A Project Lead is not supposed to be a full-time manager. One of the reasons they lead the project is their technical expertise in it. So, they should work on actual code in order to understand it better and be even more helpful to other participants.
This doesn't mean that they should burn themselves out if there is simply too much coordination involved. Ask for help and delegate part of the work to others as needed. This is also a great opportunity to improve delegation skills.
Once the project is up and running, it is important to do regular pulse checks and see where it's going. Typical ways to do it are:
- Reach out to the participants from times to times, to see how their part is going
- Ask for and give updates on the project in the daily standups (if there are any changes since the last update)
- Whenever there are updates in the specification (e.g. just finished a refinement session or made a decision with stakeholders), post a summary of changes in Slack or similar channel
- Showcase recent progress in regular Demos
- Send a short update message at the end of the week e.g. in the project Slack channel or email
What should be done if anything goes wrong, or slower than expected? Just communicate it! There is only one thing you can be 100% sure in Software development projects: things won't go as planned. Thus, the only way to succeed is to identify the changes as soon as possible and adapt to them.
This point basically repeats the first one. Communication is key! Over-communication is over-key!
The main job of a team lead is to unblock others. It may include answering their questions directly, or finding other people and sources of information that may have the answers. It is OK to do it in a reactive way: whenever a situation changes, react to it. But to take it to the excellent level, a lead should proactively identify the information that is likely to be useful in the future.
As many songs go: you're not alone! Leading something actually means achieving it by involving other people. Involve, delegate, celebrate, repeat!
The list of the expectations above may give an impression that a Project Lead is responsible for literally everything. It shouldn't be true. Let's list a few things that a Project Lead is not expected to do:
This is the responsibility of a Product Owner. Product Owner works actively with the Project Tech Lead, forming an immediate feedback loop.
This is still on the Engineering Manager. If the project fails, the Engineering Manager gets the blame, not the Project Lead.
It's the job of the Engineering Manager to give a Project lead timely feedback and highlight good decisions or mistakes. If the project goes south, ,all a Project Lead gets is learnings and experience they can use in their next initiatives.
If the project succeeds, praise goes to the entire team involved, Project Lead included. Extra effort should result into extra reward.
As mentioned above, a Project Lead should involve others to succeed.
In some teams management rewards people who execute the entire projects end to end. Asking for help is considered as "incompetence" there. Doing everything alone is recognized as "maturity" or "leadership skills". Ideally, each engineer in such a team works in a silo on their own project, while management "seeds ideas" and then waits for the portfolio of projects to be finished.
This is kind of taking the idea and turning it upside down. It discourages collaboration and knowledge sharing. It burns engineers out. In the end, engineers leave the team, and the entire domain expertise is gone with them.
Once again, involving the team is more important for a Project Lead than writing the biggest chunk of code. It's an investment in team's sustainability.
It is perfectly normal to get stuck or not to know how to do something. This is when you need a Engineering Manager or another senior colleague.
In HelloFresh we tried Project Leads technique and its variations in multiple teams over a course of several years. All the expected outcomes were obtained:
- Managers had less coordination and specification work to do
- The knowledge was spread more equally in the team
- Team members felt empowered and cared about the product they build
Another positive effect of applying this technique is that all the Project Leads progressed quicker in their career development, and several of them got promoted to the next career step. Including transitions to Managerial role.
- An Engineering Team where Everyone is a Leader by Gergely Orosz.
- Turn the Ship Around! by L. David Marquet.