The Art of Architectural Leadership with Tina Wright (Podcast & Transcript)

“Only listen to criticism from people whose advice you would take, people who you respect. If you don't want to be like that person, why would you listen to their advice?” - Tina Wright

Tina Wright is an Area Tech Lead at Grammarly and has worked as a software engineer at Coursera, TRI, and Google.

In this episode we discuss:

• What is an area tech lead?

• Technical leadership as a generalist, rather than a specialist

• How to get the best from your team through a service leadership style

• The advice she would give her younger self

Transcript has been edited for clarity.

Karen Ko: Hey there. Welcome to Engineer Your Career, a podcast brought to you by WEST, a learning community empowering women technologists through mentorship. Join us as we hear from inspiring women tech leaders who are challenging stereotypes and paving the way for future generations. We hope their career journeys inspire you with new ideas to engineer your career. Let's get started.

Heidi Williams: Hello, everybody. Welcome to our latest episode of Engineer Your Career. I'm Heidi, and I'm super excited to introduce our guest today, Tina Wright. She is an area tech lead at Grammarly and has worked as a software engineer at Coursera, TRI, and Google. She likes making order from chaos, learning about eclectic topics, and being weirdly opinionated, which I truly appreciate. She studied computer science at MIT, and outside of work, she enjoys reading, bouldering, board gaming, and dancing.

I had the extreme pleasure of getting to work with Tina at Grammarly. I feel like she was one of the best hires that I made. I was so happy to find her and that our paths got to cross, and I could not be more pleased to have her here on the podcast today. So welcome, Tina.

Tina Wright: Thank you for having me. And I have to say that honestly, the pleasure was all mine.

Heidi: So cute. Yeah, I feel like we are destined to work together again at some point. It was definitely too short of a stint, and I have so much more to learn from you, so I'm excited for you to be here with us today.

Tina: Looking forward to it.

Heidi: Awesome. We'll make it happen. Let's start way back in the very beginning. Can you please share how you first got into programming, and maybe what did you want to be when you grew up?

Tina:

So I think I maybe have a different story than a lot of people, where my parents were both programmers. Most of my aunts and uncles are programmers. So it's really more of a question of how did anybody in the family not end up in programming, honestly, at that point.

When I was a kid, I wanted to be a professional ballerina, and my dad sat me down and told me about comparative advantage and career and lifetime earnings, and we had a very tough but practical discussion on what it means to earn a living and have the things that you need for that. So yeah, I actually desperately for so much of my education wanted to be anything except a programmer because I was like, I am going to be different. I'll be a physicist or a mathematician, still very much in the STEM field, but didn't want to be a programmer.

And my first official programming class, I took in high school, and I remember my teacher, Mr. Levin, was a very memorable teacher. He used to throw chalk and do all sorts of fun lectures, but the first lecture he gave us was super memorable, and the entire 45 minutes he wrote on the whiteboard, the number three, and then said, what is this? And for the entire class, we just round robin guessed what this is. It's the number three, it's the number one, less than four. And eventually, we got to the answer, which was, it is a representation of the number three. And for me, it's such an out-of-the-box way to start teaching representation in numbers and enc, coding theory, and computer science. And so I think I just got really lucky in starting off with a non-traditional teacher in high school for programming.

Heidi: I love that. I think that's amazing. And I feel like sometimes, yeah, those moments where it clicks, I feel like I had the opposite experience in high school, where I somehow convinced our math teacher that the class on logic was computer science and should not be part of the math curriculum. And embarrassingly, he took it out of the math curriculum after I graduated, and I went back to him later to say, I'm sorry, but I ended up as a computer scientist, I'm really sorry I made you take it out. So anyway, I'm glad that for you, it actually sparked things.

Super curious. How old were you when your dad was talking to you about your life choices? Were you eight or were you a little bit older?

Tina: Yeah, no, I remember this very distinctly. I was entering seventh grade, middle school, and I asked my dad if I could go to a dedicated ballet high school, and he was like, wow. I mean, I think he was very happy that I knew what I wanted and loved that I was directed and I would ask for it, but was kind of worried about the whole thing. And so yeah, I was entering middle school, considering what I was going to do in high school, because that was also the time at which, in my municipality, we had magnet programs, and you had to apply to your high school magnet program. And so we were deciding around that time what high school I was going to try to apply to.

Heidi: Wow. Yeah. Oh my gosh, that's awesome. It's a heavy topic, but I'm glad it sounded like it was actually age-appropriate and relevant to the choices you were making at the time, which is awesome.

Tina: Oh, totally. It wasn't like I was five years old, although there were some, I've heard that before. There were some age-inappropriate computer science lessons that only when I was in college. I was like, were they trying to teach me hexadecimal in third grade? No...

Heidi: That's fantastic. I love it. I love it. Yeah, I can totally see that. I can imagine. Yeah. And interestingly, though, dance has still played a part in your life, though. You have not given that part up, even though you didn't end up majoring in it.

