When I first started growing tech leads, my biggest challenge was giving people sufficient support without being overbearing and diminishing their perceived ownership of their project. So I devised a list of questions to ask my TLs to give them a better sense of my expectations and help me quickly assess the health of the project. That document formed the basis for Metawork for Engineering Leaders. Over the years, I kept iterating on that list and it eventually became a list of all the things I expect project leaders to handle. Today, I use this list to train tech leads, distribute responsibilities among tech leads, managers, and PMs (product or project managers), and make role expectations clear to the entire project team so everyone can hold each other accountable.
When leading a project, your goals should be to help the team be maximally effective and ensure everyone (the team and stakeholders) feel good about the time investment afterwards, regardless of the outcome. You can accomplish that in many different ways – keeping people motivated, ensuring they have impactful things to work on, building consensus the team’s goals, and much more. The more intricate the project’s dependencies (meaning dependencies among tasks, individuals, and teams) the more time you need to invest upfront to ensure smooth execution. Without setting the stage beforehand, expectations for project cost and ROI will be misaligned, which causes decision churn, inefficient execution, and a lot of wasted time as people struggle to build consensus on the fly.
Below are some of the questions that project leadership (tech lead, PM, eng manager) and the team should answer before embarking on a large chunk of work to ensure that team members can be maximally effective. If you’re unable to answer any of these questions satisfactorily, it’s a sign that you should dig in further to avoid problems further down the line. And if you’re able to answer all of these, you’ll have peace of mind and be better equipped to communicate the project’s status to the team and other stakeholders around the company.
Lifecycle
Do we have a general understanding of what failure looks like?
Once you’ve spent a lot of time working on a project, finishing may start to feel more important than meeting your goals. Without defining what failure for the project looks like, the project may turn into a zombie – one that slowly limps along without sufficient team motivation or organizational support. Failure can mean the project cost is much higher than anticipated, we discovered that metrics aren’t going to move as much as we thought, or the company’s priorities have shifted. Killing projects never feels good. Having a clear definition of failure up front allows the team to have an intellectually honest conversation about whether to continue investing time in any given project.
Do we have a clear end state in mind?
Even highly successfully initiatives will eventually reach a point of diminishing returns. At that point it’s important to take a step back and determine whether it’s time to shift the team’s focus. Without a clearly defined end state, it’s easy to be swept up in the excitement of shipping while your impact diminishes.
Impact
Is it clear how the project fits into the company’s strategy?
Having a clear connection for a given project to the company’s current strategy and objectives is important for keeping the team motivated, giving other teams a clear idea of when and how to include you in discussions, and ensuring continued organizational support.
Are there SMART goals for the project (specific, measurable, attainable, realistic, time-bounded)?
Defining clear goals up front gives both the team and stakeholders clear success metrics. A lack of clarity here leads to lack of focus and disagreement about the project’s outcome – when you don’t communicate metrics for success up front, people will invent their own.
Have we identified clear risks for the project? Do we have mitigation strategies?
Even with well-defined goals and a solid plan, no project will be a guaranteed success. If you’re able to identify all risks ahead of time and devise mitigation strategies (which may include ending the project prematurely), you’ll maximize the project’s chances of success and, even if you don’t hit your goals, you can sleep well knowing you did your best work as a leader.
Stakeholders
Have clear stakeholders been identified (other engineering teams, other job functions, etc.)?
Understanding who is affected by your work helps you continually collect feedback and course correct as necessary.
Have we set expectations for the roles of the stakeholders in the project (code review, feedback, etc)?
Setting clear expectations for stakeholders upfront helps you avoid scrambling to convince people to devote their time and expertise to the project later on down the line.
Team
Are there clear owners for each part of the project (including people on other teams or orgs – design, PM, tech leads, engineers on other teams)?
When tasks or decisions lack clear owners, decision-making and execution tend to be less efficient – you risk having some areas be neglected or multiple owners arising organically, which means there’s no clear way to resolve disagreements.
Does the team understand the project lifecycle, expected impact, stakeholders, and communication plan?
Ensuring the team understands your plan for running the project gives them confidence the plan will succeed and empowers them to aid you in identifying risks and roadblocks.
Does the team understand how their work fits into the bigger picture?
Everyone should have a clear understanding of how their individual efforts tie into the larger mission of the team, the engineering org, and the company. Anytime you ask them to do something it should feel like a good use of their time.
Does the team know each other?
The best performing teams respect each other’s skillset and bond over something other than work. The importance of the former is obvious – trusting your teammates’ competency and reliability is paramount for collaborating on non-trivial tasks. The latter may be non-obvious – forming a bond that transcends the project’s goals is important for sharing authentically among the team, having hard conversations, and committing to shared goals even when unanimity is lacking.
Does the team have the right skills to deliver the project?
Starting the project with the right skillset within the team is ideal. Learning on the fly can also work well if the team is senior enough or you identify the right support (mentors and collaborators) up front. You should avoid situations where you discover part way through the project that you’ll require additional expertise from another team to do your project well.
Does the team have enough people to deliver in time?
Obviously, missing the deadlines you set reduces trust in your team overtime. Establishing unrealistic goals or workloads also hurts morale and, at worst, burns people out. Make sure that you’re committing to a reasonable amount of work for a team your size working at a realistic pace.
Communication plan
Is there a communication plan?
Formulate a plan for keeping stakeholders and the team in the loop. Defining and sharing your communication plan ensures that
- Communication is flowing among the teams and people that can help maximize the project’s success.
- People feel good about the team’s work. The bigger the organization, the more important it is to devise a clear communication plan.
Do stakeholders understand when and how to give feedback to the team?
Stakeholder feedback is often the difference between project success and failure. Without clear forums for feedback (meetings, Slack channels, docs, etc) misalignment grows overtime and trust in the team erodes.
Who owns communication for different aspects of the project?
Having an owner for communication ensures that people know who to talk to about project updates and feedback. That person serves as a steward for the quality of the communication channels and source of truth for their area. This person is often a tech lead, PM, or manager.