Source :

How Big Tech Runs Tech Projects and the Curious Absence of Scrum

A survey of how tech projects run across the industry highlights Scrum being absent from Big Tech. Why is this, and are there takeaways others should take note of?

Welcome to another issue of The Pragmatic Engineer where I cover topics relevant for engineering managers and senior engineers at high-growth startups and big tech.

If you’re reading this but haven’t yet signed up, join over 13,000 others and get The Pragmatic Engineer delivered to your inbox every week by subscribing here 👇

Question: I moved to a large tech company from a startup. I want to help my team execute well, but I’m aware the environment is different. What project management best practices have you seen across the industry, and what advice would you have on which approach to choose?

Project management is a topic most people have strong opinions on, and I’m no exception. To answer this question, I pulled in help from across the industry as well. In this issue we’ll cover:

  • Project management approaches across the industry. An overview of a survey with over 100 companies represented, plus key takeaways.

  • Project management at Big Tech. How are these done? How does the organizational setup of Big Tech influence how projects are executed?

  • The lack of Scrum at Big Tech. Why is the popular framework missing from most of Big Tech, and are there takeaways for companies operating outside this model?

  • How should you run projects in your team? I’ll share my personal take.

Before we jump in, here’s a personal story about why it’s sometimes hard to put a finger on how important project management approaches are.

Skype, Scrum, and the Reminder of What Matters

When I joined Skype in 2012, the company had gone all-in on Scrum. All engineers and product people were sent to best-in-class Scrum training, facilitated by one of the Agile manifesto’s founders. Skype went all-in on Scrum, moving all teams to this methodology over a few quarters.

And the move to Scrum was seen as a success at Skype. We went from shipping the flagship Windows app once-a-quarter at best, to monthly shipping. Most teams delivered something every 2-4 weeks. Teams rotated Scrum Master roles, agile coaches dropped in to give feedback on the teams, and Microsoft – which had just acquired Skype – was interested in taking inspiration from the speedup in delivery.

However, while Skype moved over to Scrum, a competitor was executing ruthlessly: Whatsapp. Though a much smaller organization, Whatsapp chipped away market share month after month, becoming the leading communications platform. 

Unlike Skype, Whatsapp never bothered with a framework like Scrum. Early employees shared how they never even muttered the word and deliberately ignored all heavyweight processes. Whatsapp out-executed Skype, built a more reliable messaging experience than Skype, and ultimately won the battle of messaging and communication apps.

The success of companies and project management approaches is not always correlated and this story is a reminder of this. I’m not saying how you run projects is not important: it is. But there are other things that might have a greater impact on outcomes, such as focus, leadership approaches, how people work even without a process, and so on.

Project management is a piece in a complex and ever-changing puzzle. However, it is not – and should not be – an end goal, only an enabler to reach that goal quicker.

Project Management Approaches in the Industry

How do companies run projects? I ran a survey with over 100 responses. The results are interesting. 

The summary of how companies manage projects is “it depends”. And this should not be very surprising. A newly founded startup with five people will see success in different ways from a 1,000-person, slowly growing non-tech company. Even within the group of large non-tech companies, some experiment with novel approaches, while others stick to doing the same thing that has been working well enough for years.

I segregated the companies based on whether tech was at their core, and their funding model.

Methodologies used by companies in this survey were:

  • No “formal” methodology: common for public and venture-funded tech companies.

  • Plan, build, ship: common for public and venture-funded tech companies.

  • Scrum: common for large, non-tech companies, non-venture funded companies and consultancies.

  • Kanban: mentioned across all companies.

  • SAFe (Scaled Agile Framework): mentioned with large, non tech companies and a non-venture funded company.

  • Shape Up: mentioned for a few venture-funded companies.

How do companies run projects? An overview of the survey results.

The survey revealed a few interesting findings, some of which related to the question: “On a scale of 1 (not satisfied) to 5 (very satisfied) how satisfied/happy are you with the current project management methodology?”