Tina: Yes. Although I have to say that my dad was correct in a lot of ways. I still dance now, but I no longer do ballet because it's very bodily intensive, it's hard on your knees, it's hard on your ankles, it's hard to keep the fitness level required. And so as I got older, I switched to other forms of dance that were a little bit more easy, physicality wise or easy to do casually. So have to say Dad was right. I would not be able to do prima ballerina stuff now anymore.

Heidi: That's great. That's great. As a parent, you should definitely tell your dad that he was right at some point. Just to share the appreciation.

Tina: I'll send him a link to the podcast. I'm sure he'd love it.

Heidi: That's amazing. That's amazing. Awesome. And so maybe tell me a little bit about how you got to what you're doing now at Grammarly.

Tina: Sure. So like I said, I applied for a magnet high school and ended up going to a science and technology high school, where I got an accelerated education, a lot of AP classes in all of the sciences, one of which was computer science. But I liked STEM, I enjoyed it. I knew I wanted to be into STEM. And so then when I applied for college, I was looking specifically at technological majors. So math, physics, computer science were my majors considerations.

But when I got to college at MIT, I loved the classes on all of them, but at one point, we started looking at career fairs and job opportunities, and I noticed that one of those fields had a lot more job opportunities than the other two. And I was an eminently practical person by that point. I guess that conversation from four years earlier really sunk in.

And so I knew that I wanted to choose a major that would lead me to a career that I could sustain for a long time and that would give me the type of life that I wanted to live. And while I love math and physics, I can do those sort of as passions on the side. So that was my educational story.

Out of college, I joined Google, and so that's where I really was formed as an employee, I guess. At the time, Google was just the place to be. It was building the dream, organizing the world's information, making it available, the best and the brightest. And I got to learn so much from so many different people. But I did also learn about work and life and the difference between being in a company and a career than being a student and learning. And that was not an easy transition for me at all.

So I loved Google in its own way, but it was also incredibly rocky road for me personally. After I decided to leave Google, I joined Toyota Research Institute, which was much more research adjacent, much tinier, going from tens of thousands of people to maybe 200 when I left, really small.

And then after that, I spent three years at Coursera, and that's where I really transitioned from being an individual contributor towards more of a technical leadership path. And then most recently, where I am now, I'm at Grammarly, which was exciting, because it was the first company where I came in at the leadership level and didn't start coding from day one. I came in, and I still actually haven't written any code there, which we can talk about later, perhaps. But yeah, that's the CliffNotes version.

Heidi: That's amazing. Yeah, you've done so many interesting things and really explored different parts of the field. And I remember, I feel like this was more a conversation with my dad and my brother, who struggled a little bit to figure out what he wanted to do after high school and after college. But sometimes, even though it can be a rocky road, like you mentioned, at some places, you can then discover the things you don't want or that you don't want to prioritize or what works for you or what doesn't. So it sounds like you had lots of different experiences that kind of helped you really figure out what kind of role you did want to have.

And so maybe if I could ask, can you define for us what is an area tech lead or how at least it is defined at Grammarly?

Tina: Yeah, I get this question a lot, actually. So great question. Very relevant to a lot of people. I have to say, to start. Area tech lead, I think, is becoming more of a term in industry, but it does very much vary depending on the company and even the sub-organization within a company. So I don't think that right now you can say area tech lead and everybody knows what you mean immediately.

In a general sense, it's like a technical lead, but instead of for say, a team of 10 people, it's for a group of teams or maybe even a group of teams, depending on how high-level you want to go for. Personally, the way that I define my area tech lead role at Grammarly is that I'm responsible for my five teams' technical strategy, the roadmap to accomplish that strategy, the technical backlog. So that's sort of the architecture and design pieces.

The second thing I'm responsible for is the excellence in our systems and practices and people. So this is our technical approach or our mentoring. And then the last thing that I'm responsible for is our technical collaboration and coordination, especially for larger or more complex projects or multi-quarter projects. So yeah, those three: strategy, excellence, and collaboration is what my purview is.

Heidi: That's awesome. Super exciting. And how... I guess you mentioned also that for you, this is not a coding role, and I'm curious whether, maybe, tell me a little bit about that. Do you miss coding at all? Do you feel you're able to do your job well without being hands-on?

Tina: I'm a little embarrassed, but I don't miss coding. Let's put it another way. I miss the type of coding I got to do in college that was so clean and contained, and you could have abstractions and you knew what you were doing and you could write the code and it would work, and it was beautiful.

I have not at all in my professional career had to write code like that. And I think many people will relate to this, that things that you actually do to make things work is very different from what you do in an interview or what you do in a class assignment.

So no, I don't really miss that much. I was okay at it, but honestly, a lot of other people were much better at it. And so going back to comparative advantage again, I found that some of the skills that I have on more of the leadership side. I ended up being more energized by it. I ended up being comparatively better, being given more opportunities there. And so it's kind of snowballed, and I've enjoyed that snowballing personally.

