The thing that I've been telling my team is that this is not a time to get through. This is a time to lean in. Let's not treat it as, oh my god, you focus on efficiency. Let's just do it and then it'll be done. It'll be back to the fun times. These are the fun times. They're just fun in a different way, but these constraints are making us even more creative and these challenges are going to lead to us doing some of the best work of our lives.
The way through the fear is actually into excitement. Hello and welcome to the Engineering Leadership Podcast, brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC, and I'm Patrick Gallagher, and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. In this episode, we tackle the trend toward engineering efficiency with Alamelu Radhakrishnan,
and the trend toward engineering efficiency at Shopify. Alamelu shares strategies to help you identify opportunities for greater efficiency, getting engineering a seat at the leadership table during efficiency focus conversations, frameworks for removing toil within your engineering teams, how to avoid burnout while optimizing for efficiency and more. Let me introduce you to Alamelu.
This is the head of engineering operations at Shopify, leading the teams responsible for building these systems and technical programs that power Shopify R&D. Her mandate is to maximize the impact of engineers on Shopify's missions, and her role spans across team health, engineering craft excellence, strategic planning and prioritization, and successful business operations within R&D.
Prior to Shopify, Alamelu has worked with some of Canada's most innovative product and consulting agencies, leading software delivery teams and helping organizations leverage technology across a variety of industries. Enjoy our conversation with Alamelu Radhakrishnan. To kick off our conversation, first off, just want to say welcome Alamelu. It's Friday. We're giving off some Friday energies, Friday afternoon, Friday vibes, Friday vibes. How are you doing? What's going on in your world?
Oh, I'm doing so great. 2023 has been already a role of Coaster for a year, and it's only what March 3rd, but so much cool stuff going on. I'm in Toronto. We are waiting for a snow storm this evening going into the weekend. And so I'm feeling energized. I am feeling ready for the week to wrap, and I am in the perfect mood to have a conversation with you about engineering.
That is an incredible way to enter. I think that's an historic that you're about to experience. I'm up in North Idaho right now. So again, similar latitude. It wasn't that bad. So hopefully, you know, it'll be okay. It'll be nice. The kind of snow you can play in versus the kind of snow you have to hide from. Perfect. I will get my sled ready.
I know we have a bunch of different things that we wanted to explore. I think to help our audience understand a little bit more about your background and context and the things that you focus on. We'd love to just get a little bit more about the context behind your role and your focus. And I think specifically one of the things that I found so interesting is that you've shared how oftentimes your focus is on being an extension of the engineering leadership.
And so we'd love to learn a little bit more context behind that. What does that mean? And what does that look like for for the things that you do? Yeah, absolutely. So I started off in this role as a chief of staff to our CTO. And chief of staff is a very nebulous title. All titles are made up, but I think it is a particularly nebulous one. Every company and every person implements it differently. So we talked about what it means for us. And really the mandate is to make engineering successful.
That's the goal. What are all the things that I can do and my team can do to make sure that engineering is the best version and the most impactful version of itself that it can be. And so that was sort of the genesis of the role and that continues to be my mandate. And I really think about it as every company has systems and structures and culture to make certain things happen.
And those things just happen. And a lot of times those are the things that are sort of vertical, but horizontal things across an organization don't always happen naturally. And those are often the areas where we have redundancies and inefficiencies and diversions. So I think about not each vertical slice of engineering, but the horizontal practice of engineering and how we can make that better.
I love thinking about like the systems and the culture and the horizontal versus vertical element because it can be so easy. I think to think about the whole vertical capability building. And it's like, okay, we got to go deep here and build this out. But in a way, you're sort of focusing on the parts that maybe other people aren't thinking about or focusing on and making that work.
That's, yes, that's exactly how I'm thinking about it. I want to focus on the things that if I didn't focus on them, they just would not happen or they would happen in 20 different places when they should only be happening in one place.
What that mandate turns into tactically is different every year or even every six months because I want to keep working myself out of a job. And so everything I do, I want to do it with a long term lens so that it eventually becomes self perpetuating and becomes part of the systems and part of the culture. And I can focus on the next problem.
I love that that sort of orientation towards working yourself out of a job in this way. I wanted to maybe talk about some of those blind spots. And I think especially with the orientation of like, how do you work yourself out of a job in that area.
So can you share a little bit more maybe about like some of those areas that you provide additional focus or priority coverage or some of those different blind spots and maybe like, what does it look like then to get yourself out of a job in some of those context.
Yeah, absolutely. I think that there are parts of the role that are sort of systemic. And so it is building certain systems that are always on and always running and when I say systems, I mean things like communication patterns within the engineering organization or are onboarding and are learning programs or the way that we think about the size and the shape of the organization and how we evolve that.
And those pieces are systemic. And then I think there are these sort of more acute things that come up. For example, we'll say, hey, let's do a big focus on pair programming. And then we can sort of apply all of those systems to that one initiative or to that one goal. And then when it comes to blind spots, I think it really is about when every leader is sort of focused in their area on what they need to ship. How can we think about engineering excellence horizontally.
And by no means am I the only person thinking about this in the company, but I am making it easier for them to think about it and for them to work on it. That's really what it comes down to. And some of those blind spots are just sometimes intuition oftentimes data.
A lot of conversations and a lot of like pattern matching. I want to ask you a follow question about the systems, the systems building and systems thinking specifically from from this context. So we've a lot of folks that have joined our peer group program.
And one of the intentions that they want to get from that program is to help them get to the next level to scale their leadership from maybe 50 to 100 people. And so it's sort of aligned with this sentiment of working themselves out of a job and scaling themselves up. And that systems building element.
I think is so critical. And so I was just wondering like when you're looking at some of these, you know, some of these areas when you're approaching to building a system from scratch that then would work yourself out of having to manage that system or lead that system. What's your approach there? How do you start from zero into building that new system.
I don't start with the thought of working myself out of a job. I start by really leaning into it actually like I start from the place of I have to do this and I have to be really hands on, especially if it's something new that hasn't been done. And I want to like fully engage in this. And then with that, it kind of turns into like regular problem solving where I'm thinking about like what am I trying to achieve here.
And specifically when it comes to systems building, being really, really clear about what impact the system is going to have. And then working from a first principle of simplicity. Like what is the simplest way this can be done for the organization that serves the most amount of people and creates the least amount of overhead. And then as it starts to take shape and show value and have impact.
Then I'm also thinking about, okay, how does this now become a self perpetuating thing like do I hand it off to a different leader. Do I make it so it doesn't need ownership and it just works on its own. But I think doing that right at the start, I think you're over engineering and you need to make sure that the thing works before you can ensure that the thing continues to work and then continues to work without you.
And so I'm really thinking about what is the most rudimentary system that I can build to fix this problem and going from there. I think over time it just becomes intuitive for all leaders like I'm sure it does for you as well and other people you talk to. There's a lot in the data, the more observability that we have not just of our platform, but also of our organization goes a really long way.
I can't look at one single data point and say, oh, well, this is clearly what I'm being told, but it is raising flags that say, oh, there's something interesting to investigate here. The other part of it is just talking to people being in the right context, having conversations with the right people, listening to what is being said underneath what is being said and then matching patterns across the organization.
And so often what will happen is I'll hear one person raise an issue that they're having. And then in the next few weeks, I'll hear a lot of people raise a similar issue, which makes it clear to me, oh, this is an engineering wide problem and we should have an engineering wide solution to this. The other part of your question, how do you then decide what to prioritize is perhaps even more salient.
I'm really thinking about it in terms of if I solve this problem, what impact will this have on our business and not just on the teams, not just on the people who are facing this problem, but ultimately on the business and then working back from that and prioritizing based on that.
We talk about this more as we talk about engineering efficiency and just like the shift to efficiency in the market. Previously, there was a lot of space for exploration. And so a lot of problem solving was someone on the team saying, hey, I have this idea and me saying, great, run with it.
We want to do less of that at most companies right now. And so now it's a lot more structured and it's a lot more if we can only do five things, what would those five things be and what are the most impactful problems we can solve right now, not just the easiest ones or the most interesting ones.
I think this is a really great kind of opening up into one of the trends that I know we wanted to do a deep dive on. You sort of teased the topic a little bit. Let's dive into that trend of companies moving to optimize more for engineering efficiency and moving away from some of maybe that more open experimentation.
Talk to us a little bit about like, what are you observing across the industry right now? What are some of these trends bring us into what's kind of coming through your awareness right now. I think everywhere we're seeing the sort of move towards focus and efficiency. Peace time and wartime is a very powerful metaphor that people use to describe this kind of environment, calling you know the last 10, 12 years, peace time, but now recently we're in wartime.
I don't love that metaphor personally, especially with real war in the world, but there's a framing of it that I found really useful, which is that peace time is when you have a large advantage in the market. Our job as leaders is to make a lot of bets and to move forward on a lot of bets and try a lot of things because we want to capitalize on the advantage that we already have wartime is when you are facing a threat or a significant risk to the nature of your business.
You can't make a lot of bets. You have to make a few really meaningful bets and really focus on delivering value from them that shift from having a large advantage to feeling threatened is what we are all feeling across the tech industry right now. What that is resulting in is this focus on efficiency, this focus on focus and streamlining. These conversations also end up feeling a certain way for people, especially feeling a way for most I see and most early and middle management.
What that feels like is a loss of autonomy, this sort of shift from bottom up to top down decision making, but that's not what it is. It's not a loss of autonomy. It is a different mode of operation and it is a different way to provide value that is correct for the time we're in right now. We're going to provide value now isn't by coming up with a million ideas and exploring a million new paths. It is coming up with the most creative ideas on the path that we have already put our focus on.
A really powerful distinction to think about that from the context of how that feels for an IC. Folks in our community have shared some of those conversations and how the challenges and the emotions behind them and the context there I think is really powerful. Are there other nuances to this trend towards efficiency that you're observing that are kind of impacting how organizations are operating or some of these shifts.
I think specifically one of the things that I found interesting is people commenting about some of the shifts from vertical more vertical organizations to become more horizontal and how that's causing some sort of role shifting. Are you observing anything kind of in that space? Oh, absolutely. I mean, I think meta came out and said that they're looking to eliminate managers and have more people BICs, not not all managers, reduce managers.
We're seeing the similar thing across so many companies. The way that the previous decade went that curve was so steep, the growth curve and as a result, a lot of organizations ended up over hiring and we're seeing that in layoffs now. But they also ended up over hiring management ahead of potential growth. And so now we're in the situation where we have a lot of managers and not that much to manage.
The way that managers can really add value now is through doing more, creating value themselves instead of enabling teams to create value. That really is like this idea of flattening the org and creating an org where most people can build value themselves and the least number of people are focused on enabling others to build value.
I think it's a really good distinction. I think it applies at all times. It's the managers. They have the ability and freedom to find opportunities on their own that nobody else have noticed and making impact. It can be something within the team or it can be something cross organizations and even complain-wide in this so that nobody just realizes something worth of doing.
That's a very important mindset for any engineer managers or leaders to go and find those opportunities and amplify their impact. Not just looking, oh, I only have three people on my team. What do I do? Probably the team doesn't need you, but there are a lot more I can do. And that will lead to new opportunities. I've seen that happening a lot.
Yeah, that's such a good point, Jerry. The nuance there is that it's about finding opportunities but finding opportunities that are still within the problem area that you're trying to solve five years ago. I think we were telling managers, hey, if you have an idea for a whole new app that we can build, tell us and we want these crazy ideas. And I think now we're telling them, no, no, still do this thing.
But if you have an idea for how we can do it better, we want to hear that it's still creative problem solving, but in a more constrained space, that just gives us the reason to make it even more creative. Jerry, I think what you called out was so interesting in terms of like people have an opportunity now to make it impact maybe in a different way.
Given this background context of companies have to make less bets, creativity is applied in different ways, engineering leaders need to find opportunities to make an impact in a specific problem space versus more of this open green field problem exploration in this shift to moving to efficiency, how people can find those opportunities.
I think specifically I'd love to start with the emotional element first of like how do you overcome the early experience of ICs feeling like less autonomy and some of this unsettledness or anxiety around some of these shifts. How do you come overcome the fear or the that misconception or perception of shifting to efficiency. This was air quotes for people who can't see my hands shifting to efficiency. How do you overcome like the fear or the emotional narrative.
So many people that we work with have never seen a downturn. They are the children of summer. They've never seen a winter like think about the past decade growth was crazy. Money was cheap. Everything was just growing all the time and it is really top of mind for me all the time that when people have an emotional reaction to this, they've never been through this before.
Their entire careers have just been up up up up. I hold a lot of emotional space for that recognizing that this feels really scary because if you started working in 2010, which so many people we work with probably started working around then. You've never seen this, you've never experienced this. You don't know that you're going to be okay through this because you've never been okay through this because you've never been through this.
And so just recognizing that and reminding people who have been through this before of that doesn't really change our actions but I think it changes the way we approach them and the kindness and the space that we bring to the people who are going through this differently than we are.
The thing that I've been telling my team is that this is not a time to get through. This is a time to lean in. Let's not treat it as, oh my god, you focus on efficiency. Let's just do it and then it'll be done. It'll be back to the fun times. These are the fun times. They're just fun in a different way but these constraints are making us even more creative and these challenges are going to lead to us doing some of the best work of our lives.
That's the exciting thing and so I think the way through the fear is actually into excitement. This is really cool and we are going to do cool stuff as we work through it. I love that focus on tapping into the opportunity that the constraints create and how that then can unlock different ideas and approaches and it's not something to endure but rather it's something to like you said lead into. I think that's a really powerful attitude shift.
Yeah, this quote comes to mind. I can't remember who said it but it was pain is inevitable suffering is optional and that's what I think about it this time. Yeah, it's going to be painful but we don't have to suffer through it. We can still have a great time through it.
I love that another element of this that one dive into was what I've observed is some folks have been really bumping up against the challenge of engineering organizations either not being included in the process for like a shift to efficiency operating as a company as a whole and part of that is the challenge of communicating the value of engineering to other executive leaders or to other functions so that they understand its role in the business and shifting to maybe a new area of focus.
And so I was wondering if you could talk a little bit about how you approach communicating the value of engineering or focusing on the value of engineering in a larger strategic shift towards efficiency. I'll start by saying that at tech companies there is no business without engineering.
They are the applesauce of the applesauce factory you have nothing to sell nothing to market nothing to do if you don't have engineers who are building the actual product that the business depends on inherently the value of engineering is obvious. It's there really the question becomes about how do we show the impact of engineering and how do we show the impact of engineering not just in terms of the products that we build in ship but in terms of the health of our platform as well.
And I think that's where it comes down to framing everything really in terms of business impact like this conversation I've had in so many jobs in my career where we're talking about making performance improvements and we can never seem to put aside the time to make those performance improvements because we got a ship feature after feature and it really doesn't work until you start talking about OK well if this page loads this many seconds faster your conversion is going to go up by this percentage and that's going to show up in your revenue in this.
And that's why we're looking to make this investment making it real and quantifying the impact is what it comes down to and then also sort of very new question was this question about like making sure engineering has a seat at the table.
Partly I think absolutely engineering should have a seat at the table in every leadership decision that we make in leadership conversation that we have and if it doesn't then that's a sign of a very dysfunctional tech organization but also I think some of the ways that
the ways that we make our organization more efficient is to create more space for engineers to do what they do it's not just about having them having a seat at the table but it's also about getting really crystal clear about how value is generated at a company and then removing all of the road blocks to that value generation and recognizing that anyone who is not generating that direct value is serving the people and serving the part of the organization generating that direct value.
So we're all hyper focused on the same mission for our customers. You can have some examples of creating more space for your to do that. Yeah, absolutely. I mean one thing we can talk about is just meetings recently. I'm sure you saw in the news that Shopify did this sort of big chaos monkey at the beginning of the year and we canceled all recurring meetings that had more than three people in them and it was a lot of fun.
You know, obviously you can't have no meetings forever but what it does is it really makes you rethink of these 10 recurring meetings in my calendar which ones did I really need and there were a few that I never recreated because I realized oh I started doing it asynchronously and I can just keep doing it asynchronously and I don't need to get in people's calendars for this.
And then something that is really interesting to track in an engineering org is maker time how much maker time are your engineers really getting and I would define maker time as at least a three and a half hour block of uninterrupted time.
You'll be surprised to find that it's a lot less than you think they may only have two meetings a day but if you have a meeting at 10 30 a.m. and a meeting at 230 you barely have any uninterrupted time to get into the flow and get into true creative problem solving even just looking at data like that surfacing data like that and saying hey can we move all our meetings to book and maker time so that we protect creative time that people not just engineers all people in the community.
All people in the company have that can be so impactful because it's still the same number of hours but now it's structured differently and now you can be a lot more effective with the time that you have to get into flow state.
Systematically what tools do providers and years to do that because a lot of times especially on Slack people on good age conversation that we can career view have turned that easing communication to a conversation and a lot of those conversations that guys can happen at Hawk like hey are available for chat.
We can tools were first that you use to involve to do that more easily and but also have the visibility to monitor you know I actually I don't think of ad hoc conversations as meetings and I want to discourage meetings and encourage ad hoc conversations because I think meetings are incredibly disruptive because they are fixed blocks of time with a fixed set of people and you end up and
we do this as managers and we don't even think about it but it really impacts makers but you end up sort of planning your day around it you're like okay well at 11 I have this conversation and when I have this conversation and that's driving how you spend your time. So you're seeing the ad hoc conversation does not have the aura had all the unwanted impact in comparison to a meeting.
I'm saying that they're different because I think when you are having ad hoc conversations you're starting from the place of problem solving and then you are pulling in the conversation to continue that same problem solving thread and especially now that so many of us are working remotely making that ad hoc conversation into a meeting is so much slower and so much more inefficient then just
slacking someone and saying hey do you have a second I want to talk about this thing can we pair and obviously the person on the receiving end of that is being interrupted but it's still a less disruptive
interruption than a meeting that is in the middle of your morning that you're planning your whole day around and you have the option to mute that you don't have to respond right away if you are in the zone and you don't want to get back to it for two hours or a day that's fine but I think overall canceling meetings also has the side effect of conversations being shorter and happening more quickly than if you had to book the meeting with six people and wait to get them on board.
I'm also curious how's the three and a half hours calculated. So it's a little bit like I think it's three and a half hours you could think differently like this isn't scientific necessarily but the way that I think about it is a day is two four hour chunks and that's basically the time that you have to get into flow state and to creatively problem solve but then you also have meetings I in ideal case a developer has no more than an hour of meetings a day so maybe that's
two thirty minute meetings I'm thinking about as three and a half hour time blocks ideally it would be four but I think it would be hard to get two four hour time blocks every day so it's a little bit of a swag. It's very proper way to look at the vanper experience in productivity because as you said simple of time just how you arrange that will make a lot of difference.
Totally and it's what's leading the time right is your schedule leading the time or is the work that you're doing and the problem that you're solving leading the time if your work is working around your schedule that's not great for a maker.
What's better for a maker is I'm working on this problem I'm building this feature. Oh now I have a problem I'm going to stop I'm going to DM my peer and ask if they can pair on this with me that's being driven by the right thing as opposed to being driven by your calendar. It's a powerful perspective to get things.
So we're talking a lot about maker time and I know that this this shift towards removing some of these challenges is part of a broader intention at Shopify you mentioned to me is like the quote of like removing the toil first of you give us a little more context about that but then also what are some of the other areas you're trying to remove the toil.
So we had a conversation recently our CEO talked to the company about a number of things but one of the things he talked about and he always talks about is toil. His quote basically was that toil is drudgery when you are toiling on something you are subtracting productivity from the world because you are toiling instead of being effective and instead of being the most productive you can be and so it is sort of an insult to potential and he said rage against toil do not stand for it.
It was an absolutely inspirational moment for me to hear someone say that and it made me reflect on my career and all of the times where we've been in crunch time and working really hard and pulling long hours to get something out the door.
There are so many of those memories that I look back on fondly because I was generating value and there are so many of those memories I look back on poorly because I was toiling it wasn't the hours that were burning me out it was the toil it was the fact that I was working hard for very little impact and very little value to be in an environment where we openly say we don't want people to toil we want people to generate value and we want people to
consistently continuously think about how they can eliminate toil and how they can do their job in a better way than they're doing it today as opposed to just continue to do the job they've been given is such a powerful call to action and such a inspiring way to look at the work that we do that were never held back by how we do it today because we're always looking for a better way to do it tomorrow. So there's always creativity there it's never mundane.
I'm obsessed with this question because I already start to think about some areas of my life where I'm like I'm toiling here and just simply becoming aware of that you can you can remove it. I can see how this really ignites you because of being responsible for the mandate of helping make engineering successful removing the toil being such a powerful part to that and I love the power of the idea of it being like it's an insult to productivity by toiling.
I just think I'm obsessed with that phrasing in terminology. So what are you noticing like what is what has been some of the toil that you've identified in kind of this area and what are some of the things that you're working on.
Oh, there are so many different ways that we toil without even realizing it even in things like tracking what is happening across the company like when you are in a small sprint team and there are 10 of you everyone knows what everyone's working on but then when you abstract that out to the size of the company it is very difficult to do.
It is very difficult to say what thousands of engineers are working on and this is not a unique problem. I think every organization faces this problem and just having clarity on that is such a massive eliminator of toil because you can ensure that everyone is doing the right thing because sometimes toil isn't that the work is tedious.
Sometimes toil is that the work is wrong and you're wasting time on doing a thing that isn't actually that important. Other times toil is that our systems are failing us. What I have seen often in my career is we needed to solve this problem so we solved it quickly and then it's a problem we continue to need to solve but we've never updated the solution.
I needed this report once I built it manually and now every week I'm pulling the data manually instead of taking a couple of days to automate that report because I'm too busy. I can't take a couple of days to automate it so for years I'm spending half an hour a week pulling this data manually and like some ways that this has showed up for me personally is there have been so many times I've had too much on my plate but I don't have the time to hand it off.
And so I'm just doing too much because I can't seem to take the time to bring someone on board and give them like a days on boarding to say can you take this over now. And so for weeks I'll just be in that pattern until I recognize what am I doing with my time why don't I just put in a little bit of extra time this week and make my next several weeks easier.
Really what it comes down to is toil becomes hidden, obfuscated in the patterns of how we do our work every day and we need to step outside of the day to day to look at what am I toiling on that I could be doing better more efficiently more effectively with someone else's help especially now like the time of the world we are in and the way that technology is progressing and with the same time.
And with this the very exciting stuff happening in the generative a I space there's so much we're doing that we will just not do the same way in a few years and the faster weekend sort of identify and leverage that the better off will be.
I was a rant about toil and excited one but I think it's so it's so powerful we're talking about a lot of different shifts that are going on and I wanted to ask you one more about burnout because you're talking about the attitude of like you could just endure this or you could see this as an opportunity and I
identify new ways and dive into the constraints and use those constraints for creativity and so that mandate for efficiency doesn't have to be a toil in of itself probably one of the unspoken fears when somebody here's like we're going to become a more efficient engineer organization is well that means I have to either work harder produce more and that's going to burn me out but I think also paired with this mentality and this company mandate of removing toil I could see how that helps alleviate some of that but I was wondering if you could talk a little bit about the burn outside of engineering efficiency and I think that's going to be a lot of work.
I think you're absolutely right people here efficiency and they hear oh I'm going to have to work harder and also specifically I'm going to have to work longer hours because working harder doesn't have to mean working longer hours can just mean solving harder problems and being in more challenging situations but that's not what is going to be a lot of work.
It is true that with a focus on efficiency the ultimate goal is to produce more we do want people to produce more and by we I just mean leadership in general but don't do that by working longer hours because that is unsustainable and as a result is ultimately inefficient you don't want a team that's burned out that's worse quality that's lower productivity and eventually that is the goal of the work that is going to be a lot more difficult to do.
Eventually that is the cost of replacing a great person that you had on your team so it's not efficient at all it's inefficient this is sort of what we need to shake people out of is this idea of working harder to produce more think about it more creatively in order to produce more and sometimes this idea of efficiency comes up from the place of we're not shipping enough and that's why we need to be more efficient but when you say we're not shipping enough
you really have to look at it from the top to the bottom of the organizational stack are we not clear enough about what we want to ship are people working really hard but they're working on the wrong things are they working on the right things but choosing really complex implementations that are making them slower are they working on the right things with the right implementation but we're distracting them with too many meetings in order to be effective it's never a simple answer of
people will just work harder and this problem will be solved because the problem probably exists in so many different places in your stack we sort of need to be able to sniff all of those out and fix all of those in order to allow people to be more efficient and more effective and have fun while doing so I don't want any of this to feel like work is going to be less fun because I think work is going to be more fun because we will have more fun
we will have more interesting problems to solve and more constraints in our way and great excited people to solve it with and that's where the fun and work is it's not in you know finishing your work and then playing ping pong and having a beer like I'd rather do that with my friends I want to solve fun problems with my colleagues.
So I want to ask you one more question about efficiency and engineering efficiency but within the context of decision making as an helmet because we talked about communication we talked about meetings talked about build time and removing the toil and I know you have a perspective around decision making as an opportunity for greater efficiency here so introduces to this can you dive in and tell us more about your perspective here I have so many opinions about decision making I'm going to try and distill it down into two minutes poor decision making is one of our greatest barriers to doing
good work and when I say poor I specifically mean slow decision making taking forever to make a decision or not making the decision at all is almost always worse than making the wrong decision making a decision that unblocks people and allows us to learn faster fail faster iterate faster will in aggregate lead to better results then always taking the time to make a perfect decision
because you won't get it right every time anyway the way that I really like to think about it is in creating sort of zones of autonomy for decision making you can't have the senior most leader in a space make every decision because it just doesn't scale so how can they make the decisions that they need to make and clearly define for the layer under them what autonomy zone are they in within which they can make decisions and so on and so forth.
This is also does need to be driven by hierarchy I think having clear constraints and a clear space to plan and then also clear decision making ownership one thing that I've seen a lot is people get caught up in decision making by consensus because it is unclear who the owner of the decision is and so everyone's coming together and everyone's trying to agree on a decision and we can't so we often end up making the wrong decision.
The wrong decision or a decision that just isn't powerful enough or it takes us forever to get to a decision and this idea of collecting feedback and perspective from all of the right stakeholders but having one decision maker who can say this is the thing we're going to do and it's time to disagree and commit is such a powerful unlock because moving forward always is good.
Even if you for a while move in the wrong direction awesome the statement you made about decision making the beginning got me so excited we've got some rapid fire questions if somebody was to immediately make their decision making more efficiency if there's one tactical thing you could recommend what would you recommend. Know what your first principles are know what you're trying to get to and then be willing to take risks.
Perfect. All may look are you ready for some rapid fire questions. I'm ready bring it. Okay, what are you reading or listening to right now. I am listening to just started listening to the new season of land of giants where they are talking about dating technology. It is very interesting to think about how technology has changed basically so every aspect of our lives and ways that we didn't even expect and there's good and bad to that.
I'm still early in it but it is really well done and great thinking and I'm reading a fiction book called Cloud Coo-Koo Land that I'm really enjoying and it's a book about the love of books so little bit of meta book loving there. That sounds perfect. All right, next question. What tool or methodology has had a big impact on you in recent years I've really leaned into first principles thinking and I'm learning a lot about that in the last couple of years and I'm going to do that.
I've been working on this for a couple of years and really coming to every problem from first principles and applying this mental model to every system, every sticky problem, every new team has been a really, really powerful unlock for me. What's a trend you're seeing or following that's been interesting or hasn't hit the mainstream yet?
It's not a trend, it's a piece of news but I have been following very closely Gonzales V. Google in the section 230. Case in court right now because it has the ability depending on how it goes to really change the internet and the future of content on the internet and the way that most technology companies that we interact with day to day use content show content surface content.
I think this could be very, very interesting to see where it goes and what it says about the future of tech and lawmakers and judges and content on the internet. A great thing to spotlight last question, Alameilu, is there a quote or mantra that you live by or a quote that's been resonating with you right now? It's not quite a quote but something that I really live by is this idea of showing up show up for the work show up for the people in your life.
Even when it's hard, just show up and just do the thing and show grace approach challenging situation situations that are personally difficult for you that you're not enjoying with grace. No, that's what I live by professionally and personally and means a lot to me. Wonderful, Alameilu, thank you so much for an incredible Friday conversation. This was so much fun. Bring in the good Friday energy, we have an absolute blast. This was so great, thank you both.
If you enjoyed the episode, make sure that you click subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on, head to sfelc.com. See you next time on the engineering leadership podcast.