Why Coding Skills Won’t Get You To Staff Engineer

If you are an engineer who actually comes and asks me tell me what to do, you already failed the test. He came to me in a month and told me that's not an important problem. The best idea should win irrespective of hierarchy. To go to a staff engineer, you need to lead an engineering team of like 10 people. That's like a meme. The reality is it doesn't matter. We will celebrate engineering

depth, we will celebrate impact. You're an IC engineer, you could get the most highest level by having an impact on the business. As you level up a software engineer, your scope, responsible abilities and impact, they all increase and you become more of a product engineer as you understand your customer domain, your business deliverables, and you measure your results. That's exactly what we discussed today.

And joining me is Praveen Murghasan, VP of Engineering over at Samsara. And we discussed what great engineering looks like, especially when the stakes are high. How do people act and how can you incorporate that in your own day-to-day as software engineer? So enjoy. I was talking to MO from ServiceNow a few days ago, OK. And he mentioned there's a lot of room for growth in specifically a new engineering role or not really new, but more more trendy.

I think in the forward deployed engineer, that is 1 role that I think is quite interesting. It's very much consultancy. It's very much understanding your customer, understanding your product and then doing kind of a version of an

implementation that is custom. That role next to product engineer, especially with the introduction of AI have been really on the forefront of my mind, I would say as very interesting roles that are now more up and coming from your perspective, I'm wondering what the difference is between when I say product engineer versus regular software engineer. Your thoughts on that? Yeah, No, it's a great question.

So I think from a product engineering perspective, I think the main thing is you are already responsible for a product that you're shipping to customers or you're working on a product that's shipping to customers.

So you actually get like, you know, the direct connection to the customer problem, right? So I would say like effective product engineers who I've seen like effectively grow really well, or people who actually understand the impact of their work and they want to really understand the why of like, what am I doing? And like, you know, why should I do this particular like work? It's something they deeply understand the context for. Like they partner with product

managers really effectively. They're not necessarily people who are like waiting to be told what to do, right? Like, so you think about the job as like part building business context and customer context and being able to effectively partner with product leadership to actually also like give shape to the problem. It's one of the things that as an engineer you always hold a unique advantage is you

understand technology. You also like, you know, want to be somebody who keeps up with trends of technology today in the world of like when you think about AI and all, like there's a lot of tools available now, like historically machine learning or like building complex data products used to be dedicated to specialists like you have data science functions or like really like engineers or like applied scientists who would do deep work. Today it's become a lot more

accessible. So a great product engineer can really understand what's possible to technology, understand the business context and help develop like the right solution, right? Like should you almost shrink the solution in phase is I think what great product engineers do. And it also ties back to a little bit of evolution of

software engineering in itself. I think over time, when you look at it, a lot of software engineering was about the build phase, like where people would anchor on the build phase.

Whereas today it's evolved quite a lot from a lens of like, you know, you would see that the most effective software engineers or even the people that grow themselves in their career are usually the people who do the part of understanding the business context, really well-being able to actually take that context and reshape ideas and also like partner effectively with product and other stakeholders. Interesting. Yeah. And also like just demonstrate this notion of extreme

ownership. I would say like where like an example would be like, you know, in, in our case, if we were to run a project, right, like, and we talked about the concept of a technical DRI. Let's say if we assign a product engineer as a technical DRI, the expectation becomes like from day one, they're like working with their product managers to go understand like business and customer context.

And then from there they are able to actually like drive the entire project end to end, where like the engineer usually is the best person suited to see the through line of a project. Like an example, when you think about it is like any product that you're trying to build has like a design phase, like product iteration phase, actual building, but then you go back to design and iteration, right? But ultimately at the end of the

day, what do you ship? The end product is something that an engineer built as like going through the entire

development life cycle, right? By making the engineer the directly responsible person from some product to ship, they have the they see the true line and they're the best suited people to actually flag and tell you if you're like in like any organization on where the product is in terms of like health, is it going to ship on time, whatever you plan for, what are the risks you're seeing?

So that's also one of the reasons why we anchor on like this role of like, OK, a product engineer needs to be a technical DRI to see a product ship end to end. But then what is the role of a product person in that? Because my assumption was, OK, product in the end is responsible for what ships. And I've seen some technical product managers when it comes to kind of a technical platform or product rather and that can be a platform that taters

towards engineers. But when you're saying, OK, I have a product engineer that's directly responsible individual at DRI, what is the role of a product person there? Yeah, no, it's a great question. I think the to, to distinguish,

right, like any product that you want to build usually like, you know, has a very clear product definition face, right, which means it's, it's actually quite a lot of work before you define what's even the right product to build. And it will be motivated also by many different things from, you know, is that a, is there a common customer problem that you're trying to solve? It's like one thing, what's the business opportunity is another, right?

So there's a lot of pre work to the sausage making of building a product, right? So I think about product management is a lot more of like an 80% role is actually customer facing or outward facing, not your internal operations or management of a project. Like project management is a very different thing and it's not the job of a product

manager. Sometimes people confuse this and the best companies usually lead to managing an individual project to internal people like a technical DRI or an engineering manager. In most cases in in Samsara, where I work now, where it's fundamentally we've defined it as project management's as an aspect of a technical DRI responsibility. And in some cases, when the project's fairly complex, we might tap into like a technical project manager where it's like it's involves 20 teams, right.