Heidi: Yeah, that's really cool. And how did you first discover, I think a lot of folks don't know, a lot of people picture maybe that as a principal engineer, they have an idea of what that looks like or maybe what an architect looks like. How did you discover this as a type of role or opportunity? Where did you first learn that this might be a thing?

Tina: I think for me it was really at Coursera. So I joined Coursera as a staff engineer on the authoring team under Colleen Lee, who's amazing and was a wonderful manager to me. And that team was a relatively large team, but they needed a tech lead. And for the team tech lead, that meant some of it was honestly just sprint management. So coordinating the sprints, estimating points, all that agile stuff, which I didn't love, but the previous tech lead didn't love so much that he didn't want the role. And so I got the opportunity to step in there.

And then from there, I sort of got to slowly expand what I did for the team over time. And then, as I settled into the tech lead role at Coursera, they had a technical architecture group, and this was a rotating group of people who were part of the architecture team, which was ill-defined at the time.

It sort of varied depending on who rotated on or off the team. But I got an opportunity to rotate onto the team. And at some point during that, we hired a chief architect, JR Jasperson. So he came in and had a vision for how an architecture group could work effectively within Coursera.

So a lot of what I do now is actually based on a lot of the frameworks that he taught me there. So I had kind of a slow trickling of expanding responsibility over time. I got a little bit of tech lead operationally, and then I got a little bit of tech lead, like planning and roadmap-wise, and then a little bit of architecture unstructured, and then a little bit of architecture structured. And for me, that was really perfectly keeping pace with my expanding interests. So I think I just got really lucky.

Heidi: Yeah, that's amazing. That's awesome. It sounds like you had great role models along the way while you were in that environment, and seeing maybe how different folks could approach it or maybe what they were optimizing for and whatnot. So that's really fascinating. Awesome.

And did you have a sense of when you saw the Grammarly opportunity, what made you feel like it would be a good fit for you? How did you know that you wanted this kind of role?

Tina: Yeah, when at Coursera, I decided that I wanted to move on. I knew that I wanted to give more of a shot towards this architecture piece. I liked the things that I was seeing and doing there. I liked design reviewing, thinking of larger pictures, thinking about the entire system, and the flows of that. That was really exciting to me. I love defining core abstractions and concepts. Having the three-box version of the diagram versus the 20-box version of the diagram, all of these skills were ones that I felt like I wanted more of an opportunity to explore that I hadn't quite mastered in any way, actually, probably not even close to mastering.

So I knew that I wanted to look for a job kind of in that size and shape. I didn't really know exactly what it would be called because while Coursera, we called it architecture, I think that term has gone out of favor in industry.

And so nobody was really posting architecture roles. So I really went in and just looked at the line-by-line on each of the job postings and said, what are they doing? And the Grammarly one just was so exactly the right tone and words for exactly what I wanted to do. It was like, we want you to coordinate the strategy of our systems. We want you to improve the excellence of our technical best practices. So looking at each of those pieces... In fact, it was so good that I copied and pasted it and kept it so that later I will know how I want to talk about my own skills.

Heidi: That's amazing. That's amazing. I will probably hit you up some time for that because I felt very happy with how the role was framed. And of course, that meant we found you, and I think you had an enormous impact in the time that I was there and that we got to work together. So I felt like it all came together as.... I think it is not a super common archetype. And so I actually love that we were able to put it into practice and see the impact of it. And it's definitely a flavor of leader that I would love to have in any organization that I'm working in. So I love that.

Tina: And definitely, Heidi, one of the things that I loved that we did was that we talked extensively in the interview process about what exactly the expectations were, what we wanted, what you wanted, what I wanted. And so before we even started day one, we had a sense of, okay, what does three months, six months success look like? And so I personally found that a really important part of the interview is that we came in super aligned with what the role was. Now I came to Grammarly, and then I discovered that almost no one else was doing the role that I was going to be doing, but it didn't matter because you and I were aligned in our organization.

Heidi: Yeah, that's a really key point. And actually, for anybody who is job searching, I feel like it's a fantastic conversation to have around how do each of you and the hiring manager define success? And I think you asked questions like if I've been here a year from now, what would success look like? And then we could sort of match with each other about whether that was both what we had in mind or not. For anybody who is job searching, it's a great conversation to have. So I appreciated that you asked those questions.

Tina: If you don't mind. I have one more story around this, actually. When Grammarly first reached out to me, it was actually for a different role entirely. And I looked at it and I was like, ah, that's okay. It's not exactly what I wanted. And so I looked on your job board, and I looked for other roles and I was like, I want this one instead. And I just replied to the recruiter and was like, yeah, thank you very much for considering me. Your role is fine, but actually, I want this one.

Heidi: That's awesome. Yes, another great point. Ask for what you want, not just what someone asks of you. That's a great piece of advice.

