#130 - Remote Work Insights & Leading Engineers as a Non-Engineer - Sarah Milstein

[00:00:52] Episode Introduction

Henry Suryawirawan: Hey, everyone. Welcome to the Tech Lead Journal 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 Tech Lead Journal, 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 techleadjournal.dev/patron, or buy me a coffee at techleadjournal.dev/tip.

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. In 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 communications. In the second half of our conversation, Sarah shared about her experience of leading engineers as someone from a non-tech background. She explained why a lack of technical expertise can sometimes be useful and pointed out some leadership qualities an engineering leader should have to balance out the need for technical acumen. Sarah also shared her few tips on how to upskill herself in technical stuffs and her perspective on whether a company should consider having non-tech engineering leaders.

I enjoyed my conversation with Sarah. And if you also enjoy 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 Apple Podcasts and Spotify, which I will highly appreciate. Let’s go to my conversation with Sarah after a few words from our sponsors.

[00:03:13] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, we have a guest named Sarah Milstein. She’s the VP of Engineering at Daily. So she has a very unique experience of having to work in or manage 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.

Sarah Milstein: Henry, thank you so much for having me.

[00:03:49] Career Journey

Henry Suryawirawan: So Sarah, I always like to start my conversation by asking you to share your career journey. If you have any highlights or turning points that you think are worth to share with the audience here.

Sarah Milstein: 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 publisher 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 needed a whole team involved in. And typically there was a ship date after which you would learn if anybody was gonna 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 gonna be successful until you’d 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, which was, you know. For what it was, there’s been lots of argument about it since. But it had this idea that you wanna really be connected to your customers. You don’t wanna 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 gonna 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 wrote the Lean Startup book. And this was a company that we developed to 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 coincidentally a couple of blocks from my apartment, and needed somebody to run the Brooklyn office and served 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, cause it felt like it would be a more leveraged 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 in 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. That’s been true for actually now more than two decades in my career.

So kind of an interesting combination at this point of engineering leadership as a non-engineer and remote leadership over a very long period of time.

Henry Suryawirawan: Thank you for sharing your story. The two key things that we’ll be talking a lot today is first about your remote working experience. And secondly is about being engineering leader coming from a non-technical background.

[00:08:04] Remote Work Insights

Henry Suryawirawan: So let’s start from the remote work itself. So you have worked 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 I’m sure it’s not 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?

Sarah Milstein: 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, too. 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 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 wanna be careful to note that there are lots of people for whom, for whatever, for any number of reasons, it’s not the best mode. And it’s worth investigating for your company what’s best in being upfront with people when you’re hiring, so that there’s not like luring 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 too, like you can get more juice out of good management than you can out of bad management. But in a remote setting, you have to be, for example, more intentional about communication. It doesn’t happen coincidentally. 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 it doesn’t seem as necessary. So there’s lots of things like that where 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 myself saying to somebody that I preferred working in remote companies cause they tend to be higher trust environments and higher trust, 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 the 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 that 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 wanna be clear, I don’t think that 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, they start off not trusting people very much and you can kind of build that up. And part of the way you build it up is 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 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 figured out.

Henry Suryawirawan: So it’s interesting that you mentioned about this propensity of trust, right? I can get it. For example, if you are a 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 employer, even though they may not see the bosses, they may not see the offices, the colleagues, and things like that.

[00:12:26] Propensity of Trust

Henry Suryawirawan: 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 gauge candidates or when you look at the next company that you wanna join? Maybe some tips here for people who love working remotely?

Sarah Milstein: 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 number of companies that had listed remote jobs. You would think it’d 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 3% to 50%.

A lot of people are looking for remote work. And I think that 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 wanna try to gauge rather than ask directly for a lot of the things you wanna 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 talk 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 we’re 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 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 well suited for your culture.

Henry Suryawirawan: That’s a very interesting statistics that you mentioned there from LinkedIn, right? So I even experienced it myself whenever I interviewed candidates, right? Some of them would just say, yeah, I want to find jobs which are only remote. And there are plenty of them. Which explained why LinkedIn statistics found that many candidates wanted to work remotely.

[00:15:39] Working Back in Office

Henry Suryawirawan: 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, working remotely. Is there anything in particular that you found with this trend?