Sure. Like then it makes sense where you actually have some structure around it. But if it's involves one team, an engineer who's like, you know, technical DRI should be able to do it. Yeah, So we think about product management's more like a very customer facing role. It's actually defining why we are building something, the business outcomes etcetera. The second part I would say of product management is also really understanding and giving shape to the customer

interfaces. So this could be be the person who actually coordinates across the user experience and like, you know, product design and also engineering, like the person's actually like actively understanding the customer needs, what you're trying to solve for and translate that into like the right user experience in collaboration with understanding what it takes to build this, which is where the technical DRI becomes a key stakeholder where like the DRI

will have an influence to say, for example, hey, this is the problem we're trying to solve. We could design this product in either way. A or BA might take you like 12 weeks, B might actually take 3 and B might be enough to actually ship a first version of a product.

So this is where that collaboration super crucial where having the technical DRI involved in that conversation sort of helps you both like de risk accelerate learning in general in terms of getting products out to market quickly, so you can learn quickly and iterate quickly, which is what like you know, is important to stay competitive in any industry today. Right. And I see it scale way more easy that way as well.

The thing is though, within teams, team of software engineers that kind of let's say project management or more orchestrating, more operational thing, I've always seen that executed by a product person. What you're saying is let's say a product person that is only doing that for 20% and is way more engaged with customers and strategy and how does that fit into the business? We'll be able and better equipped to then steer bigger programs and much more teams

working on that product vision. And I haven't been in a team sadly because I would love to see this that has actually operated at that scale where there are directly responsible individuals that take up kind of the technical program management within their team or as responsible person for their team and then solidly execute in that way. Yeah. Yeah, Now 100% right. So think about this for like a second, right?

Like, an example would be if let's say the project management or like reporting of a project or is owned by, let's say a product manager, right? They have to go through a phase of first information gathering internally, Yeah, because they don't know which engineering projects at risk because they're not writing code in general, right? They also don't know about all the dependencies.

And it becomes it shifts their job to be spending too much of their time now on like I'm talking to other people to collect status to like, you know, report out. That's what it feels. Like also from an engineer within that team, correct So, but. All of that's overhead, right? Like when you think about it, if you just make the engineer who's building it responsible for it, they see the true line. Like, why would he just not make

the engineer responsible for it? Obviously the one reason which is commonly cited is hey, like, but it's taking away time for me to build right now. This is where judgment comes a little bit into question where like at least the way we work at Samsara is like we have a standing policy to say project

tracking internally is like done by engineering, meaning it's a technical DRI and by default. But in case the project gets a little bit more complex, it then falls on the shoulders of engineering management. OK, if it becomes super complex, it's like one of these projects which require like coordination a lot. We will assign a technical project manager, but we will not make a product manager to it, which I don't think is the right.

So, so all because you've just taken away valuable time to give and shape customer outcomes, which is what the role is about. Like it's about managing the product, not projects, right. So, yeah, yeah. For me, when you were discussing kind of understanding the business problems in the context and mainly why we are doing things, especially early on in my career, I wanted that, I needed that.

If I didn't have that and I still have that to a certain degree, if I don't understand why we're doing this, it's incredibly demotivating because I'm just flying blind and I, I can execute to a certain degree. That's just the discipline that I have. But as I progress in my career, I have less and less patience for being in the dark. Like I truly need to understand if the ship that I'm on, if it's sailing in the right way, or if it's at least the vision that I

can see myself behind. Because otherwise I feel like I'm, I'm wasting my time. Like I don't just get joy out of executing. I want to execute and as a result have certain outcomes, certain outcomes that align with

a level of personal fulfilment. But also then what I see in an organization grow and have good business outcomes that I feel like from a early on in my career perspective, maybe I was kind of where I had these tendencies as product engineer and other fact that we are a lot or a lot of times in the dark and there is a lot of engineering capacity and building becomes easier than software engineers are kind of naturally more trending or you're your unique selling point

as engineer will be to understand the business and then be the the silver lining throughout kind of the the technical project to execute. Yeah. Yeah, 100%. I think I one of the things I loved from our conversation earlier was the fact that you've done both product and engineering. I think it's like one way where you can get a taste of both, right. And I think now, as you said, you become this engineer who probably cannot work without that business contest anymore. It's very difficult.

Exactly. So I think the way to do it is like there are we talked a little bit about how do people get to those skills? And that's another way to do it, right? Like, but I would say, as I mentioned earlier, like the best way to do this is actually go find the environment which allows for this, right? So it's like what we're talking about is unique about cultures

of how companies work. And it's something I would encourage engineers like to actually find out more about, Hey, like this is like, is this an culture or a company which is going to allow me access to my customers or who I'm working with? That's a question you probably want to ask as an engineer and you want to find companies which sort of understand celebrate this.

And there are many of them by the way, like you know, and it's also like an evolving like, you know, trend in the industry. I would say especially with the advent of AI tools, etcetera, like where the building portion, I wouldn't say it's becoming completely like eliminated or anything radical, but we know there's a lot of leverage people are gaining out of AI tools.