Tina: It was a bit of a stretch for me, so I don't think I would've been considered for that role if I hadn't asked for it.

Heidi: Yeah. Yeah, it's a good point. And I think all too often we know the sort of, I don't know, I guess the lessons we've seen in the industry that often women don't apply for jobs that are stretch assignments because they feel like they need to be a hundred percent qualified before they apply, whereas sometimes our male counterparts don't do that. They go ahead and apply anyway. And so I'm glad that you applied for it anyway, even if you didn't feel like you had had all of those experiences ahead of, so fantastic. Awesome.

And so maybe tell me a little bit about what you think helps you be successful in this role. So maybe it's something about your tech leadership, or maybe it's something about what you feel like, what specific strengths you have that you bring to the table. What do you think helps you be successful?

Tina: Interesting. Well, I don't know if I'm just in a particularly self-deprecating mood right now, but in general, I don't think of myself as particularly like rockstar or special when people are like, are you an A team? Are you going to rock it 10 x engineer? I actually don't think of myself like that. Now, I think of myself as a person who tries to get 10 x results, but it doesn't come naturally or for free. It's not something that's just easy.

So I guess to start with, do I have any particular skills? Maybe, but honestly, everything that I have, I also have had to hone extensively through many struggles and frustrations and failures. So I guess that's just one personal belief is that some of the terminology we use in industry, I think, encourages people to believe that they're either in or they're out. And I don't believe that personally. I believe that you train.

Heidi: Yeah, absolutely. And what do you feel like is maybe one strength that you have trained and developed over time? And maybe— I love asking it in this other way because you were saying sometimes you don't, it's hard to sort of talk about your own strengths. What do other people call out as a strength of yours that makes you successful in this role?

Tina: I think that there's two potentially interesting ones. So one, I'm not shy and I articulate and I can give presentations, which I know doesn't sound like much, but it used to be that if I got in front of my team of five people, I would be shaking and my voice would be cracking and I wouldn't be able to talk even to the people I worked with every day. And so the fact that now I can give presentation to a hundred people and do that every week is quite a feat for me personally. So I'm very proud of that.

Another thing that I'm told, actually mostly by non-engineers, but occasionally by engineers, is that I can articulate concepts to make them feel simple, which is really important when you are trying to communicate high-level topics to a large group of people without getting them confused or whatever. So that's definitely one that, still working on it, but I am told that I can do somewhat well.

Heidi: Yeah, I can definitely a hundred percent on that Oone. Big thumbs up on that one. I feel like even if it is a technical concept, you might be explaining it from one group of engineers to a different group of engineers who don't work on the same tech stack or something like that. And being able to translate and make it understandable and relevant so people understand the complexities or the challenges and whatnot. And I think you were able to break down really, really big things into smaller parts, and you could logically separate them in a way that made it easy for people to understand the root causes without them being entangled with each other and things like that. So I definitely feel like you are really amazing at that, in particular.

Tina: Thank you. Well, I'm a very big believer in hierarchies and the appropriate level of hierarchy or abstraction for the particular conversation. So, yeah.

Heidi: Yeah, so important to think about that. Yeah, for sure. And it helps you, I think it does help you feel more confident speaking in front of audiences. The more practice you get at different kinds of audiences, you recognize like, okay, everybody's eyes are glazing over, guess I went too deep or whatnot.

Tina: And when I'm putting together a presentation, sometimes if I don't know what I'm talking about, I'm like, oh, it's not the right time to give this presentation. The concept is not ironed out yet. We need to simplify this before we can spread it.

Heidi: Yeah, I love it. Yeah, very, very thoughtful. So maybe going back to maybe another aspect of where I was trying to go is maybe describe to me a little bit what your tech leadership style is. How do you sort of approach this... Yes, this very broad role that is both, I don't know, there's the high-level, there's getting in the weeds and the details, there's working with people. What is your tech leadership style?

Tina: So I think a lot of people throw around the term service leadership, and that's what I would say my tech leadership style is. But also, I don't know that we all mean the same thing when we say that.

And so when I say that, there's a couple things that I mean, so first is that the people in my organization come first. So what I'm trying to do are the things that improve their lives, what can I provide that makes their lives better? So that might mean, hey, we need clarity on the next year's worth of roadmap for this technical improvement, or that might mean we need help unblocking this piece or that piece, but if the people on my team don't want it, then I'm probably doing the wrong thing.

Another thing that I like to do personally is, I don't believe in swooping down and personally fixing problems. I think that actually, at my level, at least, takes away the owning team's authority and intuition and experience in that space if I come in and fix it for them. Also, like I said, I'm not that great at fixing either, so why would I do that? But what I like to do instead is to find the engineers on the team, the senior engineers perhaps, or even more junior ones, depending on what the right size of the problem is. And I try to take the challenge and narrow it down to a scope that now it's the right size and shape for them to stretch towards it. So I don't want to give them something way too big and just drop it on and be like, figure it out, but I also don't ever want to take away the opportunities for them.

