Strategies for Shipping Large Projects
When I first joined Pinterest as a backend engineer six years ago, I came from a start-up background. My bag of tactics focused on shipping quickly in a fast-moving environment. I tackled every problem the same way: Narrow down impact, reduce scope and dependencies, and deliver in the shortest amount of time. But what worked well for me in small teams was ultimately a hindrance in large ones. I had to re-learn.
I had to adapt to a bigger company. I often couldn't do it solo or execute with just a few people. Shortcuts were looked down on. Correctness and safety were priorities over speed. It was a bit of a shift, and at some points, I seriously considered jumping back to start-ups.
This post is in response to Sean Goedecke's https://www.seangoedecke.com/how-to-ship/, where I found Sean's shipping philosophy familiar. But the question of how to get things shipped is worth adding detail to. I will outline what I've learned in the last few years on how to ship large projects, which I define as involving multiple teams that take a year or longer to execute. A lot of this can be found in best practices in project management--for a good reason. But this learning is all built on trial and error and my mistakes along the way.
Reducing Risk In The Beginning
The easiest projects to deliver are isolated to the immediate team. There, everything is under the control of one manager. As long as you have trust from that manager, you can run the project however you want.
But when you ask for resources from other teams and orgs, the stakes become higher. The further away you are from your own management chain, the less control you have over both whether you get the help you ask for and whether it's delivered in a way that allows your project to be successful.
The table stakes, a deep understanding of the current system, and the problems to be solved are apparent. But explaining it to other teams is a challenge. The clearer you can communicate the current system and issues to others without context and limited time, the easier it will be to get support. I found detailed architecture diagrams helpful with this (C4, mermaid). User stories and acceptance criteria can also add to the picture of what things could look like after the project is done.
Only with a good shared understanding of the problems can teams tackle resourcing. At a minimum, you're asking for other teams' time that could be spent on other initiatives or for them to hire additional headcount. Spending extra time on estimating impact and building a relationship between your team and partner teams' management chains is worthwhile. Your project needs to "win" in the marketplace of potential projects.
Next is figuring out what actually needs to be delivered by each team. This is the most critical phase in the project and is worth front-loading as much work as possible in this phase. Missed requirements for multi-team projects can significantly impact the timeline. Your partners have other commitments. They may not be able to make room to satisfy new problems found mid-project.
Often, it's not clear which requirements are "launch blockers" and which may not be needed immediately at launch. Spend time with your users and stakeholders to dial this in and communicate outwardly.
Other times, you may have vague requirements. The solution may depend on the implementation or on parts of the system you don't have a solid understanding of yet. It's still worth it to front-load discovery in the beginning stages. But if you can't, then explicitly mark them down as unknowns and try to clear things up as soon as possible.
After each team has confirmed requirements, you can take a first stab at building a project timeline. Work with your partners to define each major milestone each team needs to deliver by what date. And make sure that it satisfies the dependencies within each work-stream. Even though the timeline is guaranteed to change, having it from the beginning is essential. A timeline makes the commitment from each team explicit. At a minimum, you have a guarantee of a base level of commitment from your partners.
Lastly, after the requirements and timeline have been set, make sure your project is properly reflected in your team and each of your partner teams' OKRs. You can have your management chain meet with the management chain of your partner teams to solidify the relationship.
The beginning phases of a large project are critical to its success. You must win the other team's commitment to help and try to capture what they must commit to by looking into the future. The more front-loading you do in the beginning, the fewer surprises you'll encounter mid-way through that might delay or derail things entirely.
Reducing Risk In Execution
Once things are underway, you can use a few tools to help move the project along as expected.
The first is recurring meetings between partner teams. These meetings should include all stakeholders and, ideally, leads who can take steps to unblock a project if issues arise. Initially, these meetings can center around technical discussions on the design and implementation. However, the true goal of these meetings is to prioritize all the project requirements and track their timeline. At some point, you have to pivot from discussing technical details to reducing risk in delivery.
Another is one-on-ones with members of your immediate team members—this is similar but more personal than partner team meetings. The trap you can fall into here is assuming that as long as your team members know what to work on next, things will move according to the timeline. While your teammates may be brilliant and work hard, your project is not the only thing on their plate. Operational work, other projects, and personal goals may conflict with your project. In these one-on-ones, its easy to fall again into the trap of technical discussions on the project. However, the true goal is to deeply understand your team members' priorities and ensure there is enough priority to reach the milestones on time relative to other tasks.
I've found sprints to help schedule work with your immediate team. Unlike partner teams, where you have the luxury of working with senior leads and can depend on them to keep their milestones on track, you lead your team and have the responsibility to hold everyone accountable to the schedule. Have everyone break down their subproject into individual items and personal milestones. And schedule and measure progress against these in sprint planning. The trap here is that it's easy to feel like there is progress just because work items are done each sprint. However, a more accurate measure is whether each significant milestone is on schedule.
Given this much emphasis on reaching milestones on time, it's best to have a single timeline view of the entire project in an easy-to-reference document. Each milestone and date can be treated as a "reference point" for team members and partner teams. The goal is to get early signs or indicators that things are slipping as soon as they occur so issues can be mitigated.
Whether from your team or partners, each deliverable may partially miss the mark. We can solve this in two ways. First, create acceptance criteria for each deliverable up front. These criteria can include a demo of the feature or going through some use cases. The second is doing a "test drive" yourself as soon as things are ready. This way, you will have a more accurate reflection on how things are going.
A single chat channel for all stakeholders and contributors is beneficial outside of meetings. Setting a culture of unblocking work by pinging people will help the project progress, especially in a remote setting. However, try to avoid getting too deep into threads. If there is a problem that is worth a document, move to the document format. Otherwise, knowledge is hard to follow, and you can make suboptimal decisions.
Reducing Risk In The Release
The majority of the risk should have been removed by the time a project is ready to be released. Successful migrations have been well documented (https://newsletter.pragmaticengineer.com/p/real-world-engineering-challenges), and I defer to prior work on tackling these engineering challenges. I'll just say that from the many migrations I've done throughout my career, I've always found value in building more migration automation.
But the biggest risks in a release are missing requirements. So, before you migrate, find ways to certify the release, whether through a committee designated by your manager or experiment results.
Ideally, new requirements don't pop up during this phase, but sometimes, they do. If the partner teams can't react in time, your project can get delayed or deprioritized. Solutions to this may exist beyond your level—escalate through your management chain and build executive support for solving the issue.
If the project is user-facing and experiment results are not neutral, you may need to delegate parts of the investigation. I've found that the most effective engineering projects that tackle this phase have the clearest communication of the problems so that things can be effectively delegated. Do as much front-loading for other investigators as possible and break down the problem for them, and you'll have better results.
Working Through Challenges
Throughout a large project, you'll deal with two main issues.
The first is related to the design and execution of the project itself. A design or implementation might miss a key requirement. Other work might distract the team and cause milestones to slip. By front-loading as much re-risk work as possible in the initial stages and having solid project management fundamentals as outlined above, you can catch these as soon as they happen and work with the teams to resolve them and reduce the impact on the timeline. You can also maintain trust with partner teams by communicating progress and timeline changes as early as possible. By now, partner teams will also have your project's success included in their OKRs. Lacking visibility on risks and progress is a quick way to reduce trust.
The second is related to aspects outside your control. Your project might conflict with another team's mandate or core design principle. Your project may be de-prioritized partway through by a partner and delivery dates shifted up by an entire half year. Or a key customer may not prioritize adoption, and the project's end goals may not be realized.
Sean's original article emphasizes maintaining trust with the leadership team—to have a strong track record, a good reputation, and to project confidence. While some may consider these attributes typical large company politics, roadblocks outside your control can spell doom without leadership support. Being able to escalate upwards and being able to work across team or departmental boundaries with the help of your directors and VPs is essential to unblock projects if there are no immediate solutions between stakeholder teams.
How and when should you escalate? First, you need to judge if you are in a position to escalate. Does your team have enough impact within the company and on a stakeholder's team to make pushing worthwhile? Do you have enough support within your management chain? Second, you need to exhaust all paths through the stakeholder team. If you've done the work to build shared understanding and there still isn't a reasonable path forward, that's a sign to start working on an escalation.
An escalation document is a formal document backed by senior leads on your team and your manager that outlines the impact on your company if your project is blocked. In this document, give context on the existing systems and problems you're trying to solve. And estimate the impact on users or finances if your project can't finish. Keep the document factual and concise. And lastly be ready to defend every number or position you present.
Once ready and reviewed, this document can make its way up your management chain. Your director can then work with the stakeholder team's directors on a solution. Or if that doesn't work, your VP and their VP. The goal isn't to force a solution by bulldozing using rank. It's to find solutions to impossible problems purely considered within the two stakeholder teams. Solutions possible from a higher management level include having your project count as an exception to a design mandate. Or moving headcount around to fill a gap. Or re-emphasize the importance of the project on the company using the impact and numbers you presented and have the stakeholder team prioritize a solution.
Parting Thoughts...
The opportunity to tackle larger projects in large organizations has been an interesting part of my career progression. It not only involves a different set of skills working through people, but you also develop intuition for how to de-risk projects. I still consider myself early on this journey, but my experience here can help others navigate similar situations in their work.
