Stacey Gammon (Elastic)
What works for a small company may not work for a large company, so what do you do when your organization experiences rapid growth, and the old way of doing things is no longer sustainable? In today’s episode, we speak with Stacey Gammon, a tech lead and Principal Software Engineer at Elastic. She has been with the company for almost five years and in that time has been able to observe firsthand the challenges that come with rapid growth in areas like scalability, communications, and project management. Tuning in you’ll hear Stacey break down the details of her role and how she manages teams and people. She elaborates on how Elastic is currently approaching the problem of scalability and how it is still a work in progress. We hear from Stacey about the many projects they have going on at one time and why the biggest challenge is often saying no to new projects. Later, we discuss retrospectives and why they can be a safe and effective way for teams to learn from past errors. Stacey shares the details of the formal mentorship program at Elastics and unpacks why the long-term benefits of delegating outweigh the extra time commitment it requires in the short term. Stacey shares her feelings on spending a large portion of her time in meetings and why she believes one-on-one meetings are valuable. We loved having Stacey on the show, and we’re sure you will find the conversation every bit as insightful and thought-provoking as we did! For all this and more, tune in today!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas and I’m joined by my co host, Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, thanks. Our guest today is Stacy Gammon, a tech lead and principal software engineer at Elastic where she works on the Cabana team. It was a pleasure to hear Stacy’s story, so let’s jump in.
David: Stacey, it is so nice to meet you. Thank you so much for taking the time today. Can we start by having you tell us who you are and what you are?
Stacey: Yeah. My name is Stacey Gammon and I’m a tech lead at Elastic.
David: Awesome. And what does a tech lead at Elastic do?
Stacey: Depends which tech lead you ask. So my particular role, there’s about 80 engineers on the team that split up into five different areas and the tech lead is in charge of code quality. We do some project management, a lot of orchestration, just knowing who’s doing what and what’s going on, and guiding coming up with processes that will help our developers be more efficient. It’s a very free role as meaning, like, if I see something that I think needs to be done, I can do it. When I first got the role, it was told to me that it’s no longer my success is judged on the success of the team as a whole. So it was like, you see something that will help the team be do better, then that’s kind of what you have to do.
Alex: One thing that we’ve noticed is that everyone has their own unique spin on these sort of like archetypal roles. And I’m curious, what’s your special sauce or unique spin on being a tech lead?
Stacey: I would say I get where your question is coming from. I think there’s people that are like depth, they’re domain experts and they can grow to be principal engineers in that way. And then there’s the other path, which is more breadth and it’s just more people oriented. And I think that’s kind of the path that I’ve taken. I’ve been with the company for a long time, five years, so I do have a very large understanding of the code base and how it’s grown Although now I’m pretty checked out of it by now, so. Yeah, it’s just trying to ensure code quality, setting architectural direction, technical vision, knowing the right people and getting the right people in the room. I don’t need to be the domain expert if I know who the domain experts are and I can just get them talking to each other, you know, just spying things that are going to cause problems down the road, shaping projects. It’s just a big can of various things.
Alex: Yeah, for sure. I know that. I’m sure lots of folks are familiar with Elastic and elasticsearch, but would you mind sort of like just explaining more generally what the project is and then sort of like how the organization that you work for, how it interacts with the elasticsearch code base.
Stacey: Sure, yeah. So I work on Kibana and we’re a layer that sits above elasticsearch. We’re a platform team and other developers build their applications on top of Kibana. So we have a whole security organization that has their security product that has an application in Kibana and we have an observability product as well that writes code on top of Kibana. And then we leverage the data in elasticsearch to search and display and let users analyze that data. So I sit at the platform layer in Kibana.
Alex: Very cool. This is probably my ignorance, but do you feel like your platform in client facing, like client side code, or do you feel like your platform backend services? Or am I just completely missing the architecture?
Stacey: Both. We have a lot of client side code. It’s very complicated, so it’s not like your average client side browser facing code. We also have a lot of server side code that’s in Kibana. So there’s. We’ve talked about having Kibana as middleware before. We’ve got Task Manager, we’ve got alerting capabilities, we need to be scalable and then we leverage elasticsearch as a service as well.
Alex: And so your role sort of like encompasses the whole scope of Kibana and you support teams through who do that work?
Stacey: Yeah, my role encompasses the platform side of Kibana. So the area teams are operations, security core, which is just like the core capabilities that like every developer building on top of Kibana needs to use. Like we have these things called savedoc objects and that’s like a core concept that’s owned by the core team. Migrations, backward compatibility. Then we have the application services team, which kind of is more UI facing. They will have like these reusable components. And then Kibana was like. So Kibana is split into two halves. We’ve got the platform half and then we have the analytics half. And the analytics half will have things like our Dashboard application and our visualization capabilities that can still be reused. They’re still, you can still consider them part of the platform because they expose code that other developers can then use in their own plugins. And then outside of that, we actually have the two organizations, the solution teams, which are completely separate organizations, but still commit code directly to our repository and they leverage utilities from our visualization plugin, from our dashboard plugin. They might embed a dashboard inside their page so they don’t have to build it themselves. They might use this search bar capability inside their page. We try and give them the building blocks to make it really easy for them to iterate quickly and also build solutions that are very connected. So we have like, for example, this system called UI Actions. And so like you, you want to register like an action on like a panel kind of like in Chrome, you know, and like you go in an application, you want to like share a photo. There’s a bunch of different things that come up. And other developers registered their, you know, special link inside that. So we have something similar to that. So you can kind of connect the solutions together. So you’re in Maps and you want to run a machine learning job on it, or you’re in Discover and there’s like an IP field and you want to say, view this. In the Maps application, they’re all owned by different teams and the platform just kind of helps them connect together, create.
David: More of a flow, kind of rewinding a little bit. You mentioned that when you sort of moved up to staff, you were told that like your performance would be kind of measured against the performance of your teams rather than you individually. And so I’m curious, like, did that transition happen while you were at Elastic or was that, was that earlier or like sort of. How did that come about?
Stacey: That was at Elastic. Before Elastic, I was never in a leadership position. I joined Elastic as just an engineer. I actually had no leadership ambitions. I was quite scared of making any decisions and I coding, you know, role and I quite enjoyed it. And then at some point someone asked me to be an area lead of a team. And an area lead is like 20%. Back then it was 20%, 20%, like roadmapping, kind of mentoring responsibilities and 80% coding. So I was like, ah, you know, it’s a opportunity and it’s only 20%. So I’m gonna, you know, get my feet wet with this leadership thing. And I took it and I enjoyed it. And then I think maybe like a year or so later, I. My manager reached out and asked if I wanted to be the tech lead. And that was a huge jump because it was from, like, leading a team of like, three. Three people to. To leading a team of 20. I think at that point, it’s not, say, leading. It’s not. I’m not a manager, so I don’t have direct reports, but leading the architecture, so, you know, helping developers code and overseeing, you know, the architecture and everything. And it was pretty scary to get, but I was like, again, I was like, this is an opportunity. I can’t say no to it. So I. I took it. I’m really grateful for that manager because if he didn’t actually, like, reach out and ask me, I don’t think I would have actually reached for it. And then once I got my feet wet doing that, I was like, all right. I kind of like. And then I’ve been pushing up the career ladder, you know, ever since, and trying to, you know, see what I can do for the company.
David: Awesome.
Stacey: That’s.
David: That’s really cool. Do you think. You know, sometimes people talk about the idea of, like, a staff project or basically, like, completing some sort of project that’s of a big enough scope that the company’s like, oh, okay, yeah, like, maybe this person is ready for more responsibility, that kind of thing. Was that your experience? Was there anything like that around the time where your manager sort of prompted you toward tech lead or sort of. What do you think prompted that decision, if not like, a specific project?
Stacey: So there were a lot of projects going on at that time, but I. I suspect that wasn’t the reason I was asked. I think I was asked because I was more outspoken about things that I wanted to push for change. Like when we moved away from Angular into React and JavaScript to TypeScript, I just had no fear of creating documents and sharing them with the team and being like, we should change this. This is a risk, et cetera, et cetera. And I think it pro helped that I did have big projects that were going well in addition. But there are plenty of developers that run big projects successfully that it’s not like a requirement to. To get to the next level. And even when I actually finally got to Principal Engineer 2 just last month, and that. That also. Thank you. That also didn’t come with the project. There were some things that I were running, but it was actually more of, I think, the communication and the outreach and just getting to know people in all parts of the. Being more involved and more heads up as opposed to just staying down in a project is actually one of my weak spots. I think that I had a tendency too much to do that and I needed to look up more, connect with other people.
Alex: So I’m curious, when you’re sort of like documenting issues or talking about the future of architecture, how do you connect these, like, sometimes it seems like very technical achievements or goals with like, sort of what the organization is trying to do it. Do you have a specific approach to aligning those two things?
Stacey: Such a good question. And we are trying to figure that out right now. We are. You know, we’ve grown so quickly that we had like no process and all these teams would have their own roadmaps. And we’re really feeling the pain of that now of trying to figure out how do we prioritize, how do we get teams to prioritize technical debt and compare the priorities, and how do we also avoid micromanaging these teams and saying, you have to do this, you have to do that. So we’re actually just now trying to experiment with okrs, and if we can come up with like, measurable results that we can give the teams, then maybe that can give them more direction as opposed to this giant list. We have this list of like 80 projects to try and keep track of, but there’s just too many. There’s tons. And it really dilutes our focus and causes a lot of slow feature development. So we’re growing as a company.
Alex: Are there any projects that you’ve worked on in the last few years that you feel like really aligned well with the organization and created a lot of value?
Stacey: Yeah. So one of my first projects that I worked on was this thing called Embeddables. And it was sort of like our dashboard and capability has a pluggable infrastructure. So you can have these little, what we termed embeddables plopped in there, and then anyone could write their own, and then it will show up there too, and it will also, you can add them to your own application. So if you have a dashboard, but a solution wants a curated dashboard that’s specifically set up with their things, they can do that. The UI actions one I really liked as well. I actually didn’t even realize it kind of related to the Chrome or the, the Android way of doing things. They have like a very similar system. Until another developer was like, oh, it’s really like this. And I looked at it, I was like, oh, that’s very cool. And then most recently I’ve been documentation has been my pet project that I’ve been really excited about. I wrote TypeScript, like documenting JavaScript, especially in our very unique world where we have a single giant repository with a bunch of JavaScript plugins that are all in it. And like we have our own way of defining what those boundaries are. Like, what are the capabilities that each plugin says this is a service that you can use and which is like internal code. It’s just like something we define and I don’t know anybody else in the industry that does it. So we were looking at using API Extractor, but it just didn’t work for us. And so I wrote something using this library called ts morph on a light layer on top of the TypeScript compiler. And it’s just so much fun. It’s also because I can get my hands dirty coding again. So that’s my therapy, the project management stuff. I’ll go into my little code corner and build more API documentation stuff. But it’s actually, it’s supporting now the ability to track like, code metrics, code quality metrics, which I really want to. That’s a passion of mine because we have so many developers writing code to this repo and we’re in different orgs. If you go up the hierarchy, the first person in common is our cpo. So like, we’re not going to go talk to the CPO and try and come up with like a development best practice. So we really have to like work together to come up with these best practices and having insight into the plugins. And if we could give them a quality score, then we could say, hey, this is the bar we’d have to get agreement on. And we have this thing called the Contributor Council, which is something I came up with that getting representatives, technical representatives from all of those solution teams into a group to try and make it more of something that we did together rather than something that the Kibana platform team is dictating. Because we can’t really dictate it. We don’t want to dictate it. We want to do this together. We want to understand their needs. Yeah. So my API documentation system, I just have so much fun with.
Alex: Nice. Did the API documentation service arise out of the work that you were doing to create the code quality metric, or were you just sort of like scratching your own itch and then it happened to become useful?
Stacey: It actually, no, I started using it, I think for the code quality metrics. Then it all kind of came together organic and I was like, I can use this to Create our documentation system as well. So it just came together and that’s kind of why I started using TS Morph as well. It’s just I had a lot more control. You’re not going to get a lot of control with API Extractor. It’s just for documentation. But with using the Typescript compiler, I can say how many times is this public API using the any type? How many public APIs are missing comments, that kind of stuff.
Alex: That’s really cool. I think a lot of engineers, I think they sometimes like inherently understand the value of these kinds of tools, right? They’re like, oh man, that’s amazing. It’s going to make my day to day so much more better. But we often struggle to communicate like how valuable these tools are in a business context. Did you have to sell this idea to non technical users or someone? And how did you do that?
Stacey: Yeah, it’s tough. And selling the idea of projects is something that I’ve had to work towards for a while. I felt like, oh, I need a ton of metrics and stats and this giant presentation to convince product that this is really important. And that would be kind of a blocker because that would be very time consuming and I wouldn’t always get around to doing that. And then at some point I realized if I just say it, they actually trust me. So I’ve been leveraging that a little bit, just being like, oh wow. I actually have some, you know, people trust my opinion and I can say this is really important. And also getting the contributor council to, you know, the solution teams to be like, what is important to you? More communication going on. But it’s really, it didn’t actually take as much as I thought. It helped that I also kind of took on the work by myself. But I am delegating the actual writing of documentation at this point now and there are teams that are on board and fully behind it. So that’s really awesome.
David: I think it’s interesting you mentioned that, you know, it helped that you did the work yourself. Something that I’ve found is that oftentimes when trying to sort of sell, to basically sell the value of a technical change to the business, it helps a lot to have like de risked significant parts of it by having jumped into some of it yourself. Right? You might not have the finished solution, but you can prove that like the hard part is tractable or whatever. Is that kind of what you mean when you say that you jumped into it or like to what extent? Like what level of polish did you have before sort of presenting it to folks.
Stacey: I had it practically done. Honestly, when I was doing, I had like a side project where I was tracking the, some of the metrics and I was like, oh, I can do this. And it actually did not take me that long to pull it together. And so it was like, hey, it’s done. And then we actually went through a review with some of the teams that we thought might end up owning this code in the long run. And they had some concerns about not using API Extractor and using this like custom implementation. And at the end of the day it’s like, well, listen, we’re in the prove value phase. We don’t have any documentation now. We haven’t for years and it’s been a huge gap and now we have something and I’ll maintain it for the time being. And once we can prove that this having documentation is really valuable, then we can have the conversation of who owns it. And you know what, if you want to go and like rip my whole implementation out and put in your own, feel free. I don’t care. You know, I just want documentation and how does it.
David: That’s a good segue to sort of the next thing that I wanted to ask you, which is like, once you’ve sort of got buy in from the. Org on any project, right, this, this API documentation is a good example, but just in general, like there’s also a step where you sort of need to get buy in from the, from the various teams involved, right? And sometimes the, sometimes the different teams are sort of like focused on different things and might not have exactly the same sort of incentives or exactly the same goals. What’s the approach that you take for sort of selling the project to teams and using, you know, influencing those folks to sort of buy it? Because you mentioned earlier, you’re not a manager, you’re not telling people what to do, right. And so there is a little bit of a, of a sales process happening there too, or something like that. What does that look like?
Stacey: Great question. That’s actually something that’s been difficult for me with the role to figure out. You know, I’ve had to learn that it’s not like you have. There are subtle ways to get people on board with things. It’s an art, you know, like, how do you make someone think something’s their idea, you know, or like, or listening to them and framing it in a way that they can understand. And it’s, it’s a work in progress for sure. There are a lot of things and sometimes you just have to back off. And be like, all right, if this isn’t important for you, you know, like planting seeds like this is here for you, maybe, you know, I think this is important. But, you know, if you don’t, sometimes you have to just let people go ahead and fail or not fail. Like, maybe they were right and it wasn’t important and maybe you, you know, maybe you were right and they will fail. But that’s okay because it’s a learning experience and you all learn from it and there’s value in that.
David: It is a little bit tricky when you end up being right and they did fail and you still have to bite your tongue and not say, I told you so, but you’re right. I mean, I think, I think that makes sense. I think letting people fail is hard but important. And also, at least for me, I’m not right all the time. And so it’s interesting to sort of. To sort of see other ways that people solve problems. Do you find that there’s sort of like that you ever have to sort of mediate between different teams and sort of get them. Maybe someone has bought into your idea or they’ve sort of taken it on as their own idea, or they’re feeling ownership around it. But you’re now trying to get multiple different teams to collaborate on something. Or maybe you’re trying to convince the managers to allocate some resources. Maybe the. Org is bought in, but you still actually need to do a little bit of horse trading to get the right engineers working on the thing that you want instead of the other priorities. Is that something that you run into? How do you navigate that?
Stacey: Yeah, it’s really tough. And it’s more. Rather the most difficult part is saying no compared to getting other people to say yes. I think it’s new projects coming up and saying like, no, this is not more important than these other things. And we don’t have the best process right now. We’re working through it. We’re trying to come up with just now we’re trying to come up with our stack level priority. Stack, we call the Stack encompasses the elasticsearch team, the Kibana team, the machine Learning team, and I think Logstash team too. And we have to coordinate with the solution teams, the Observability team and the Security team. And we have these top five projects. We have one between Kibana and Observability, one between Kibana and Security, one between Kibana and elasticsearch, one between Stack and Cloud. And I’m like, okay, that’s like 25 projects. And most of those projects end up falling on just a few of the core teams. And so, you know, you’ve got 20 developers and 25 projects. It’s just not sustainable. And so we really need to consolidate those lists and figure out which are the highest priorities, what are the goals of the company, and where can we stick in some of the technical things, too. We actually, with the OKRs, one of them is being operationally stable because as we’re moving so fast, we’re hitting some issues where that’s some scalability issues, and even if it takes that whole fail thing. But now when you feel the pain, it’s like, all right, now we have to really focus on this and make sure that we can have insight into our operational stability and what’s going on with a lot of these new services that we’re building. That’s really cool. A perfect answer for that. I’m figuring out if you have the right answer. You can tell me. No.
Alex: We learn a lot by listening to folks like yourself and how you do it. We talked about sort of learning from failure a couple times, and I’m curious, is there any particular way that you think teams do that well, or how do you help teams learn from failure?
Stacey: Retrospectives, I think, are the best way to do it, and you need to in a delicate manner so that you’re not blaming anybody. We had a project recently that went through a retrospective and we came out with a lot of good ideas, project management ideas, because it’s like, all right, this team didn’t know that this team was doing it. This team had expectations on this other team, but they had no idea. They didn’t realize they needed it by this date. And so it’s like, all right, well, where’s the information? We’re in. We’re a remote first company, and so we need more things written down, but not just more. More things written down could equal nothing written down. If you have too much, you have nothing because you can’t wade through all the information. And that’s actually something. We’ve been a very open communication company. And, you know, it’s like, don’t have so many email lists because just like, hey, email the whole team. But now it’s like, I don’t think that’s going to scale because not everyone can read every email. So, yeah, trying to scale and figure out how our communication is is really important.
Alex: Changing subjects real quick. I was curious, like, do you mentor or sponsor folks at all through your work or in your role?
Stacey: We have a formal mentorship program which I Did a few times, which was really great. And informally there is mentorship where like delegating is one of the things that I’ve been focusing on because I am a doer and I like to do things and I have to get used to not doing things but asking other people to do things. And so delegating and then helping them through that because you don’t just want to drop a bunch of stuff on their plate and it actually, you know, that helps you scale and then you can rely on that person to kind of pick that up the next time. Do that kind of tip.
Alex: When you delegate like that, how do you make sure that you don’t increase your time commitment by having to answer all the questions necessarily and that kind of thing?
Stacey: Well, I think you have to be prepared to increase your time commitment initially with your sight set on the long term goals of eventually decreasing because yeah, there is likely going to be an increase. And even if then like you, you know, you get pick up a new mentor and that’s more time, you pick up a new merchant. It’s just part of the job. I think it helps the company out in the long run because those people can then grow and then mentor people of their, their own.
Alex: Earlier you mentioned that you there was this sort of, I think you called it contributor council. Is that something that you, you participate in?
Stacey: Yeah. So it’s just a group of people that tech leads that are from the different organizations so we can kind of learn from each other and some of the principles like I feel like myself, I have a co tech lead as well and we’re very passionate about a lot of these topics because we’re the platform team and we’re very quality conscious and some of the more the other teams are very more feature focused and so it’s just a way that we can share information with a smaller group of people too because we have an email list that the entire contributors of Kibana but we can no longer, you know, back when we were young when we wanted to make a decision we’d have like a GitHub issue and it would be like vote thumbs up or thumbs down to like figure out what you wanted to do. You can’t do that when you’re like at 100 people or especially contributors it’s like 300 people. So have a smaller group that you can kind of iterate more quickly on decisions, learn what’s important for them. And also what I the goal was to, was to also kind of give them more ownership in it. So we aren’t dictating the quality terms. However, as it’s turned out, they have a lot on their plate as well. This was like an optional thing. It wasn’t like they have all their usual priorities that they’re doing. So we found that they’re for the most part happy to sit back and just listen and talk about their problems. But there’s not a ton of volunteering to drive any of these like projects that we’ve suggested. But I get that that’s fine.
Alex: Cool. I think a lot of folks are probably interested, I mean, are familiar with sort of like working with a manager and then I think as you sort of like go up in the career ladder, you become comfortable working with a team and sort of like aligning up and down. But things like the Contributor Council. Right. Those are sort of like a third kind of work, you know. And do you, do you have like a particular approach that you bring to these sort of like cross cutting groups to make sure that there’s the concerns that you have are sort of represented and dealt with?
Stacey: We have a process for the Contributor Council. We’re trying to make it very async friendly. So like we started out with a meeting and then we’re like forget it. And honestly we haven’t been that good at sticking with it because that’s the thing with the meeting. It’s the forcing function. You have something on your calendar that you’re going to go to, you take that off. You have to rely on someone to remember to send out an email to say, hey, what are the topics? So we do have a process written up for it. It’s a work in progress and we have picked out a few projects. The Developer Documentation 1 is one of them and it was great to see like, hey, like other people on solution teams are very interested in that. So that can also help raise the, the visibility of certain projects.
Alex: That’s cool. And was that something that was important to you and your team as well? The projects, the developer documentation, I guess.
Stacey: Oh yes. Yeah. Actually the team that was the least interested in it was like the core platform team because they don’t use a lot of platform services. And then we had this meeting where someone was like, I’d rather have no documentation than documentation written in this way that we might need to rewrite. And so then we had other people from the solution teams or from the analytics side that were like, whoa, whoa, whoa, you know, we really want this documentation. So nice.
Alex: So is it, do you feel like you, was that like a plant, the seed kind of opportunity or Is that sort of like a sweet, we all got lucky. We all want the same thing kind of a circumstance.
Stacey: There was a lot of planting of seeds with the documentation stuff and. And we also got lucky. I mean, there’s always plant seeds.
Alex: Awesome. I’m curious, you know, your experience with it sounds like inside of Elastic you had a lot of opportunities where people sort of reached out and said, hey, we’d really like you to do this work. And that seems to have worked out really well for you. Do you find yourself doing that at all with other people in your organization?
Stacey: You’re referring to how I like got the tech lead role. Yeah, we don’t do that anymore. Now that we’ve grown, it’s not really that fair. And I get that, you know, we now we’ll post like a job and we’ll have people interview for it and give opportunities to everybody. Otherwise you’re just relying on someone saying like, oh, that person, you know, might make a good fit for this role. And we want to give everyone the same opportunity. So. And I weigh in on like, oh, this person I think would. Is like doing very well, but I don’t make those decisions. That’s up to the team, the teammates.
David: So what does the process of that look like then? If you’re sort of. If there’s a new opportunity that comes up, like how is it sort of broadcast and how do you evaluate sort of the applicants, so to speak?
Stacey: So we have these weekly emails that go out from each team and at the top of them are all of our career opportunities. And it says, interested in any of these yourself? You know, apply. And so that’s the visibility. And then they will just go through the normal review process and interview process.
David: And what about like opportunities that maybe like, we’re not talking about sort of a change in official role or a change in level, but like opportunity to, to drive a new project or something like that. Is there a process for sort of. For sort of distributing those opportunities?
Stacey: Not an official process. There’s definitely like, there’s this one project runtime fields and there were a lot of like work streams that spun off of it. And I would suggest as like, this person would be great to run this. There’s also another person on a team that has been here for like a year maybe, and I think they’re doing excellent and I’ve noticed that they’re continually getting like the help this person out with this and help this person out with this. And it’s great for them because they have like such a broad knowledge of that area of code now. But I’m like, listen, I think this person’s ready to lead a project and I think they’d be great at it. And I don’t want them to get bored or feel like they’re constantly helping. So I talk to the team lead is what I do because. And the area lead, I don’t want to dictate anything. So give my suggestion.
David: This is shifting gears a little bit. We touched a couple times on sort of like the fact that you’re not a manager and that you obviously interact with management. But I guess I’m curious like how do you think of sort of your relationship with your peer managers? Like I think when we were talking before about sort of selling ideas to the org, my mental model for that is that there’s like a director or a VP somewhere that is like reviewing sort of the stuff that you’re proposing and deciding whether or not it makes business sense. That’s probably a little bit simplistic, but for the sake of argument. But then there’s also probably like a manager or a set of managers who are like basically sort of beside you in the organization. Right. Like you might be leading, you might be tech leading a team and there might be a manager that’s directly attached to that team. What does your relationship with them look like?
Stacey: So we have this concept at Elastic that we call the three legged stool or the triumvirate. And it’s that at a certain level in the hierarchy you have your team, your tech and your PM and they work together and they theoretically have equal weight. And you, there’s a lot of overlap. Certain folks will end up having much more overlap and other folks will have less. But you just lean on your strengths. And so I, we have a like slack channel with. We’re actually a four legged stool. We’re very special channel cause we have two tech leads but we, we iterate a lot and so like the OKRs, we’re working, we’re all working together. We all like do the all hands together and it’s nice because you can lean on people’s expertises. It also on the downside, you have a potential for duplicate doing the same thing twice. Waste like we’re all in the same meeting or something that’s like, yeah, we don’t have to all be in the same meeting. Or it’s like should I be like am I stepping on my toes if I do this process thing? That might be more team leading. And it’s also I think at risk of the bystander effect being like, oh, this needs to get done. It’s like, well, there’s three people that could do it, but who’s going to do it? Who make final decision if we’re all equal, you know, so like in the perfect, ideal, happy world, we all agree and everything. But I think what can happen is that decisions can fall through the cracks because there’s just so much going on and there’s not one singular person that’s held accountable.
David: It’s really interesting. I think a lot of the teams that I’ve worked in certainly in the past several years have not been like external customer facing and there usually isn’t a product manager sort of part of the stool I’ve been working in, I guess in two legged stools for a while. How does the interaction specifically between sort of your role and the product manager look?
Stacey: They help us shape the roadmap. They give us a lot of insight into how our customers use the product. They help create like the user stories and like they’ll work with the design team to create, create mocks. So we have like a planning feature development process where it’s like stage one is like, why, why do you want this? What are the goals? And that is heavy PM input. And then it’ll go to the next stage. I think it’s, it’s like research and vision. I can never remember which one’s which. But then the next stage, the tech gets more involved and help like the tech lead will get more involved and they’ll help shape the vision, like and phase it down. Like maybe they’ll say this is completely like architecturally this will be impossible. Or maybe they’ll say, hey, if just tweak this, we could like work a lot quicker and a lot more stable. And then, gosh, what’s next planning. Then you have to figure out like, when are you going to release it? Who’s doing what? We’ll do an RFC at that point. So start digging into the details. Because most of the before that it’s more hypothetical. You’re not into the details. Rfc. You get into the details, you have an architectural review, then you’re in the delivery phase where you’re actually like, this is like the project management phase where it’s like, did you do that yet? You know, and then you have like your check mark and you know, any at risk in real life, it’s not as simple as like I moved from stage one to two to three to four. There’s like a loop there. It’s like, oh, we hit four now. I gotta go back to two because we forgot about this thing. But having that defined really helps, right?
David: You mentioned like sort of once you jump into execution. I actually have a lot of questions about that. I think the transition from planning to execution is sort of like one of the. Well, I mean there’s lots of interesting things in the processes that of our work but. But that’s one of them I guess. Two questions that I have. So first of all, like in my experience I found that it’s really easy to sort of like fall into a failure mode where like there’s a planning cycle and there’s like a bunch of people that are involved in the planning cycle and they put together some plans and like throw it over the fence to a bunch of other people to go and implement it. And I mean my experience has been that that doesn’t work super well. So when you think about sort of like designing projects from a high level, how do you think about the granularity of like the. To what extent is it, do you want to design to be fully spec before you sort of like engage some of the people that are actually going to be implementing it or like the engineers sort of like the more hands on programmers.
Stacey: Great question. We often involve the people that are going to write the code in the plans. Like that’s actually. They’ll drive it, they’ll drive the rfc, the person who’s going to write the code. So prior to that it’s not fleshed out that much. It’s more like the vision, like what’s the end goal? And like paragraph summaries. But we’re not getting into the actual architectural details. And once you get into the plans, the engineer will create the rfc. And as far as details in the rfc, we try and focus on the public API, depending on how complex it is. If you’re changing a bunch of internals in a plugin and you want your team to review that, you could come up with the architectural diagram. If you’re changing public APIs that might affect downstream teams that are consuming those APIs, you’ll want to do this and get their input there. So we try and keep it high level. Like it’s not a PR review. That’s the last, that’s the delivery phase.
David: Makes sense. And then you also mentioned like, sort of like on the execution side there’s like this progress tracking that has to happen.
Stacey: Who.
David: Presumably someone in the, in the three legged stool, who’s responsible for that, which leg is it? And also like tactically, how do you measure progress in A project.
Stacey: Good question. The team lead is technically responsible for delivery, but really, you know, again, it’s kind of. We all help out as far as how we go about tracking progress. We’re again working on that. We’re recently someone kicked off a JIRA experiment to see if we could do jira. We all kind of have our own way of doing this, which is one of the difficult things. Like, I have a project meta issue where I’m like, I have a table and I have tagged everybody and I’m, I’ll like update the, the issue every week and be like, did you do this? Yeah, like when I had to run a project, that’s what I did. But everyone does it differently and things can fall through the cracks where you just relies on like, we do sync meetings a lot, which I’m not a huge fan of because I like leaning more on it. Like our calendars are getting full and full and full. And it’s like when you have a repeating weekly meeting where it’s just like status updates. It’s like, wow, this could have been Async. And that’s why I lean on the GitHub issue. But it really depends on the, the project owner and the team lead. And it varies wildly. But we are trying to create some consistency, maybe with jira.
David: Every company eventually ends up with jira. And it’s not because JIRA is great, it’s because JIRA is there. But I don’t want to get sued by Atlassian.
Alex: So you mentioned how sort of the planning and RFC phase is different than the sort of PR review. And I was curious what makes sort of like your work on an rfc? Maybe you’re commenting on rfc, what makes it different from the work that you do in sort of PR review?
Stacey: So the goal is, if you’re heading in a terrible direction, to stop before you have written an entire pr. And we’ve had that happen, you know, where if you just took the time upfront to think through the problem, to design the goal, to get input from other people, you can spot a lot of problems ahead of time. And using a template also forces the developers to, if they’re reading it, they’ll see some like, the pitfalls we have. Like, oh, did you pay attention to this? You know, don’t, don’t do this, don’t do that. So that helps a lot. And a tech lead will review it versus PR reviews, tech leads. Actually, I rarely review PRs anymore. Like, we’ve got the area leads that will do that. So for me that’s A way to scale.
David: Interesting. I remember a question I had. Now it’s similar but you mentioned sort of the, your preference for async work. And I’m curious, I’m actually specifically curious how much of your week is spent in meetings and out of those meetings how many of them are recurring meetings versus like sort of one offs for a specific topic.
Stacey: I actually in my like I keep snippets of what I do every week and I started tracking like how many hours I was in meetings. So it varies. 10 to 20, sometimes more. Maybe I should say 10, 10 to 20 hours. Yeah. In meetings most are recurring. Do a lot of one on ones which I actually find pretty valuable. I’ve been trying to make them to spread them out a little bit more so that my calendar gets a little bit more free and I try and front load all my meetings to like Monday and Tuesday. And so Wednesday, Thursday, Friday will hopefully be like my focus days. My company does this amazing thing for Covid. We have shut it down days because we’re all in different countries. If like holidays and stuff and days off, some people are still working. So it’s very rare that like everyone in the company at the same time stops working. And so we have these shut it down days where it’s like just don’t do anything, shut it down. And it’s not taken out of our just it’s two Fridays every month and it’s incredible, which is awesome. But it’s also like gosh, that was my day to actually go.
David: Yeah, that’s one of the challenges, challenging things about anytime you take time off. It’s like the number of things you need to get done doesn’t change. But it is nice at least if everyone else is taking the same time off, you’re not going to come back to like a full inbox. That’s pretty cool on that same. So kind of following up on that. Then you mentioned you do one on ones a lot. I also am a like I’m a big believer in having one on ones with having lots of one on ones. Is there any specific sort of like format or template you use to decide like what to talk about in your one on ones and also who are you meeting with in your one on ones, what’s the frequency, that kind of thing.
Stacey: So I don’t have a specific format. I probably could do better by thinking ahead of time more of what I want to ask. Often I have nothing lined up but my main goal is just to get more comfortable with like knowing these people and creating that communication path. So when something does come up, it’s like, oh, I know that person. I totally like able to go chat with them. And as far as who, it’s mostly people on my level or above that are, that are also in other organizations like tech leads, on other teams, some team leads, some product leads. It’s actually I didn’t used to do as many one on ones and one of the feedback I got when I tried to go up to Principal 2 a few times and I didn’t get it and the feedback from one cycle from one person was like do more one on ones. Because I don’t think I was seen as much. And people are like, who’s. What is she doing? You know, just like. And I think maybe it was like, like a nervous thing. It’s like oh gosh. And time. It’s like, ah. But I actually, you know, he said that and I was like, all right, I’m gonna do it. I’m gonna have set up a one on one with every person in this company. And on my calendar was like very full but it was actually really useful. And now like I’m in that habit and like just the other day I was like looking at our org chart and seeing like there’s a tech lead on cloud and I don. Know this person. They’ve been here for six years, I’ve never seen them. So it’s like I’m setting up a one on one. Like hey. And it’s very, you know, it’s just to get to know people, create that connection.
David: And what’s the frequency of the one on ones?
Stacey: It depends on the person and whether like we’re involved in the same project or not. Like I had a one on one with someone I was mentoring to lead a project and it was weekly. So if there’s an ongoing project, it’ll be weekly. If you. It goes as far as like I think I’ve set some up to be like every six months if they’re like really far out there. Just because I want to like have a reminder. But you don’t want to take up too much of your calendar.
Alex: Yeah, I just. For what it’s worth, I feel like one on ones are like the secret power. It’s like when you run into a situation, you get it. You can get an honest gut check from folks and relying on that one on one and it’s just immensely valuable for sure.
Stacey: I think it helps in like bigger groups too. Like once you have you feel comfortable with person with a person like on an individual level. Level because you chatted like in private, then you feel more comfortable speaking up in a bigger group because it’s like, oh, that person knows me. They have my back, they know who I am.
Alex: Yeah, totally curious. Are there any resources you recommend that you have read along your career journey? You know, blog posts, books, or people that you would follow? Just any resources that you might recommend to someone who’s either at your level or trying to get to your level.
Stacey: I knew you were going to ask me this question and I don’t have that great an answer. I have some answers I’ll follow. Like Tanya Riley, I think she’s amazing and I’m in a bunch of slack groups which I don’t have. I don’t spend as much time on there as I would like and honestly I rely on my co workers a lot to share good information. I should read blogs more, but I just, just I have a lot of non work things like hobbies I like to do and so I’m just not the kind of person that’s like, oh, I’m done for the day, now I’m going to go read 20 like engineering.
Alex: For what? That’s totally. What I love about these interviews is that you learn that everyone has a different approach. And I think that it’s great to sort of share with folks who are looking in this, you know, just all the different ways that people approach this kind of stuff. So I think that’s great.
Stacey: Great.
David: Except for this podcast. Beyond, like if you listen to this podcast, you should be doing that in your spare time for sure. Beyond that, none of the resources matter. Other hobbies are great, but listen to the podcast. Last question. We ask everybody this. So if you knew you were going to get the other question, then you know you’re going to get this one. How much time do you still spend coding these days?
Stacey: So little. It’s so sad. The established code week, which I think we’re going to try and do once every quarter where like mine’s next week. I think I’d like to decline as many meetings as I possibly can and I’m just going to go like fix a bug or add like comments so my API documentation looks better. Or maybe try and write a plugin for some like total side project in Kibana. Plugin? Yeah. Tech leads just don’t really get their hands dirty writing code anymore. It’s sad.
David: Yep, yep, fair enough. I understand. I’m not surprised, but I agree that it is a bit sad. Thank you so much for taking the time today, Stacy. It was really really nice to meet you.
Stacey: You too. Thanks so much.
David: That’s it. Thanks so much for listening to Staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding finding value of this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website, podcast.staffenge.com the website also has our contact info. Please don’t be shy.