So there's this magical moment where you have to find the person you want to hand it off to and scope it down to the level at which it's an exciting challenge for them, but not something that scares them too much.

And then I'd say maybe another piece around service leadership is that I don't view my role as a decider in technical decisions. I'm more like an arbitrator. And so what I mean by that is that I am pretty much never the most informed person in the room. All these people have so much more experience than me. They have so much more time on the ground with the problem, but also sometimes they don't agree. And so how do we make sure that a decision can happen, informed by the people who know the best, whose feet are on the ground?

And so the way that I personally like to do that is to get the conversation down to the root-most assumptions. I find that once people get to the right set of assumptions, the answers kind of fall out from that, unless, of course, one of their root assumptions is in conflict with another root assumption. And that's where you have the real fun problems, the real fun... disagreements, I guess.

Heidi: I can imagine that. That's awesome. Yeah, I love that. And I do feel like that's another one of your skills, is the facilitator of those conversations. And I feel like it's always interesting to be able to... asking the right questions and digging and getting to the answers, I think. At getting folks to feel like they're really participating and owning the process and the decisions at the end of the day. I think that's fantastic. Yeah.

Tina: It is one of the most satisfying and the most incredibly frustrating parts of the job, honestly, because people will say something and you'll be like, okay, but why do you believe that? Or, okay, but can you see where they're coming from? Please. Please. Please.

Heidi: Yeah. You said before seeing people to stand in each other's shoes and understand the other perspective or the other assumptions and whatnot. Yeah, that's fabulous. And speaking of challenges and frustrations, have there been challenges with your approach, and how do you, I guess, tell me a little bit about what that journey has been like.

Let's take a quick break to hear from our sponsor.

Karen: Are you ready to take control of your career? WEST can help. The WEST Career Accelerator is a six-month learning program that combines one-on-one mentorship and group-based career coaching to help women gain clarity, save time, and define success on their own terms. We're here to help you create a path towards the career you'll love. Check out how WEST can help you succeed at joinwest.org.

Heidi: And now back to our discussion.

Tina: Oh, of course. There's definitely been challenges with the approach. So like I said, with the arbitrator, but not decider, there are times where a decision needs to be made, and people are maybe not totally coming to the same page. So you can get them towards the core of the issue, but sometimes they truly don't believe something, like one of the assumptions, and you can't get them to align, in which case you have to get to a point where... kind of hate 'disagree and commit,' but you do need to get to a point where you're like, okay, but this is the way we're going forward with this, and here's the consequence to your team. And for that, I try to be compassionate of like, Hey, I am really sorry about the consequences to your team. They're probably correct that this will suck for their team in some way.

And so then you want to appeal to shared values of like, 'Hey, I'm super sorry that this would suck for your team, but thank you so much for the service you're doing for the whole organization to get this working. Thank you for being willing to help us out in this way.' And I hope that that works.

Other challenges, sometimes, like I said, I like to scope down projects to the right level of stretch for the person who I'm delegating to. Sometimes there's just not a person to delegate to. And that's another challenge of, I'm scoping it down to some arbitrary point, and I don't know whose skill level I'm aiming for. Maybe there is no team that's ready to take this on. Like you and I worked on a project that didn't have a team assigned to it, and so then I'm just scoping it out without a sense of where my end goal is. And so that was definitely fun and challenging in its own way.

Heidi: Yeah, I can imagine that. Yeah, I just feel like there's always some guardrail, and at least knowing who is it that's going to take it on or whatnot, there's something that helps you focus it a little bit. Yeah, that's awesome.

We touched on a little bit that we talked about before you joined the company, how you wanted to define success, how I wanted to define success. Do you mind sharing that a little bit? How is it that you have defined success? It is a challenging thing because just I think coding ends up being a little bit more concrete to sort of point at things. But yeah, tell me a little bit about your process of defining success and what's worked and what hasn't worked so well.

Tina: Yeah, I'll be honest, this is one of the areas that I'm still figuring it out. It's definitely an active area of exploration. One of the challenges I've had is that I've been able to define certain success metrics, but there's no verifiable or falsification in it. At which point I'm like, well, this is what success looks like, but you'll never know if I get there, so just trust me, I'm there or I'm not there.

And that's very dissatisfying for you as my manager. And honestly, it's incredibly dissatisfying for me as a person, too, because I want to have some sort of verifiable markers of success. And so personally, the way that I'm working through it right now is trying to find verification mechanisms in narrower questions.

So, for instance, when I talk about our strategy, our technical strategy, this could be something along the lines of, we will build an LLM pipeline to be able to train on personalized data and give you personalized results. So that's the goal.

And then I can say, did I state that goal clearly? And so how do I verify that? I could say, well, do others incorporate this idea into their discussions and their designs?

If others are incorporating it into their designs, then okay, we've set our goal clearly, and if they're not, then they probably don't actually know what the goal is.

