It's really important to understand the stage of your
company and the kind of risks you face at your stage and make
decisions that are appropriate and remind other people about
that the other people that you work with all the time, hey
everyone, my name is Henry Surya we Robin.
And you're listening to the technology, you know, podcast
the show where I'll be bringing you the greatest technical
leaders practitioners and thought leaders in the industry
to discuss about their Journey ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our Journal. Hey everyone.
Welcome to the technology on our podcast, the podcast where you
can learn about technical leadership and Excellence from
my conversations with great thought, leaders in the tech
industry. If this is your first time
listening to technology, you know, subscribe and follow the
show on your podcast app and also social media on LinkedIn,
Twitter and Instagram. And for those of you longtime
listeners who want to appreciate and support my work, subscribe
as a patron at technology. No, dot f / Patron, or buy me a
coffee at technology, not Dev slash.
My guest for today's episode is Sarah milstein Sarah is the VP
of engineering at Daily and has run remote teams for 25 years
and this episode Sarah started by sharing some remote work
insights. We may not have heard before
such as why remote. Distributed teams often have
higher propensity of trust how remote work.
Could help make difficult conversations easier and how
leaders can establish Swift trust by having more intentional
communication. Asians in the second half of our
conversation, Sarah shared about her experience of leading
Engineers, as someone from a non Tech background, she explain why
a lack of technical expertise can sometimes be useful and
point it out some leadership qualities and Engineering leader
should have to balance out the need for technical Acumen.
Sarah also shared her few tips on how to obscure her selves in
technical staffs. And her perspective on whether a
company should consider having non Tech, engineering leaders, I
enjoyed my conversation with Sara, and if you also enjoyed
this episode and find it useful, I would appreciate it.
If you can help share this episode with your colleagues
friends communities. So that more people would also
be able to learn from this episode.
Please also leave a five star rating and review on a podcast
and Spotify which I will highly appreciate.
Let's go to my conversation with Sarah after a few words from our
sponsors. Are you looking for a new cool?
Swag? Technology, you know.
Now offers you some swags that you Purchase online.
These wax are printed on demand based on your preference and
will be delivered safely to you all over the world.
We're shipping is available. Check out all the cool swag is
available by visiting technology.
No dot f / shop and don't forget to break yourself.
Once you receive any of those tracks.
Hello everyone. Welcome back to the new episode
of the tank original podcast. Today, we have a guest named
Sarah milstein sees, the VP of engineering at Daily So she has
a very unique experience of having to work in or manage the
remote teams for more than two decades.
I think this is really interesting.
Today we'll be talking a little bit more about remote working
her experience or any insights that we can learn from her
anything that we haven't learned from the pandemic because she
had more than our experience, right?
So Sarah, thank you for this opportunity.
Looking forward for our conversation.
Henry, thank you so much for having me.
So, Sarah, I always like to start my conversation by.
Asking you to share your career Journey if you have any
highlights or turning point. So you think what to share with
the audience here? Yeah, so I started out working
in nonprofits and I wound up being able to find work as a
freelance journalist writing about tech and got lucky in that
I was able to write for the New York Times as a freelancer and
through that, I got connected with O'Reilly media which at the
time was a big book. Sure and Conference producer and
O'Reilly hired me to help edit a series of books in my work with
O'Reilly, in addition to getting much closer to the startup world
and the software world. I also had the experience that
editing books was a lot like shipping software at the time,
which is to say that there were a number of repeatable processes
that you need. Get a whole team involved in and
typically there was a ship date after which you would learn if
anybody was going to buy the thing because at the time
software shipped on a date and it came on a CD and you had
really no idea if it was going to be successful until you spent
sometimes years and thousands or millions of dollars on it and
books were similar and it seemed like a sort of a broken model to
me that we could do things a little bit differently.
And I started to learn from some of the books.
We didn't publish these books, but at the time, the extreme
programming books had an idea of pair programming and trying to
get closer to your customers and like the agile Manifesto was,
you know, for what it was, there's been lots of argument
about it since, but it had this idea that you want to really be
connected to your customers, you don't want to build things that
are irrelevant. And those ideas felt really
exciting to me in editing and I started to bring those into the
book publishing process. And then eventually kind of
jumped into the software world to be able to work more directly
on things that increasingly as the web developed.
You could ship continually and didn't require having to wait
years to find out if anybody was going to buy your thing and I
worked in a lot of different roles in software and a lot of
different companies over a number of years.
I wound up eventually running Lean Startup Productions which
Eric Ries With The Lean Startup book and this was a company that
we developed. Publish a bunch of his ideas and
related ideas and that brought me even closer in some ways to
the software world because those ideas were pretty influential
for a while. And it took me back into
software where after working for the federal government in a
software Organization for the federal government.
A friend recruited me to work on the engineering team at
MailChimp at the time MailChimp which is based in Atlanta.
Georgia had just opened an office in Brooklyn which in
fact, Incidentally a couple of blocks from my apartment and
needed somebody to run the Brooklyn office and serve on the
engineering leadership team and I wasn't an engineer.
But I'd been in software for a long time at that point and had
a lot of the business skills that they needed in the office.
And I was excited about the idea of working in engineering,
because it felt like it would be a more leverage place to be in a
software company and that I'd be able to apply more of the ideas,
more directly. And that was fun for a couple of
years. And I've since gone on to work
for a couple of other companies and Engineering leadership.
And so, in almost all the cases, as you noted earlier, the
companies themselves were remote, like distributed
companies or I was working in satellite offices or usually it
was a hybrid. And I was working with people
who were very distributed and often, I was working from home
and that's been true for actually, now more than two
decades in my career. So, it kind of an interesting
combination at this point of engineering leadership as a non
engineer and remote leadership of are very long.
Ang period of time. Thank you for sharing your
story, the two key things that we'll be talking a lot today is
fast about the or remote working experience.
And secondly, it's about being engineering leader coming from a
non-technical background. So let's start from the remote
work itself. So you have work in remote setup
or hybrid sometimes for more than two decades.
Most of the people has just started working remotely during
the pandemic and some people are even going back to the office
these days. So, working remote is something
that is unique experience, but Sure it's not be unique to you.
What are some of the key things if you can share?
When the pandemic happened is there anything that you need to
do differently from the previous remote setup that you did?
Well, I think one of the things that is true about remote work
is that it works incredibly well for some people and not at all
for other people and there are a number of people in between of
course to I think we've all learned in a lot of ways in the
last couple of years, is that there's no point in being
pedantic. Talk about what's better or
worse? It really depends on different
individuals and the culture of different companies.
Even though I personally prefer remote work and have found it to
be over time, more productive. And I can talk about that, I
want to be careful to note that there are lots of people for
whom for whatever friend number of reasons.
It's not the best mode and it's worth investigating for your
company. What's best and being upfront
with people when you're hiring so that there's not like Laura,
People on a false premise but that said I think there's a
number of things about remote work that I have found to be
more effective and some of it is just that to do remote work,
well requires good management and that's true in person to
like, you can get more juice out of good management.
Then you cannot have bad management.
But, you know, remote setting. You have to be, for example,
more intentional about communication, it doesn't
happen. Totally.
Now, I think that's a benefit having leaders and managers who
have to be more intentional, tend to be better leaders and
people get better information, more consistently.
You can do that in person, but lots of people kind of forget or
doesn't seem as necessary. So, there's lots of things like
that were remote work just kind of reinforces good practices,
but I think there's also some more subtle things about it.
That are kind of interesting. So, for example, a few years ago
before the pandemic I noticed, Self saying to somebody that I
preferred working in remote companies because they tend to
be higher trust environments and higher trusted.
Lots of research shows makes for much more productive and happier
teams and it was a little funny when I heard myself say that
because the conventional wisdom is, that remote work is low
trust. I did some research into why I
might have felt that way and why that might not be their
conventional wisdom. And I think what's interesting
is that it turns out that people have different ways that they
build trust with other people and different ways.
If they feel trusted, so there's some psychological terms for
this and I hope I'm not getting these wrong, but there's this
idea that some people have a high propensity for trust and
some people have a low propensity and I want to be
clear. I don't think that's the low
propensity is a judgment. It's just a different mode and
the people who are low, propensity feel more trusted
when people see them and they trust other people when they can
see them. That's part of their experience
of trust and they tend to start off the low propensity means.
Start off, not trusting people very much and you can kind of
build that up and part of the way you build it up as by seeing
each other people who have a high propensity start off more
trusting and you can kind of lower the amount of trust
certainly but they also tend to be people who don't need to be
seen to be trusted and who don't need to see other people.
They are more interested in the work product.
So you can see where people like that tend to be drawn to remote
work, and tend to feel like very trusted and like, they can trust
their colleagues in a setting. And that is kind of designed for
the work product, being the thing.
That's most important. So I think there's a number of
subtleties like that about remote work that we're still
learning and will take a while to get figure it out.
So, it's interesting that you mention about this propensity of
truss, right? I can get it.
For example, if you are totally remote company and you have to
hire people, definitely, you need to have a lot of trust with
the people also for the employee themselves.
Right. They need to put a lot of trust
in the employ even though, They may not see the bosses, they may
not see the offices, the colleagues and things like that,
maybe in the first place. How can we gauge this propensity
of trust for a candidate or maybe for an employer right?
How can we actually gauge that this is a good trusted place
that we can go to? Is there some tips that you
normally do whenever you get candidate?
So when you look at the next company that you want to join,
maybe some tips here for people who love working remotely Yeah.
Well, I think one advantage that we have gained is that in the
last couple of years, a lot of people have figured out whether
they like remote work and whether they hate it and a lot
of times if they like it, they are like the high trusting High
propensity. And a lot of times when they
don't they're low propensity. So there's a little bit of Auto
filtering. I learned recently that in the
time since before the pandemic LinkedIn has seen only a small
bump in the Were of companies that list remote jobs you would
think would be like a huge increase and it's something like
it went from 3% to 13% of their job listings but the job Seekers
went from like three percent to 50 percent.
A lot of people are looking for remote work and I think that's a
lot of people have discovered that they are more productive in
a remote setting and happier and they might not associate that
with trust. So it's a hard thing to ask
about and typically you kind of want to try to gauge.
Rather than ask directly for a lot of the things you want to
learn in an interview anyway, one of the things that we do at
Daily, where I am now we sell real time audio and video apis,
so that anybody can embed real-time Audio and Video in any
app or website. And so, we're like a pretty
technical company. And when we are hiring people,
we do for any kind of a role, we do a paid take home where the
candidates produce on their own time, some kind of work product.
That we've given them instructions for and they can
ask questions as they go and then we talked it over and
that's the main thing that we use to make decisions about
people but it's not just what they produce.
A lot of what we care about is how they talk to us about it.
Do they ask important questions as they go when were discussing
things and we're talking about the decisions they made does
that get into an interesting conversation where they're
asking us questions and are being a little bit of
vulnerable? And when we ask them questions,
they're able to say I don't know or be very clear about why they
made decisions. And those kinds of signals are a
lot of the sorts of signals that you get.
When you're trying to figure out trust with new colleagues, are
you able to ask questions? Are you able to answer questions
are people defensive or not? So defensive?
So I think that kind of stuff. Again, it's a little bit
implicit but can give you the sorts of signals that help you
figure out if somebody's will. Suited for your culture.
That's a very interesting statistics that you mentioned
are from LinkedIn, right? So I even experienced it myself
whenever I interviewed candidates, right?
Some of them will just say, yeah, I want to find jobs which
are only remote and they are plenty of them, which I
explained widely than the statistics found that many
candidates wanted to work remotely.
But why do you think some companies wanted to go back to
the previous setup? Even though, during the
pandemic, I'm sure most of them would have seen that it works as
well. Can remotely.
Is there anything in particular that you found with this trend?
So one thing is, I do think there's lots of people including
lots of managers and leaders who don't trust other people and
don't feel trusted, unless they see them and they want to feel
trusted as much as they want to trust other people.
Like, that's very important. So that's real for some people I
think though it is also the case to be completely candid, that
lots and lots of companies have spent a whole lot of of money on
real estate and real estate leases last for years and years
sometimes decades and they want to get some value out of the
real estate. You can have a debate about
whether that's a good motivation or not, but you could see if
you've spent that money and you feel a greater sense of trust
with your colleagues in an in-person setting or in a hybrid
like partially. You're at least in person some
of the time that can start to feel pretty compelling.
In some cultures, there are also, of course, times when in
person is more meaningful, a lot of people find that generative
work do brainstorming. For example, is easier in person
and richer, so that's valid and there are times when it's
probably not as useful to be in person.
But on balance, it might be hard to figure out what's worth it
and what's not and if you have a culture where people are already
used to it and the leaders tend to feel like they can trust
people more and They spent the money, you could kind of see
that math adding up for some companies I think makes sense,
right? Some people wants to have more
collaborative one to have in-person meeting and maybe spot
the creative conversation out of the blue right.
Not always in meetings video, meetings are more which
sometimes it's a little bit fatigued, right?
Another thing that you mentioned in your blocks that you have
some other insights from doing remote work, which you have
never heard before. Could you share, maybe some
other insights that you think are worth to share here apart?
On this higher trust because you said earlier, that remote works.
Sometimes breeds higher. Trust are there any other
insights that you want to share with us here?
I think there are a couple of other things that are
interesting and there's a few kind of basic ones I can talk
about. For example, this is a little
bit unconventional as well, but I have found that hard
conversations. Tend to be easier over video
than in person. So a lot of times people, if you
have to deliver difficult feedback or if your Lying
somebody off or having any kind of a really hard conversation
like that in person, people can feel really exposed
understandably. And, of course, sometimes people
cry and they have like, a whole big range of emotions when
they're on video in your, a little removed from each other.
Sometimes that gives people a little bit of space to feel a
little bit less uncomfortable with a hard conversation.
And that's true on both sides of it.
The manager and whomever is The info.
So I think that actually surprisingly can be a little bit
better. A little counterintuitive, I
think sometimes too. There's a real intimacy that you
can get at work. This isn't true universally but
a lot of people working from home you have a chance to see
their space you and I are on video right now so you can see
some of my books and you might be able to hear that my dog is
eating her food dinner. Pretty loudly which I apologize
for But you get a sense of my life a little bit, and it's a
kind of a form of intimacy to be in each.
Other's spaces to see each, other's families and pets.
There's a lot more cats wandering around video screens
and remote work, and a chance to be connected to each other
beyond the selves that we bring to work.
Now for me, I find that to be like a very compelling kind of
intimacy when I'm in an office working with people.
Now, I often feel like how can I know you because I don't see the
space. You inhabit otherwise and I
don't see your family and your pets.
It feels pretty disconnected. It's totally fair that not
everybody wants their family and pets in their house on screen
all the time, but it's become relatively common and to me,
that often feels like a very big point of connection that we kind
of lose in an office. You get different things in
person, but a loss of a real context for a person's life.
So those are a few of the basic things.
Things. I do think there are some other
more subtle things like a sense sometimes of having an in-group
feeling where people for whom remote work Works.
Feels like you're part of a community part of a group that
is a little bit different from the world where it doesn't work.
And that can be a little bit of a form of trust as well.
So in there's both some Logistics to it and some kind of
subtle human connection pieces, that can be really powerful.
Just do you touch on about the in-group?
Think maybe Keith can elaborate more, right?
So you wrote in your blog that you have this in-group bias kind
of thing. Maybe you can explain.
What does it mean? And what do you mean by people
associating as an in-group thing, whenever they work
remotely? And how does it differ with the
known remote work setup? Well, the idea of in-group bias
is that people who recognize some commonality among each
other identify with each other. And feel like they are part of a
group and that is itself Trust. Going to be part of the group, I
think before the pandemic, when it was much still like a thing,
but much less common that people work remotely.
The feeling of we like remote work and we're good at it, that
felt like you were part of a pretty special in group and
could just be itself, trust-building among people in
remote companies, out of the gate more and more people, of
course, and more. And more companies work this
way. Now.
So, it's a little bit less of an in-group that's differentiated,
from the norm. But it's still clear that
there's groups of people who like to work primarily in person
and groups of people who like to work, primarily not in person.
And I think in both cases, you get a little bit of in-group
sensibility of, were the kind of people who like to work in this
way. And as I said at the beginning,
filtering for the people who want to work the way you do, you
don't want a culture of people who are all the same.
You want people who add to your culture but you do want a
culture where people can work in the modes that you have set up,
and if part of your mode, Remote work, finding people who are
excited about that and feel connected to each other because
of it is a smart thing to focus on.
Right. And I think you also mentioned
that sometimes all these things like working remotely, being
part of a group built a swift trust, right?
Even though you just join a company, which you didn't know,
you haven't met any of them, but you easily can work together,
right? Collaborate with each other.
Like, you know, each other for a long time.
So I think that's a really, really interesting track for me.
Like, I started working remotely also, just after the Endemic.
Initially, I was a bit skeptical, how these things
would work. But yeah over the time after I
went through it, I think the experience taught me a lesson
that yeah you can actually build trust even though you never see
anyone even though maybe sometimes in the video meeting,
sometimes you don't even see the person because they turn off the
video but still things get done and you can build relationships
with people, of course, nothing beats the personal experience.
If you meet them face to face, but I think this pandemic and
remote work setup also taught me about Truss right.
Building trust even though you don't know any of the
colleagues. So another thing that you
mentioned in the beginning is about communicating
intentionally in the remote work setup.
You need to communicate a lot more intentionally and you also
bring a topic about this that communicating more intentionally
actually brings better outcomes. Can you touch on a little bit of
this? How can we bring intentional
Communications into work especially in the remote setup?
Yeah, so actually I'd like to tie the idea of the Swift for us
to communication. So Swift trust is an idea about
how groups with certain properties can come together
very quickly, to have very trusting relationships that have
good outcomes. And in a workplace setting, the
canonical example is a movie set where people have a limited
project. Almost everybody has a
well-defined role and they've got a clear goal of what they're
trying to do. Software can be pretty similar.
So intact, we have a lot of the potential for Swift trust in
that. It's usually pretty clear what
people's roles are. There's often some time frame
that's got some limits on it and ideally, there's a pretty clear
vision of what we want to do and so we can benefit from the
mechanisms of Swift trust. If we ensure we have those
pieces in place. So as leader is part of our role
is communicating about what we're trying to do to be.
Very clear about what our strategy is for the next year
and for each quarter and helping people understand what that
means for their work, what they should prioritize based on our
strategy and what they can do prioritize now, that's all
great. Everybody thinks they're doing
that. But one thing that's pretty
clear. If you've been in management for
an hour and a half, is that you have to say things repeatedly.
Many places in different ways for it to land for everybody.
So, if you wanted your whole company, whether that company is
30, people are like 30,000 people to be able to tell you
what the company strategy is right now, so that they can make
decisions that are aligned to that strategy.
You can imagine you have to be able to repeat it a number of
times in a number of ways at Daily were about 60 people right
now and we have some very specific munication heart beats.
So we do two at the beginning of the year, I can yearly strategy
but we know that that's going to change over time because we take
in information and Tack to new information and I'll note to
we're still a fairly early stage startup so we are still reaching
a kind of product and sales Market fit.
So our strategy is going to change in a different Cadence
than a much bigger and more established company.
But even in bigger companies you need a lot of heart beats for
people to know what's going on. And in fact the distance between
the Making the decisions about the strategy and the people who
are executing, that gets pretty far.
So you need a lot of ways for them to hear what you're saying.
But we think about annual and half year, we also do quarterly
planning and we have very specific All Hands where we
share that information and then have follow-up Q&A sessions with
written questions and a chance for us to respond live and
record those sessions. And make sure everybody sees
those. And we've got them posted a
number of places and in between In we have two all hands a week
one that's company-wide usually about some Department giving a
presentation. Sometimes we talk to a customer
and then an angel hands because about half the company's
engineering and sometimes we get more technical.
We do demos things like that but we're pretty regular about that
stuff. Like it's twice a week and we
don't let that go. We also have every week at the
beginning of the week, one of our Founders shares a week ahead
post, talking about some things that are coming up.
Look out for. And at the end of the week,
almost, everybody writes an end of week.
Note about what they worked on this past week and what they're
going to be working on next week and the founder will highlight
some of those notes in the week ahead as well.
So we have a bunch of ways that we stay connected to each other.
Just that's all scheduled. It happens all the time.
And when we have changes to things, we're really specific
about making sure that we've announced that, and we have very
dedicated time for Q&A. Sometimes we don't have very
many managers between execs and staff of relatively flat still
because we're just for small, but we will also bring in
managers if that's particularly relevant to and make sure
they've got info to answer questions if needed.
So, all of that is kind of table Stakes, basic good
communication. But it's easy to let that go
when you're not in person and becomes much more important when
you're not otherwise seeing each other altogether in a
distributed environment. So, saying things repeatedly, I
also learn it. Hard way, right?
So especially in the remote setup when you don't even know
where people actually read the messages or not, right?
Sometimes you may think that they may have not read, it may
be related to this. My question will be, how do you
actually build accountability of maybe even for people to
acknowledge what you said? Right?
And take that as a priorities for them.
For example, if we are talking about strategy or maybe
priorities for the team. So, is there any tips that you
do normally for building accountability?
Especially in The remote work setup where sometimes we don't
get acknowledgement from people and we don't know whether they
actually taking that has the same product.
Yes. Yeah.
So I want to be clear. I think about accountability,
not just as taking responsibility for what you said
you would do or what you've been told to do, but accountability
is much more about learning from what you've done and adjusting.
So everybody will make mistakes or wind up working on something
that the company makes mistakes in your involved.
What I care about when we talk about Accountability is, did you
learn from that and adjust? And how do you talk about that?
So, people know, so one of the ways that and I will say again,
like this is one of those places where implicit and explicit
signals are important explicit signals for us.
Might be do people talk in their end of week about what they
learned and what they're doing differently as a result of what
they've learned from something they did or in team Retros.
For in the rare incident, we don't have that many incidents,
but when we do having Retros and being able Oil to make sure that
we've learned from those, that's all explicit and is important
but an implicit one that helps us figure out if we're
communicating enough. Is that every quarter as we get
toward the end of the quarter, people increasingly start asking
for information about strategic direction that will help them
make decisions. And I think that's a good sign
that they consider that a really important input to their own
day-to-day decision-making. And then they'll track toward it
because we have repeated conversations about our strategy
and what's working and what's not and how that affects
people's work. So that part of that
conversation, thanks for sharing that I think it's really
important signal there, right? If people are asking for the
strategies of people ask for clarity, I think that's a very
good signal that. You do have a very high
collaboration, first of all and also High accountability because
people want to know from their leaders, what Other strategies
and priorities for them. Thanks for sharing that.
So let's move on maybe to the second part of our conversation,
which you mentioned in the beginning, in your career
Journey that you become the engineering leaders even though
you came not from a tech background, tell us a little bit
about this. How did you first of all end up
in software engineering teams and what are the challenges that
you have to overcome when you take these jobs?
Yeah, it's interesting. So, as I said earlier, I jumped
from other Areas of software leadership from operations and
marketing and sales into engineering.
When a friend helped recruit me into a role in engineering
leadership. And when I joined right before,
actually, right, before, I joined MailChimp, I interviewed
about 30 friends to find out. What did I need to know about
managing Engineers, that was going to be magic and special
and different from managing other people.
And 100% of people told me that Engineers are just people and
it's the same. I think that the myth of what
Engineers are like, was playing in my brain in a way that turned
out. Not to be true because my
friends were right, turns out Engineers are people, too.
And there are certainly company cultures and engineering
department, cultures and individual teams have cultures.
But there's not a monolithic. Here's how Engineers behave or
even particularly strong. Trends that are different from
other kinds of departments. So I think one of the things
that I have learned is that leadership is leadership.
And in software, we have different risks than in other
kinds of businesses. And it's also the case that
you've different risks at different stages of your
business, early stage, or later stage, and you have to manage to
those things specifically. But there are not hugely
different things that you have to do in engineering versus
marketing. For example, I think it's a very
unique thing, right? Whenever we spoke about
engineers, some people will have different perception.
Oh, they are Engineers, your, you know, they need a different
kind of treatment. They are like, I don't know.
Like some special people, especially in the tech,
companies, we have plenty of Engineers.
And yeah, like we can see some Engineers who acted like a diva
or more like a geek, which are sometimes difficult to work
with. But I think what you said sounds
true, right? At the end of the day they are
just Human After All or they are just people.
And Leadership is also about managing people well or
effectively. I think the advice for listeners
here is don't treat managing Engineers as totally different
things than managing other ploys in a different parts of the
companies, but treat them as also like people, which brings
to the leadership qualities, right?
So what do you think are some of the leadership qualities that
work? Well, even though you come from
non-tech and you apply it as well, in the engineering set up
as well, one of the most important thing.
Things is being able to understand where we have risks
and opportunities and making sure that we're having those
conversations. So that's both reinforcing
what's our strategy and what are the risks and opportunities in
our strategy but also in the mechanics of how we're building
things are we investing in the right kinds of technology and
processes? And people are we building to
deeply without getting information about whether people
want? The product, for example, are we
building too quickly and not taking into account, security
risks, or reliability risks, that we can already see on the
horizon? These things shift, of course,
as I said earlier, stage of your company age of your company
tight, like, whether your B2B, or b2c, all of those kind of
affect how you think about things, but being able to bring
those perspectives into your leadership, and into your work,
with teams and individuals. It is critical of course, in any
management role, but particularly in software where
our risks are often very high and in different places than you
might expect from other kinds of experiences.
So how about if you actually being asked by the engineers for
some technical advice? So I think this is sometimes the
gotcha for some of these managers who came not from the
strong technical background, sometimes the team has a
challenge. Maybe, for example, even option
A and option b, what should we do?
So how do you actually Overcome that challenge, right?
Whenever the team is trying to resolve a certain technical
problems. Of course, the go-to person
would be the manager. Do you find this as a challenge?
And if so, how do you actually face The Challenge and actually
gave them a good solution? Yeah, most of the time when
people are coming to me, their challenges are technical
challenges but within the context of a business problem,
what does the customer want? What's our strategy do we have
the right people? Or there's like, Act on the
team. And how do we make choices
within that context? And I can partner with people to
help them figure out what are the right questions to ask him,
what are some of the options? And sometimes we brainstorm
together and sometimes I'm just sort of coaching them thinking
through things. Everybody who works with me,
knows my background like it's rare that people are coming to
me with specific technical questions.
It's usually looking for more context and help making a
decision. But sometimes people do need,
technical help. And part of my role is to know
when somebody needs help that. I can't provide And helping make
sure they get connected to people in the organization who
can or sometimes people outside the organization who can help
us. Sometimes we need expertise, we
don't have. And having a big network of
people that I can contact and work with.
If we need expertise we don't have is part of my role to.
But I think it's actually in some ways.
This funny strength of not being able, I can't just answer a
technical question, helping people figure out how to find
the answer and especially if the answer resides somewhere else in
the Organization giving other people the ability to share
their expertise and figure things out.
Together is hugely beneficial for teams.
I don't mean to suggest that all engineering leaders should be
non-engineers but I think there are sometimes some silver lining
to it. We can take advantage of.
Yeah, so you wrote this also in your block right.
There are some benefits for the managers of being non-technical
maybe you can share a little bit more.
What are some of the benefits that you experience and maybe
for you to also, Tips for the engineering managers or
engineering leaders out there who are non-technical background
as well. Yeah, well, I mean, I never
micromanage anybody's engineering.
That's a non-issue, but I think it's also important to know that
I'm a little bit unusual as a nun engineer, but it is usually
the case, especially as companies get bigger and older
that people in senior engineering leadership roles.
Don't touch the code and aren't making huge.
Technical Ian's on their own and the ones they are making or
they're doing collaboratively and not very often.
I'll talk a little more about some of the details but I think
it's actually not that unusual. That a lot of what I do is kind
of what most engineering leaders do but as I said I'm not
micromanaging, anybody usually tech leads on the teams and the
EMS and the team the engineering managers and the teams that I
work with, have a real chance to grow as Leaders themselves.
I need them to be good partners and to help work with me so that
they can bring information about technical.
Opportunities and risks. And I can bring information
about business opportunities and risks and we can make good
decisions together and we both grow in that environment.
So I think of that, it's part of like, the satisfaction of the
job, but I think it's also potentially a benefit for other
people. A funny benefit is that nobody
ever expects me to know about the technology, so I can ask
anything at all. And sometimes that gives
Engineers a chance to teach me things.
Or a lot of times, the EMS who work with me, teach me a ton.
They Teach me this stuff every day and that has a nice
balancing effect in our status and our trust.
I think it's trust building when they teach me things.
So it's not just a one unidirectional kind of
relationship and I think it's easy for me to help focus on the
business on the strategy on communicating about the business
needs because I don't tend to get lost in the technical
details. That's not the nature of the
conversation. I'm going to have and I can keep
going. In the business context so they
can keep making good decisions and asking good questions to
make sure we're moving the direction we want to go.
So how about if let's say you work on a specific things,
right? And you do really need sometimes
a technical contexts. So how do you actually upscale
yourself or learning? Because intact?
I was, especially, we have so many things.
You can't definitely cover everything, right?
But how do you actually as a engineering leaders yourself up,
skill on a certain area in order to catch up or Be in sync with
the rest of the team. Do you have any tips how to
learn by yourself or self? Learn about stuffs?
Yeah, so I have a few things that I do.
First of all, as I said, I asked the people in my organization to
teach me things all the time, whether that's ICS or other
managers and sometimes our founder, who one of our Founders
is very technical and wrote our early systems.
I asked questions a lot for people who work with me but I
also have a couple of group That I'm in with other people in
Tech. And what I think is really
interesting about, those is a lot of times.
There are a lot of engineers in those groups, who ask each other
questions, who don't know about anything at all, like, it could
be about a language, or about containerization, or could be
the whole range of small kinds of projects to Major
implementation details and they asked each other because nobody
can have had all of the experiences you would need at
this point to run complex. Technical projects.
So I don't have any hesitation about asking people to teach me
technical things over, but I sometimes have a little bit of
like, oh, am I going to be asking a dumb question, and what
I find is all the time, people are excited to share their
expertise and literally, everybody in the group chats is
asking each other stuff to learn and share information.
And then sometimes I read to, I tend to read more and listen to
podcasts and taken other kinds of Media Watch talks.
And things, I tend to read more about software development than
about Ring, but sometimes the bits about software, like,
technical details about, I don't know, databases or something,
get in a way that I find useful over time.
So I think still the key here is that don't be afraid of asking
questions, even though with your direct reports, right?
The hesitation will be there for sure, but I think the key is not
be afraid to ask to anyone so that they can help you actually
to fill in the details of context and actually in the end
it will help in making decisions.
Right? Because I think some of our
people People actually do rely on the leaders to make good
decisions for them as well. So you also mention that not all
companies actually receptive to the idea of engineering leaders
who come from non-technical background.
Do you have some experience around this, and what should
people do? In order to see whether this
company, actually, accepting people coming from non-technical
background as a leader? Yeah, well, I will say it's not
appropriate for every company at every stage, like some
companies, Especially earlier, stage need, technical leaders
who can do some of the coding. Like you kind of need all hands
on deck and as companies grow, it becomes you get farther and
farther away from the GitHub account.
But I think it's also the case that you want to be as a leader.
You want to be trusted and you want to be able to trust the
people you're working with. And if a company has a really
strong bias in just doesn't believe that a non engineer
could lead Engineers being The first one in that situation
would be hard, it would be hard to feel trusted and for them to
trust you. So I would be cautious about
that especially in a younger company in the place where I've
encountered at the, most is recruiters, who for whatever
reason, don't realize I'm not an engineer contact me and then
when it turns out I'm not really.
Well, of course, these Founders are working with would never
hire a nun engineer. And I'm like, I don't, why are
we in this composition? But I do think that for
companies that have Strong engineering culture already.
It's probably pretty rare that you need another technical
decision maker. What you need is, somebody who
can help tie engineering to the business needs and can make sure
that you got the right systems for making good decisions that
you are getting good inputs. There are the right people in
the room for making good decisions and that you can
collectively understand benefits and trade-offs of different
directions. What that will mean short-term
and long-term and that you can think about that.
Lately for your stage of company and that does not require a
super deep engineer. And again, the bigger the
decision them less often you're making them in the more people
have voices in it. So it's sort of thinking about
that as more of a process that you want to be really healthy
and strong and aligned to the business.
I think points, you toward people who have a lot of
business experience in software, rather than towards people who
necessarily have deep technical expertise, when you can bring
that into the Room from other folks.
So I think the few key lessons that I picked from what you
shared is that. Yeah, different stages of
company requires different kind of leaders especially in the
early stage where probably you need to cover so many things
including coding and the other thing is that for like slightly
bigger or maybe more, scalable type of companies, you probably
don't need all much deep technical kind of leaders
because you will need to make strategies good decisions.
Tying up with the business, right?
How you strategize together? Product and Engineering
together. So that we built the good
product for users and for people who are still thinking that as a
tech company, you need to hire just engineering background
leaders. Maybe this is also a proof that
you don't actually need to always hire the technical
background kind of leaders because it can also work
especially when you want to make good business decisions aligning
with the tech. So, thanks for sharing all this
Sarah. I think a lot of listeners here
would learn a lot from this conversation.
Yeah. So before we Wrap up our
conversation, actually. I have one last question that I
always ask from all my guests, which I call the three technical
leadership wisdom. So think of it like an advice
that you want to give to our listeners here, maybe from your
experience or from your expertise.
Could you share? Maybe your tree technique
wisdom? Sarah.
Yeah, so I have a few things these I think are all true for
all companies but especially true for software companies.
So the first one is something I've said here a couple of times
which is that it's really important to understand the
stage of your company and the kind of risks you face at your
stage and make decisions that are appropriate and remind other
people about that the other people that you work with all
the time. So it's for example, typically
In earlier stage companies, your biggest risk is that nobody will
buy or use your product. And so it's not as important
that you're caring about security and reliability, unless
that's the nature of your product, but most products not
the case. And you want to really make sure
that you're building quickly and in a way that lets you get
feedback from customers early and often so that you aren't
building stuff that no one's going to buy as you get bigger,
you have Kinds of risk, reliability security, sometimes
increased legal risk, and a number of other kinds of things.
You have to shift some of your decision-making and that's
partly why companies, slow down, as you get bigger.
But you want to be careful that you understand your context and
that you're building the software, and the company for
the right stage that you're in, and you're reminding other
people about that all the time, because everybody forgets.
So that's one a little bit related to that is The idea that
you should build and ship the smallest, things that you can
that potentially add value for your customers.
Now, that's an idea. That's pretty well established
and software these days, we try to get away from like a
waterfall and it's two years away and will ship a thing and
maybe it'll be useful and maybe it won't.
We're going to try to build in smaller pieces.
I didn't that's still there tends to be a little bit of
regression to the mean of shipping later and in bigger
pieces and reminding people. The time and giving them ways to
make decisions so they can ship more quickly and see value and
learn as they're going is really useful.
And you can do that outside of the software itself.
Like it's completely true that you can think about processes
and meetings and documents. All of that can be thought of in
smaller pieces, that move more quickly.
So you can get value earlier or determine that you're not adding
value. And again you need to adjust for
the size and stage of your Any. But thinking about shipping more
quickly and having fewer dependencies learning as you go
incredibly valuable and then I would say to It's Easy in any
company but it's especially easy and software to have 10 or 15
strategic priorities which means you have no strategic
priorities. That as a leader, you have to
really be able to say these are our priorities and we're going
to work on them and we want to make decisions around these and
we're going to back burner some other things.
Not going to work on this right now.
We're going to work on it in a much lower level rather than
saying everything is a priority and you have to get everything
done, you get so much less out of people.
First of all, they feel like they can't work effectively but
also they don't work. Effectively people can't work
without a sense of what's most important to the company.
And how should they focus their resources and that's true.
Whether you have 30 people, or 30,000, even if you have a
seemingly unlimited number of people, they have limited amount
of time. They all have to make decisions
about what's important and what they should be working on.
And so helping them have a really strong sense of those
different. What should you work on?
And what should you not is a real leadership Advantage?
Wow, I really love all of them. Especially the last one because
especially in an early stage startup sometimes it could
happen that you have so many strategic priorities.
Sometimes he could be a lot of pivot.
Sometimes it could be a new customers feedback coming in
that we have to somehow meet. So I think yeah, privatizing
strategies don't overload our people.
So that they are confused at the end of the day and not be able
to work effectively, thanks for sharing this wisdom.
So Sarah, if people want to connect with you or want to
discuss some things further, like the remote work or being
engineering leader, is there a place where they can find you
online? Yeah, so my website has all the
ways to connect with me and it's Sarah.
Milstein.com SAR, aah. Am i l St?
Een nice. Okay, I'll put that in the show
notes as well. So thank Sarah for this talk.
I really learned a lot from you today and we thank you so much.
It's been a pleasure Thank you for listening to this episode
and for staying, right until the end, if you're highly enjoyed
it, I would appreciate if you share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot.
In order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page, at Tech Legion l.f website, including the full
transcript enter, I think words and links to the resources
mention from the conversation. And lastly, make sure to
subscribe to the shows mailing list on pack leader dot f to get
notified for any future episodes.
Stay tuned for the next technology, another episode.
And until then goodbye,