A lot of the problem, the, the core art of engineering is problem solving with the business problem in mind and to create like a business impact, right? That part is not going away anywhere, right? Like problem solving as a concept is going to, it's here to stay, right? We will always have new problems to go solve and the tools to go solve those problems are helping us and become more simpler, which is where what the leverage

you're getting. And yeah, I think it's like the engineers of the future are just the people who actually know how to leverage these tools the best to go solve the right problem. So being able to build context and on the business is going to help accelerate companies. The more people companies have where they have demonstration of like curiosity to understand the

business and like the customer outcomes, those companies will thrive. And like, that's like I think what's happening in the industry in itself and that you'd see more and more engineers who like companies will try to attract and recruit. Like I try to do that all the time. It's like find people who demonstrate a lot of curiosity and has a track record of like, you know, focused execution towards that curiosity. That's equally important. And that's a winning

combination. Like, in a way, it's a very powerful combination because when the more people you have with those skills, you don't really need to prescribe to them. Also, like, what to do? They would often tell you what to do. Yeah. Because they've, they've they will not wait. And they will try and figure things out and then they will start. Yeah. Is curiosity something that you can cultivate? Because for me, I've always had

it for certain topics. I'm just very curious when it comes to let's say deep tech and maybe even fundamentally how a lot of things work. I haven't been curious until I've had to apply it, which makes sense for me because I'd like, I don't like wasting my time. To a certain degree. I I still enjoy a lot of things

that are time wasters. But when it comes to deep tech, I don't see the need of learning a lot of things with regards to that because there is just an abundance of things to know until I actually, I'm at a certain point where I have to apply it. And then it's scary because then you have to dive deep and you have to make it your own quite

quickly. But that's always been a driver for me. Being curious at the right time or even in advance cultivates or kind of stimulates Dr. And then where I see people lacking curiosity, I sometimes also see a lack in drive. And you can compensate that with discipline. But I also, as a team lead a little bit closer to, let's say, engineering manager. If someone's not curious, I have no clue how to do it because I

have it innately. And if someone else doesn't have it, I can't just say have it, yeah. Yeah, No, I think it's, it's a very interesting question, right? Like I think when you think about curiosity, I think can be cultivated, but it's also a little bit of like individual choice. And I think that's totally fine, right. So we've talked about in a way like, so when I think about businesses, different businesses, right, Like people, the businesses are in different stages and businesses have

different cultures, right? Like a culture could be like it's, I don't really believe that like, OK, what is whatever I'm saying is the only way to run an engineering organization or like, you know, develop products, etcetera, right? There have been many companies over time successfully evolving, which has operated in like a very waterfallish manner of

working, for example, right? And there's been companies that actually like, have I've seen people worked in an environment which is like boxed to say this is your role. Do that really well, right? In those cases, like what I would define it as is like it's called focus, right? Like, you know, you have a very clear responsibility and having focus towards doing that, it's a powerful thing.

So somebody you might look at their resume and they would say, hey, like I actually had the built up a really strong skill set as an engineer and I actually like was given this specific problem and then I did really well, right? Like, and that person can be immensely successful, right? The question if you ask me though, would I hire that

person? I would probably say it's still no. I would look for like curiosity and that's more my personal choice in the cultures that I want to build in. Like, you know, taking into account like the phasing of where the business I work at is like some sort of a high growth business. Like, you know, we while it's a reasonably larger size business with like billions in revenue, but we consider ourselves to be

the missions like 10 plus years. Like what we need is actually people who can deliver with focus but bring along curiosity because they have this multiplier effect in the organization. It's not just about for them getting what has been asked of them to be done, but they can also help shape or give way to what are the next 5 things we can do by short circuiting some of the processes slash like just general product development approaches.

Maybe did talk about technical Dr. is or like product engineering, which is where like, you know, being able to be a good engineer with really good skills, you actually can focus and actually develop and have a track record of shipping products. But coupled with curiosity, you would know what is the right sequence to build. And also like you could actually have an influence on how you can help accelerate the growth of the business, right? So. So I think that's the.

A little bit of a difference, I think, and I think it comes down to individual choices. I do think though, the evolution of like, you know, AI in recent times is going to push more of the industry forward into the direction of people that thrive are the ones who actually can demonstrate both curiosity and focus. Like, and we also see like another way to think about it is like even when you study engineering carriers, there's always like outcomes could vary,

right? Like some people actually have disproportionate outcomes. They would actually grow themselves to be like really senior engineers quickly, etcetera. And you usually could bat and match that to people who have both curiosity and focus, whereas some people would still be very successful, work at like really incredible businesses and be a part of that journey, but might not grow to those higher order influential roles.

And that usually comes down to their, they might be very focused engineers and really good at their job getting stuff done, but they didn't really like enable the impact of that business, which requires curiosity. Gotcha. Yeah. Curiosity is always been a big driver for me, and I also see that the people that tend to not necessarily be curious, they

might be the most headstrong. Like when someone disagrees with me, I think it's interesting because if I have a certain perspective, if I have a certain vision and then someone that I think is is very smart, someone that I admire disagrees with that, that means there is a learning opportunity. I'm not going to try and convince someone from what I believe, but I want to understand their perspective because then I can better judge what is in the middle or is it