So that's one example of trying to say, okay, what is success? Success is having a clear goal. What is our verification mechanism? Well, we're going to look for a closed loop of others incorporating the goal that you've established into some work that you then get to observe.

Heidi: I love that. I love that. Yeah, I think you're right. I think you do have to break it down, and it is so much a role of influence that it is the same way that I think anybody would say, how can I measure my influence? It does end up being, does your thought process or your direction or your guidance that you've given people end up showing up in the work that they're accomplishing, and hopefully, eventually delivering the impact that you expect that it will as well.

But that is, it's harder to get those near-term signals along the way. So I love that you're breaking it down that way and thinking about how can I get feedback loop there?

Tina: I think the challenge that I've had is just exactly like you said, the near-term signal. So, as I feel like some of the goals or the definition of success I have get a little bit more vague, the minimal loop that I can get to verify has gotten longer. So let's put this into coding analogy. When you code the quickest loop for your coding is like, does it build?

And your IDE can sometimes tell you that within, before you've even noticed that you finished typing, right? And so that's a really nice tight feedback loop. Great. But if you're doing an end-to-end integration test, well, now you might have, if you're lucky, two minutes. If you're not lucky, like an hour's worth of testing to do. And so that's a longer feedback loop.

Now, once you start talking about is the goal for our 50-person organization clear? Well, I'm not going to get a design back that incorporates the goal within three seconds. I might not even get one back that month.

Heidi: Yep. Yeah, totally.

Tina: Humans are just better with small feedback loops, and that's one of the things I struggle with. How do I get this feedback loop as small as possible for things that are large and vague?

Heidi: Yeah, that's awesome. Well, I can't wait to hear. I feel like someday you'll be able to write a book about this as you discover what works and what doesn't. And I'm sure there are so many people— It's interesting. I have to say a lot of the things you're mentioning, I think people managers run into the same thing about how do I define success.

Tina: For sure.

Heidi: How do I get that adrenaline hit of, I did something and it worked. And I do remember when I first started coding, I was like, you can immediately build something and look at it and be like, I did that. And then all of the feedback loops become more indirect and longer to measure. So there's a lot of similarity there.

Tina: Yeah, definitely.

Heidi: Excellent. So let's see. Maybe moving on a little bit. So thinking about this sort of area tech lead, and honestly, you've actually had so many different interesting parts of different stacks that you've worked on over your career. Do you consider yourself a generalist? And maybe the sub question, do you feel like being a generalist is required for the kind of role you do? But sort of bonus question on that point, but do you consider yourself a generalist? And if so, how did you cultivate that?

Tina: Yeah, very much so. I am very much a generalist. Cultivating it? That's an interesting question. I think that a lot of things fascinate me, naturally. And so if anything, concentrating and staying with something for more than a couple months or years is the harder part for me.

I like hopping around and learning new things. When a problem comes close enough for you to see the level of detail of it, it starts to become fascinating to me. So that has been something that I really like doing is, I'm now nearer to a security organization, so I'm learning all sorts of security concepts I didn't use to know, which is like, oh, that's such a cool area that I was terrified of before.

Heidi: That's awesome.

Tina: So I think that part isn't too hard. I do tend to be a need-based learner, and what I mean by that is that if a job or somebody else isn't asking me to learn something, I don't tend to go and do it. I'll probably go and read my own personal books instead because I'll just do it. So I like to be exposed to a lot of different problems and then, by that exposure, drive into what I need to learn.

Heidi: I love that. I'm definitely not a hobbyist either. And I will say I took time off after Grammarly, and I tried to set myself up with some courses and things like that, and I really had trouble. I don't think I finished any of them. I finished one that was sort of pointless, but otherwise, I don't think I finished any. It's just really hard without feeling like there's a purpose in mind of a way that I'm going to apply it. It's really hard to just do it on my own.

Tina: Totally. One of my shames, and I'm sorry to my Coursera alumni for admitting this is that I have completed remarkably few Coursera courses considering that I get free courses as an alumni. So the barriers to entry are as low as they possibly could be, and I still don't do them.

Heidi: Yeah, I can hear that for sure. I think the myth of hobbyist programmers, I actually think there's fewer out there than people imagine. People who are like, Ooh, I can't wait to code my own thing on the weekend or go find some new technology for no reason except that I'm curious and just spend my weekend hours on that.

Tina: I mean, this was something that I really struggled with for a lot of my career, I guess you can call it. But when I would interview people, they'd be like, what are you doing on the side? I'm like, nothing. Forty hours a week, I thought, was enough.

But for a long time, I used to ask all of my mentors, how do I find my spark? How do I find my specialty? And this was the question I had for probably five years of my career. And I'll be honest, I never found it. I never found something that I wanted to do for the rest of my career. And it took me a long time to get comfortable with the idea that maybe it's okay not to have a specialty. I'm currently a generalist and very much enjoying that, and finding that this role suits me and that it actually has value in some organizations. Not all of them need this, but the ones that need it desperately need it. And so I'm coming to terms with the idea that maybe I'll never be an expert at one field, and maybe that's kind of cool.

