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,