What I learned about working at scale - my 3rd year in LinkedIn

This month marks my third anniversary in LinkedIn. In what has become somewhat of a mini-tradition for me, I am writing down some reflections on what I have learned over the past year. My first year was all about picking up technical skills, while my second year was about honing my soft skills. 

In my third year, it was all about scale. In January this year, I officially made the transition from an Insights Analyst to an Insights Program Manager. I was already doing some scaled work before this, so I thought I probably had the hang of it. 

… But how wrong I was. There had certainly been a learning curve, and I learned a lot from my managers, teammates, and cross-functional partners alike. There are too many lessons to list, but I’m going to summarise the top five things I’d learned about working at scale.

Note that these are not about project management in general, but rather the difference between working on smaller, self-contained projects and bigger, multi-quarter projects. 

1. Big projects are complicated, and many factors are outside your control

As an analyst, deliverables are typically self-contained, and many things are within your control: methodology, slides, narratives, etc. There are things out of your control like client deadlines, but for the most part, things are relatively manageable. 

When it comes to scaled projects, your sphere of control shrinks considerably. This is because of many things: you need to work within the established tech stack, there are dependencies on other teams’ deliverables, etc. 

This may not sound fun, but this is why there is scale — no one can scale on their own or in silos, and working to plug your work into the broader ecosystem is exactly what scale means. 

Why does knowing this matter? It matters because it influences how you problem solve.

2. Problem-solving at scale means being less tactical and more strategic 

When I was an analyst, problem solving was very tactical. How do I get this code to work? What’s the best way to analyse this data? How do I tell a better story? More often than not, some secondary research, looking up best practices and getting feedback would be sufficient. Issues can be worked out relatively quickly.

Working at scale means that finding a fix for the moment is not sufficient. The solution needs to be efficient and automated as much as possible. It is about processes, not one-time fixes. But establishing and changing processes are hard, and you need to know what is the most effective way to go about it. 

This is where understanding your spheres of control and influence is critical, as it helps informs the levers you can pull. If an inefficient process is completely out of your control, who can help you provide feedback in the most effective manner? Who can help you get more resources? What do they care about? How are your priorities aligned with theirs?

Reflecting on these factors and levers would mean less time spent barking up the wrong tree, and more time spent driving the project forward. 

3. Scale means a very different approach to change management

Scaled projects usually mean that your stakeholders balloon in size and in type. In a small project, there are only a few stakeholders, and you can spend one-on-one time with each of them and manage expectations closely. 

With scaled projects, sometimes your stakeholders include a whole department, or many people across multiple teams. Talking to every single one of them would be both crazy and inefficient.  

Stakeholder mapping would be important — who are the key decision makers? What motivates each type of stakeholders? Who has the strongest influence? Who are the end users, or the closest to them? Who are more receptive to the new idea and could help you champion it? 

Each of these questions would matter differently depending on the context of your project. But in general, a good understanding of your stakeholders would lead to the best change management strategies. 

4. Resource management is complicated; understand the teams you work with

If you think resource management is only a problem for managers, think again. Even if you are not a people manager, if you work at scale, you need to learn about resource management, and how it happens across the teams you work with. 

Different teams would have different processes and priorities. Stay on top of team priorities, how they are set and when they are set. You don’t want to end up having a resource gap at a crucial step of your project, and find out that the next available slot is months away. This is a problem that is particularly acute for scaled projects that stretches across multiple quarters.

Working at scale also means that timelines may shift due to dependencies on other work streams. This would shift your own timelines, and the resources you have secured at the beginning of the project may become out of step with the new timelines, and you would need to figure it out again. Being close to the teams you work with means you are more likely to be able to adapt when things change.

5. Morale matters — take care of your team, and take care of yourself

I had saved the most important learning for last — managing morale. Big, complex, and multi-quarter projects can be exhausting. It may be even more so for people who are not used to these long cycles — I used to be able to ship multiple deliverables a week, or close a project within a quarter. But now, that is often not the case.

Adjusting to the fact that I won’t see many tangible deliverables in a quarter had been one of the most difficult adjustments that I’ve had to make. There were moments when I felt frustrated and exhausted by the seeming lack of progress despite weeks and weeks of work. But that was partly because I had always looked at the end product as my ‘result’. In a multi-quarter project, that end point is by definition not achievable within a quarter. It is important to set regular milestones, and celebrate them when they are met. 

This applies to the team you work with as well. It doesn’t matter if it is a team of high performers, if their morale is low, or if they are experiencing fatigue or burnout, they would not be contributing at their full potential. 

Check in with them regularly. Make sure they are taking regular breaks and not sprinting through the whole quarter. Celebrate their wins, big or small, along with the rest of the team. 

Do the same for yourself. You are capable of more than you think, but only when you’re taking care of yourself. 

Closing thoughts — scale is a mindset

My initial draft had compared ‘analyst’ and ‘program manager’, hoping to reflect learnings from my transition into my current role. But the more I wrote, the more I realise that it is not about the role itself. Scale is a mindset that can be applied to your work no matter your role.

It is not so much about specific types of projects, but rather a certain way of thinking. You can create a bigger impact if you:

1. Understand what factors lie within your control, influence or concern
2. Be strategic about how you approach these different factors as you problem-solve 
3. Understand your broader stakeholder group and what motivates them
4. Be aware of priorities and processes of the teams you work with
5. Take care of your team, and take care of yourself

I hope you found these useful. I’d love to hear what you think: what have you learned about working at scale?