Heidi: I love that. I feel like I am also a generalist, and I feel like the thing that is my spark is connecting dots between seemingly random things and having someone else have a light bulb go off that gives them idea of how to solve something in a new or different way. And so honestly, I feel like the spark for me is just amassing random information, for better or for worse.

Tina: Yeah. Someone told me the other day, they were like, Tina, I think of you as my system specialist. And I was like, okay, so you think of me as your generalist specialist. Cool, cool.

Heidi: Generalist specialist. That's a new job title. I believe it. I'm going to hire one of those, one of these days.

Tina: I think you should, if only because it'd be hilarious.

Heidi: Oh, so fantastic. Yes. New April Fool's Day job post, a generalist specialist. That's so awesome. Let's change tack a little bit, which is, can I ask you, what is the scariest or riskiest thing that you've ever done in your career, and how'd you get up the courage to do it?

Tina: Oh yeah. I think probably the scariest thing I ever did in my career was that I took an extended break after Toyota Research. I was kind of frustrated with the experience of being in a research organization. It wasn't exactly what I thought it would be like, and I very much learned, actually, that it wasn't for me.

I don't like green fields and pastures and open spaces. And the problem that I had was that I thought this was my dream job. I was so excited. I thought that I was finally going to get the professorial side of myself, which I had always envisioned as a physics professor, and I thought, but I can use my programming skills and apply them. And the team was amazing. And it was just this opportunity that, for me, I thought it checked all of the boxes. I was so excited.

And so it was kind of heartbreaking that I was so unhappy a couple years later. And so people were like, so are you going to look for the next job? And I kind of was like, I don't think I can look for the next job because I would pick this job again.

And so I decided to take a break to figure out why am I working? What is making me happy or unhappy in my job? Because the way that I'm making decisions right now is not correct. I would just make myself unhappy over and over and over again, and I needed to step away from the job and even step away from work for a while and just think about what do I personally value in life?

But it was terrifying because my parents were like, you're never going to get hired again. Don't do this. They grew up, or their careers progressed through the dotcom bust, and they saw people who were let go and didn't get jobs for another five years. And so my parents were like, don't do this. This is stupid. And I decided to do it anyway.

And I can say that taking that time was incredibly valuable for me, and I came back to Coursera with a much more intentional idea of what I wanted culturally from an organization, what I wanted personally from working, what I want to feel and accomplish and grow, and all of those things just honestly made me so much more grounded as an employee.

Heidi: Wow. Yeah. That's amazing. And was it a fairly structured plan of how you were going to answer these questions or was it a little organic? Do you have any resources to share for other people who might be soul-searching?

Tina: I did some structured things and some unstructured things. So I'll be honest, my break was longer than I intended. I was only going to take three months, and it ended up being a year because after three months, it felt like no time had passed at all.

But I did a couple different things. I'd have to look up the exact resource, but I used to be really into FIRE, like personal finance paths. And one of the things that they had there was this concept that when people finally do retire early, they tend to be a little unguided. And so several of the blogs that I had been following had life value exploration activities, and I did a couple of those, and that really helped me understand some of it, although not as particular to my field.

For instance, when I had to look at what kind of cultural environment did I want work, that was a different exercise than say, do I value family or traveling or hobbies?

Heidi: Yeah, I love that. I love that you were able to find some, even though they weren't exactly for what you were needing, it sounded like you found what you did need at the time. So that's really cool. Well, these have all been amazing insights so far, and I love it. Do you have a particular piece of advice that you would give to your younger self?

Tina: Oh, super interesting. I think, personally, a piece of advice that I'm giving to myself even now, but I would definitely give to my younger self is only listen to criticism from people whose advice you would take, people who you respect.

I, early on in my career, had some people who thought I should be operating quite differently, and it really took my self-esteem down a notch. But in hindsight, I look back and I'm like, why? I didn't respect them. I didn't think they were good engineers. I didn't want to be like them, so why would I take their criticism? And so this is something that I still try to remind myself as somebody is like, you should do this. I'm like, or not.

Heidi: That's fantastic. I love that. I feel like, especially if you can catch yourself in the moment, maybe, where you're even getting that feedback, I think it's always that first time you hear it, you're like, Ugh. And then I love that. That's just a great way to frame it, which is that you don't have to take all advice or criticism that comes your way.

Tina: Yeah. If you don't want to be like that person, why would you listen to their advice?

Heidi: Yeah, yeah. Totally. Totally. Are there some particular sort of books and articles that you would recommend or resources that you would recommend?