Sarah Milstein: 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 wanna feel trusted as much as they want to trust other people. 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 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 could 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 could 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’ve spent the money, you could kind of see that math adding up for some companies.

Henry Suryawirawan: I think it makes sense, right? Some people wants to have more collaborative, want to have in-person meeting and maybe spark the creative conversation out of the blue, right? Not always in meetings. Video meetings some more, which sometimes is a little bit fatigue, right?

[00:17:36] Other Remote Work Insights

Henry Suryawirawan: Another thing that you mentioned in your blogs 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 from this higher trust? Because, you said earlier that remote work sometimes breeds higher trust. Are there any other insights that you wanna share with us here?

Sarah Milstein: 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 you’re laying 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 and you’re 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 receiving 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 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 in 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 that 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 has 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. 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 I think there’s both some logistics to it and some kind of subtle human connection pieces that can be really powerful.

[00:20:47] Ingroup Bias

Henry Suryawirawan: Just now you touched on about the in-group thing. Maybe if you 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.

Sarah Milstein: Well, the idea of ingroup 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 building 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 worked 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 we’re the kind of people who like to work in this way.

And as I said at the beginning, filtering for the people who wanna 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 is 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.

Henry Suryawirawan: Right. And I think you also mentioned that, sometimes all these things, like working remotely, being part of a group, build a swift trust, right? Even though you just joined 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 fact. For me, like I started working remotely also just after the pandemic. 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 lessons 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 relationship 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 trust, right? Building trust even though you don’t know any of the colleagues.

[00:23:21] Swift Trust & Intentional Communication

Henry Suryawirawan: 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?

Sarah Milstein: Yeah. So actually I’d like to tie the idea of the swift trust 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 in tech 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 timeframe that’s got some limits on it, and, ideally, there’s a pretty clear vision of what we wanna do.

And so we can benefit from the mechanisms of swift trust if we ensure we have those pieces in place. So as leaders, 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 deprioritize.

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 in many places in different ways for it to land for everybody. So if you wanted your whole company, whether that company is 30 people or 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, we’re about 60 people right now and we have some very specific communication heartbeats. So we do two at the beginning of the year, kind of yearly strategy, but we know that that’s gonna change over time, cause we take in information and tact to new information. And I’ll note too, 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 gonna change in a different cadence than a much bigger and more established company.

But even in bigger companies, you need a lot of heartbeats for people to know what’s going on. And in fact, the distance between the people 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 an 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, 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 Eng all-hands, because about half the company is 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, to 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 gonna 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. And sometimes we don’t have very many managers between execs and staff. We’re relatively flat still, cause we’re just, we’re small. But we will also bring in managers if that’s particularly relevant too, 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, much more important when you’re not otherwise seeing each other altogether in a distributed environment.

Henry Suryawirawan: So saying things repeatedly, I also learn it the hard way, right? So especially in a remote setup when you don’t even know whether people actually read the messages or not, right? Sometimes you may think that they may have not read it.

[00:28:28] Accountability

Henry Suryawirawan: Maybe related to this. My question will be how do you actually build accountability or 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’re actually taking that as the same priority as us.

Sarah Milstein: Yeah. So I wanna be clear, I think about accountability, not just as taking responsibility for what you’ve 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 and you’re 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 or in the rare incident, we don’t have that many incidents, but when we do, having retros and being able 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 they’re part of that conversation.

Henry Suryawirawan: Thanks for sharing that. I think it’s a really important signal there, right? If people are asking for the strategies or 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 are the strategies and priorities for them. Thanks for sharing that.

[00:30:50] Being an Engineering Leader from a Non-Tech Background

Henry Suryawirawan: 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.

Sarah Milstein: 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 gonna be magic and special and different from managing other people. And a hundred percent of people told me that engineers are just people and it’s the same. And 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 have 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.

Henry Suryawirawan: I think it’s a very unique thing, right? Whenever we spoke about engineers, some people will have different perception. Oh, they are engineers, 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, where you have plenty of engineers. And yeah, like we can see some engineers who act 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. They’re 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 a totally different things than managing other employees in the different parts of the companies. But treat them as also like people.

[00:33:31] Leadership Qualities

Henry Suryawirawan: 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 applied, as well in the engineering setup as well.