mine or is it his. And in the end, the outcome doesn't matter. I learned something and the people that are curious, I've seen kind of not necessarily throw away their own opinion, but take this as an opportunity and learn from that. Yeah, no. It's 100% right. Actually, what you said resonates with me. Like, you know, in terms of people that are curious, like want to learn. I think learning is the driver. I think that's foundational,

right? To give you a practical example that I actually saw was like, we had like a product that like, you know, which is about like detecting some signals with data available. Like, and we had the solution that was built like long ago, but we almost got to a point where the customer was not happy and like, you know, we'd like thought, OK, like we're hitting a wall or a dead end, right?

Whereas when we hired, we actually ended up hiring a new engineer who actually like started and started to look at this problem with fresh eyes. So he went back to sort of square 1 and question a lot of the fundamentals of like how we thought about solving this particular problem. And he was able to also like reconnect and talk to people who had built the original solution and like understand both their

point of view. And then we kind of came up with this iteration, which was almost like, you could call it going back to first principles like erase everything that's been done, like you've spent a year, but sure, really like going back to square one and then rethinking how we should build

this solution. And we were able to come up with a new methodology to like, you know, approach the problem, which actually we are now like rolling it out to customers and we are already getting very positive feedback on. So it, it comes down, I think when I reflect on that particular like story, which happened in the organization, I

see two things. 1 is like yes, having people who actually bring the mindset of like being curious about problems and like being able to go to the depth also like it, it really helps you. The other one that I also felt that helped is like, you know, and as you said, like curiosity. Curious people usually come at it from, they usually also like a coupled with like a mindset of collaborating.

It's incredibly powerful because then you get like you, you're sharing ideas between like really smart people. And then you also bring the notion of like the best idea should win. Like we at Samsara, we actually talk a lot about like meritocracy. Like one of the things that I enjoyed telling people and talk about is like the best idea should win.

Like wherever it comes from. We would have a like, you know, we generally like to celebrate the idea of the best idea should win irrespective of hierarchy specifically, right?

Like, and I've usually always seen like the best ideas come from like everywhere. Like we've have stories from like interns coming and having an impact by like kind of asking like the question which nobody thought about and so on, right. So, but I think coupling curiosity with a culture where you actually can eliminate hierarchical thinking is incredibly powerful. And pulling people together in that environment usually results in like the best outcomes for the business. Right.

And like, yeah, when you're running a larger businesses, you you have to think about these as like more like, OK, how do you make make it in into the company's culture? And I think, yeah, we, we try to do a good job there, like try to kind of celebrate some of these stories. And like when we see these instances go bring it back to like an all hands setting and actually tell people this is what good looks like. It cultivates that into the culture that's. Very nice.

Like I've never been responsible for cultivating such a culture. Fresh pair of eyes is incredibly powerful. But the hiring strategies that I've seen, they very much still test on hard skills. I was at a conference and it was about technical leadership and then we had an on conference and I was like, I really want to talk about AI and hiring. Like what, what have you changed in your hiring process? What is still solid and what is different?

And some people are like, well, we're still experimenting or we do have a hands on part of the hiring process and then it's in a call. And then I'll say, well, I'll just jump back in two hours. And that person stays in that call and executes and they can use whatever AI tooling. Other teams I've seen or companies that say, OK, we expect you to use AI and we just do pair programming. So do whatever you do normally and then I'll see that.

But that is all very much with regards to hard skills. I'm wondering when you say, OK, I look for hard skills, but I also want you to be curious. And if you only have fundamental hard skills by virtue of not you not having curiosity, I'm less certain on are you going to be collaborative? Are you going to be asking questions on the business outcomes? Are you going to care at all?

How do you then in your hiring, because you are in the end part of the people that is responsible for this culture and you want people to be curious to drive business outcomes. How do you make sure you actually find the people that go through and then are part of that company? Yeah, no, it's a, it's a great question.

So the, I think one thing we look for effectively when it comes down to hiring is like some techniques to actually check for these skills that I talked about, like curiosity and focus, particularly if you unpack it, like how do you go for, how do you go about it, right?

So the first thing is we look for trajectory of people over their time, like whatever they've done, like, you know, one of the things that you can always look for is like, you know, people that have had like some degree of a trajectory like would have usually done like or delivered outcomes for a business, which actually made them like, you know, successful and they got promoted in other places, etcetera. Right. And we dive into it a little bit

more into the details. The, the most common question I end up usually asking people is like to talk about like one of their favorite projects and like why? And it's a little bit of an abstract easy question, which you might get. But what I'm looking to hear is about the first thing is I want to understand, like, do you really understand why you bought this product?

What's the outcome? Like if this goes back to understanding the business outcome and is sometimes people tell me I was told to work on it, that's actually a flag for me. Like, you know, it's like you just like went by somebody else's vision, but like you didn't really paint a vision yourself. So that's something I try to dig into, right.

The other thing I look look for is usually when people talk about their like, you know, journey is actually like talk about or ask them for specific decisions they influenced and made and the why, like, and if you've really done the work which you picked as a project, you can talk to those details really well. And then actually I look for some degree of excitement from the person talking about it.

