Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revello.com-elc today and save $2,500 off your first hire. 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. After surveying hundreds of engineering leaders, we've pinpointed the Top 10 Challenges Engineering Leaders are facing right now. So this is part 1 in a four-part series sharing some of the very best insights from hundreds of ELC events, podcasts and conference sessions.
In this episode, we focus directly on you, the leader. The excerpts we've pulled out tackle the challenges that are within your control and we're talking about challenges specifically like how you coach and develop your team, how you influence or create buy-in and even how you manage up or manage cross-functionally with your peers or people outside of your expertise. So let's dive into our first segment on coaching and developing your team.
You probably know that your effectiveness as a leader is measured by the results and impact of your team. So your ability to coach and develop stronger team members is a key capability to greater impact. So here's an excerpt from our podcast conversation with Tara Ellis, who shares her approach to growing your team beyond their current skills and role. I tend to think about it as just really pragmatic. Everybody wants to grow in some way and most people, you know, in order to do
that sort of growth, they often, they can't stay in one place, right? I know this is the truth for myself, so why would it not be true for my team? And so I really try to normalize that. When someone joins my team, I try to spend a fair bit of time with the expectation that you are not going to be here forever. I hope you are here as long as I can keep you, as long as our journey is kind of going together. But at some point,
whether that be a year, three years, five years, you're going to outgrow this. That's just the nature of work. And so I like to be really upfront about that. And I also like to prepare for that. So I do that in kind of two ways. One is with my engineers is that I know you're going to want to grow. I want you to grow. So let's have proactive conversations about what that looks like for you. And that can run the gamut. Sometimes people, it's
just really about skill acquisition. So like I had an engineer when I was managing a front end team, who really wanted to get more into mobile development. Okay. So how do we give you opportunities to stretch kind of that muscle in it in a space that you don't know about? That's something I would think about skill acquisition. I've had an engineer as her like, I'm really bad at public speaking. I want to be able to hold a conference
stock and I don't know how to do it. Okay. Let's start with me. And then we'll move to a team meeting and then maybe we'll move to all hands and we'll work up to it. And then of course, you know, the proverbial, I want to be a manager. I was just always like, do you know what we do? I mean, you think you might want that. And so that one's a little trickier but in a much longer process. But again, it requires some kind of forethought and effort.
And so all of this really is predicated on the, this is going to happen. So why don't we just do it together? Yeah. Confronting the inevitable in a way on the way. I think being inevitable. Yeah. Exactly. So is this a like a upfront expectation said in the first conversation? Yeah. When do you have that growth conversation? I don't do it right away. I usually wait the first quarter. Let you get your kind of under you.
What I do like to do though is let them know it's coming. So when we've gotten to that stage, then I usually how I introduce it is like, Hey, for the record, I'm someone who cares a lot about growth. And I think it's important. And I think we should talk about it. We should be very explicit about it. So I want you to think about what are the areas? What do you want to grow? What do you want to learn? What do you want to do? I'm
not asking for a five year plan, you know, but went direction. I don't even know. Do you want to be a leader? Do you want to be a technical leader? Do you want to be a people leader? Do you want to just five head and a lot of engineers who are like, I really just like doing what I'm doing. And I'm like, that's great. So think about that. And our next one on one, I'm going to ask you. So you have two weeks. And it's okay if you don't
know right away. But yeah, this is kind of the moment that we're going to start talking about this. One other thing that I think is also really important in this is I also really try to set the expectation that, Hey, we are partners here. I'm not driving your career bus. I can't do that for you. Right. But I can be an excellent navigator. I could tell you, Oh, you should make that right over there. I don't think it happens as much with senior
engineers. Generally, they kind of know what they want to do in some fashion, some are really buttoned down in summer. Like, but there has been times when I'm like, I don't know. You tell me what to do. And I'm like, I can't really tell you what to say. I need you to tell me what you need. And then I can support that. So I think it is actually really clear to get that expectation out so that they're not looking to me to kind of solve that for them. I'm a facilitator.
And did this become a conscious priority for you as a part of your regular interactions with your team? Was there like a personal experience where somebody maybe had that explicit conversation with you? When did you realize like, this is the important thing that I want to make sure every person I'm managing or leading has this conversation? That is a really great question. I don't know if I have, I don't know if I have one
like originating point, but I guess I have just two things I would say. One is earlier in my career, I had the fortune of working in places where people and senior leadership identified me as someone to invest in. And so I remember I was working as maybe my second tech job. And I had come in as a contractor and then I got hired on full time. And I'm completely self taught engineer. So I have a degree in international studies in German,
but not coding, right? So I've kind of gone around about into this career. Your home, Jerry's a geologist? Oh, nice. Yeah, only find what a person that does the same. A geologist? Yeah, I'm an audit. I talk to you in your industry. I know I have a whole, I have my whole bias about that. I was like, I think I'm a better engineer
because I have that better. But that's spicy. But you know, I remember sitting with, I was at a Christmas party and our director had sat at our table and we ended up talking with him. There's four of us for like an hour. And that's the first time I'd ever spoken to him. And, and that was it. And then the Monday morning, there was this beat, fudge meeting. There was like a new initiative that was starting. And at the last minute, I
had gotten added to the invite. And I'm like, what is this? You know, my boss's like, why are you glossing? I don't know. Like, I, you know, and I remember kind of going on and we're going to totally build this whole new platform. It was again, pretty hush. And my director trained my boss and be like, she's smart, find something for her to do on
this basically, right? And so I've definitely had people intervene in my career. And so I think that for me is this is a certain way of paying that forward, having a pre-sposition to say, Oh, how do I help you? I think a part of it is too. I, I haven't yet forgotten what it's like to be an individual contributor and kind of be flailing and not knowing that you're driven in a certain way, but you just don't know how to get there. And it's really
just kind of a question of altitude. I can see more than my engineers and my directors can see more than me and the VPs can see more than them. Like, when you look across the org and these things just don't happen if you don't have that kind of help. And so, I don't think there was really just one thing. It's just kind of like this conglomeration of experiences that made me say, Hey, I want to make sure I'm a multiplier for the people
that I'm leading. It sounds like such a special moment where somebody's like calls out, she's really smart. Give her something to do. I imagine like probably felt amazing in that moment. I don't know. I don't know. It was, it was like, Well, you see me, how did you get that from one, you know, one dinner and then also, Oh, God, it's a lot of pressure. Another dynamic to coaching and developing your team is who should you invest your time
and effort on to support their growth. And in a podcast conversation with Elaine Joe, Elaine shares that if you want to build self sufficient or more autonomous teams, the key is actually to focus on amplifying the growth of your higher performers. This is actually one of my favorite topics and also my pet peece and my management philosophy.
I think leaders need to do more to amplify their top performers. I mean, if they need to spend more time to work with and support and help their best performers to grow more for a lot of time leaders spend a lot more time focusing on low performers, not to say they are not important, but we like glad the people who contribute the most have the highest ambition and aspirations that they got the least support. So the way to do it for best
probably usually they actually don't need a lot of hand helping. I just need to tell them what I'm looking for, what is a goal and try to listen to them understand first thing, understand what they want to do first. Again, it's all about finding the right fit and
right matches. So I have drug conversation with drugs or skip level conversations so that they wish for me what they're really exciting about, what they want to do, what are the pet projects working on, what challenge, whatever they want to go, once understand that I will match what we are doing as an organization that my potential have alignment match of the goals and give them that opportunity. The other thing is remove roadblocks, right. Top performance,
they are match or problem solvers. So they eager to take initiative ago, but lots of time, they face a lot of roadblock, they don't know how to move and their solution usually is in work harder, but more hours, right. Just go drop. Sometimes that's the right thing to do is special of a technical project, but a lot of time when leader can come in and wait a second,
it's that roadblock, I might be able to remove that roadblock very quickly, right. It might be hard for them to do, I've been working on roadblock, well, this is not the area of focus, like for some of the MMI researches, so we need this data, we don't have the right data. Focus one, I can find budget for you to create those data, we can hire people to clean up those data so that you don't need to manually clean up these data so you can focus on doing modeling
research. You need tools, I can help to create those tools and remove the roadblock, and then the other thing that help it collaborate with them to do brainstorming or help them validate their solutions. Lots of time we're bringing this up, I'm thinking of doing this, what do you think? As much they really eager to solve the problems. Every one of us, especially surprisingly,
many high performance also do a impaster centrum in a certain degree, right. So really help them to do that the way that I solved the problem with them is not just that you're good, you're good, just pump them up. No, it's actually, let's look at the problem. I actually agree with this solution, and this is why I like your solution. These are the reasons really to engage them to support them, empower them and also help them to gain the confidence and give them that kind of
heart opportunity to try that out. And they will be out of confidence so much. The last thing is be responsible and accountable. I told my people that if we fail being the leader, that means I don't love the failure. Because even though I don't do that project, I approve that direction, I approve the solution, right. So I have to be accountable for that. I don't need to take credit, I don't need to brag about self, I don't need to say that this is my idea. If the idea works,
because they are my team, naturally, that means I did my job, right. So credit goes where credit you know should deserve, but I own up the failures. That is what I hope is to help them to ease the concerns, to create a fail-safing environment. High performance needs to be in that fail-safing environment so they're willing to explore and to eat away. As a US company, hiring remote engineers can be time-consuming, expensive, and frustrating. You could hire freelancers, but you don't know
how much they'll focus on your business. Out sourcing to dev shops, risks, control over who works on your projects and expensive long-term contracts. Or you could look overseas, but working across lots of time zones can really slow things down. Enter Revello. Your gateway to a talent network of over 400,000 pre-vetted engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to your business. Revello simplifies the hiring process,
enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts you only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control. You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. Now, we're going to spotlight a
different challenge. This one's focused on influencing and creating buy-in. So you have an idea that can fundamentally improve your company. But how do you leverage relationships and get others to believe in your idea or buy-in to a decision or direction? Pete Peterson joined us and shared about how generating quick wins and showcasing success were critical tactics to gain more influence in buy-in. Yeah, it was tough, right? Because you don't have that rallying point that
you mentioned, that common goal, common objective. You have 30, 40 different pipe-dems, everyone's doing whatever they want to do to a degree. How do we convince these 30 different directors or whatever that we do have common objectives? We do have some things in common. There are places where we can collaborate. There are places where we can have sort of economies of scale if we pull all of our resources together and we can all benefit from these things.
So unlike positions that I've had in the Valley where Tech is keen, Tech was a, it's a city that felt like a necessary evil. It wasn't something that was used as a competitive advantage. It was like, even when I joined, you know, they were talking about just keeping a light on, making sure the email stayed up. And I'm like, you know, I can do that, but that's not what I do. You're right. And I will do that, but I'm here to make change. I'm here to initiate,
to be the impetus for some kind of transformation and what we're doing here. I'm here to solve some problems. The biggest thing is finding collaborators, people that are willing to work with you, people that are willing to take a chance and do something different that it hasn't normally been done at the city. People that can see your vision. I went running to organization like that. I'm sort of the first thing I do is I just sit back and listen, right? I try not to rock the boat. I try
to just understand and learn. And then I can't just the area find out what's going on in other departments. What struggles are they having? What are they trying to achieve on their own? A lot of things you get is you get these little pseudo IT departments that spin up in every department, thinking how we can roll our own. We don't need the overall department. So I go through and I find these things. And then you see a problem. You like, okay, I need a quick win and you need a win.
So tell me about your problem, what you're working on. In this case, it was the housing department. The director of housing wanted to be able to use iPads to do case management. So when it comes in, they need a housing assistance. They go sit over to the side. They're giving an iPad. They fill out their information. That goes into the overall system. And then from there, we have a case management that's assigned to a case manager who takes them all through the process. So I look at that and I'm
like, I can do that. And this will be a great project for me to bring on this new technology. I think one of the key parts of it is to find a business champion or business, you know, collaborator or whatever we want to call it and then have a quick win, right? Not a win, it takes a year, not a win, it takes two years, but a quick win. So, you know, we were able to go in and collaborate. So they find it the project, they had director find it the project. My team built
the project and I don't know, four to six months, maybe a little less. And then we could showcase that project throughout the city. And we make the other directors envious. Look what we're able to do, look how quickly we were able to implement it, look how effective it's being for the housing department. And we can do these things for your department as well. Some of the initiatives that you may have had or wanted to do for some period of time, we think that we can help you get those
things done. So having that quick win, having someone that was able to to fund the project with us and then being able to showcase the final product helps move the transition, right? Helps to allow us to continue to build create momentum and bringing in this new technology and this new framework and this new thought processes that how we get things done. How much easier is that second conversation after having like that proof of concept that quick win in those results showcased? Super easy.
I mean, it's super easy. I mean, because you've been able to demonstrate that you can do what you say you can do. And you know, not to sound arrogant or think, but we're not, you know, we weren't the typical CIO. I had never been a CIO before, right? Every position I've had is engineering, leadership, VP of engineering, CTO programmer throughout my career, but it was always about building
product. It was never about the supporting and organization from the IT perspective. You know, I had enough information or knowledge about that because when you get into a startup, you pretty much do everything. I've installed routers, you do whatever to get that startup where it needs to be. So, you know, it was knowledgeable enough. I was new enough about it to do it.
But the real transformation, it's really in the applications, right? The applications that we exposed to our citizens, the applications that allow our citizens to talk to the city and to be exposed to the services and things that are provided by the city. That's the real power. Most of the things from an IT perspective are gone to the cloud anyway, right? You know, we don't need a data center. We had one and one of my objectives was to shut it down. All that infrastructure
stuff, Office 365, all that stuff, and the cloud, let them handle that, their experts. Let's talk about business logic. Let's talk about things that are specific to helping the homeless. Let's talk about things that are specific to helping people that have housing needs in a very expensive area. Let's talk about how do we make sure that the police department or the fire department and the building inspections department can communicate effectively? I mean, there are so many opportunities
to make a difference. So many opportunities to make a difference. Super proud of the accomplishments there. Probably even though it was one of the most difficult environments, it was probably one of the most fulfilling because it wasn't about just making money, right? It was about helping people
and giving back. Let's break down another component to gaining buy-in. In a conversation with Johnny Ray Austin about how best-a-ag navigated being required, Johnny shared the communication strategies their leadership team used to gain buy-in before and during the acquisition process. You know, myself and David and Brady, who were the co-founders at Till, we were really aligned and
resolute that we wanted to be like pretty transparent with the team. And you know, transparency, not meaning necessarily every single detail is communicated all the time, but it's really not withholding crucial information that people need in order to be able to make their own decisions. And so from the very beginning, before we even chose best-a-ag as a route or even before best-a-ag was even the contender, like we were very transparent, saying like, look, we are exploring this path,
right? At the time, we were thinking about raising money and also in that position and we didn't really know exactly which route we were going to go down. We shared that with the team, you know, we said, hey, this is path number one, this is path two, path three is a shutdown, like we were very open and talking about like, this is a path, it's very unlikely, but like, this is a thing that could happen. And so we chose transparency from the very beginning because one, we thought it was the right
thing to do, two, we knew the team could handle it. And three, it was really just one of those things where it was going to make the process easier. Because with the economy, the way it was at the time, people were already, you know, anxious, right? What's going on with tech? What's happening, you know, six months ago, jobs were all over the place, everyone who's offering, like, now people are thinking about layoffs. And then we've seen like a lot of those layoffs come to fruition. But
at the time, it was really about, are there going to be layoffs? And so we didn't want people to be surprised by anything. We really wanted to give people an opportunity to just sort of like make whatever decisions they thought best that serve them in their families. Obviously, we wanted to keep as many people as possible, but we really wanted to make sure we did right by the team. And so we
were very transparent from the very beginning about what we're thinking about doing. And so we were having weekly standups, full company, David, we get up and talk about here's how fun raising is going. Here are conversations with potential acquisition partners are going, right? Here's the path that we think we're going to go down, you know, as we were eliminating paths, we were like saying, okay, you know, we're not going to go independent. There are too many risks there. We're
going to go down acquisition. Let's just focus on that here moving forward. Here's this company called Besteg. Here's why we think they're a good fit for us. You know, here are all the pros and what are the potential cons and here are some other companies we were talking to. And I was getting feedback, you know, directly, and I'm sure others were as well, that people were really appreciative of that because they knew what was happening behind the scenes. So it gave them the confidence to know
that they were making the right decisions for themselves and for them families. And, you know, if it was going to be a besteg, then they were checking out the besteg website, maybe stocking a few of the people who worked there trying to get a feel for what it would be like to actually work there. Giving people plenty of time to sit with this information was really helpful because when
the decision was made and Besteg was the chosen company, it didn't feel like a surprise. It wasn't like, oh, wait, now I have to think about this whole new company and how's my job going to change, et cetera, because people have already been thinking about this for weeks at that point. Yeah. Well, I think one thing that stands out to me is how powerful it seemed to give your team the choice to participate and to think about it and to essentially respect them enough to share
ahead of time. Sure. And how that led to a sense of ownership and shared interest in investing, investigating these different pathways. Are there any other sort of lessons or processes around what it was like to communicate to the team throughout this sort of investigative or exploratory phase? Once it started to get to the phase where you're pretty certain about what the path
was going to be like, what was that like? Yeah, I mean, once we knew what the path was going to be, then conversation very quickly shifted from which path is going to be to, obviously, this is the path and this is what we need. First and foremost, we needed everyone to continue to do their jobs to the best of their ability because that was the reason for the acquisition is because the product was obviously super important, but also we made it known that the team was the most important thing.
If we're going to build this thing, best they needed our team to be largely intact because the idea is out there, it's no secret necessarily what we do and so it's not about stealing our ID and running away from it. It's about the fact that they believe we were the best
team to actually pull this off and that's why they wanted to work with us. And so communicating to the team that that was the most important thing was actually really helpful because it then gave them the permission to sort of like focus on their jobs and the continues to do a really good job knowing there was something at the end of it, right? It's kind of hard to do your job really well
and it's just like, well, are you going to be accompanying in a few months? I mean, that's how I would be essentially, but knowing that hey, there's someone there, they want us, it's going to be great, don't worry about it, just continue to do your job well. Really gave people the opportunity to focus
there and so that was really the important part. And after that it was really about the balance of not necessarily over sharing because anyone's ever been through an acquisition knows that like they're just an enormous amount of details and like diligence and things you have to do in order to get things across the finish line. And so it was really about establishing the balance of pulling people
in when we needed them, but then also, you know, doing this catch and release sort of thing. All right, thanks for all the help with this. Here's where we are. You did a really good job. Now I need you to go and like, you know, work on these tickets or whatever. So that was a super helpful and, you know, important part of the process as well. Now let's talk about managing up. If you're not thinking about how your work is being seen and understood by others, then you're going to have a difficult
time achieving the outcomes you want. Jan Chong shared with us three fundamental principles for effectively managing up visibility, understanding how your manager evaluates success, and how you align your work to solve the problems faced by your manager. I think there's three basic pieces that are at least how I think about it. One is the visibility of the work that you're doing and how much the person in just case your manager really
understands it. In engineering, we're usually lucky and that for a really long time, in our courters reports, other people that have been engineers. And so they get the fundamentals of writing code and what are the challenges with bugs and how, you know, you have to refactor and how you have to keep code living and they need tending. That's actually not truly understood if you're not an engineer sometimes. Then there's how does your manager actually judge your work
to be successful. And this is the piece that people usually have a sense of the visibility and understanding, but they stop thinking a little bit about, okay, how is it evaluated? Because we know our work so well that we think, oh, okay, if I've done a good job, it should be self-evident through the work. It should just be really obvious that this is now good and possible. And we don't
think, oh, do other people have that same frame to think about it that way? And then the last one, which is even more, I think, advanced is how does the work that you're doing solve the problems that your boss have or can help them in general? I think people now that I am in a leadership role, people come pitch me ideas all the time for projects or things we should do. And I think say sometimes leave a little frustrated if I'm not like, oh, yeah, sometimes it's like, oh, it's a good
idea, but just not important enough right now. And that's a great answer because you see your slice of the world so much, but you don't always see the whole slice of the world. So people are generally focused on solving their own problems and they don't realize, hey, this problem's just not that important. Actually, relative to everything else that's going on or this solution actually creates
more problems from your boss than other places, which is really, really common. But if you can align that and create solutions that solve both your problems and your managers problems, those are gold, like all fun, there's an heartbeat. And the specific question you asked there is how does this solve the other person's problem? Yeah, yeah, like we have our slice and we have an engineering
particular because engineering is complicated and complex. So often and the details matter. So we're so trained to be in those details and think about that that it actually is something we have to force ourselves to do almost as an exercise to step back and say, okay, how does this fit into
the bigger picture? What is the thing that really matters? Another exercise I sometimes tell young managers to do that's a regular practice, but kind of lines into this is when you have your one-on-ones with your boss, what you want to talk about as a manager that's different from what you talk about as an individual programmer is you want to say, hey, these are the problems I'm going to solve this week. This is my priorities. This is what I'm not doing in order to focus on those
pieces. And this is kind of what I'm worried about on the long run. This is kind of what I see coming on the horizon that I think we might want to be thinking about in the future, but there's nothing to be done right now. And what you're doing with that is making the work of management visible
because often the work of management is not visible. What did you spend the whole week doing? You've got people to align around a decision that's not inherently visible other than people saying, oh, yes, I think we should do that now, but it's hard to tie that back to OI spent two hours talking to different programmers on the team to pitch that it was like a pro and a con for this particular decision. So this kind of helps make visible like this is literally how I'm spending my week.
And then management often can also be like when things are going well, you don't always see all the work that's required to keep it going well so then you're like, okay, why didn't you solve all the problems right? That's helped provide a context and framing that so it's like, okay, well, here's what I'm deliberately being forced to deprioritize in order to get these pieces done. But what about how you manage your peers cross functionally or outside your domain expertise?
Matt spits joined us to talk about leading beyond your domain expertise and he shares the types of questions that you can ask to engage in meaningful conversation, how to probe effectively, and then ensure that strategies are well thought out and contextually appropriate. Let's take the example of leading a department where we're not familiar with it. And so, for example, I've added today the technical support department reports up to me as to security.
They'd be taking technical support as an example. I do not have expertise in technical support. I've never worked in technical support. But in general, I've observed technical support at companies that I've worked at. I've been a customer of technical support in many situations in my life. And as an outsider, I have some opinions and some familiarity with it. And I think the approach that I've taken is twofold. One, to just come as a student and go to that department and
say, hey, what does good look like? You tell me. I mean, I'd love to understand what your strategy is, how you want to make this department the best department at any company it can possibly be. Diving deep and really understanding that, I think that sends a message that I care. The other thing that I have, the value that I can provide to all these departments is visibility and context. The perfect strategy for support or something like security doesn't exist. It's
contextual, right? And the things that we're trying to do as a business, the things that are happening outside of those departments that maybe I have visibility into, that is value that I can provide to those people in shifting their strategy and setting the right strategy that's contextual appropriate. My approach there has been like really getting into learning what's happening with those departments and really understanding from their perspective what good looks
like. And then also giving them the context to be able to shape what good looks like in the context of the company that we're at today. The other part of the challenge I can see in eyes and your leaders is that why you're not expert at state, security or other domains and you have an expert on the team, but you are still responsible, accountable for the outcome. And you want to engage in that conversation with it, making sure that the outcome is good. You mentioned proving
as you have conversations with the main expert. What's your approach to probing is more of a standard list of questions or a framework you rely on to, again, with a similar to coaching, like help you to solve your own problem that kind of way. I think that there's a few different ways
they could add it. So one is just general management coaching, setting a strategy, communicating a strategy, breaking it down into the appropriate initiatives, like sequencing those initiatives, breaking those down into things that we can expedon, like community deadlines and dates, dates, et cetera, et cetera. Like those are sorts of things that are generic and applicable in any regard, both of the domain that you're working on. There's providing context and taking that
expertise and contextualizing it for the company. And so again, as I mentioned earlier, there's giving that person the context of what the business context in which they're operating. And then asking probing questions to convince themselves that what they're doing is the right thing. And I think that you'd be surprised that a's interested outsider can have a significant
impact just by asking questions and playing back when a person is telling them. It makes that leader sort of think about things differently and refine their strategy based on that. And the third tool here, again, I can't coach on, I don't have more domain expertise than our
security lead. But what I can do is find people in my network, in the company's network, et cetera, who are domain expertise, or at least peers, if not people who have more expertise and hook that person up, hook our security lead up with those people as a way to sort of pressure test the, hey, this is how I'm interpreting what Van Tazdien's are today. This is what I think we need to focus on from a security perspective. What do you think interested outsider who has security domain
expertise? When do you know you can't stop probing and you know, this is very good. You get to what you want. It's more of an arthritis. When I am convinced that they're convinced and have done sufficient diligence that their plan is the right plan and approach, then I think I'm done. We had to accept the fact that why are responsible conable but there are risks to take? Oh, absolutely. If there's one constant, it's change and risk and imperfection and completeness.
How do you rebuild morale after a riff or reorg? How do you get that senior engineer to work on a project they're not excited about? So many folks shared with us that they want to better inspire or energize their people and teams to achieve their best. The perfect person to support here is Laura Taco, who spoke with us about how to inspire developer productivity and the key word
here being inspire. The memory and the footprints that those wrong incentives leave behind are very deep and I think about organizations of having the momentum of like a cruise ship and then you try to
do something. It's like trying to steer it with a spoon. It just takes a really long time. And so there's a gap that always needs to be closed because you've trained people that hey, you're a mouse and if you do this, you're going to get some cheese and then all of a sudden you put the cheese somewhere else and they're still going to be looking in that old place for the cheese until
you teach them. Hey, it's over here. Here's how you can find the cheese. And if we think about that with people, it's not just about changing the measurement, but you have to fundamentally change the way that people work. In an order to do that, they have to be motivated to change the way that they work. And that is the hard problem you need to figure out a way for them to believe or see that the version of the org or of themselves that you're trying to get them to is better than the one that
they currently have. Right, because that's all I think at some level, we're all working in sales. Right, we're trying to persuade people to do things differently. And I think at some deep level sales is just selling someone a version of a different version, a better version of themself. And so you really need to answer that question, what's in it for me in order to get them to change
their behavior. And that's why that intrinsic motivation piece is so key and essential. Because if they don't have motivation, it's just harder to get them to move the needle and harder to close those gaps to get the change to actually be enacted on the ground where it matters. This is profound.
I mean, I think about a lot of times there's resistance to not want to be salesy. And so when I think about like, what is the case for an engineering leader to develop influencing skills, like this to me seems like the supreme case for why it's so important to be able to cultivate a vision for somebody else. That to me is like, it's profound. Yeah, you know what I as an engineering person,
I think this like, I'm very turned off by salesy marketing things. I think that's a very common attitude like in our pocket of the industry because it's like, it's so easy to define ourselves on what we're not. And I worked with a really great business coach when I started my coaching business. And one of the things that you worked on was like, I really have an aversion to anything that's like salesy or marketing ee. And she just said like, but don't you think that clients
working with you has a positive impact not just on them, but on their whole org. And I said, of course, and she said, but they can't have that positive benefit unless they know about it and unless they know about you. And so what are you going to do? And I just thought that really changed my whole perspective on this. And I think influencing doesn't have to feel salesy. And I think engineering we often get that push back to like salesy, influencing stuff on things that we don't
believe in. But as an engineering leader, absolutely, if you believe, I want to make sure that my team has the best possible environment, the best possible developer experience so that they can do their best work, you got to have to have you need to learn how to influence and have to learn how to
present that in a way that gets people to participate in your system. Because if you truly believe that that is the right ethical moral thing, but also like the right thing for the business, you need people to participate in that only comes with influence. You know, when we talk about motivating others, like one of the big questions is motivating others to what? What's the result? One of the results that you're probably looking for is how do
I make my team or organization more productive? Sometimes the greatest motivation is feeling heard and then seeing direct action taken to solve your problems. And that's exactly what Pretty Coata and Dan Cater shared at ELC annual 2023 on Atlassians journey behind creating developer joy, removing friction and empowering teams. So one of the reasons we're here is because you and your teams at Atlassian have been on a journey with developer productivity over the last couple years.
I'm curious what specific problems did you and your colleagues observe engineers at Atlassian struggling with that made you go, okay, you know, we have to do something here. We need to make an investment. That's a great question, Dan. How many of you have to deal with tech debt? unanimous, right? We all talk about it. We all think about it. So what happened with Atlassian is we've grown. We now have over 260,000 customers, Rivian, NASA, Reddit and many, many more, right?
And our headcount has scaled since 2020. We've nearly doubled. So we have 11,000 employees, nearly half of them are developers and we've grown. We've shipped new things. We've acquired companies. We've built new products. And what comes as a side effect of growth is growing pains, right? We all talk about it as tech debt. So you start having these water cooler conversations, right? It's like, oh my goodness, this is just taking so long to fix. And you know, this is broken,
and that is broken. And so we are no different. We saw the same things. And so our engineering leadership decided to dig into it and understand what is going on here. And I think what we found shouldn't surprise any of you, right? The first thing we found was there was just too much friction, too much friction to get things done. Things were taking longer. It was much slower. And then the other thing that we found was, you know, you have this friction. And I'm sure each of you can
at the top of your head rattle off for things that you can do to address this. But what we found was that our themes didn't feel that they could just go fix it. They didn't feel that empowerment. And that was surprising to us, right? Of course, you know, if you really think about it more, this happens to all of us are amazing product counterparts. We want to drive the business forward. We want to drive business outcomes. And I can tell you the number of times I've started out a roadmap. And
like, we should address this tech debt in this quarter. And then see, I see you laughing, you know, exactly where you're going with this, right? End of the quarter. It's just in the bottom of your roadmap. And so this is what we found. And the other phenomenon that we found was our developers were so afraid to break things. You have a growing product and you have a customer incident to resolve. Or even after that, you know that there's this gnarly piece of your stack. But do you really
know what all your downstream dependencies are? Do you know the impact of it? And so we found that our developers were, you know, layering changes after changes just because of the fear of doing something wrong here. And you know, we found this with the explosion of microservices, right? Things are definitely different from when I started out 20 years ago. Same. Atlasian was one of the first tech companies to go distributed even before COVID, right? And we're a worldwide company.
What we found is we have all of these services. I have no idea who owns this. And if I have a question, I send a question to whoever I think is the right team in Sydney. It takes 12 hours for them to come back and tell me, actually go talk to this other person. Another 12 hours, right? So these are some of the things where we knew we had to do something. Yeah. Well, I think we can all relate to basically all of that. I know I can, especially the going into planning with the best of intentions.
We're going to tackle this problem and then leaving with, wait, what happened? Why am I? Why? Okay. Well, I guess here we are again. So how did you get exact buy in? Like, how did you actually make time carve it out, protect it and get buy in from the exact team to go tackle these things? Yeah. So our CTO came in about a year ago and luckily for us, right? We've been super fortunate in having the CTO who really believes in making lives better for our developers. He is very
passionate about developer joy, right? Like one of the things that he likes to say is that code is like a human body. You take care of it and it takes care of you. Having that executive sponsorship has been super important. And I think that's one of the key things that's really made a huge difference. And I can see that tangible improvement, right? It's a company level okay. I have to make sure that we have accounted for developer productivity, developer joy related work in every road map.
And I make sure that our teams have time to go fix it. And we didn't stop there, right? And we knew up front that metrics were super important for us to have. It was not just the Dora metrics. So we decided to focus on cycle time and deployment frequency. Those are the key ones that we decided to focus on. And we decided to ask our developers what they thought, right? What is your satisfaction level? And so we sent out a survey to collect this information. The key thing to
remember here is it's all of this data working together. It's not each one in isolation, right? So when we ran our first survey, our satisfaction scores were just under 50%. That's not a good number. Absolutely have to do better than this. And so our leadership team came up with a three part framework. The first one is awesome tools. I mean, we are craftspeople. You need to have the right tools to get your job done. And Atlassian really believes in this open tool chain philosophy.
Developers are empowered to pick the tools that make sense for the problem that they are trying to solve. And when we can't find the tools that we need, we build it ourselves. So Compass is a great example. And that's something that I am personally super proud of because I work for Compass. We found that with this distributed world and distributed teams, keeping track of things was super painful. So one of the things that we built, which was homegrown first for our own needs. And then we said,
you know what? This is useful for everybody. And we graduated it and baked it into a product. Right. So that's Compass at the heart of it. It's a catalog. It's a software component catalog. You track whatever matters to you. And you have information metadata around whatever you're tracking. How do I get in touch with this team? So the Slack channel is right there, centralized, their on call schedule, run books, documentation, and so on. So we believe, so awesome tools is one
of the pillars. And the second one is empowered teams. And this is one that I think makes it possible to do it at last year. Right. As part of developer productivity, the program itself, every team gets 10% of time to go fix whatever you think is important for your team. So this is the power of localized decision making. Right. The central program is not telling you you shall go fix this. It's telling you go understand what your team needs to address. Make sure you invest
at least 10% to go address this. And we have a number of success stories from this approach. One good example is the Confluence team looked at it and they basically said that our PRs, the number of PRs that get to prod within 48 hours, it's 12% and that's not good enough. This is one of the problems that they decided to tackle. They spent one quarter and the number jumped to 31%. So as we close our first episode tackling the top 10 challenges, I've got three questions for you.
What have been the most effective ways that you develop and coach your team? How do you approach influencing or creating buy-in? What do you do to manage up or manage your peers effectively? We want to know what you've learned and how you're tackling these critical issues. Send us an email or share a comment on LinkedIn and help us share the wisdom of engineering leaders across the community. See you next time on the Engineering Leadership Podcast.