Transcript
Saraf: I lead the platform networking org at Netflix. What I'm going to talk to you about is based off 17-plus years of experience building platforms and products, and then building teams that build platform and products in different areas of cloud infrastructure and networking. I've also had an opportunity to work in different scale and sizes of the companies: hyperscalers, pre-IPO startups, post-IPO startups, and then big enterprises. I'm deriving my experience from all of those places that you see on the right. Really, my mission is to create the best environment where people can do their best work. That's what I thrive by.
Why Strategic Thinking?
I'm going to let you read that Dilbert comic. This one always gets me, like whenever you think of strategy, strategic planning, strategic thinking, this is how your experience comes across. It's something hazy. It's something hallucination, but it's supposed to be really useful. It's supposed to be really important for you, for your organization, for your teams. Then, all of this starts looking really hard and something you don't really want to do. Why is this important? Strategic thinking is all about building that mindset where you can optimize for long-term success of your organization. How do you do that? By adapting to the situation, by innovating and building this muscle continuously.
Let's look at some of these examples. Kodak, the first company to create a camera ever, and they had a strategic mishap of not really thinking that digital photography is taking off, betting too heavily on the film. As a result, their competitors, Canon and others caught up, and they were not able to, and they went bankrupt. We don't want another Kodak at our hands. Another one that strikes close to home, Blockbuster. Blockbuster, how many of you have rented DVDs from Blockbuster? They put emphasis heavily on the physical model of renting media. They completely overlooked the online streaming business and the DVD rental business, so much so that in 2000 they had an opportunity to acquire Netflix, and they declined.
Then, the rest is history, they went bankrupt. Now hopefully you're excited about why strategic thinking matters. I want to build this up a bit, because as engineers, it's easy for us to do critical thinking. We are good at analyzing data. We work by logic. We understand what the data is telling us or where the problems are. Also, when we are trying to solve big, hard problems, we are very creative. We get into the creative thinking flow, where we can think out of the box. We can put two and two together, connect the dots and come up with something creative.
Strategic thinking is a muscle which you need to be intentional about, which you need to build up on your critical thinking and creative thinking. It's much bigger than you as an individual, and it's really about the big picture. That's why I want to talk about this, because I feel like some people are really good at it, and they practice it, but there are a lot of us who do not practice this by chance, and we need to really make it intentional to build this strategic muscle.
Why does it really matter, though? It's great for the organization, but what does it really mean. If you're doing this right, it means that durability of the decisions that you're making today are going to hold the test of the time. Whether it's a technical decision you're making for the team, something you're making for your organization or company at large, your credibility is built by how well can you exercise judgment based on your experience.
Based on the mistakes that you're making and the mistakes others are making, how well can you pattern match? Then, this leads, in turn, to building credentials for yourself, where you become a go-to person or SME, for something that you're driving. In turn, that creates a good reputation for your organization, where your organization is innovating, making the right bets. Then, it's win-win-win. Who doesn't like that? At individual level, this is really what it is all about, like, how can you build good judgment and how can you do that in a scalable fashion?
Outline
In order to uncover the mystery around this, I have put together some topics which will dive into the strategic thinking framework. It will talk about, realistically, what does that mean? What are some of the humps that we have to deal with when we talk about strategy? Then, real-world examples. Because it's ok for me to stand here and tell you all about strategy, but it's no good if you cannot take it back and apply to your own context, to your own team, to yourself. Lastly, I want to talk a bit about culture. For those of you who play any kind of leadership role, what role can you play in order to foster strategic thinking and strategic thinkers in your organization?
Good and Poor Strategies
Any good strategy talk is incomplete without reference to this book, "Good Strategy Bad Strategy". It's a dense read, but it's a very good book. How many people have read this or managed to read the whole thing? What Rumelt really covers is the kernel of a good strategy. It reminds me of one of my favorite Netflix shows, The Queen's Gambit, where every single episode, every single scene, has some amount of strategy built into it. What Rumelt is really saying is, kernel of a good strategy is made up of three parts. This is important, because many times we think that there is strategy and we know what we are doing, but it is too late until we discover that this is not the right thing for our business.
This is not the right thing for our team, and it's very expensive to turn back. A makeup of a good strategy, the kernel of it is diagnosis. It's understanding why and what problems are we solving. Who are we solving these problems for? That requires a lot of research. Once you do that, you need to invest time in figuring out what's your guiding policy. This is all about, what are my principles, what are my tenets? Hopefully, this is something which is not fungible, it doesn't keep changing if you are in a different era and trying to solve a different problem. Then you have to supplement it by very cohesive actions, because a strategy without actions is just something that lives on the paper, and it's no good.
Now that we know what a good, well-balanced strategy looks like, let's look at what are examples of some poor strategies. Many of you might have experienced this, and I'm going to give you some examples here to internalize this. We saw what a good strategy looks like, but more often than not, we end up dealing with a poor strategy, whether it is something that your organizational leaders have written, or something as a tech lead you are responsible for writing. The first one is where you optimize heavily on the how, and you start building towards it with the what. You really don't care about the why, or you rush through it. When you do that, the strategy may end up looking too prescriptive. It can be very unmotivating. Then, it can become a to-do list. It's not really a strategy.
One example that comes to my mind is, in one of the companies I was working for, we were trying to design a return-to-work policy. People started hyper-gravitating on, how should we do it? What is the experience of people after two, three years of COVID, coming back? How do we design an experience where we have flex desk, we have food, we have events in the office? Then, what do we start doing to track attendance and things like that? People failed to understand during that time, why should we do it? Why is it important? Why do people care about working remote, or why do they care about working hybrid?
When you don't think about that, you end up solving for the wrong thing. Free food and a nice desk will only bring so many people back in the office. Failing to dig into the why, or the different personas, or there were some personas who worked in a lab, so they didn't really have a choice. Even if you did social events or something, they really didn't have time to go participate because they were shift workers. That was an example of a poor strategy, because it ended up being unmotivating. It ended up being very top-down, and just became a to-do list.
The next one, where people started off strong and they think about the why. Great job. You understood the problem statement. Then, you also spend time on solving the problem and thinking about how. What you fail is how you apply it, how you actually execute on it. Another example here, and I think this is something you all can relate with, like many companies identify developer productivity as a problem that needs solving. How many of you relate to that? You dig into it. You look at all the metrics, DORA metrics, SPACE, tons of tools out there, which gives you all that data. Then you start instrumenting your code, you start surveying your engineers, and you do all these developer experience surveys, and you get tons of data.
You determine how you're going to solve this problem. What I often see missing is, how do you apply it in the context of your company? This is not an area where you can buy something off the shelf and just solve the problem with a magic wand. The what really matters here, because you need to understand what the tools can do. Most importantly, how you apply it to your context. Are you a growing startup? Are you a stable enterprise? Are you dealing with competition? It's no one size fits all. When you miss the point on the what, the strategy can become too high level. It sounds nice and it reads great, but then nobody can really tell you, how has the needle moved on your CI/CD deployment story in the last two years? That's example of a poor strategy.
The third one is where you did a really great job on why, and you also went ahead and started executing on this. This can become too tactical or reactive, and something you probably all experience. An example of this is, one of my teams went ahead and determined that we have a tech debt problem, and they dug into it because they were so close to the problem space. They knew why they had to solve this. They rushed into solving the problems in terms of the low-hanging fruits and fixing bugs here and there, doing a swarm, doing a hack day around tech debt. Yes, they got some wins, but they completely missed out the step on, what are our architectural principles? Why are we doing this? How will this stand the test of time if we have a new business use case?
Fast forward, there was a new business use case. When that new business use case came through, all the efforts that were put into that tech debt effort went to waste. It's really important, again, to think about what a well-balanced strategy looks like, and how you spend time in building one, whether it's a technical strategy or writing as a staff or a staff-plus engineer, or you're contributing to a broader organizational strategic bet along with your product people and your leaders.
Strategic Thinking Framework
How do we do it? This is the cheat sheet, or how I approach it, and how I have done it, with partnering with my tech leads who work with me on a broad problem set. This is putting that in practice. First step is diagnostics and insights. Start with, who are your customers? There's not one customer, generally. There are different personas. Like in my case, there are data engineers, there are platform providers, there are product engineers, and there are end customers who are actually paying us for the Netflix subscription. Understanding those different personas. Then understanding, what are the hot spots, what are the challenges? This requires a lot of diligence in terms of talking to your customers, having a very tight feedback loop.
Literally, I did 50 interviews with my customers before I wrote down the strategy for my org. I did have my tech lead on all of those interviews, because they were able to grasp the pain points or the issues that the engineers were facing, at the same time what we were trying to solve as an org.
Once you do that, it's all about coming up with these diagnostics and insights where your customer may say, I want something fast. They may not say, I want a Ferrari. I'm not saying you have to go build a Ferrari, but your customers don't always know what they want. You as a leader of the organization or as a staff engineer, it's on you to think about all the data and derive what are the insights that come out of it? Great. You did that. Now you also go talk to your industry peers. Of course, don't share your IP. This is the step that people miss. People don't know where the industry is headed, and they are too much into their own silo, and they lose sight of where we are going. Sometimes it warrants for a build versus buy analysis.
Before you make a strategic bet, think about what your company needs. Are you in a build mode, or is there a solution that you can buy off-the-shelf which will save your life? Once you do that, then it's all about, what are our guiding principles? What are the pillars of strategy? What is the long-term vision? This is, again, unique to your situation, so you need to sit down and really think about it. This is not complicated. There are probably two or three tenets that come out which are the guiding principle of, how are we going to sustain this strategy over 12 to 18 months? Then, what are some of the modes or competitive advantages that are unique to us, to our team, or to our company that we are going to build on?
You have something written down at this point. Now the next step of challenge comes in, where it's really about execution. Your strategy is as good as how you execute on it. This is the hard part where you might think, the TPM or the engineering leader might do all of this work of creating a roadmap, doing risk and mitigation, we're going to talk about risk a lot more, or resources and funding. You have a voice in this. You're closer to the problem. Your inputs can improve the quality of roadmap. Your inputs can improve how we do risk mitigation across the business. Do not think this is somebody else's job. Even though you are not the one driving it, you can play a very significant role in this, especially if you are trying to operate at a staff or a staff-plus engineer level.
Finally, there can be more than one winning strategy. How do you know if it worked or not? That's where the metrics and KPIs and goals come in. You need to define upfront, what are some of the leading indicators, what are some of the lagging indicators by which you will go back every six months and measure, is this still the right strategic bets? Then, don't be afraid to say no or pivot when you see the data says otherwise. This is how I approach any strategic work I do. Not everything requires so much rigor. Some of this can be done quickly, but for important and vital decisions, this kind of rigor helps make you do the right thing in the long term.
Balancing Risk and Innovation
Now we look like we are equipped with how to think about strategy. It reminds me of these pink jumpsuit guys who are guardians of the rules of the game in Squid Games. We are now ready to talk about making it real. Next, I'm going to delve into how to manage risk and innovation. Because again, as engineers, we love to innovate. That's what keeps us going. We like hard problems. We like to think of them differently. Again, the part I was talking about, you are in a unique position to really help balance out the risk and how to make innovation more effective. I think Queen Charlotte, in Bridgerton, is a great example of doing risk mitigation every single season and trying to find a diamond in the ton. Risk and innovation. You need to understand, what does your organization value the most? Don't get me wrong, it's not one or the other.
Everybody has a culture memo. Everybody has a set of tenets they go by, but this is the part of unsaid rules. This is something that every new hire will learn by the first week of their onboarding on a Friday, but not something that is written out loud and clear. In my experience, there are different kinds of organizations. Ones which care about execution, like results above everything, top line, bottom line. Like how you execute matters, and that's the only thing that matters, above everything else. There are others who care about data-driven decision making. This is the leading principle that really drives them.
They want to be very data driven. They care about customer sentiment. They keep adapting. I'm not saying they just do what their customers tell them, but they have a great pulse and obsession about how customers think, and that really helps them propel. There are others who really care about storytelling and relationships. What does this really mean? It's not like they don't care about other things, but if you do those other things, if you're good at executing, but if you fail to influence, if you fail to tell a story about what ideas you have, what you're really trying to do.
If you fail to build trust and relationships, you may not succeed in that environment, because it's not enough for you to be smart and knowing it all. You also need to know how to convey your ideas and influence people. When you talk about innovation, there are companies who really pride themselves on experimentation, staying ahead of the curve. You can look at this by how many of them have an R&D department, how much funding do they put into that? Then, what's their role in the open-source community, and how much they contribute towards it. If you have worked in multiple companies, I'm pretty sure you may start forming these connections as to which company cares about what the most.
Once you figure that out, as a staff-plus engineer, here are some of the tools in your toolkit that you can be doing to start mitigating risk. Again, rapid prototyping. This is way better than months or weeks of meetings trying to make somebody agree on something, versus spending two days on rapid prototyping and letting the results enhance the learning and arriving at a conclusion. We talked about data-driven decisions. Now you understood what drives innovation in your org, but you should also understand what's the risk appetite. If you want to go ahead with big, hairy ideas, or you are not afraid to bring up spicy topics, but if your organization doesn't have that risk appetite, you are doing yourself a disservice.
I'm not saying you should hold back, but be pragmatic as to what your organization's risk appetite is, and try to see how you can spend your energy in the best way. There are ideathons, hackathons. As staff-plus engineers, you can lead by example, and you can really champion those things. One other thing that I like is engineering excellence. It's really on you to hold the bar and set an example of what level of engineering excellence does your org really thrive for?
With that in mind, I'm going to spend a little bit of time on this. I'm pretty sure this is a favorite topic for many of you, known unknowns and unknown unknowns. I want to extend that framework a bit, because, to me, it's really two axes. There's knowledge and there is awareness. Let's start with the case where you know both: you have the knowledge and you have the awareness. Those are really facts. Those are your strengths. Those are the things that you leverage and build upon, in any risk innovation management situation. Then let's talk about known unknowns. This is where you really do not know how to tackle the unknown, but you know that there are some issues upfront.
These are assumptions or hypotheses that you're making, but you need data to validate it. You can do a bunch of things like rapid prototyping or lookaheads or pre-mortems, which can help you validate your assumptions, one way or the other. The third one, which we don't really talk about a lot, many of us suffer from biases, and subconscious, unconscious biases. Where you do have the knowledge and you inherently believe in something that's part of your belief system, but you lack the awareness that this is what is driving it. In this situation, especially for staff-plus engineers, it can get lonely up there. It's important to create a peer group that you trust and get feedback from them. It's ok for you to be wrong sometimes. Be willing to do that.
Then, finally, unknown unknowns. This is like Wild Wild West. This is where all the surprises happen. At Netflix, we do few things like chaos engineering, where we inject chaos into the system, and we also invest a lot in innovation to stay ahead of these things, versus have these surprises catch us.
Putting all of this into an outcome based visual. Netflix has changed the way we watch TV, and it hasn't been by accident. It started out as a DVD company back in 1997. That factory is now closed. I had the opportunity to go tour it, and it was exciting. It had all the robotics and the number of DVDs it shipped. The point of this slide is, it has been long-term strategic thinking and strategic bets that have allowed Netflix to pivot and stay ahead of the curve. It hasn't been one thing or the other, but like continuous action in that direction that has led to the success.
Things like introducing the subscription model, or even starting to create original Netflix content. Then, expanding globally to now we are into live streaming, cloud gaming, and ads. We just keep on doing that. These are all the strategic bets. We used a very data-driven method to see how these things pan out.
Real-World Examples
Enough of what I think. Are you ready to dive into the deep end and see what some of your industry peers think? Next, I'm going to cover a few real-world examples. Hopefully, this is where you can take something which you can start directly applying into your role, into your company, into your organization. Over my career, I've worked with 100-plus staff-plus engineers, and thousands of engineers in general, who I've hired, mentored, partnered with. I went and talked to some of those people again. Approximately, went and spoke to 50-plus staff-plus engineers who are actually practitioners of what I was just talking about in terms of strategic framework.
How do they apply it? I intentionally chose companies of all variations, like big companies, hyperscalers, cloud providers, startups at different stages of fundings who have different challenges. Then companies who are established, brands who just went IPO. Then, finally, enterprises who have been thriving for 3-plus decades. Will Larson's book, "Staff Engineer," talks about archetypes. When I spoke to all these people, they also fall into different categories of being deep domain experts, being generalist, cross-functional ICs, distinguished engineers who are having industry-wide impact.
Then, SREs and security leaders who are also advising to the C levels, like CISOs. It was very interesting to see the diversity in the impact and in the experience. Staff-plus engineers come in all flavors, like you probably already know. They basically look like this squad, the squad from 3 Body Problem, each of them having a superpower, which they were really exercising on their day-to-day jobs.
What I did was collected this data and did some pattern matching myself, and picked out some of the interesting tips and tricks and anecdotes of what I learned from these interviews. The first one I want to talk about is a distinguished engineer. They are building planet scale distributed systems. Their work is highly impactful, not only for their organization, but for their industry. The first thing they said to me was, people should not DDoS themselves. It's very easy for you to get overwhelmed by, I want to solve all these problems, I have all these skill sets, and everything is a now thing.
You really have to pick which decisions are important. Once you pick which problems you are solving, be comfortable making hard decisions. Talking to them, there were a bunch of aha moments for them as they went through the strategic journey themselves. Their first aha moment was, they felt engineers are good at spotting BS, because they are so close to the problem. This is a superpower. Because when you're thinking strategically, maybe the leaders are high up there, maybe, yes, they were engineers at one point in time, but you are the one who really knows what will work, what will not work. Then, the other aha moment for them was, fine, I'm operating as a tech lead, or I'm doing everything for engineering, or I'm working with product, working with design. It doesn't end there.
If you really want to be accomplished in doing what you're good at, at top of your skill set, they said, talk to everyone in the company who makes companies successful, which means, talk to legal, talk to finance, talk to compliance. These are the functions we don't normally talk to, but they are the ones that can give you business context and help you make better strategic bets. The last one was, teach yourself how to read a P&L. I think this was very astute, because many of us don't do that, including myself. I had to teach myself how to do this. The moment I did that, game changing, because then I could talk about aligning what I'm talking about to a business problem, and how it will move the needle for the business.
A couple of nuggets of advice. You guys must have heard this famous quote, that there's no compression algorithm for experience. This person believes that's not true. You can pay people money and hire for experience, but what you cannot hire for is trust. You have to go through the baking process, the hardening process of building trust, especially if you want to be influential in your role. As I was saying, there can be more than one winning strategies. As engineers, it's important to remain builders and not become Slack heroes. Sometimes when you get into these strategic roles, it takes away time from you actually building or creating things. It's important not to lose touch with that. The next example is a principal engineer who's leading org-wide projects, which influences 1000-plus engineers.
For them, the aha moment was that earlier in their career, they spent a lot of time honing in on the technical solutions. While it seems like this is obvious, it's still a reminder that it's important to build relationships, as important as it is to build software. For them, it felt like they were not able to get the same level of impact, or when they approached strategy or projects with the intent of making progress, people thought that they had the wrong intentions. They thought they are trying to step over other people's toes, or they are trying to steamroll them because they hadn't spent the time building relationships. That's when they felt like they cannot work in a silo. They cannot work in a vacuum. That really changed the way they started impacting a larger audience, larger team of engineers, versus a small project that they were leading.
The third one is for the SRE folks. This person went to multiple startups, and at one point in time, we all know that SRE teams are generally very tiny, and they serve a large set of engineering teams. When that happens, you really need to think of not just the technical aspects of strategy or the skill sets, but also the people aspect. How do you start multiplying? How do you strategically use your time and influence not just what you do for the business? For them, the key thing was that they cannot do it all. They started asking this question as to, if they have a task ahead of us, is this something only they can do? If the answer was no, they would delegate. They would build people up. They would bring others up.
If the answer was yes, then they would go focus on that. The other thing is, not everybody has an opportunity to do this, but if you do, then do encourage you to do the IC manager career pendulum swing. It gives you a lot of skill sets in terms of how to approach problems and build empathy for leadership. I'm not saying, just throw off your IC career and go do that, but it is something which is valuable if you ever did that.
This one is a depth engineer. It reminded me of Mitchells and Machines. They thought of it as expanding from interfacing with the machine or understanding what the inputs and outputs are, to taking a large variety of inputs, which are like organizational goals, business goals, long-term planning. This is someone who spends a lot of focused time and work solving hard problems. Even for them, they have to think strategically. Their advice was, start understanding what your org really wants. What are the different projects that you can think of? Most importantly, observe the people around you.
Learn from people who are already doing this. Because, again, this is not perfect science. This is not something they teach you in schools. You have to learn on the job. No better way than trying to find some role models. The other piece here also was, think of engineering time as your real currency. This is where you generate most of the value. If you're a tech lead, if you're a staff-plus engineer, think how you spend your time. If you're always spending time in dependency management and doing rough migrations, and answering support questions, then you're probably not doing it right. How do you start pivoting your time on doing things which really move the needle?
Then, use your team to work through these problems. Writing skills and communication skills are very important, so pitch your ideas to different audiences. You need to learn how to pitch it to a group of engineers versus how to pitch it to executive leadership. This is something that you need to be intentional about. You can also sign up for a technical writing course, or you can use ChatGPT to make your stuff more profound, like we learned.
Influencing Organizational Culture
The last thing I want to talk about is this character Aang, in Avatar: The Final Airbender, when they realize what is their superpower and how do they channel all the Chi, and then start influencing the world around them. To me, this is the other side effect of just your presence as a staff-plus engineer and the actions you take, or how you show up, whether you think of it or not, you're influencing the culture around you. Make it more intentional and think about, how can you lead by example? How can you multiply others?
Also, partner with your leadership. This is a thing where I invite my senior engineering tech leads to sit at the table where we discuss promotions, where we discuss talent conversations. It's not a normal thing, but it is something I encourage people to do. Because, to me, it's not just like having a person who's a technical talent on my team, their context can help really grow the organization.
Role of Leadership
The last thing, if you have seen this documentary, "The Last Dance", about Michael Jordan. I highly encourage you to see this. It's very motivational. Then, in terms of leadership, everybody has a role to play. What I want to give you here is, as a leader, what can you do to empower the staff-plus engineers? It's your job to give them the right business context and technical context. I was talking about this. Do not just think of them as technical talent. Really invite them, get their inputs in all aspects of your own. I know this is a hard one to do. Not everybody thinks about it. This is how I like to do it.
Then, giving them a seat at the table, at promos, and talking to exec leadership, and protecting their time. Finally, this is another one where, as a leader, it's your job to pressure test strategies. By this, what I mean is, if your technical leadership is pitching all these strategies to you, it's on you to figure out if this is the strategy that will deliver on the org goals. How we do this is by having some meeting with the technical leads in the organization and leaders, where we work through all the aspects of strategy that I talked about, and we pressure test it. We think about, what will happen if we go build route or if we go buy route?
Then, that's an important feedback loop before someone takes the strategy and starts executing. Finally, help with risk management and help with unblocking funding and staffing. If you do all of this, then obviously your leaders will feel empowered to think strategically.
Recap
Understand the difference between strategic thinking and how it builds upon creative thinking and critical thinking. How it's a different muscle, and why you need to invest in it. Thus, we covered the strategic thinking framework. It's a pretty simple thing that you can apply to the problems that you're trying to solve. Then, important as a staff-plus engineer, to play a critical role in how you balance innovation and risk. Understand what drives innovation. Apply some examples that we talked about. You are influencing the culture. I want to encourage all of you to grow and foster the strategic thinkers that are around you, or if you are one yourself, then you can apply some of these examples to your context.
See more presentations with transcripts