Usually the person who's really done it is very excited and proud about some of the things that they navigated along the way. Really proud and really proud about it. And you can actually easily feel it. You can like, you know, get it out of the conversation quickly because they know the details. They feel good about some of some things that they've done. They usually also get a little reflective on, oh, I learnt this later, like, you know, and so those are all really strong

signals. And then you look for two things. One, did they get the business context, the customer context asks you executed on this project. What did you do with that? Did you do anything with it is something I usually fish for like, you know, OK, you got those contexts you executed like, yeah, we this was the technically hard part of it. All of that's great, but did you do something to either like, you know, accelerate timelines, like make it a better customer

experience? Like think through the longer term impact of the product you built, Maybe like you made a technical decision with a forethought off. I know we've done this, but the next three things we're going to do is this right? So, so those are incredibly strong signals. The other thing which by default I look for is like people's demonstration of focus. Like I mentioned, curiosity and focus being the other thing.

Focus is very, you can only very clearly see where people have actually spent their time and shipped meaningful things over time. This is just almost like a test of time thing, right? Like, you know, you sometimes have engineers who hop around all the time, like, you know, a year like into different jobs and so on.

What I personally feel from my experience is like if you really want to deeply build something great, you need to put your time and you need to actually like iterate on it and really be

focused on it, right? So and that you get signals by really understanding, have they worked on problems which they saw it from zero to 1 or like, you know, took it at from some point to another major point, like almost like a step function change in outcomes for the business and were they able to stay with it through the ups and downs, which I think is a very powerful thing to look for, especially in today's world. It's extremely easy to get distracted.

All know that, right? Like everybody is like so many sound bites around you, so many tools thrown out at you. Like focus is a really powerful thing. And I think a lot of the people who succeed would agree, say like, you know, the curiosity and focus I think are the most powerful things. And I try to like really like look at that through deep diving people's work in an.

Interview the first part that you mentioned of what is a project that you're proud of or what are some of your fondness memories with regards to learnings or even failures that you can share. I typically ask that from an interviewer perspective, like from an interviewee perspective to my interviewer because I want to see that same spark.

If I'm going to work with these people, I actually want to just like you see if that spark is there. If they have done something at this company that I'm applying for that they are proud of or that it's a failure and they've learned from it. I want to see introspection. I want to see productivity. I want to see reflection and learnings because then I know for me and from my perspective, it's an environment where I can do the same. There is room for that. People are already talking about

that. It's not the first time someone has asked a question like that. I don't want it to be something new that I introduced. I want it to be part of the culture that I'm applying for, which I think is very powerful. And sometimes from an interviewee perspective, you might think, OK, what am I going to ask? Honestly, just having a personal conversation and going on that level I think is completely. Fun. I think it what you said makes a lot of sense, right?

Think about this for a second. You asked me earlier in the conversation like hey, like how do I as a person find an environment where I can become a great product engineer, technical DRI, etcetera. This is a good shortcut way for you to get to an understanding if that environment actually allows for it, right? Because you're just asking the same question of like, what is it like to work here, right?

Like you'd get clear signal around why somebody's saying that's because either they worked in and like for you to learn these skills, you need an environment to be very clear, right? Like not every company operates like this, like I worked at different places and people choose to do operate differently.

So you want to understand if that environment is going to be like product centric, like the environment's going to actually enable you to be able to. Is the environment actually going to tell you like, you know, hey, show curiosity, like understand the business problem? Are they going to tell you like, you know, go to your job? Yeah, right. Like we told you to write code for these four tickets. You might you want to ship, you might not know why.

Just execute, correct. Yeah. And so that's something that you want to get a signal. So it's a perfect question for you to ask and look for the actual signals from, like, you know, a good way to understand the culture rather than ask somebody. OK, tell me about your culture. Like, OK, tell me about your favorite project. Yeah. Yeah, absolutely. I was speaking with MO and then we were diving deep into the forward deployed engineer role.

And from that I had the feeling of, OK, you have a lot of responsibilities on your plate. You need to be technically apartment to know your product. You have to dive into customer contexts and figure things out and how to make that match, also understanding the business problem. So then I thought maybe it's not a good role for people that are early in career and I'm wondering if product and understanding the business and innately early in career people

might be more curious. They're not as jaded as people that have been in the industry for 20 years and have burned themselves just a little bit too often to be that way. So they have that drives like a blank canvas, a real fresh pair of eyes. I feel like product engineers and that role, they are well suited for people that are more

early in career. They can come in with a fresh perspective and really bring things down to square one with regards to reasoning and asking questions and learning from that perspective. Yeah, it's an interesting thought, right. I think the so forward deploy engineers is something that we don't have at Samsara at the

moment, right. But I think I guess the fundamental way I would call the difference is like, you know, you're building custom solutions where you need a forward deployed engineer who's working more with a specific customer. All our product engineers work on products that's like catering to like a larger customer base, right? So whether it's like, but if the customer interaction is still true, so, so that's kind of the crux of it.

