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

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

Project management is a topic most people have strong opinions on, and I’m no exception. To answer the question of how different companies run engineering projects, I pulled in help from across the industry. 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.

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.

How Do Companies Run Projects? An Overview of the Survey Results.

I segregated the companies based on these categories:

• Public tech companies: Publicly traded companies with technology at their core. Many of these companies had previously been venture-funded.
• Venture-funded scaleups: Startups with Series B or above funding. These companies are typically valued at least at $300M, and are growing aggressively, often eyeing an IPO in a few years’ time.
• Venture-funded startups: Startups raising pre-seed, seed, or Series A funding. These are typically growing companies with less proven business models.
• Non-venture funded tech companies: Established tech companies that have not taken venture funding and are not publicly traded. These companies often have less aggressive growth goals than venture-funded ones.
• Large non-tech companies: Both public and private companies which do not have tech as their core function.
• Consultancies: Companies providing development services.

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.

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. Let me use this feedback to plug Linear, an issue tracking system, co-founded by one of my former Uber colleagues, and a tool that startups I invest in almost all decided to use and speak highly of. Note that I have no association with Linear and was not paid to write this.

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.

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. Read more about how software engineers lead projects at these places.
• 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.

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. Subscribers have access to the 🔒Project Lead Expectations document that hundreds of teams have taken inspiration from and used with success.

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 Program 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.

A telling summary of how the Product Manager role at Big Tech is different from Project Managers or Product Owners in many companies, is summarized in this tweet from Facebook product manager Ben Erez: