Mahdi Yusuf (1Password)
Today’s guest is Mahdi Yusuf, Tech Lead for the Server Architecture Team at 1Password. Our conversation is about what it means as well as what it takes to navigate the needs of the org, client, and staff in order to find the best path forward. We kick things off by hearing more about what Mahdi’s job at 1Password involves and he talks about the chief concerns and responsibilities of working on the platform code that the rest of the app is built on. Mahdi’s role specifically requires him to do a lot more than write code though, including designing projects, communicating between nodes in the org, and mentoring staff. This is a balancing act indeed and our conversation moves to focus on what it looks like to handle these tasks with equal measure. One of the biggest skills the position of Tech Lead requires for Mahdi is empathy, and he talks about how a big part of what he does involves listening to concerns and working out when it is best to make a pivot and focus on something different for the overall good. In an environment with so many different stakeholders, knowing what this is can be a huge challenge! We wrap up our conversation with Mahdi on the subject of excelling in your career, talking about what it takes to do truly good work, thinking bigger than the specific problem one is working on, and the necessity of having difficult conversations. So to hear Mahdi’s insights on creating rock-solid products while maintaining a healthy and effective team, 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 Romos and I’m joined 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: Absolutely. Madi Yousef is a senior staff engineer at 1Password. He’s worked at a number of roles in tech, including cto. Our conversation covers a lot of ground, so let’s get into it.
David: All right, Mahdi, it is a pleasure to meet you. Thank you so much for taking the time to do this with us today. Could we start by having you tell us who you are and what you do?
Alex: Sure.
Mahdi: My name is Marty Yousef. I am the Tech lead at 1Password for the server architecture team. I think maybe what translates best to other teams is the platform team. So there’s the backend platform that powers One Password. You know, I’ve joined on and kind of managed API and the backend and the database and that’s what I do. For the most part, me and my team do that.
Alex: Nice. @1 password. Are there tech leads and is there like a common set of expectations for tech leads or folks who are operating at level?
Mahdi: The tech leads aren’t based on title. They kind of go all the way down to senior and all the way up. So it just depends on your domain experience and people who we think could do the job. So there isn’t any like title that associated with a tech lead role. More about the domain and area that you’re working on.
Alex: Oh, interesting. And so I want to dig into that a little bit. Like what’s the difference between being a tech lead and a role? Like even like, would you mind explaining some of the role titles?
Mahdi: So there’s an engineering manager associated with each of these teams, 1Password. And then there’s a tech lead who’s responsible for the technical work day to day. And you know, that’s breaking up tickets, planning the sprints with the rest of the team and making sure things are on track. But there’s a lot of cross functional stuff. So if somebody on another team has a bit more experience about this particular thing, you can kind of work together to get the job done, which I like. I think it’s A good thing. It also enforces, you know, communication and helping each other along. I think sometimes people get siloed into places where they don’t want to actually be and they’d like to branch out a bit more, which that gives a bit more space for and allows the team to have a bit more flexibility in what they work on day to day.
Alex: Cool. Just to make sure that I’ve got this right, so there’s teams have an engineering manager and they have a tech lead and then you also work with a group of ICs to get the work done.
Mahdi: Correct, so. Yes, exactly. So each team is a bunch of individual computers, so you’d have a team. So the software architecture team, it’s my team and a few others. I’m the tech lead on that team and we work together for our particular task, basically making sure the API is stable, making sure the site’s reliable and staying up and we work as a unit. And then if there’s other teams that would need us to kind of deal with stuff like the queue, for example, is one of the things recently we’re dealing with. That would be something that we would get pulled in on and work with the team that’s dealing with the issue to resolve it and get it all the way through.
Alex: Nice. Thank you for explaining that. That makes a lot of sense. 1Password is interesting, I think from the outside looking in is that it was a native first company that has now built services out behind it. I’m curious, do you find yourself approaching the tech lead role differently than your native folks? Are there things that you do the same? How has that cross pollination happened?
Mahdi: Yeah, so maybe a little bit of history about 1Password maybe makes more sense to explain how that kind of grew out of there. So they were a local Mac at first, so I imagine there was a lot of Mac developers. The founders were pretty into it and pretty passionate about that. And I think the company kind of organically grew out of that into what it is today. And so I think they grew into that necessity. And you know, a lot of companies struggle going from one to the other. So either really good at back end or really good at the Mac and design and stuff like that. So finding a company with both, it really speaks to the team that was there early on and what they got done and that really informs generally how they work. There’s a bit of a split, so we kind of have to integrate at a high level in terms of how the client apps work and the backend work. So we have a book that we share across and then we synchronize there, and then they build against APIs, we write for them, and that’s how generally the teams work. There’s a whole ladder of ICs on that side that work towards getting things done, and then we meet in the middle.
Alex: Nice. How do you find yourself approaching your role from a strategy perspective? Like, how do you help the team sort of choose what to do next?
Mahdi: You know, that involves a bunch of things, right? So my team specifically isn’t tied to any particular feature or product, so it’s basically mostly monitoring the system and how it’s doing and our general initiatives internally, which also help the other teams build quicker and faster as a whole. So a lot of the stuff that we’re working on is paying down tech debt, ensuring that we have headroom to scale, and getting the metrics out so we can work with the ops teams to make sure everything is going in the right direction. And then we also have our own initiatives about making things incrementally better for the system. And things that we see that we don’t like incrementally iterate on them and go about that way. A lot of our work is informed by what we see in our metrics and our logging and error rates that we do get. A lot of the work is going down to putting that down. And then obviously, you know, as any large system has a little bit of tech that they have to kind of work around, so we put some effort around that and make sure that we pay it down as quickly as possible. So it doesn’t. It isn’t a limiting factor going forward. I’m still, you know, formulating my thoughts on that at a high level, how that works, but generally that’s my, you know, my strategy at the moment. But we’ll see how that evolves as things grow and scale.
David: With one password, how does planning and prioritization work in that context? And especially, like, how do you sort of decide between paying down tech debt versus building out new features?
Mahdi: It’s a really good question, right? Like, it’s a really, a balancing act. And you have to constantly, like, thinking through, like, okay, well, this thing, and you have to think ahead, like, three, four months, right? Going, okay, we have one thing here now, you know, what does that enable if I do do it or if I don’t do it, what happens?
Alex: Right?
Mahdi: A lot of it’s mostly a balancing act. And, you know, things could come at you from the side that you weren’t aware of, right? Something could go down or something could break and you have to kind of reshift on the fly as you’re going. It’s definitely something that you kind of work towards. You want to be a position of power where you can make these decisions from a place where you’re like, okay, nothing’s really pressing me right now. What would I like to do? And that’s your plan A and that’s how you want to be operating. But you know how it is when there’s big systems and things go wrong. Then you have your plan B of like kind of focusing on what you need to get done and get that there. We haven’t had too many of that, but generally that’s how I go between like, you know, short term goals here. What can we get done and what does that enable? Does that enable another team to kind of get their job done and what does that look like? And if it’s something that’s in the near term, then it’s like, okay, well, let’s see what we can kind of get done in the next couple months so that we can do the work that’s going to require us to do the heavy lifting. So incrementally getting there, I think is really key. Breaking them up into smaller chunks is something I think really helps in that regard. Because if you try to take on a big task and try to block out six months, you’re never going to get it done. But if you incrementally move in the direction that you want to be, then that kind of, you know, regardless, you’re always going to be making progress towards your goal.
David: Yeah, that makes sense. You mentioned sort of if there’s things that you can do to basically unblock partner teams, how do you keep context on sort of what those teams are trying to accomplish so that you can identify like the stuff that you can do that would unblock them?
Mahdi: Yeah. So, you know, we have meetings with other tech leads just trying to get a sense of what’s going on. And you know, we’re all aware as an org, you know, what the high initiatives and goals are for the quarter or for the year. So we tend to keep an eye on what’s going on. And you know, we communicate and try to get to what the core problem is and what needs to get solved in order to enable all this stuff. But I think communication is a big one and I think, you know, a lot of the tech leads exhibit that one password where they communicate with their, with the other team members and try to get ahead of these things when they’re planning Their, their work and that, you know, brings up discussions and meetings and so on and so forth. So a lot of it happens at design time too, where you know, okay, this is something we’re going to need from X amount of team or ask for input early on in the design phase so we can, you know, smooth the path to getting to where we’re going to go. So it’s just mostly about figuring out the decisions and then just implementing and that as smooth as that path can.
David: Be, the better that makes sense. If you think about sort of how you spend your time, if you’re anything like me, it varies quite a bit day to day. So let’s maybe think like on a longer time horizon, maybe a month or a quarter. What percentage of time do you spend sort of working on individual projects? And that might not be coding, it might be designing or whatever, but like specifically working on a project versus like the sort of communication aspect that you just described, where you’re kind of keeping tabs on what other teams are doing, for lack of a better word. And then also I think like the third big bucket that I think of and please let me know if you think I’m missing anything is sort of like the team oriented work, like the training, recruiting, mentoring, stuff like that.
Mahdi: Yeah, so there’s a lot there. So I’ll go from the last one. So the, so mentoring people on my team, you know, they all have goals, they all have strengths and you kind of want to, you know, help them along and where they’re going. And a ton of people did that for me when I was coming up and I, you know, super appreciative of that and giving them opportunities to shine on areas they, you know, want to show that they have experience or learn more. I think is really important. I think that should be in the forefront of your mind at all times in terms of being a lead or a leader in any organization really, because, you know, you’re directing them. So if you, you have a lot of power there and that shouldn’t be taken on lightly and it should be something that you think through and give time for that. So I have, you know, weekly meetings outside of like what we’re doing to talk just about what’s going on. And that’s outside of the one on ones that the manager does all that. I’m just trying to get a feel for what they want as a leader technically, just so they can get opportunities to work on, they want to work on. The next thing you mentioned is design and that’s about phases, right there’s new projects, new initiatives that come up, problems that arise that require design. You know, a lot of it starts in discussions and then as it becomes more real, it becomes more formalized and you start writing things and analysis as to what’s going on. You know, depending on the time of year it is, it’s, you know, 20 to 30% of my time. And then, you know, a chunk of it’s kind of dealing with stuff that happens and fielding questions and like, how should we go about this? So at least there’s some direction that we’re all like cohesively understanding that we’re going towards. And, you know, I just joined and there’s a lot of that trying to feel it out. You know, I’ve been there for about 10 months now and just trying to feel out, you know, people’s personalities and trying to show that you’re part of the team and want to help is a big part of it. So I think, you know, showing that humility to kind of work with them and get the things done as a team I think is really important. Can’t remember the last one. My stacks probably got too deep. What was the last part that you asked about?
David: No problem. So we asked about sort of focus on individual projects, which was the design bit. We asked about mentorship, which you covered. And then lastly, sort of how much time is spent in that sort of communication zone that’s constant?
Mahdi: Like, that’s all the time. I think that’s like, honestly a lot.
David: Of in between everything else.
Mahdi: Yeah, context switching for that sort of thing. I think it’s pretty common for the glue bits. You know, people are trying to synchronize people across other things. Or if you notice something, you’re pinging somebody saying, hey, what’s going on here? Can you explain? So it’s a lot of asking questions. Right. And I tend to do that a lot when I’m trying to figure out stuff because, you know, I’m not working in these areas that I poke in on all the time. And it’s important to kind of leave it to the team that’s doing it. Right. They have more context than you. But yeah, I’d say that’s a good chunk of my time being spent just kind of communicating. You know, obviously there’s my team focused, sprint planning and all that stuff, of course, but, you know, that’s a bit more tight knit because we know what we’re working on and my context there is quite high. But for things cross team, it’s a lot of communication and Talking about what we’re working on and, you know, asking for a design document when that one doesn’t exist and kind of go on, what’s the intention here behind this? So, yeah, it’s hard to say really. I haven’t actually thought about percentages, but I’d say, you know, that one’s a good one, a good sized one. And then I’d say 30, 30, 30. You know, if we’re going to go there, leave the last 10 to miscellaneous.
Alex: Yeah. So it sounds like you do a lot of different kinds of things and that’s like a common thing that we see from lots of folks. I’m curious, when you sort of zoom out and you try to understand you’re doing all these different things, how do you know that overall quarter in, quarter out, the work that you’re doing is aligned with what your organization wants to do?
Mahdi: Yeah. So it’s a question I ask myself every quarter as we plan things going forward. The company has OKRs that we have and we want to line in with them, but we also have our own initiatives that we direct and that line up with those OKRs and things that we think are important. So it’s something that managers and I work together to kind of figure out what that is. And it’s honestly comes down to a decision of what we need to get done. And what does it enable. It’s kind of the same framework just to kind of work through. Okay, we want to do this thing. Okay, well what does that help? Right. And then you have to really like break that down, justify the reasons why you want to do it. That requires some introspection. Right. You can kind of go, technically that’s not great. Right. Very easily. And you can make an argument for that coherently, but you have to take a step back. Okay, well what does that really enable? Like if we spend a bunch of time reshifting it and it does the same thing it was doing before, what did we really gain here? We spent a bunch of time. So that decision making process requires you to take a step back and kind of go, what’s the gain for that particular effort? And that’s something you have to take. You have to do it at certain times. You can’t be doing that every day, otherwise you’ll be too close to the problem and you won’t get context at a larger picture. So, yeah, you need to be thoughtful about it, but not too thoughtful. You don’t want to be thinking about it all the time and spinning your wheels in that regard.
Alex: Yeah, I’m curious. I think you just described sort of like a problem that we all face at one time or another, which is when you work maybe on something that’s technical, that’s not immediately visible, it’s maybe like a layer or two deep. You mentioned that you’ve got to think about what it enables. So if you work on a for instance, if you work on a platform team, how do you think about the work that you do and how that it drives sort of your customers experience and how do you make that case to the organization?
Mahdi: So it’s tough because the nature of my team is mostly how it’s getting done and not what’s getting done. Less features, more about how can we accomplish this feature needs, this technical thing accomplished. How do we go about doing that is the focus of my team. So it’s less tied to individual experience, but more about reliability and consistency. The fact that like one password, if it goes down, you won’t have access to your newly created passwords, the syncing will go down. So those things are the things that are top of mind for things that we’re doing and the changes that we make day to day. It’s something that we want to think about as we’re making any given change. Because it’s not just a web app that’s talking to it that we can deploy every day. There’s client apps that have certain versions that behave certain ways. So I have to think long term. They make a change based on a server thing that we have. Well, the client apps going to exist and the customer may not update to the newest one. So that means whatever we built on the service that has to stay there until that one becomes deprecated or out of support. So those are the kinds of things that I’m thinking about. Right. And it’s a, I don’t know, maybe it’s a level, maybe a level down from where features land because those things you can iterate on and change as you see fit. So yeah, I get the question. And it becomes a bit more specific when you’re on a platform team because it’s more about the health of everything else because there’s things that are built on top of the thing that I’m working on, which means that you need to be rock solid most of the time. There’s a ton of people put a ton of effort to get it there and you want to see it through.
Alex: Yeah. I’m curious as I was talking to you either at 1Password or somewhere else, you know, have you ever been in a situation where you see a technical investment that you’d like to make, you feel that it would benefit everyone, but like the client value or the customer value may not be immediately apparent, you know. And if you have been in that situation, like, you know, do you have any specific techniques you use to sort of communicate the value to the organization?
Mahdi: Yeah. So prior I was the CTO at Gyroscope and you know, we had problems like that where we had a mobile app and an Android app that we had to support. But similar problem people were on old versions, conversions, whatnot. And you know, you always schedule time for the things that your goals, right? Which are features, you know, acquire customers, you know, lower churn. So these things take up your development time. But then there’s other things that, like, you know, tech debt or upkeep. And the way I kind of worked at it when I was over there is if there’s something bothering you, I’ll give you the time and then you can fill in the gaps. Right. And if it isn’t bothering you enough, then let’s just keep going. Right. But that’s a balancing act, right? You really got to get a sense of what’s going on. Because if everyone’s unhappy about something, right. You have to also think about your team’s mental health. You want them to be happy when they’re working because if they’re happy and they feel productive, they’re not stressed out because of all the monotonous things they need to accomplish. I think that’s good team management stuff where you can find the balance between going full tilt features, product stuff all day versus, okay, well, this is really painful for our engineers to get something accomplished. What can we do here? Or they’re uncertain about something. If they make a change, where they’re going to cause a regression, right. That means you need to pull the handbrake a little bit and go, okay, let’s take a cycle or two, writing some tests or planning out what we want to do to fix this specific problem. Right. It really becomes a thing about, you know, how much empathy you have for your, the engineers that are actually in the code every day manipulating it. Right. You have to keep involved and listen when there are complaints because if you don’t, then you’re just going to burn out your team over nothing.
Alex: Right.
Mahdi: Then there’s a balance. Right. You can’t. It’s never one way fully one way or the other. Right. But you can always kind of strike a balance that helps people get to a happy medium.
David: We’ve touched a couple Times on sort of like the balancing of different priorities. And I’m curious, from a tactical perspective, like, what do you actually use to keep track of sort of all the things that your team needs to get done and sort of how you’re progressing against it.
Mahdi: So prior Gyroscope, I was doing a bunch of GitHub issues, and now we use GitLab and that’s how we keep track of stuff. We have sprints that we do. That was a bit of a learning experience for me because we’re a smaller startup prior, and I was used to kind of working it that way, where everyone has high context on everything and a lot goes on set, right? Everyone just kind of knows what they need to get done and there wasn’t much time spent communicating. Now when you multiply the team by a couple hundred, then it gets problem. More of it becomes communication than working, right? Well, not more, but like, the ratio is way different. So there’s a lot more time spent sprint planning and getting things in order, getting everyone on the same page, getting everyone to buy in, you know, and having input. And I learned quickly that you need, you know, tight cycles here, right? You want to keep them tight and you want to learn from those cycles as much as you can do the cycle, you know, use your judgment. What do we think is a good goal? Okay, let’s go do that. Then you come back afterwards, what did we do wrong? And then you iterate on that as best you can until you get to a place where you. Everyone’s happy and on the same page and they know what’s coming up. Hey, I noticed this in last sprint. Okay, we’ll put it in the log for the next one. We’ll discuss it in the sprint there. And that keeps everyone on the same page as to what’s coming in, and it keeps them focused on what they’re working on now. So, like, okay, you noticed something, file an issue. We’ll deal with the next sprint or the sprint after that, and then we come and hash it out during the sprint, what do we want to do? And then people will advocate for this particular thing. Oh, this is a huge one. We can’t. Can’t progress without it. Or another person be like, no, that’s not important. For these reasons, this thing is more important. Then you kind of have to make a judgment call. You know, it’s tough being in that spot because it’s honestly kind of assessing what’s going on. And sometimes you don’t have intimate knowledge. You have to sit there and listen to what everyone thinks and what their explanation for the reason are. And then. And then you take a step back and go, okay, well what does this enable? And then you go into that framework going, okay, cool, that’s what’s happening there. Great. And then you step back in. Okay, we’re going to go with this one, I think. What do you guys think? Does everyone feel happy about it? You know, sometimes not everyone’s happy, but, you know, you got to make a decision and move forward. But that’s generally how I kind of keep track of it. Then obviously I have a side to do list of things that I just get inundated with that’s on my plate that I just kind of keep track of slowly. And then they’ll rise and shift depending on what’s happening. I haven’t found a solution for that just yet. I don’t think there is one. I think it’s just kind of dealing with it as you go and filtering those in as they become priorities into your Sprints.
David: Yeah, if you’ve got one to do list, you’re doing great. I’ve got, I think a Google Doc somewhere and physical notepad somewhere and a sticky note on my desktop.
Mahdi: I try to keep the places where I need to look to a minimum, but I’m always constantly changing what I do there. I’m not exactly sure if there’s any concrete way of going about it, but I think honestly it’s about assessing the priorities at any given moment and trying to make the best call possible.
David: Yeah, there were two things that you mentioned there that I kind of want to circle back to. One of them was the tasks that the group feels makes sense to take on could change like, you know, based on the information that you get. And I’m curious what four of those decisions are made in if it’s like something that just comes up at Sprint planning or if there’s another way that you can sort of that folks in the team can flag that sort of concern about a plan. And then the other thing that I wanted to circle back and so I’ll make these two points and then we can address them one at a time. And I can remind you if I get too far ahead of myself here, but the other thing you mentioned sort of the change in atmosphere where in a small startup everyone has high context and sort of you can run quickly, whereas in a bigger org there’s more need to sort of make sure that the context is explicitly shared with folks before they start working on a thing or while they’re working on A thing as sort of the situation changes and I’m curious what tactics you use for that.
Mahdi: So I’ll address the latter one because that’s the one I remember. So at a startup, you know, when I was last at the code base was actually quite big, right. It wasn’t a small one, but you know, I was there from early on so my context is very high. You could probably talk about any given thing and I would know what was going on. Right. So, and there’s a couple people early on they were in the same position that would know what was going on. So you can make a high level decision fairly quickly, right. Assessing like the need and what’s going on without having to look at anything. Right now in a team that is built on a product that’s pre existing, they all join the team, they may not have that context. So it requires you to take a step. There’s a step now where there’s an investigation phase that was different from the other startup. Now that’s just my role in that particular startup and that may be coloring my whole view on this. But if you’re intimately aware of a particular area of the code, you can kind of reason about it pretty well, right? What downsides to a particular decision? There are, and there’s people that I Lean on 1Password all the time for this sort of thing because it’s specific to one password. Now those things you have to get a decision point done. So you’re not stepping on any toes or going in opposition to what the plan was or what the previous design was. Right. There’s a time period for that. At a startup there’s a couple of people that kind of know that and they, there’s not that many stakeholders which, which makes the thing a bit more involved in terms of a discussion. Right. So at a startup you just kind of bring it up during the planning and then you, you kind of figure out that solution there and then you kind of move forward. At a company like this, it’s a bit bigger and we’re growing, so it’s probably only going to get, you know, gradually more difficult is that you need to have a phase where you design a phase where you, you know, reach out to everyone going, hey, we’re planning on doing this. What do you think? You leave some time for feedback and that’s the biggest thing that’s, you know, been a change for me, the pace, right. Where all those things happen before anything actually gets done. Right. And accounting for that.
Alex: Right.
Mahdi: In the process and stuff like that, which I think Are all great things when you have to kind of work at the scale and size that the company is. So that’s how I balance it. Can’t remember anything about your first question.
David: So the first one was you mentioned that there’s sort of like an iteration cycle or you know, a process where you’ll define a goal with the team and then you’ll work toward it and then you’ll sort of regroup and you may change the plan as you go along. And I’m curious if Sprint planning is like the forum in which those changes are decided upon or if there’s some other way that, you know, folks in the team sort of flag changes.
Mahdi: So like at the beginning, I remember there’s this cross org nature of things, right? So some decisions happen there, right? Where other people are making inputs like, you know, I prefer to be this way or you know, someone who has a bit more context around what we’re going to be doing says maybe that’s not the best way because we’re planning on doing this, that there’s a forum for that and you kind of follow up with them later. Then there’s some decisions that happen at a lower level as to what we’re doing and those are a bit more, the scope of them is a bit smaller. So they sometimes overlap, sometimes they don’t.
Alex: Right.
Mahdi: For a lot of these other decisions, the Sprint planning is the place for that where, you know, a lot of the decisions get made. We, you know, as we discover in that phase I described where you’re investigating, you may learn that it’s not possible or you may learn that it’s a lot more work. Then you have to take a step back and going, okay, cool, maybe we need to take a second here and chat with more people in order to understand what the real goal here is. Right. Or what, you know, do we want to take a step back and reassess how we want to do it. So there’s always, I try to always plan a little bit ahead of where this always doesn’t happen, right. This is the ideal. But the ideal is that you kind of want to look ahead going, okay, well these are the things we need to investigate. Let’s try to get them in now so we have some time to look into it and then readjust if the plan needs to change. Because if you go, hey, we’re going north, right? And then you see there’s a giant storm ahead north, they’re like, okay, let’s go south. Because you want to maintain like some momentum with your team. Right. So as long as you kind of stay a bit ahead in terms of like, okay, these decisions need to get locked away before we can move in this direction I think is important. And that’s kind of the balancing that I kind of do in that regard. But honestly a lot of it comes down to having some key discussions about what the plan is in the direction. Once that’s settled, then you go about how and that’s a little bit more lower scoped investigation. And then once the, you know, the point, research points come out of that, then you’re like, okay, cool, here’s the plan forward. And knowing X, Y and Z, here’s the plan forward. A lot of it’s ad hoc, you know, and as I’m talking through it with you guys, I’m thinking through like what does that actually, actually end up being? And I try to stay ahead because, you know, I don’t have all the context everywhere.
Alex: Right.
Mahdi: And you know, as the company gets bigger and bigger, I’ll have less and less. But you’re relying on experience a lot more at that time, right, Going okay, well I imagine this is how this thing works and then you go from there.
Alex: Something that strikes me about a lot of the things that you said is that it, it focuses a lot on your relationship with the people that you work with. You’ve talked about how you listen and you change the plan. I think you’ve earlier on you even mentioned you have to have a lot of empathy for the folks doing the work. And I’m curious, you know, is there something that led you to that understanding of empathy as being a way to help people?
Mahdi: Well, you know, that’s just a personal thing for me really to be honest. Like, you know, to be fair, I can also be hard headed and other things. So it’s not totally like there’s always a balance to these things. Right. But I think most of my career I was the one implementing things and kind of going through the slog of it, you know, rewriting your signup form for the 18th millionth time. Like there’s no glory in that, but it needs to get done and you know, you just plug away through it. But you don’t want to burn out your engineers because they also want to have challenging, interesting problems they want to work on. Right. So you don’t want to create atmosphere where you know, that isn’t thought about. Right. You need to be thinking about it always and trying to, you know, challenge them just a little bit outside of their scope or a little bit more interesting work. Right. Where it isn’t just like, do as I say, and that’s what we’re doing. You want to have a place where people can go, hey, I’m kind of bored with this. I kind of want to work on this sort of thing. Okay, cool. We’ll try to get you more of that type of work sent your way. And, you know, a lot of it’s also figuring out, you know, what they’re comfortable doing and where they want to go with their career. Because they’re individuals, they may not be in it for what I was in it for.
Alex: Right.
Mahdi: And for me, it’s about, you know, this stuff needs to get done. Let’s knock it out. And I was that type of person where you kind of get handed a problem or an area that’s kind of like, you know, not being organized. You kind of take it and try to put some hard edges so you have some, you know, bounds, and then you kind of work and iterate within there. Try to work in a way that you can incorporate others. Document what you can so that it’s clear when somebody new comes in. So I think empathy goes a long way in those things, documentation, right? Because if I write something, I know how it works, no problem. But if you don’t think about the person coming in behind you or you tell them to go read the code or something, to me, it’s like your job isn’t only that. It’s only a small subset of it. You should be there and available to field questions, have somebody challenge your assumptions and explain why you went that route. And maybe that route, we decided is no longer valid and we can go a new way. So to me, it requires a lot of humility and empathy and, you know, diminished ego a little bit, right? Where it’s like, it isn’t about you, it’s about what we’re working on and how we’re gonna get there together. Right? And I think, you know, I think a lot of those things are lost on most people because, you know, everyone’s out to make their name and stuff like that. But I think the people that I’ve remembered, you know, throughout my career are the people that were helpful to me and, you know, were kind and had impact, you know, broader than just what code they wrote. Right. There’s a time and place for that. Predominantly, my career was in startups where a lot of it’s just like, okay, get to it work, right? And then, you know, through various sizes, right? And it changes, right? The skills that you needed to. That got you There may not be the ones that get to the next goalpost. So it’s truly humbling because you’ll go through phases of that in your life and it really takes a second to kind of recalibrate, going, okay, I need to be different in this context, and I need to be a bit more open to feedback. And I’m a very generally inquisitive person especially, and I take time to take time to think back on why I did things and how I went about it and go, what can I do better? And, you know, asking that of your team is important too. Is there anything that we could do better here or we feel like we could do better? And I think that creates a mechanism where there’s an openness to discuss things and, you know, make things better.
Alex: Yeah. Do you ever think about the work that you do in terms of psychological safety?
Mahdi: Not in those words. Right. But like, if I see, like, for example, let’s say, you know, we’re getting a lot of regressions, right. There’s a reason that’s happening. Right. You talk to people, they’re smart enough. Okay, so then what is it? What’s the problem here? Is it, you know, it’s something that’s. That’s happening around them? Right. If people don’t want to have regressions, they don’t. Like, that’s not a goal. They wake up in the morning, I’m going to go create regression. That’s not the goal here. So then what’s the bounding box that’s causing that environment to thrive?
Alex: Right.
Mahdi: Are we going too fast? Do we not have enough tests, whatever it may be? Right. And I’ve gone through that. All companies are the same. Once you see enough of them, same problems crop up, same kind of issues. Technical aspects may change depending on what space you’re in and whatnot. But it’s all people stuff. And the more you think in that way, the more you realize, okay, well, this is happening. It’s not the individual, it’s something that’s happening around them and the environment that they’re. And that’s causing it. Sometimes it’s individual, sometimes, but most of the time it’s environment. Right. In that regard, yes, but not so psychological. But like, what’s causing this to happen? Right. What lever is being pushed for this to be the result? And if you can figure out the levers that you control, then you have some options as to how to get a different outcome.
Alex: Yeah, that’s a really interesting insight. I think it can be always hard for us to hold on to the core idea that, like, no one shows up to create a bug. Right. And to really do the hard work of looking at the environment around the individual and to be empathetic towards their experience. Right. Like, it’s a hard task to fill.
Mahdi: Yeah. And it’s not always quantifiable. Right. Honestly, like, most of the time it’s not quantifiable. So you can ask a question, what’s wrong? Well, it’s hard to kind of articulate. Right. So you have to be kind of inquisitive. Okay.
Alex: What.
Mahdi: When I’ve done stuff like that, right. What environment was I in? Was I working late? Was I shipping stuff quickly? And there wasn’t a lot of tests. Is the design lacking? Like, there’s a bunch of things to go through to kind of get you there. And I think that checklist. I’ve never thought about it that way, but those are the questions I kind of ask in my head going, okay, last thing, I think it’s this individual person that’s the problem. I get. That should be the. The very, very last thing. Right. It should be a bunch of other questions you asked prior before you get to that conclusion.
Alex: Yeah. Zooming out a little bit. Like, what’s interesting, you know, there’s always an environment sometimes where, like, a bug happens, but then at another level, we, as individuals, we want to grow, we want to progress in our career, and sometimes that’s difficult. You know, when you approach that with people that you work with, maybe, like, you know, you might call it sponsoring or mentoring, like, how do you approach helping someone grow through their, like, career track?
Mahdi: Yeah. So maybe I’m a bit different when it comes to this stuff. I never put much stock into titles and whatnot. And, you know, I know we’re on the Staff Edge podcast and stuff, so it’s a bit on the nose here, but for me, just focus on doing good works. Right. And I think if you focus on that and make that your priority. Right. And then, you know, tell people that you. What you did and how you got through it, and, you know, say, hey, I’m going to kind of take over this problem here. I’m going to try to get it to a solution point. Right. If everything’s, you know, transactional, then nothing has actually any meaning. Right. And that’s not what you’re taking away from the scenario. Right. When I leave a company, do I leave with my title? No, my title stays there and it’s done. Right. I leave with what I did, how I did it, the people I Worked with, you know, what I accomplished, what I learned as I was working, the insights that I had, the fun that I had with the people that I was working with, those are the things I can take away with me. Right. So I think, and I see this a little bit with, you know, people that are coming up and they want, you know, the title, the opportunity, the. The scope to work at will, exhibit that. And a lot of times what happens in these bigger companies is that you’re not rewarded because there’s so many people in the company and there’s. Everyone is requiring that attention. And you end up most of the time working at the level of the title that you’re looking for before you get it for a while. Right. And knowing that should try to unclick you from that. Right? Now, obviously, you want to have some career progress and stuff like that. Look for opportunities to shine. Look for. And those are tough to come by. Right. Especially in large companies where there’s a lot of initiatives at any moment and have varying levels of impact on the organization. But if you’re consistent and reliable, I would bet on the side that you’ll get there. Right now, putting a stopwatch to it is, you know, something I probably wouldn’t do. Yes, like watching an egg boil. But to me, it’s like kind of work towards it. And if your goal is to just get a title, it’s about the work that you’re doing. Right. And if your goal is to just get a title, then, you know, look for positions where you think that would be a good fit, you know, not at your current company or, or. Or pitch to them. But I always try to say this, right, in terms of sponsorship and knowledge. Like, knowledge is an experience of the things that I try to optimize for. Right. Because those things help you kind of grow and open your mind to new things. And those are the things that I try to get out and, and share for. And communicate. Right.
Alex: Yeah.
Mahdi: And share those experiences, things that I’ve experienced, things that they. Or opportunities for them to experience it. I think those things are better to do as a way of sponsorship and leadership and mentorship in that regard. So that’s my little, little talk on that. But, like, honestly, I think a lot of it depends on the individual and what they’re looking to get out of it.
Alex: Right.
Mahdi: They may not even be interested in, you know, deep IC role. They maybe want to become an engineering manager or a product manager. You know, your openings in that regard are limitless. If you’re starting from an engineering perspective. Right. They’re always an asset. If you go into all those other areas.
Alex: Yeah. I want to touch on something you said earlier, which is that when people come to you and talk to you about career progression, I think you hit the head on those. You’re like, do good work. I’m curious, though, like, what if a person feels like they’re doing good work, but you don’t think that it’s necessarily aligned with what the organization needs? How do you help a person work through understanding the difference between just doing work and doing quote, unquote, good work?
Mahdi: That’s a tough one. And I honestly haven’t come across it yet in my mind. You know, if you’re operating in a. Like, I’m assuming, you know, the company you’re at is operating in a metrocracy, or, you know, good work is rewarded and there’s a path forward from there. That’s a tough one. And my thoughts on it aren’t. If you feel like you’re not being. You have to really, really be honest with yourself. Right? This is where reflection comes in really key here, Right. Because if you’re not honest with yourself, right, Then it becomes a bit of a hole you can go down. That doesn’t lead anywhere good. Right. But if you are honest with yourself and go, okay, well, where can I improve? Listen to the feedback, right? Now, sometimes that feedback may not be true, Right. And I’ve been through positions in my life where that’s been the case. But you just keep working and focus on, like, what are you taking away from this? It comes back to that point, right. For me, like, if you’re really after, like, progression and that’s what you’re really focused on and you think you’re there, then great advocate that. Let that be known. That’s what you want to do. And then follow up with work. Now, good work in the sense of, like, communicate. It’s not what you’re working on, it’s how you’re doing it. And then your overall area. There’s tons of things to work on. What if you take a small. Be helpful. Right. Ultimately, what it comes down to. But there’s. I’m sure there’s an area that’s being neglected. Go there and clean it up. Right? Talk to your thing. Say, hey, what’s a thorn in your side? Right. Tech lead. What’s the thorn in your side that you wish you had time for?
Alex: Right.
Mahdi: Like, I don’t. I never ever tell people to work late unless it’s like, absolutely necessary. But you want to grow Quickly, then you got to put in the time, right. If that requires you working later or working in your weekend, up to you. And obviously that if you pick things that are going to move the thing forward or things that are painful to people, then great. Right. But to me, it’s. It’s a very hard question that I don’t have any, like, you know, really thoughtful insights on. But to me, honestly, it ultimately comes down to do you feel like you’re being recognized for the work that you do do? And then look for if there’s a mismatch between what the company’s valuing and what you’re valuing, it’s good to check in, right? So there isn’t. Because these things are few and far between.
Alex: Right.
Mahdi: You check in, you know, for promotions, like once or twice a year if you’re at a company that does that, and then you go from there. So check in, check in early so you’re not wasting three months, you know, toiling away at something that doesn’t matter. But ideally, everything that you’re working on should be something that should be factored in. So if that’s mismatched with what you want in your progression, then you have to check in, talk to your team, lead. So I think, you know, it all folds in together there. But for the most part, if you feel like genuinely, if it’s a thing, you have to be honest, really honest with yourself, right? And like, you know, talk to a colleague that. A trusted colleague or a mentor that you have and ask them for some concrete feedback. There’s. And then if it’s. If they’re all coming out of the conversation going like, this doesn’t seem to be right. And have a tough conversation. It’s always tough, but it’s just a conversation. Don’t shy away from these things, these things that you kind of like, shy away from. My life general mantra is lean into them. Lean into them. It’s not as bad as you think, Right. And if you do that, more often than not, I think people will understand where you’re coming from and get insight to what motivates you. And I think it’ll lead somewhere good. End of that, it’s still not working. And then it’s. Then it’s like, okay, maybe it’s time to look around and see, like, the world’s a big place.
David: I think you touched on two things that are some of my sort of favorite ideas for in general, how to be good at stuff. And one of them is self awareness. And that gets to being honest. With yourself. Right. But it kind of goes both ways. Some people are too hard on themselves and some people are too easy on themselves. Right. And so I think of self awareness as being sort of an important, important cheat code to everything. But also the idea of like embracing difficult conversations. Right. That is something that’s taken me a long time to learn. But if you’re self aware and if you’re willing to embrace difficult conversations, including, you know, checking in about how people think about what you’re doing. Right. That’s a pretty powerful path forward for anything. Not. Not just sort of, not just software engineering, obviously.
Alex: Exactly.
Mahdi: Right. And communicate what you’re facing, feeling and how your goals and I think, you know, we do a pretty good job at 1Password in that regard. Right. People are able to communicate what their personal goals are and the goals for them on the team and how they line up with our.
David: You know, that’s really cool. Is there, is there a process for doing that? Like, do you have sort of some. A way of folks sharing personal goals formally or is it just sort of like in the culture?
Mahdi: So the culture is still forming, right? We’re growing big now and you know, but it’s something that I think everyone values the company and you know, seeing those line up for each individual’s in a, you know, let’s say like it’s like a long path, right. And everyone’s got their, you know, where they’re at and where they want to be and you know, they kind of highlight those things. Hey, I would like more opportunity to design things. I’d like more opportunity to implement these things. You know, some people are in the spot in their career where they would like to, you know, how there’s T shaped people and there’s very general. They know a little bit about a lot of things. There’s people that have, you know, deep about a few things. So there’s people who are still widening their. The top of their tail, other people who are trying to link more depth on particular topics, so they highlight those things. So then as work comes in, you can kind of go, hey, there’s an. Here’s an opportunity to kind of do this. And I try to keep my eye open for these things right. As. As they come in the pipeline sometimes there’s not a lot of opportunity for that. Right. But you can make some find something that kind of sucks and go, hey, can we put some time towards this? You know, we’ll fit it in. It’s print after spin. We’ll put some time towards it. So at Least the person is getting some development and some experience. I think finding that balance and prioritizing it is really important. What we do is we set goals, personal ones for the year. Then we have team ones that we set quarter that are fall into yearly ones for the whole org. And they’re not specifically tied together. The personal ones are hopefully not in competition, but they’re side missions and you can do them as you work in. And it requires a little bit of, you know, thoughtfulness from your leaders to kind of get that accomplished.
David: Yeah, that’s a really interesting model. I’m going to have to think about that a little bit more. Shifting gears entirely. We’re almost at time. There’s two questions that we, we tend to ask everyone who comes on. One of them is, are there any people or resources that you can point to as like places where you’ve learned a lot about this stuff, about sort of like maybe staff engineering specifically, but also just like leadership and mentorship and you know, etc, all the stuff we talked about today.
Mahdi: You know what, I’m a person who likes to think about things, you know, just like, hey, there’s this thing that I’m like, I range from getting really angry about them and like, just going like, this is not cool and going like, why is it like this? Right? And then I go, because I, I really believe, like I. And I, I don’t buy into like institutions much, right? I’m like, it’s just somebody making some decision somewhere. It doesn’t really matter, right? And they’re optimizing for something they think is important. And I don’t think that. And I’m not actively combative. I get sometimes you just have to fall in line and work within the org, right? And not specifically to companies, but just, you know, ideologies about these things. So I go, what’s the real thing behind it? What’s really motivating and thinking that through? And there’s, you know, there’s books I can riddle off all the books everyone reads and you know, but those are things that just expand your mind, right? They give you a bit more context, get you out of your daily rut, right? You’re thinking about like databases every day. Okay, well let’s, let’s stand up a bit and take a look around and see what other people are thinking about. What are the things that people are experiencing? You know, people deal with the same type of problem every day, right? They’re not entirely unique, right? There are some problems that are unique, but most of them aren’t. So what are these strategies like at a higher level? What are the strategies that people employ to kind of solve these problems? What are the ways of thinking about them? Right. Frameworks, I think, are the things that you should kind of collect as you go forward, but go deep on them. Right? Go deep. Right. Have some, like, you know, gut instincts, and all these things push you in one way or the other. So I’d say read the books, but then challenge what they tell you. Right? And then find the nuggets of truth there. Just find a book. There’s tons of book people will tell you to go find. You know, but I tend to, you know, personally, I’m of two modes. You know, something for the heart, something for the mind. So, you know, if you’re interested in new technology, go read about the book. O’Reilly’s got a bunch of awesome books that they put out for these things. Read and consume everything you can about a topic. Right. When you’re learning, just read. There’s infinite amount of resources here. Right. But also, don’t forget what you’re doing. Right. Engineering is a means to an end, not the end. So focus on what you’re doing and what you’re working on. You could spend your whole day working on algorithms, but what did you just do? What did you do? Right. Did you optimize a shopping cart? Or did you actually protect people or help them with their lives or make things easier? I think a lot of that goes unsaid in engineering. And a lot of the problems we’re seeing with a lot of these companies, it’s nobody taking a step back to go, why am I doing this? Right. And the places I’ve worked are generally places where I think I can have impact on people’s lives in a positive manner and get paid commensurately for that offering. Right. I think there’s not a lot of, you know, think about what you’re doing and how you’re doing it and what you’re working on. And these books, you know, there’s a list of them. You can go find them, read them, you know, and those are books that help you technically and give you some context here. And those are good. But the books I tend to find are more about, you know, entrepreneurship struggle. Right. You’re not the only one who’s had adversity in life. So read about other people’s difficulties, and they may seem, you know, the individual. Individual may be easy for some things, other things may not. So don’t. Don’t ever compare. Everyone’s on their own. Little path and try to learn from other ones that you can. Right. So that’s my, you know, what I tend to read and look into and stuff, but I’m more about, you know, what motivates people and what do you think is, like, what do you, you know, what you admire in others, right. And really talk to those people and kind of go, hey, what are those things that you’re doing on? And I try to do that when people reach out to me. So I don’t know, I kind of rambled on a little bit at the end there. But I think that answers your question.
Alex: Yeah, that’s a really interesting take, you know, finding your way through learning, I think. So the last question that we like to ask, hopefully it’s fun. How much time do you find yourself coding nowadays?
Mahdi: So last role to this role, I went from like, you know, 70% of my time to now, like 30% of my time, 35% of my time. And it was a bit of a balancing act. Like, early on, I’d leave going, I didn’t get anything done, right. And I’m like, what is going on? And I’d feel like, terrible. My dinner going, like, what’s going on? Right. And it took me a while to reframe in terms of like, okay, well, you know, you helped a bunch of people along and you got some of your stuff done, you’ll come back to it. Like, I end up staying late because I was like, I was fielding like meetings and questions and what do you think about this? And kind of going here, great. And then all my time that end up doing that, or majority of my time, I end up doing that. But that’s kind of why I’m where I am, where I am. To help facilitate that kind of discussion and move these things forward and maybe be a bit more forward looking in that regard. So, you know, I’d like to be coding more. Right. The idea of staying in the IC route is doing that. Right. But not what it ends up being, unfortunately, sometimes, right, where you’re kind of focused on, you know, larger problems and a class of problem rather than the actual solution to a particular problem. So, yeah, less so. I’d say about 30 now. And I can imagine that’ll probably go down as things progress, but I think you kind of have to kind of let that go and reframe what you. What the role is for you right now at the staff level, right. You can. There’s a lot of people deeply technical and kind of do that. But the higher up you go, I think there’s a little bit less and less of the coding becomes more of like, you know, kind of discuss what the problem is and then implement. But yeah, less.
David: Awesome. Well, Marty, thanks so much for taking the time today. It was really, really, really fun chatting with you.
Mahdi: Awesome. Thank you guys for having me. And it was really, really cool chatting about all this ideas and stuff about engineering. There’s not a lot of space online for a lot of this stuff, so it’s awesome that you guys are doing this.
David: Actually, on that note, before we break, where can folks find you online?
Mahdi: On Twitter, yousef3 and my blog, mightyuser.com awesome. Thanks.
David: We’ll link those up in the show notes.
Mahdi: Awesome.
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. It is a really useful signal to us that folks are finding value in 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.