Now, when you think about like, you know, is that role suited for like an early engineer or not, I generally don't believe that like, oh, like these roles are only for people with experience or like like somebody who is like more earlier cannot do it, etcetera. Like I don't I really don't bind to that school of thought. I think the key is to if you are

trying to cultivate that culture and like you want to have it in your teams, meeting people where they are with their skill set and then exposing them to some of these qualities like which you want from product engineers and iterations. Like an example would be like, you know, you might actually have like a small feature which you could easily give it to a like a junior engineer who just maybe graduated out of school. And but then you use that as a means to teach them.

Hey, like what's important here is for you to actually understand some of the customer impact, etcetera. A trick to do that, which I often encourages and which is highly encouraged. It's I'm sorry, it's like getting engineers in front of customers, like have the product manager take the engineer to like even be a family on the wall. Like listen to a couple of calls like you benefit from these things, right?

So the IT goes back to you then understand the why and it helps you cultivate that mindset of like, OK, now I actually understand the why so I could make better decisions. And the second thing would be like teaching them to measure outcomes. Like, OK, you shipped something. Can you actually proactively think about actually like understanding if what you shipped as a feature, they didn't get adoption? Like why are people adopting it? And you could easily build out like dashboards, right?

Again, like this, I could consider a role of a product engineer where you not only understood the why and you saw the true line to the product, but you also measured what happened like, and you form an opinion on maybe you want to work with your product manager and to find the next iteration of this product because it didn't really get the outcome you wanted. But if you didn't measure it, how can you move on to the next thing, right?

So, so those are small things that like I think any engineer can do. And I think the way to think about it is like as people level up in their careers, they're just taking more larger efforts or like driving more complex things. But the mindset to work with ambiguity or the mindset to lean in on customer feedback and get this context needs to be developed and can be developed from early on, right. And so that's how we think about it. So not necessarily specific to

like, oh, you need to be senior. I would actually highly encourage more younger engineers to look for environments that support these and yeah, and like, try to cultivate these skills early on. Yeah, I think what I'm. About to say is is relevant for both people that are early in career, but also people that are more senior that will come at A at a certain point you'll face a challenge with regards to it's something I've never done before.

It is bigger than the scale of impact that I've had before. And I feel like in your position, you have many more conversations with people that are facing this, where you from your standpoint believe they can do it, but they from their standpoint, they've never done it, which means sometimes there's a lack of confidence or even a high feeling of imposter

syndrome. I feel like there's a lot of imposter syndrome in this industry and it's due to the fact that typically we are doing a lot of things that we might have never done before. If you're doing the same thing over and over again, are you really growing or are you kind of coasting? Sometimes it's OK and everyone's kind of family situation or personal situation is different. But for the people that want to grow, they will find themselves

in unknown waters. And more often you do that, the more confident you become. But there will still be an inkling of can I do this or is this beyond my scope? The further you grow in your career, the more senior you are, the bigger responsibilities you might get, and especially when the stakes are higher. Can some stress some people out? How do you have that conversation with people where you truly believe they can do something, but they don't

believe in themselves? Yeah, I know it's a it's a great question. So we when we actually like rolled out this notion of technical DRI at Samsara, we actually talked about this, right. So we. We didn't think about it as a binary or like only it's reserved for senior engineers and above or like special types of engineers, right. So we actually said we want to develop our entire organization

to build these skills. Like as a engineering leadership team, we we have a responsibility to develop our people with these skills if because we believe this is important for the culture of the company, right? So the way we went about this was two things. One is meeting people where they are like giving the scope of the problem that actually kind of stretches them like always like stretch people a little bit, but then meet people where they are.

Like we don't want people who might have never done like a, let's take an example, right? Like we had this project that we

had to ship in four months. It was for a big launch moment that we usually have like, you know, customer facing events and it had to chip in four months and then I had to personally step in and say, OK, we're going to have like this staff engineer lead this project because it's a mechanism to de risk like, you know, an outcome. So while we had really good senior engineers on the team, it's like not like we didn't

have good talent. That was not a place to experiment because you had like, the stakes are too high. It's just risk. Management. Exactly. It's a risk. Management thing, whereas in other cases where we didn't have that kind of like, you know, oh, we, we're not under a clock, we would take risks. Actually, we said like, OK, let's actually have this engineer in a couple of cases

where they've motivated. Let's give them the role in cases where people didn't want to push themselves or like want to pick up a larger challenge, we would give them a little bit lower scope problem and say like, why don't you operate in this? But it's still like fulfills the role at your level, but then you're slowly developing these skills. You're not in the in isolation. We also went one step further and said we actually want our junior engineers to develop these skills.

So the way we're going to do this is an Ng manager will be their backstop, but we're going to teach them along the way. Like you know you're building a feature, you're going to be a technical DRI, you need to work with your product manager, get on calls with customers. You will actually define the solution, you will report on it, flag to our status issues, etcetera, and drive it through the line in terms of understanding the impact of work, etcetera.

But then every step of the way will backstop you with an inch manager supporting you, checking in on you and making sure you don't you're not stressed in like, you know, distressed through the process. It's not like saying like either figured it out to do it or get out. Like that's what's not the intent. It's really like this is from an intent of it's going to help you