Tina: Sure. If you're interested in the engineering IC path, I personally found Will Larson's staff engineering book very helpful for me. I don't think that it lays out completely everything in clarity, but also at this level, you also won't get a hundred percent clarity. So I think it gives just enough structure to start having you ask the right questions of yourself to help you make decisions about your career. So that personally landed at a time, that was when I was asking the same thing of what does this even mean to be a more senior engineer? So I love that. If you don't mind, I also have a little bit more philosophical books. Is that okay?

Heidi: Go for it, please.

Tina: Okay. So one book that... I mentioned earlier, JR Jasperson, my architect lead, he recommended to me Sean Achor's book The Happiness Advantage, which was really interesting because it's about how positivity can shape your work and actually give you an advantage in your career pursuits as well. Not just talking about happiness in life, but how an optimistic outlook can affect the way that you approach problems and make decisions. And that was really helpful for me.

And one that's maybe even further out in the philosophy section, Bertrand Russell's In Praise of Idleness. I know it's an ironic thing to talk about in a career podcast, but he really looks into the idea of why do we work? What are we working for? What's the purpose of work? If you can do twice as much work in half the time, should you work twice as many hours or half as many hours?

Heidi: Wow, I love it. Oh my gosh, I'm going to have to go read that one. I haven't read that one, but I love that you called out Shawn Achor's book, The Happiness Advantage. I got to hear him speak when I was at Adobe, and it was a game-changer, and I am a naturally positive person. And so I felt both super validated that that is a useful and beneficial approach without being in sort of that Pollyanna mode where you don't realize the reality of what's actually happening, but that you actually can move things forward and have that sort of problem-solving mindset of there's got to be some way to solve this or move forward and whatnot.

And I definitely refer to his concept of learned helplessness and can spot it in organizations now and sort of think about like, aha, this is why we're not going anywhere, is because people have somehow learned that no matter what they do, they can't change the outcome. So that book really resonates with me.

Tina: See? Great book for both sides, because I'm a naturally pessimistic person, and like to nitpick all of the problems in everything.

Heidi: Maybe that's why you and I were a good pair.

Tina: We balance each other out.

Heidi: Totally. Totally. You got to have a partner in crime. So fantastic. Excellent. And I guess just a couple more quick questions. Who is someone that you look up to in the industry? You mentioned that you're not necessarily fangirling about famous people, but is there anyone that you look up to that you feel like would have an interesting career story for a future podcast?

Tina: I mean, if we want to talk about fangirling, I do fangirl a little bit on Tanya Reilly. I think her talk on being glue was very interesting and solidified some concepts that I had, so love that. But in terms of my personal relationships in my career, yeah, totally at Google, Andrew Lookingbill and Casey and Charles Mendez, Casey Ho, were great mentors to me.

I have to say from college, Elizabeth Reed was somebody who I very much admired at that time, and now it's amazing what she's done with her career. Grammarly, I very much respect some of the women that I've worked with there. So Tal is an excellent PM that I worked with, or Mariana's a great engineering linguist there. And Molly Hellman's been a fantastic ops coordinator and TPM coordinator, and so I very much admire them.

And at Coursera, Colleen Lee, my manager there, was just, if I could be, if there's one person that I just would want to be, it would be Colleen, personally.

And then at TRI, I super admired Alison Thaxton. You know how we talked a little bit about the myth of the engineer who does everything at home? She is totally that. She was so passionate about all of the robotics projects that she would do all the time, and she'd come into work, and it was just such a joy to see that passion.

Heidi: I love that. And maybe just one last thing. Any spotlights that you would like to share? Anything that you want to advertise or are you speaking anytime soon that we can come and hear more about your experiences?

Tina: Sure. So I'm actually going to be speaking at QCon in San Francisco this November, November 20th. I'll be on Joy Ebertz's track, who did an earlier podcast here, Principal Engineer and Beyond. So, giving a talk there, watch that if you'd like. And I guess at Grammarly, my company, and specifically my team, actually, is hiring for many different engineering roles. So tons of new stuff in the ML and AI space that we're starting up. So yeah.

Heidi: Amazing. Amazing. Well, double whammy for sure, to hear you and Joy together at QCon in November. Fantastic and highly recommend that folks apply and check out the open rolls at Grammarly. It's a great place to work, and you'd get a chance to work with Tina, which would be amazing. So awesome.

Well, I can't thank you enough for spending time with me. I feel like that just flew by. So many great topics and just really loved getting an insight into your role as an area tech lead and how you have defined success for yourself and the kinds of things that make you do a great job at it. So thank you so much for sharing everything today.

Tina: Oh, thanks so much for having me, and always a pleasure to talk to you, Heidi.

Heidi: Awesome. Take care.

Karen: Engineer Your Career is produced by WEST, a learning community that empowers women technologists through mentorship. Special thanks to our audio production team, Heidi Williams, Amanda Beaty, and yours truly, Karen Ko. If you enjoy our work, we encourage you to share this episode with a friend. Want to hear more from Engineer Your Career? Subscribe on your favorite podcasting app. We look forward to having you back for our next episode. Thanks for tuning in.