Insights that are worth thinking about are below. I advise to treat these carefully, given the survey is non-representative in sample size. Nevertheless, they are observations I can confirm.

  • Teams with dedicated project managers typically recorded lower satisfaction ratings at public or venture-funded tech companies. However, at non-venture funded companies and consultancies, several respondents were very happy with project management, and called out these people as a reason for their satisfaction.

  • Teams being allowed to choose their own way of working was more common at public tech companies and venture-funded scaleups. Large, non-tech companies and smaller, non-venture-funded companies were more likely to mandate the same approach for all teams within the company.

  • Team autonomy and high satisfaction seemed to be correlated. Many people rating their satisfaction as 4 or 5 mentioned autonomy, freedom and flexibility, and the putting of quality first at the team level, as a positive.

  • Teams struggling often had little to do with the methodologies. People mentioned lack of vision, good engineers leaving, lack of transparency or poor tooling as reasons why things went badly. For these teams, no change of methodology would help because the issues ran deeper.

  • JIRA has been mentioned mostly with negative associations: all 13 mentions of JIRA were in this setting. Being able to get things done without working much with JIRA was mentioned as a positive. Additionally, a recently IPOed, high-growth tech company moved over to JIRA and ran a survey among engineers. It measured a Net Promoter Score (NPS) of -83. This is staggeringly low, and means that 83% of engineers would advise against JIRA. As a counterpoint, an engineering leader at a public tech company with stable growth shared that their organization heavily relies on JIRA, using it as a knowledge engine. In their case, JIRA works well for large-scale coordination, after the organization fully adopted it.

Project management approaches that do not work well share a few characteristics, according to respondents who left a rating of a 1 or a 2:

  • Engineers not involved in estimations that the team then committed to, is a frequent pain point. In my view, it’s one of the easiest ways to demotivate engineers – to the point of some leaving – and also to get a false sense of what a team can achieve.

  • Requirements changing, even with dedicated project managers, sits poorly with engineers. While there are teams where requirements change a lot, on these teams it’s typically the engineers who run the projects, and can deal with them. However, when a dedicated project manager is unable to shield the team from requirements changing, respondents rated this approach as poor.

  • Teams with no autonomy to change a failing project management approach also recorded low satisfaction. These kinds of responses were pronounced at companies where all teams were expected to follow the same methodology. It’s an example of directive leadership and while this approach can work well for roles where there is little creativity needed, it is usually a poor way to build high-performing software engineering teams. When teams can iterate together and change their processes on their own terms, satisfaction and productivity go up.

Browse all anonymized responses here.

How Big Tech Runs Projects

Big Tech differ in how they approach executing tech projects, compared to the rest of the industry. I gathered data by talking with people at well-known publicly traded tech companies. Here is how they typically get things done:

How Big Tech runs engineering projects. Typically used methodology: as each team can choose how they work, the methodologies used per engineering team can vary, even on a project basis.

Big Tech shares several characteristics in how engineers execute on projects:

  • Engineers lead most projects: either a tech lead, or an engineer on the team taking the lead.

  • Teams are free to choose the project management methodology they use. Many teams go with an RFC-like planning process, iterate on building, and ship all within a few weeks. Other teams use more Kanban-like processes, where they work on the highest priority items.

  • There are no dedicated project managers for team-level projects. Most of these companies have Technical Program Managers (TPMs) who step in for large projects involving multiple teams, or run across organizations. The ratio of TPMs to engineers was around 1:50 at Uber.

  • Project management artifacts and processes vary between teams even in the same organization. Most teams have a project backlog, do standups at intervals as the team sees fit, and retrospectives every now and then.

  • First-class developer tooling is a given in these places, and plays a large role in short iteration cycles. Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members.

For people who have worked in Big Tech, much of this is familiar. However, if you were to try to copy this same approach in a more traditional company, it would likely fail. This is because the organizational structure of Big Tech greatly impacts how teams can – and do – execute.

Big Tech Organizational Structure that Impacts Projects