in your long term carrier. And I think the one of the things I try to tell people I work with always is like, you know, a lot of these skills are not about like, you know, just point in time going to help you in this job where you're doing today for this particular company. These are good skills to have. And it's going to, you're just going to be happy that you develop these. And we're in an environment which wants to support you through that. Yeah.

I think that's amazing. One of the things I'm really fond of is my experience in operations before I did any type of software engineering. And then figuring things out that are running in productions and issues that can arise. And the experiences of fucking something up. And then really just blowing up something on production and immediately getting a phone call and being like, I really don't want to answer this, but like, clearly they know it's me, so I have to. And owning up to that.

All those experiences in the moment, maybe not as fun, but reflecting back, I'm really thankful for opportunities like that where maybe I had a little bit too much responsibility or I don't even know and I wasn't even aware that this was a conscious de risk opportunity for me to learn and grow. But I'm really thankful for those opportunities very early

on because they really accelerate growth. Yeah, I know. You're 100% right. It actually brings a fond memory myself when, like, I was like, just a year out of school and like, I was now owning the system at Salesforce.com. And my mentor who was supposed to buddy with me on everything I do, he's checking all my work. He was actually on leave and the system was owned by just the two of us. Yeah. And on that particular week, it went off, right.

And I actually had like, you know, somebody from the customer success team, like at my desk asking, like, you know, I need to report back to these really large big bangs on what is going on and, like, do you have an update? And like, I was like, Oh my God. Like, you know, it was like

panic. Yeah. Like. And but I also have fond memories of that time where my manager at the time actually came to my desk and basically they got the customer success Rep out of my way, said let him do his job, you can come to me for status updates. And then he pulled me aside and said, like, don't worry, just focus. I'm here to backstop you and make sure like, you know, we get through this. And that actually helped me a lot. I was able to focus.

And then like, we found the issue in like the next maybe an hour or two. And then, yeah. And I drove that entire postmortem process, etcetera. Like when was the first time I were doing it? The first year out of school, like taught me a lot and, and you're totally right. I think the it's these experience that shape you and the moment it feels hard, like it's like people say like what doesn't kill you make you stronger. It's true, right?

Like, you know, actually, like you take these experiences and the next time you see it is like, you know, you can handle it with a much calmer head. And you also learn. And you now aspire to push yourself to like, OK, what else can I do? Because you're now testing your own sort of skills here. Absolutely. One of the thoughts when you were explaining where we put our staff engineers are for projects that really we cannot take. We cannot afford to be risky here.

And then other projects where you can afford a little bit more risk, you put on engineers that first of all want this and have to drive, but also where you're like, OK, I, I do think they can do it. They just have to prove themselves and then you have opportunities where there's room for people early in career that are enabled by other engineering

managers potentially to grow. I feel like if you have an organization where the engineers are very driven, you need to have enough opportunity where they are in these positions for them to learn and grow. If there's not opportunities and they get bypassed, maybe then there's not opportunity for growth from their perspective. So you need to have this balancing act of having the right people and the right assignments for the job. Otherwise, it's a lack of

fulfillment. I'm laughing because I just heard this last week. Well. That's a recent team. Yeah, Yeah. No, I think they, OK, I'll tell you the way I think about this

specifically, right. I think the reason this was this came up in context to us with AI leverage and with how the industry is shaping a common thing that most people will be confronted with right now is like teams are going to be smaller, there'll be more teams, but smaller teams is you can get stuff with some degree of AI leverage.

Obviously it's not like 100% there, but like, you know, you do get leverage, but the and a lot of people who get leverage more are people who are a little bit more senior, obviously, right. So, so teams are shifting in shape to be a little bit more senior. And this is happening in across the industry, I would say, right. So somebody had actually asked me like, hey, but like if we have a little bit of a composition shift, like what do we do for creating opportunities

for people? Like very valid question, right. My answer to that was pretty much consistent and always straightforward, like where we are not making the shift only separately just on by dimension of saying that hey, like teams are going to be a little bit more senior, etcetera. We actually coupled that with also like re looking at our what does it mean for our engineering hiring and also like engineering career ladder, for example, right?

Like most people, when you think about why do people feel this way, a lot of driven people want to grow to the next level and they actually there's an industry sort of meme, I would say is where for you to go to a staff engineer, you need to lead an engineering team of like 10 people. That's like a meme, honestly. Like that's like how a lot of big tech companies operate, right? The reality is like, it doesn't matter, right? You want to grow to US staff engineer, senior staff or

whatever. Like all these titles vary by companies. So, but fundamentally when you think about the skill set growth that you're trying to deal with, it's like can I take on larger complex problems that require a degree of ambiguity for me to go unpack and the impact on the business is going to be a step function change for the business in the context of public. That's what the definition really of anybody who's a senior, much senior engineer is,

right. Today with the world shifting, I think one we talked about a lot of more senior engineers leveraging AIS junior engineers to work with, right? So they're able to get more work done by gaining leverage. The ultimate measure of success for them is like, you know, did I have the impact on the business? And now we've normalized it to say, like, you know, you don't need to actually like meet a bunch of people.

That was just an industry norm in the past and I actually drove this process at Samsara to say like, you know, we will celebrate engineering depth, we will celebrate impact for what

