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.