Dina Spitzer from Square Engineering discusses growing a career over a decade, from software engineer to tech lead
Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard. I am the lead for Developer Relations here at Square. Today I'm joined by Dina Spitzer, who is an engineering manager at Square, has been with the company for coming up on 11 years now, has seen a lot of changes over time. Dina, I'd love for you to just give us a little bit about you. What did you do before you joined Square, and then let's talk a little bit about your journey as you've been here.
Dina Spitzer: We can start back in 2010. So 2010, I graduated with my degree in computer science. Was really interested in the startup world in the Bay Area, and so kind of always knew that I wanted to go from Champaign, Illinois, glamorous Champaign, Illinois to San Francisco. And so I found a startup willing to relocate me out to the Bay Area, joined them, was super excited. And then I saw firsthand how chaotic startups could be and how for a while, every single year I was shopping around for a new job. Either I was laid off or was about to get laid off or the company was kind of flatlining. And so when I joined Square back in 2013, they were my very large stable company and I think we were at about 600 people when I joined. So still pretty small. Pretty small. Different world.
And yeah, I've been on three teams at Square. First team was around building internal tooling for risk management. Second team was the team management team. And so I got the opportunity to work on the Labor API, which is one of our public APIs on that team. And then I kind of got pulled into this world of APIs and I'm like, oh, there's a lot of improvements I want to make with our Square developer platform. And so after building Labor API, I moved over to the developer platform to one of the infrastructure teams to help actually improve the platform for internal developers to be able to build APIs at Square.
Richard Moot: And that's basically why I joined. I mean I think it was like Carl Perry who almost seven years ago and sort of convinced me with joining this team because it was very much, at least the way that it was pitched was it's a little startup within a larger company. And so it was very exciting, lots of new things being built, trying to figure out a lot of things like taking an existing product and how do we create APIs for it. And the team that you were part of is very critical to making that possible, building out the framework that was going to allow people to be able to expose the different parts of the Square point of sale system to transform into APIs and allow people to build on top of it. In that time, so you joined as a software engineer and then you evolved over time to being a lead within your team, becoming an expert in what it is that you were working on. And then more recently in the past couple of years, you transitioned to an engineering manager. So I'd love to chat a little bit more what the evolution has been and how at what point it felt like this felt like more of the same and then the point where it goes, okay, this is totally different.
Dina Spitzer: Yeah, sure. Great question. So I joined the team that I'm currently managing, I think five or six years ago as an IC, individual contributor software engineer. Just joined wanting to make the world a better place. And then I had a vision, had a drive, really studied our platform from the ground up. And I guess I can't say specifics about our internal tooling or internal infrastructure, but let's see, I identified some improvements I wanted to make to our internal architecture, internal infrastructure, got the team on board and we really started building in that direction. And then a little over two years ago, my manager departed the company and literally overnight asked, Hey, do you want my job? You have 24 hours to decide.
Richard Moot: Oh my gosh
Dina Spitzer: And I'd always been like, it was kind of crazy and I had just had a baby too. I'd been back for two months after coming back from maternity leave and I'm still catching up and I'm like, okay, let's do this. Let's just try out this whole engineering manager thing. Never looked back and it's been an adventure. Every day is a different adventure. It's a fun job. Yeah.
Richard Moot: Yeah. I mean, one thing that is, I similarly had gone through that transition from being an IC to being a manager. Granted, I know that I have had a very different role. I don't do traditional software engineering. It's a blend of things. But one thing that really stuck with me in that transition of IC to EM or management is I remember something that Carl Perry said to me before he had left when I was really thinking about whether or not to go into management is the difference between leadership and management. And that it's very easy for us to start to believe that in order to be a leader, you need to be a manager. And I think it's a very common misconception that just because somebody's a manager doesn't necessarily mean that they're a leader and it's actually possible to be a leader while being an ic. I think that's why we've seen the growth of the tech lead as a job that has come up is that when you become an expert or you inspire others, you help others, you mentor others, but you're not necessarily a manager. I'm just curious how you've seen this difference when you've gone from being an IC to being an EM and what you sort of see as that difference between leadership and management.
Dina Spitzer: Yeah, definitely. I definitely felt more of a leader as a tech lead than as an EM. I feel like a tech lead is very much, here's my technical vision, let's get the team on board and it's very much individual leader, let's go. But also let's take the team with us. While management, it was definitely a shift in mindset, I would say, because with management it's empowering others to lead and only really stepping in and using your voice as a leader when there are gaps and when it's needed. But ideally, you manage yourself out of a job. Ideally you empower those and delegate and have others on the team step up and really I guess use their own voice, empower them to become leaders. And often in one-on-ones, those people will express, they want to step into that leadership role or want to do that tech lead role. And so then you start finding work to actually enable them to step into that leadership role. So you're very much supporting and empowering people to lead rather than being like, I'm the leader. Here's my voice, this is what we're going to do. It's much more of a supportive role.
Richard Moot: I think that you put that really well because one thing that I found particularly different about going from IC, at least in the initial phase, I know that there's this phase where some people will become a manager but then still have IC responsibilities. So you're doing that player coach type thing. But the thing that you touched on there that I think is really important to learn how to do is the delegation piece. And I found that to be particularly challenging at first because I think as an IC, you get so used to being able to just take on the work and complete it or figure out how it should be solved. And I think the part where I feel I felt the most growth in going into management was being able to actually hand something that I know that I could do really well, but giving it to somebody else to be like, no, I want them to do it because they're going to grow more as an individual when they do it, and I'm here to be that resource.
So yeah, I just love the way that you started talking about the delegation piece, but it just felt like that's a thing that you don't really do as an ic, you're, you're not really delegating things. You're just like, yeah, I'm just going to go solve this, or I'm going to go talk to my manager and they're going to help me unblock me.
One other thing I was just curious about in the mindset shift from IC work to EM work, I'm curious, how has your idea of what success in your role has changed? Because as an IC, it's like, Hey, I completed this work, or I created this design and implemented this or launched this product feature, but that's not, you're trying to do enable a whole team of people doing this, but you're not actually the one doing it. So I'm curious if you could talk a little bit about how that mindset shift has changed in terms of what you think of as success.
Dina Spitzer: Yeah. I would say that there are two components. There's the internal management and then the external management. And you have to think about both and you can be successful or not successful in either of those areas. For example, internal management, it is successful when I empower someone to step into the leadership role and they step into that role and I can reward them, I can promote them based on that. I would say that's more like leadership and internal management, and that's a success story. External management success story would be like we redirected and pivoted to align the team with the direction of the company, and we're now able to help the company hit a specific milestone in working with product and so on. So it's how do we fit into the bigger picture? And both are very different and very different skill sets and both kind of invisible work as well.
Richard Moot: Yeah, no, totally. I mean, one thing is because of this shift, it's like I don't know how often you might feel this way where you can end up having a day where here's the things that I wanted to accomplish today. And by the end of the day you might end up just going, I have no idea what I did. You suddenly just jump into meetings or you're addressing firefighting and you look back and you go, I feel like I didn't do absolutely anything, but you know, did something. But I don't know, it feels disconnected at times because trying to just sort of unblock things for people and once it's unblocked, you're not seeing the result of it. You're just seeing like, okay, somebody has an answer, they can move forward and forward. I'm going to see the result of this a week or two from now.
Dina Spitzer: Yeah, I definitely agree with that. And a skillset that I've had to learn is living vicariously through others accomplishments. So if somebody on my team was able to accomplish something because I unblocked them, because I delegated the right work, I had the right conversations to set them up for success and give them that work, it's their project, they're running with it and they succeeded, but I'm like, yes, I played a role in that. And you kind of just have to take those wins where when your team succeeds and when the individuals on your team succeed, you're succeeding.
Richard Moot: I think that's very well put. You no longer try to look at, it's like you have to redefine your personal success through your team's success. And so on those days or weeks where you feel like I didn't do anything, but all of a sudden you see all the updates from your team on like, Hey, look, we shipped these three, five things and look at what kind of impact they're having. And you're like, wow, I'm so proud of my team. I can't believe that they're able to do all this stuff. So yeah, I definitely say that's probably one of the more rewarding parts in trying to make that shift. One thing I want to go back to a little bit is, and this is probably more true now that you're the engineering manager on the team, when first starting on the team that was building out the frameworks for our developer platform, we were having a big shift in terms of how we were actually building APIs.
We used to have it all built by one team trying to build it into all these different services and we realized this isn't scalable. And so we then shifted over to this decentralized way of, Hey, we're going to build out a framework and we're going to give this to a bunch of teams and say, Hey, you're going to use this in order to go and build out those services. I recall that that period of time was a little bit rough because there was a lot of heavy on call firefighting type stuff. I'm kind of interested in how that has changed for the team over time and how do you help build that resiliency for a team to be able to work through the constant firefighting and then now be in what is a much more stable place?
Dina Spitzer: Yeah, great questions. I think the biggest thing that we did early on, I'm trying to think back, but the first year joining the team was actually dig into what are we getting paged for? Why are we waking up at night? We actually found that the majority of our pages were not real. They weren't actionable. I mean, our monitors and detectors were just a little skewed. They were just a little off or they were detecting things that weren't actually real issues. And so we put a lot of effort into actually reducing the page volume and the noise around that. And then we did a lot of work around what are the noisy parts and how can we extract them out? We did that for logging. Yeah, I'm trying to recall because it was like five or six years ago, I know. But we did a lot of work upfront to basically figure out why are we waking up in the middle of the night and how can we get that page volume down? And after, I would say a quarter or two of working on that, it was much more balanced on the team. It was a much, much nicer team to join and a team where you're not regularly woken up in the middle of the night and it was great. And then we could kind of continue with our vision after that. But there were fires when I joined, lots of fires.
Richard Moot: It was a very interesting time. But I mean, I think that the work too actually, and I think something that can get overlooked quite easily sometimes is how many false positives are we really getting here? And let's actually block time to go back and see are we trekking the right signals? Is there anything that we're actually fixing here or are we just creating a lot of noise? I mean, nobody wants to be on a chaotic on-call rotation.
Dina Spitzer: No. And also another thing I'm recalling that we did was we used to all just swarm. We would stop our project work and swarm on on-call issues, and that means that your project work doesn't really move forward. So there were just a lot of process changes that we made very early on and we were like primary on-call, primarily digs into the issue. They can leverage secondary on call if they really need to. They can pull in someone else from the team. But having that separation of concerns on the team really helped us to actually continue pushing our product work forward will also fighting fires.
Richard Moot: Yeah, I mean it's crucial because it's too easy, especially when you're in that firefighting mode to just be dropping everything and being like, oh, we have to go put this out. And then you're in this context switching and trying to go pick up the old work and it's much harder to move things forward.
So one thing I wanted to ask about is as you've now been in the EM role for a while, how is it that you have approached or, I mean this is going to feel like a weird question, but what is it that you noticed or look for in some people who are starting to evolve into that tech lead role and how do you think about fostering that or trying to fan the flames on that interest?
Dina Spitzer: Yeah, I've definitely worked with a couple people on my team who've expressed they want more leadership responsibilities. They wanted to step into that role. The biggest thing is identifying a project that they can actually use to step into that leadership role or sometimes asking them to identify a project and working with them and product to figure out what that really senior project is going to be. And sometimes there is no project for a little bit, and until you identify that project, you coach them and mentor them on leadership traits within their given work
So that when it comes time to actually take on that really senior project, they're ready, they're there. But I also really like the primary and secondary DRI model. So let's say that somebody really wants to step into the tech lead role. I have them be the primary DRI, and then I have someone a little bit more senior than them be secondary DRI to provide coaching and mentorship as we go. And I found that that's really effective so that they have that support when they need it, but really they're the ones leading the and leading the project.
Richard Moot: Oh, that's really great. And it's so funny to hear that because on our API design team that I lead, we actually kind of followed organically a very similar route that when we have somebody that's going to be pairing up with a team that's working through an API design, we always have a primary and a secondary and we kind of treat it. One person is kind of run it and then you have somebody's backup. Part of that is to handle when somebody's has to go on leave or something that somebody's able to immediately pick up on it. But we found that when onboarding people into that process, it was super valuable to have the more senior, more knowledgeable person as a secondary. So it feels like there's a safety net. So when you get to that unknown uneasy area, you have somebody who you can consult with on the side, you can be like, oh, here's the things that you should think about. So it's great to hear that great minds think alike in terms of these approaches.
Dina Spitzer: Yeah, it's an effective model and it's also really awesome to see that less senior engineer who's assigned as primary DRI. It's really awesome just to see them grow and improve and receive that mentorship and really take that mentorship and lead. It's one of my favorite things about management, to be honest. Just seeing that growth of everyone on your team and enabling that.
Richard Moot: As you sort of foster growth for individuals. I had this kind of conversation with one of the Mikes that works here, and there was an interesting thing that he talked about when trying to help somebody level up say even in just their software skills is I'm just wondering how much this might ring true for you that when somebody's going diving into an engineering design or trying to interpret a product requirements document that, how often have you found to, rather than giving somebody the answer, just giving them another question or another direction to have them investigate in order for them to go learn it on their own? Because I think it's very tempting to just be like, oh, I know the answer to this. You should go talk to this person, do this thing and do this. And you kind just go, well, why do you think that's happening? I mean, do you find that happens fairly often or what are your sort of different tools for fostering that type of engineering growth?
Dina Spitzer: Definitely that. Another tool that I use is if there's someone a little more quiet on my team, but I know they have the answer, I'll be like, oh, person A, what do you think about this? And I know they have the answer, but I know that they don't really always feel safe or comfortable expressing in a big group setting. And so redirecting conversations to get focus on people who otherwise wouldn't speak is a tool that I really like to use.
Richard Moot: Yeah, I think that's a really good one. I think it's an interesting thing too because you learn the ways in which you can do that because for some it might feel like being put on the spot, but when you know that, oh, this person totally knows the answer to this, I'm just trying to give them that moment to shine and be like, Hey, go ahead and tell us all so that they can basically express that. I think another one that I've used, I don't know if you've used it as well, is whenever somebody on the team actually has done something and you're trying to share it with others, I always am very egregious about just giving credit to people all the time. I'd much rather say that Anthony and my team did this. Jordan and my team did that, and part of it is to direct people to be like, Hey, when you want an answer on this stuff, you actually don't have to come to me. You can go to them and they'll give you the answer for that. But I felt like it just helps boost the confidence of, these aren't me, these aren't my ideas, this is my team. I'm just here to empower them.
Dina Spitzer: Yeah, I definitely grew with that. And something that I'm doing right now is some of the more vocal tech leads on the team. I'm actually coaching them to try and play that role. I'm like, you've had your time in the spotlight. You're a very powerful technical leader. Let's now shift your focus to actually empower these other people to actually step up because there's only so much air in a room. There's only so many voices that can be heard. And so it's interesting that I've learned to do that through management, and I'm also currently having conversations with some of the more vocal people on the team to coach them to actually empower their peers as well. Yeah, something I'm doing right now is just coaching the more senior technical voices on the team to actually shift and empower other people on the team and to kind of shift the spotlight over from them to some of their peers, which is a different kind of leadership for them.
Richard Moot: Well, and to harken back to something that you actually said previously where that's kind of teaching, that little step of going into an engineering manager is when your work as an EM becomes more invisible, and so the more senior, the more of a voice that you end up having. You have to learn to be more reserved, more careful with it. Because sometimes it's like you say something and people are like, okay, that's what we're going to go do. And you're like, well, that's not what we want to happen. But also it's like you allow other people that space to grow, and so when it's dominated by the more senior people, suddenly you can develop this culture of like, oh, well, there's no mentoring, there's no advanced projects to work on. The more you coach more senior people to be sit in the background, let other people discuss and only kind of dive in when it feels like, Hey, it looks like we're veering off, or, Hey, actually I think this might help a little bit more. So I think that's wonderful in terms of trying to really balance the seniority
in your team in that way.
Dina Spitzer: And honestly, one of the best things I ever did for my team was had a kid three years ago, I left the tech lead and I came back and there were all these leaders in my absence, and there was so much room for the team to grow in my absence too. And so timing worked out.
Richard Moot: That's really funny that you say that because I think he just immediately gave me a flashback of when I joined the API design group was because my manager went on paternity leave and was gone, and I had to cover for them and leave this other group or at least participate in this group. I wasn't leading that at the time. And that I would admit as an IC, I was like, this is wild. For three or four months of just like I have to answer all these questions, I'm completely out of my comfort zone. But I mean, in the end, it's really good growth. In all honesty. I think what convinced me to actually that I wanted to do more management type stuff was being able to be thrust into that tried in this place where I don't feel like I'm completely committed to this. There is a timeline where I don't have to do it anymore. And so it's great that there's these ways to sort of inadvertently create that space and you come back and you find out like, Hey, the team didn't fall apart without me. In fact, they're stronger and better than they were previously.
Dina Spitzer: A hundred percent. And on that note, I'm actually starting maternity leave for baby number two next week.
Richard Moot: Wow, congratulations.
Dina Spitzer: Oh, thank you, thank you. And my tech lead from my team is actually going to be covering for me in my absence, and I think this is just an excellent opportunity for him to step into the management role and to really learn and grow in that area.
Richard Moot: How have you approached preparing somebody? It can be this one person in particular, but it's sort of thinking, how do I, it's not often we get these opportunities and they be like, how do I explain to somebody else to do what I do? Most of the time you just start doing it and you build your own process and mentality and framework, but then it's in this moment you have to go like, wait, now I actually have to codify this to some extent. How has that been and how have you sort of approached it?
Dina Spitzer: Yeah, great question. So I literally started a brain dump doc two months ago, and anytime I was asked to implement some sort of process or do some sort of process or think about some sort of question, I just put it in the doc. And then last week I actually cleaned up the doc. I was like, okay, is my wild random brain dump? Let me actually clean up the doc and then have a really long conversation with this person. So I can give you some examples of things that I put in the doc. So the easy stuff is like, Hey, every quarter do something with this spreadsheet. It's like the very standard process things that managers have to do. Okay, fine. That's the easy stuff. And then there's the other thing where it's like, here are the ongoing conversations that I'm having with these people and these teams. This is the status of each of those conversations, and I want you to continue these conversations. And then another category of items that made into that doc was more taking a step back and very high level questions like things that I'm thinking about with my team in that moment. So it's how does my team align with the goals of the company right now?
Richard Moot: How is this person going to get promoted? Just very high level questions that I'm constantly trying to get data points for and constantly thinking about. So it went from very do these steps and do these process things to very high level. What are questions that we should really be thinking about? And I really trust the person that is covering for me. I think it's just a slight shift in his mindset. But yeah, I think I'm leaving my team in really good hands.
Yeah, it's interesting in that reflection where there's the bullet, the task list or the priority list that we build of like, oh yeah, here's the things you got to do on this particular cadence. But then it's also great that you, you're creating those more abstract. Here's your north star things. Make sure that you're following these things. And when you're feeling lost or confused or if something out of the ordinary happens, as long as you're kind directing towards these things, you're going to be going in the right way. But I mean, these are all things that you sort of built into your team over time. Anyways. This is what's important. If it's not in this realm of things, it's not that important. Don't worry about it. And that's I think, how you end up building a team that you can trust a lot.
Dina Spitzer: Yeah, definitely. I agree.
Richard Moot: Well, I think that's probably a place where we can say that's it for today. I want to thank you for joining us here on the podcast and helping us in getting the very first episode done. And I think that it was a great conversation talking about the evolution of going from IC to EM and how do you foster growth and trust and seeing others become better software engineers.
Dina Spitzer: Yeah. Awesome. Thank you so much. Thank you so much for your very insightful questions. This is a lot of fun.
Richard Moot: Great.