you have on the business. If you are an individual contributor, you're an IC engineer, you could get to like the most highest level by having an impact on the business and also like, you know, just be an individual contributor without the need to be like, oh, I need to be managing A-Team or like, you know, I need to be the more senior person in the team. So, so that's one thing we've tried to squash and move along,

right. The second part, which you asked about is like the opportunities, creating opportunities. We've actually flipped the script here to say a product engineer needs to go learn about the customer and the business. So my view on this is especially for engineers who needs to grow beyond a certain level. If you are an engineer who actually comes and asks me tell me what to do, you already

failed the test. Like my expectation is we'll build you an environment where like you actually have access to customers, you understand the business strategy, you actually like, you know, have access to all the data from what's happening internally in terms of product usage, etcetera. We want people to actually come to us and tell us what to do, not necessarily like me prescribing or like, you know, this is what you need to do. And that's the type of engineers

that are going to thrive. Like, you know, it's at some sort of today, but also I think in the industry over time, right. So the so that's what I would tell people. And I think the two things that needs to transform is like companies in the industry need to move along from this idea of like, you know, you only go to bigger engineers by like leading larger projects that that means like larger lots of people that I think needs to shift along and I think it is shifting along and Italy.

And the second part is the environment you want to create is for people to understand, create opportunities, etcetera, not just be limited by like opportunities being created a little bit top down, ish, right. So, so that I think is extremely important. I can give you an example to make it practical. I had hired this engineer who recently joined us and I had originally told him go work on

this problem, right? Yeah, he came to me in a month after looking at that problem and told me that's not an important problem. I was like, OK, yeah, some. Confidence. Doing that is good, yes.

And because I think what he was doing was he was observing where all the engineering resourcing was going, what is the more important problem and what is the complexity. And he was just like learning about all the different product investments happening. He was a much senior engineer, so he'd, he did, I feel like giving coming in. He was a very senior engineer. So he had the he felt he had the

agency and like to do it right. And yeah, but I loved it that he came and told me like, no, I actually want to work on this other problem. And I told him why. And then he actually said like, you know, hey, like I think the current team is like a little bit struggling there. I think I have some of these skills which and I have also like a better idea of doing it. So so I said, OK, you have my blessing. Go do it right.

So he jumped on it and I, my original intent was to hey, like he was going to work on the project and be done right. So later he comes and tells me I actually under like to develop the solution end to end. We also have some platform dependencies which is owned by another team and I need them to

do something. I'm going to actually jump in and work with them and build this platform capability which is going to help ship this product, but also guess what, ship five other things which we want to do in the next year. Yeah, right. So he did that on his own, like I didn't tell him. Right. So you did enable him, that's correct. Yeah. So the general point here is like, you know, you can operate this way. Like it's just really you have to find the environment that

enables you. And these are obviously like the example that I called about is like somebody who's a very senior engineer. But my thing that I try to tell people on my team is like, I would do that for anybody, right? Like, and that's the environment I want. Like, you know, you, you should come and feel empowered to have conversations. I think the only thing is like, usually as you go higher in levels in companies, you just get access to more context.

And like, that's something that it's on us to share with more people, right? So, yeah. So that's the main way I think about it. Yeah. I love. That a lot, I think in environments where ideas win and it doesn't matter where you come from or what your role or title is or how much experience you have, even if you have the feeling of this might be a good idea and there's room for you to have that conversation and to execute then on opportunities as well. That's just from a fulfilment

level. I think that's going to be a blast. Operating in specifically. Yeah, before we round off, we've talked to product management, but also or product engineering, but also organizational culture. Is there anything you still want to share before we round off? No, I think the, the only thing I would say is like, you know, when I look back at my career, whatever helped me, if I were to summarize it, it, it comes down to like fundamentally like 3

things. I would say 1 is a little bit of an obsession to understand the impact of the work that I'm doing. Like, you know, and it's actually extremely fulfilling when you do that. I would say like, you know, so that's something that's I think I would encourage people to really lean in and understand

why am I doing, what am I doing? Like answer your why, like you know, and so you find the work that you actually like, you know, enjoy doing the most and then while you do it, demonstrate curiosity and focus, right? So I think that helps you do that really well. But I think ultimately I found joy in like finding work because based on the impact that we do, like, I think at Samsara, it's like very real world as it gets on the products I work on, like it has an impact on people's lives.

Like we do things which affect safety in the real world. We do work on like, you know, running the world more efficiently and like being more sustainable.

It it speaks to me in terms of meaning and like the how we do it. This where I have most fun because trying to foster an environment of like, you know, having a lot of talented, curious people and enabling them and like working on these solutions, which are very meaningful for the world in a way where you are applying a lot of cutting edge technologies that's enabling it today.

It's like incredibly fun. So I think I'd, I'd encourage people to like, you know, find what's fun for them and the usual way to go about this, like, you know, answer your why. And also for optimizing your career, just think about like the impact that you could be driving because every company out there will want people who can like kind of multiply the impact they are having in the real world. Yeah, thank you so much for coming on and sharing. Of course. Yeah, awesome.

We'll round it off here. If you're still listening, let us know in the comments section what you thought of this episode, and otherwise we'll see you in the next one.