Sarah Milstein: One of the most important 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 too 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. Type, like whether you’re 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 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.

Henry Suryawirawan: So how about if you actually are 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, given option A and option B, what should we do?

[00:35:15] Benefits of Non-Tech Background

Henry Suryawirawan: 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 give them a good solution?

Sarah Milstein: 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 conflict 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 and 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 too. 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.

Henry Suryawirawan: Yeah. So you wrote this also in your blog, 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 give tips for other engineering managers or engineering leaders out there who are non-technical background as well.

Sarah Milstein: 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 non-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 decisions on their own. And the ones they are making are, 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 on the teams, the engineering managers on 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.

Oh, 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 the 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, a 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 gonna have. And I can keep bringing the business context so they can keep making good decisions and asking good questions to make sure we’re moving the direction we wanna go.

[00:39:23] Self-Learning Technical Stuffs

Henry Suryawirawan: So how about if, let’s say, you work on a specific things, right? And you do really need sometimes a technical context. So how do you actually upskill yourself or learning, because in tech especially we have so many things, you can’t definitely cover everything, right? But how do you actually, as an engineering leaders yourself, upskill 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?

Sarah Milstein: Yeah. So I have a few things that I do. First of all, as I said, I ask 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 ask questions a lot for people who work with me.

But I also have a couple of group chats 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 it could be the whole range of small kinds of projects to major implementation details. And they ask 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 in group, but I sometimes have a little bit of like, “Oh, am I gonna 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 too. I tend to read more and listen to podcasts and take in other kinds of media, watch talks and things. I tend to read more about software development than about engineering. But sometimes the bits about software, like technical details about, I don’t know, databases or something get in in a way that I find useful over time.

Henry Suryawirawan: 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, the context. And actually in the end, it’ll help in making decisions, right? Because I think some of our people actually do rely on the leaders to make good decisions for them as well.

[00:41:51] Company Accepting Non-Tech Engineering Leaders

Henry Suryawirawan: So you also mentioned that not all companies are 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?

Sarah Milstein: 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 accounts.

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 and 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.

And the place where I’ve encountered it 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, they’re like, well, of course, these founders I’m working with would never hire a non-engineer. And I’m like, I don’t, why are we in this conversation?

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’ve got the right systems for making good decisions. That you are getting good inputs, that 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 appropriately for your stage of company. And that does not require a super deep engineer. And again, the bigger the decision, the less often you’re making them and the more people have voices in it. So 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.

Henry Suryawirawan: 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 scale up 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 build the good product for our 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 wanna 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.

[00:45:14] 3 Tech Lead Wisdom

Henry Suryawirawan: 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 wanna give to our listeners here. Maybe from your experience or from your expertise. Could you share maybe your three tech lead wisdom, Sarah?

Sarah Milstein: 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 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 wanna 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 gonna buy.

As you get bigger, you have other 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, cause 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 in software these days, where we try to get away from like a waterfall and it’s two years away and we’ll ship a thing and maybe it’ll be useful and maybe it won’t. We’re gonna try to build in smaller pieces. I think 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 all 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 company. But thinking about shipping more quickly and having fewer dependencies, learning as you go; incredibly valuable.

And then I would say too. It’s easy in any company, but it’s especially easy in 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 gonna work on them. And we wanna make decisions around these, and we’re going to back burner some other things. We’re not gonna work on this right now. We’re gonna work on it at a much lower level, rather than saying everything’s 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 difference, what should you work on and what should you not, is a real leadership advantage.

Henry Suryawirawan: Wow. I really love all of them, especially the last one, because especially in a early stage startup, sometimes it could happen that we have so many strategic priorities. Sometimes it could be a lot of pivots, sometimes it could be a new customer’s feedback coming in that we have to somehow meet. So I think, yeah, prioritizing strategies, don’t overload our people so that they’re 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?

Sarah Milstein: Yeah, so my website has all the ways to connect with me. And it’s sarahmilstein.com. S-A-R-A-H-M-I-L-S-T-E-I-N.

Henry Suryawirawan: Nice. Okay. I’ll put that in the show note as well. So thanks Sarah for this talk. I really learned a lot from you today.

Sarah Milstein: Henry, thank you so much. It’s been a pleasure.

– End –