In order to understand how Big Tech manages projects, let’s take a step back and look at the environment most of these companies operate in, which I dive deeper into, in the article What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not.

  1. Autonomy for software engineers and teams. The expectation of developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has. This is a huge difference. It impacts the day-to-day life of any engineer.

  2. Curious problem solvers, not mindless resources. A motivated engineer easily makes multiple times the impact of a "factory worker" who only does what they’re told. For organizations with a factory worker attitude, this approach will bias towards more heavyweight project management approaches that leave little room for interpretation, on purpose.

  3. Internal data, code, and documentation transparency. Employees – and not just engineers – often have access to real time business metrics and data sources, to write their own queries and create custom reports.

  4. Exposure to the business and to business metrics. Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business.

  5. Engineer-to-engineer comms over triangular-communication. Traditional companies will encourage hierarchical communication that slows down information flow, and results in slower decisions.

  6. Investing in a less frustrating developer experience. Companies that care about engineers solving problems quickly set up various platform teams, which reduce the developer experience churn.

  7. Higher pay, justified by higher leverage. Companies that leverage engineers well, have no trouble paying close to the top of the market, or above it.

  8. Caliber of the talent hired. These companies hire highly competent and highly motivated people, thanks to the combination of all the above. They have a large pool to choose from, as they are known for generous compensation packages, and strong career growth opportunities.

Empowered and autonomous teams are the building blocks of all these companies. They are also the key differentiator between many companies in the tech industry.

While not all teams within Big Tech will be fully empowered, these organizations – along with progressive thinking startups – are closest to implementing ways that ensure teams are as empowered as possible.

Teams with clear ownership is another building block of Big Tech. Each team of 5-15 people has a clear vision and mission, and the skills and autonomy to execute on it. The mission could be “Build a world-class booking experience for seniors” for a product team on a hospitality product, or “Empower teams to integrate rating experiences with close to zero effort” for a product platform team.

Product-focused teams are typically composed of cross-functional team members like backend, frontend and/or mobile engineers, with product managers, data scientists and designers often also on the team. Platform-focused teams tend to not be cross-functional or tied to a specific domain. 

Note that even though engineers have high-level specialization, in Big Tech most experienced software engineers are expected to be able to pick a broad range of engineering work, and the interview process also reflects this generalist approach.

Product Managers: Yes, Project Managers: No

Another curious difference between Big Tech and everyone else is the role of Product Managers, and the lack of Project Managers or Product Owners who are dedicated to teams.

The role of product managers at these companies is defining the strategy at the team – the “why” – and the steps to execute this strategy – the “how”. As Facebook product manager Will Lawrence phrases this:

“The role of a product manager is to figure out what game we're playing and how we're going to play it. Strategy is choosing the game we're playing. It’s finding worthwhile areas to invest in and creating a compelling vision for how we can succeed in this game. (...) Execution is how we play the game. It’s the day-to-day processes, decisions and actions we take to make progress towards our mission.”

Product Managers ensure that the team keeps working on the right thing. This means working with the business, with data science and with design to build a roadmap, create plans, prioritize work and escalate where needed. At large companies, this itself is a full-time job already.

In many cases, Product Managers do not own project management at Big Tech. The team is responsible for the execution, and the team lead – usually the Engineering Manager – is responsible for making this happen.

With empowered and autonomous teams, managing a project is rarely a top down exercise. Each team will vary, but I’ve found great success in rotating the project lead role among engineers, helping everyone on the team grow their leadership muscle.

The lack of dedicated project managers raises several questions. Are engineers overloaded with project management? Is managing projects a good use of engineering time? All of these are possible, and here is my take.

  • For team-level projects, not having a dedicated project manager ends up simplifying processes, and strengthening personal relationships. Engineering project leads will add as little process as they can, as this is in their interest. When collaborating with other teams – also without project managers – they will also build relationships for other engineers leading projects, or owning products. This kind of engineer-to-engineer communication is more efficient than if it went through multiple project managers as well.

  • For complex projects that span several teams across different offices and time zones, leading such a project is a full-time job for an engineer. Big Tech pulls in Technical Project Managers (TPMs) to manage these complex, and often strategic projects, taking the load off engineers.

  • Dedicated Program Managers or Project Managers still exist within Big Tech. They are typically tied to external-facing commitments and customers – such as a Program Manager for the Apple partnership – or to long-running initiatives, like a compliance program. Similar to how TPMs are not allocated to a single engineering team, these Program Managers or Product Managers also don’t tend to have an engineering team, but they work across many teams instead.