"Mastering the Art of Tech Leadership and Influence" (Video & Transcript)

"I really love investing in people. I found that the relationships that pay the most dividends are not when I improve a technical stack, make a service better, it's when I invest in a person and their skill and their abilities.” - Tina Wright

"it is sometimes harder to be an introvert and be a leader, but think about what are the actual difficult parts and what are you actually needing to get done, and is there a different way you can go about getting it done?" - Joy Ebertz

“[I try to] help teams be successful only when needed and otherwise kind of put those guardrails and things in place and empower teams to just to get things done and get out of their way.” - Vanessa Towers

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

Joy Ebertz is a Principal Software Engineer, prolific blogger, avid ultrarunner, and an advocate for increasing the number of women and minorities in Computer Science.

Vanessa Towers is a technical leader with 18+ years of experience as a software developer, architect, and engineering leader in various domains such as government, retail, healthcare, financial services, energy and technology. Vanessa is VP, North America Head of Technology at Thoughtworks.

Tessa Jones is a senior backend software engineer with 8 years of experience working at large and small companies across media, health tech, and fintech.

Transcript has been edited for clarity.

Tessa Jones: Thanks, everyone. We have a great panel discussion for you today. Regardless of where you are in your career journey, I think you'll find something relevant for you here. And if there are questions as we go, feel free to drop them in the Q and A section, and we'll get to them at the end. So, to start, can each of you share a little bit about yourselves and your journey to tech leadership? And I'll start with Tina.

Tina Wright: Great. Yeah, so I've been in the software industry for about 15 years now, the first 10 years as a generalist, backend, individual contributor. And then in the last sort of five years, transitioning to technical leadership, starting with being tech lead of a team of individuals, maybe about eight people. That team grew to almost 20 people towards the end. Then joining an architecture group where we oversaw some of the decisions across a broader organization. And then finally, now into my role where I'm an area tech lead for the enterprise area of approximately four teams, 30 engineers or so. So that's been my transition that I'm still actively making. Joy, do you want to go next?

Joy Ebertz: Sure. So I started out at Microsoft. I was there for a short time, and then I was at a very tiny startup. There were four people when I left. And from there I went to Box. I started at Box as a full-stack engineer, decided I really didn't like CSS, moved into backend. Then, at some point...was it before? I think it was before Heidi was my manager, but I went into management, and while she was my manager, I decided I hated management. So she helped me with the transition back out of management and into a staff role at that point. And then from there, I got promoted to senior staff, and then I moved over to Split. We don't technically have titles at Split, but I've been told I can use Principal as my public title. So effectively that's more or less what I am, but my role here is more or less looking at our backend engineering team as a whole and what sort of standards should we have, trying to make sure our architecture makes sense at a high level, and generally trying to steer people in a single direction, ideally single direction. Vanessa, do you want to go?

Vanessa Towers: Yeah, yeah. Thank you. Joy. I started my career as a software engineer back in Australia about 2007, and worked, I guess, as an IC for about five years, and a little bit of tech lead, a little bit of dabbling in the tech lead role. And then I relocated to the San Francisco Bay Area in 2012, and joined a consulting company, joined ThoughtWorks, a consulting company here in North America. And I've kind of grown up as a leader within ThoughtWorks since then. So I'm still with that company. And started off as a tech lead for different sort of client engagements, leading teams at the team level, and then leading multiple teams. And then over the years, progressed to leading accounts and leading engagements. And then from there progressed to leading multiple accounts and portfolios of accounts, and also dabbled a little bit…. At one point, I was what we call a modernization SME within one of our practices. So, also kind of spent a couple of years just narrowing my skillset a little bit around enterprise modernization, platform and cloud and cloud modernization. But in the last couple of years, I stepped into this role, which is North America Head of Technology. And so I'm a technical leader for about 400 techies, consultants here in North America. And mostly my role is to help define the global tech strategy for ThoughtWorks and then execute it. So come up with an execution plan for my region for North America. Yeah, happy to be here.

Tessa: Thanks so much. So we're going to talk about three main topics today: developing your tech leadership style, challenges and decision-making as a technical leader, and leading via effective communication. So jumping into that first one, your technical leadership style. I wanted to start by asking, Tina, you've mentioned the book Staff Engineer, it's called, and how it helps you think about leadership. Can you elaborate on how this book shaped your approach to defining your leadership style?

Tina: Yeah, I even brought a prop in case anybody wants. [Holds up a copy of Staff Engineer: Leadership beyond the management track by Will Larsen.]

Tessa: Amazing.

Tina: For me, this was really interesting because I wasn't really thinking about leadership intentionally or thinking about career paths at all. I was just sort of like, I'm doing my thing, it's good. And I got the opportunity to sort of step into leadership roles haphazardly. But because I hadn't been thinking about it, I didn't really think about what my path might look like. I thought it could just be, either I must be a specialist and have a security background and dive really deep into one thing, or I had to go into management, and neither of those really appealed to me.

So this book was really eye-opening for me because it showed different paradigms of leadership that didn't involve management and didn't involve heavy specialization into one expertise. And that really resonated with me. So I'm still discovering my journey, but the thing that it made me start thinking about was to think really intentionally about what skills do I want to be developing for myself?

What activities do I actually want to spend my time on? I looked at a calendar and said, oh, that's a calendar that I like, versus that's a calendar that I would hate to do. And thinking more about what energizes and drains people, because that, for me, was a way to find which path made the most sense for me personally, and which paths really were unappealing to me. So when we talk about my personal style, I really love investing in people.

I found that the relationships that pay the most dividends are not when I improve a technical stack, or make a service better, it's when I invest in a person and their skill and their abilities, and then that's a relationship that pays back dividends to me and also just energizes me as a whole. So that's kind of where this book helps me to start to coalesce my own thinking about what leadership means.

Tessa: Yeah, really interesting to hear how you can still derive fulfillment from those people skills as a technical leader. So Vanessa, you worked at companies of various sizes and in multiple sectors like government, retail, and healthcare. How have you found that your tech leadership style changes depending on the company type, if it does at all?

Vanessa: Yeah, I think, like Joy said, when we kicked off, titles and roles look different at all the different companies that we work for. And certainly, I have to navigate that as a consultant because I'm working with lots of different clients in lots of different environments all the time. So, because I'm a consultant, what that really means is I have to be flexible when it comes to my own technical leadership style, and I have to really understand my client's organization and be adaptive to their environment as much as possible.

So I try not to get too stuck on technical roles because it looks different across all our clients. So, for example, some of our clients fully embrace the tech lead role, while at other clients, this doesn't exist at all. And so you have to figure out how to navigate and be successful in those different kinds of environments.

At some of our startups or digital scale-up clients, they might be at a point in their company where they've not yet hired any architects. And so all technical roles at all levels are still very, very hands-on. And so you can't go into an environment like that and be a post-technical hand-wavy technical leader because you'll get shut down pretty quickly.

So you have to sort of acknowledge the environment that you're in and figure out what that setting needs and see if you are the right, and hopefully you're the right person for it. And sometimes you're not the right fit, and you also have to acknowledge that in consulting, as well.

So yeah, I would say my technical leadership style varies a lot. It depends. It mostly depends on engineering culture, and engineering culture is usually influenced by the size and the maturity of the organization, and sometimes the industry.

So in really highly-regulated industries like healthcare or banking and financial services, we often find that compliance and regulations introduce a huge amount of complexity and process into technical solutions and technical delivery. And so as a result, there's just a lot more process to navigate as it relates to making technical decisions and delivering software.

There's often a lot more structured technical governance models in place, like architecture review boards that you have to navigate. So those kind of things go with the territory, and you just have to figure out how to make it work in as frictionless a way as possible.

I would say that regardless of the industry I'm operating in, I just follow the same principles-based approach to technical leadership. So I really advocate for collaboration and co-creation of architecture and design as early in the process as possible.

Fast feedback loops, I really push for data-driven and objective technical decision-making, and also feel that it's really important to follow...I don't know if everyone on this call is familiar with what's called the architect elevator model, where no matter what level of the organization you're operating in as a technical leader, you want to remain connected to the engine room, you want to stay close to engineering teams, and really be a champion for engineering teams.

So I find that to be really, really important. And then the other thing I really try to do, and how I've managed to scale myself over the years and take on increasing responsibilities, is just to follow the principle of lead where they cannot and facilitate where they can.

So in other words, help teams be successful only when needed and otherwise kind of put those guardrails and things in place and empower teams to just to get things done and get out of their way. So that's been working so far. So yeah, that's a little bit about my approach to technical leadership.

Tessa: Awesome. Thank you, Vanessa. Joy, you've spoken about the importance of embracing your strengths when it comes to tech leadership, especially for those who consider themselves introverts. Could you share more about this in the context of your tech leadership style?

Joy: Yeah, so I guess for me, early career, and for most people, I see there tends to be this idea of you need to be good at everything. And honestly, early career, you kind of do need to be improving on everything across the board. But at some point, I realized that I don't necessarily have to be amazing at every single possible skill. What I need to be able to do is get the problems at hand solved or find a way to do the things that need doing.

And, for example, I'm not always the best at thinking on my feet. This tends to be an introvert skill. We need time to think on our own before we come up with lots of ideas and questions. And so in that meeting, I might not ask any questions, but then how can I come back later and use my strengths to ask all of those questions that I had?

Or maybe I just should start asking for pre-reads in certain meetings, or kind of figure out how I can start thinking about things ahead of time. Similarly, one thing I'm known for by some people, at least, is that I write a blog on Medium, and that was part of this too. I realized I was actually very good at writing and like I mentioned before, not necessarily as good at speaking off the top of my head, off the cuff, but if I can take the time to then write and get my thoughts out and then present that back out, oftentimes it's a little bit easier for me, and I am still getting the points across. I'm still communicating with people. So the same goal is getting accomplished.

So in general, I would encourage you, it is sometimes harder to be an introvert and be a leader, but think about what are the actual difficult parts and what are you actually needing to get done, and is there a different way you can go about getting it done?

Tessa: Yeah, that's great. Okay, we're going to pivot to tackling decision-making challenges as a technical leader. So Vanessa, what's your approach to technical decision-making? Who makes the final call in these situations, and what's your role in the process? Maybe you have an example of a technical decision you could share to help illustrate.

Vanessa: Yeah, absolutely. Okay. There's a few questions there. I'll try to break them down.

So who makes the technical decisions, and what's your role? I think that what I've learned is that if you try to be the sole decision-maker and override your team on decisions, at the end of the day, it just creates resentment and sort of disempowers teams. And so as much as possible, like I was saying before, you want to empower teams. You want to get out of their way. You want to let the team own decisions as much as they're capable, as much as they can. And sometimes that means letting them fail safely.

And it also means being comfortable. I'm a bit of a perfectionist, but a challenge for me has been being comfortable with good enough and letting teams fail. That can be really, really hard, but that's sort of part of it, but you really need to do that to get the buy-in, because the problem is if you just override your team, they might be nodding at you, but they're not really going along with you.

And when things get tough, you'll pay the price down the road. So typically, that's how I think about, what's my role? I might be a tiebreaker when needed, but other than that, try to get out of the way as much as possible and facilitate those kinds of conversations with teams and whatnot.

Earlier, I mentioned that part of my technical leadership style is advocating for data-driven and objective technical decision-making. So I can share a story. I have lots of stories. I can share one story around that. For example, a recent one, where we had a client architect we were working with who had gone off and developed a really cool and really complicated in-house technical framework for GraphQL, and we were working on a project with this client architect.

And so what we found is they invested so much of their time into it, this client architect was really, really adamant about using their homegrown framework as part of a solution for what we were doing, a big application modernization program. So if you step back and look at that, it was sort of a situation where this framework was basically a solution looking for a problem. How do we jam this thing in and make it work?

And so, part of the reason I've stayed at ThoughtWorks is we're tech-agnostic when it comes to technical decision-making. So rather than just go with the client's sort of default homegrown framework in this kind of setting, we try to follow a process that will help drive that tech-agnostic methodology. So we'll typically do a build or buy exercise and do a bunch of technical spikes and then had to come back to the stakeholders and say, well, this is where that framework sat against all these other candidate frameworks and solutions.

And in this case, by doing that kind of data-driven and objective approach, we were actually able to get that architect to accept, over time—It did take a couple of weeks— but accept over time that their framework just wasn't fit for purpose.

So I hope that what you might take away from that is sometimes taking that data-driven approach can just kind of help take the emotion out of it. And as long as you can stay objective and you've got facts and data, and of course, you don't want to spend too much effort on it, you don't want to spend all your energy doing that whole thing, but you need to timebox it, you need to. But coming back with data and pros and cons and trade-offs has always been a really good way of moving things forward.

Tessa: Thanks for that. Joy, what about you and your technical decision-making approach? In particular, I'm wondering about your favorite tactic for overcoming objections or reaching consensus on competing ideas.

Joy: So I have a couple of thoughts. The first one is kind of related to the writing I was talking about before. There was a particular project I was working on with a couple of coworkers. We got along super well. It was a great group of people, but it was a technically complex problem. And we came up with a solution. We were like, oh, this is great. And then the next day, one of us was like, oh, but what about this edge case?

And so then we rethought the whole thing and we came up with a solution. This is great. And then the next day, there was another edge case, and I realized at some point we were literally going in circles. We were going back and forth between probably three possible solutions. And it was just this like, oh, but what about this thing? Oh, but what about this thing?

And eventually I realized we just needed to, what Vanessa was saying, write down the pros and cons of each one and really list out and document, okay, these are all of the things that make this great and these are all the things that make it bad and this is why we're picking this one out of all of them. And it helped us both see all of the problems at once on a single page, but then also the next time one of us was like, oh, but what about this thing, we could point back and be like, we already thought about it and this is why we don't care about that thing or why it's not as important as the other thing. So, really just getting it down on paper was incredibly helpful to gaining consensus and allowing us to move forward. So that's one thought.

The other one is more about, I guess, how I currently often approach things. And it's sort of, I guess, a little bit nuanced in terms of, first of all, I want to make sure I'm gaining opinions across the board. As one of you mentioned before, bringing down decisions from on high rarely works out well.

So you kind of need to understand what people are thinking and try to bring in those opinions, and then maybe help guide things. If you really think there's a single correct answer, then maybe try to help shepherd things in that direction. Or if you don't, then trying to figure out what the largest consensus already is, and how do you make sure, at least, things are aligned, even if it's not maybe what you would've picked on your own. But people are headed in the same direction.

And to that extent, there are a few things I always do. I almost never answer a question myself first, because I find that some, at least with my current coworkers and various groups, if a senior person comes in and says, I think X, then sometimes more junior people are too shy to be like, oh, but I really think Y is the right answer. So that's one thing.

And then I've sort of alluded to this, but just being aware of your coworkers and their personalities and their backgrounds can be really important. For example, we have over half of our engineering team in Argentina, and so English is not their first language, and I know some of them are less comfortable speaking up in meetings because of the English aspect. Regardless of extrovert, introvert, just the English aspect makes 'em a little nervous. So sometimes it's a matter of finding ways to back-channel with those people, talk to them on the side, ask them in chat so they have time to think about it.

Or even the pre-read, like I mentioned before, that helps introverts too, giving them something to look at ahead of time so they can be thinking about it or even ask questions on the document, and then maybe you meet together to discuss a little more, but at least it allows them to get their opinions in some other way.

And then to the point of culture, again, some cultures tend to be, or at least our US folks tend to be a little bit more combative, and like no, that's wrong because of whatever. Whereas the Argentina folks tend to be a little bit more like, go with the flow, make everybody happy sort of a thing. So sometimes it's also calling them out or bringing aside the people you think really have a strong opinion or thoughts on a particular subject and trying to make sure that they voice those, even if they might not naturally do it. Yeah.

Tessa: Great. Thanks. Tina, I'd love to hear a bit about your approach to technical decision-making and specifically how you deal with ambiguity in your leadership roles.

Tina: Yeah, ambiguity is my pet topic right now. It's the area that I'm personally working on developing, so it's super fun for me, and I mean that in a somewhat sarcastic way because I'm a really precise person that likes schedule and boxes. And so ambiguity is the most uncomfortable thing for me, and it makes my skin crawl.

And so that's something that I need to actively push against because it's actually healthy sometimes to have ambiguity. And so, lately I've been asking the question, when somebody wants me to make a decision, and I desperately want to make a decision, I ask, actually, should there be ambiguity at this time? Is this appropriate time for ambiguity to exist? And if so, then instead of making a decision now, which is probably premature and going to be the wrong decision, instead we're going to make clarity in the form of how and when will we resolve this ambiguity.

So it's not, “Right now, I need a decision,” it's, “When will I need a decision and how will I get to having a better decision at that point?” So this gives enough clarity to others to know that it's being taken care of, but still make space for discovery of new information because you're not quite ready to resolve that ambiguity. That's something that I've been practicing currently, and it's been so hard, and I have to say it is skin-crawling and terrible, but also so necessary as you start moving into spaces where a snap decision could mean months of wasted work.

Tessa: Alright, so now a question that each of you can answer, and this is related to challenges with technical decision-making. So we've all had to work with difficult personalities or people with whom we often disagree. How do you approach working with these individuals? And I'll start with Joy.

Joy: So I have kind of a funny story here in that I have a coworker who was just totally rubbing me the wrong way. We were not quite butting heads, but every time I interacted with him, I was like, oh, this is terrible. What the heck?

And then we had an offsite, a full engineering offsite, and I went for a run with him. And then afterwards, I was like, every time I interacted with him, it was just this little bit of like, okay, but I know he doesn't actually mean it to come off that way. I am sure it's just the language barrier or something. I know he's a cool guy, so sometimes it's just a matter of forcing yourself to get to know someone.

There's another coworker I work with who, when I interviewed him, I was like, oh, no way. This guy's going to be terrible, but he's actually one of my favorite people to work with now.

So it sometimes really is just getting past that initial gut response and forcing yourself to get to know somebody. The one thing I would say, though, is, or I make sure to do, is to keep an eye out for, is it just me being impacted by this, or is it a bunch of people? And if it's other people as well, then oftentimes, I will make sure to escalate to their manager or to somebody in a management role who can do something about it, and basically be like, look, this is the pattern of behavior I'm seeing. This is what's happening. As a result of that, we need to find a way to make this better.

Tessa: Tina, how about you?

Tina: Yeah, first, that's a really great point, Joy. Thinking back to some of my own conflicts and remembering, I will deal with a lot of interpersonal conflict on my own behalf, but the instant it hits my team, I'm escalating that so fast, because I will not put up with it on behalf of the people that I care about and value. So, really a great point there.

I also really like to push into one-on-ones, learning idiosyncrasies, but that can be hard, and sometimes it's not even enough. I would say other tactics that I work, is driving discussions towards facts, things that you can ultimately agree upon, and then moving forward from that. So state the implicit assumptions, you believe this or you believe that, and get down to what are the baseline pieces, because then you can have a discussion on the decision itself and not on the personality traits of the people.

And a last thing I'll say is, when you're doing these one-on-ones to learn this person's idiosyncrasies, the other thing you really want to do is try to boil it down to what are your shared values, principles, goals, what do you have in common? Because that's the pieces, the bedrock that you can then move forward with. If you have no commonality, you're just not going to move forward. That's just the reality. But presumably, you're at the same company, you have some shared interests, you should be able to find something

Tessa: Great. For time's sake, I'm going to move along to the next question. Vanessa, if you want to fill anything in there, feel free. But I'm going to start by asking you about communication strategy. So that's the last bigger topic we wanted to cover today. So how, as a technical leader, you bring people along with you in driving a solution? Yeah. So the question for you, Vanessa, is what are some strategies you use to come to a solution?

Vanessa: To do that? Yeah, okay, let me think. So I think it really builds and extends upon some of the things we've already been talking about, but I think step one is about establishing that technical vision and sometimes even a team charter. Why does this team exist? Why do we have a platform team? What problem are we trying to solve? What's our hypothesis? What are the outcomes we're trying to drive to? What are the constraints? Cost is often a big constraint, as an example.

And then what are these shared principles that we have that's going to help us collectively solution? So that's always kind of step one. As a leader, I think you need to drive that and you need to pave the way there for your teams.

Then it's about using different ways of communicating. So what is a technical vision? Maybe it's like C4 diagrams, maybe it's a mural, right? It's going to look different. There's going to be different artifacts. They're going to be at different zoom levels. They're going to be for different audiences. But again, you have to drive that and figure out what's needed and figure out how to speak the right language and at the right level to different audiences.

If you're trying to get buy-in from the business organization, that's going to be a different conversation than if you're trying to make a business case versus influence the technologists. That's a very different conversation. So understanding your audience and overcommunicating, and being thoughtful about the different communication methods, is really important.

I think I've already sort of shared this, but I want to make it really, really clear when I was talking about my principles-based approach to technical leadership, the reason it's important is, as a technical leader, you don't want to sort of help put forward solutions that seem random to the team. You want the team to be able to reverse-engineer how you got there, based on those principles. And when you can do that, when you show everyone what are the principles that are guiding you to some of the things that you are suggesting, that's where you can get everyone collectively solutioning with you.

Now you're all working with those shared principles, and you're kind of making the team autonomous and helping them be a part of the solutioning process. So that's really, really critical. And then generally, in terms of there's usually, again, the level of process and the level of artifacts and things in the mix is going to change, is going to look really different depending on whether, as I was saying before, it's a startup or an enterprise traditional company, what scale, and whatnot.

But at the end of the day, there's usually some sort of artifact that helps you communicate a candidate solution. Maybe it's a RFC, like a request for comments document in a scale-up setting. Maybe it's a more formal design doc in a more traditional environment. So you need something like that.

And then something that I've also found to be really, really useful is architecture decision records. So once you've gone through those candidate solutions, you've come out the other end, you all made a decision. Capture that. Capture that in writing, capture the forces at play, the things that were looked at, and make sure the team...in terms of consensus, you really need everyone to sort of commit. And even if it means disagree and commit, but you need everyone to be like, yep, we're all going to move forward together with this solution. We worked through it together, we came out the other end.

So that's, at a really high level, some of the key things that I tend to follow in terms of communication strategies for bringing people along and working through solutioning and coming out the other end with a decision.

Tessa: Awesome. I love that principles-first reasoning, because it also has a side benefit of growing the team and helping everybody just improve as an engineer, too. So, Tina, I'd love to hear about communication strategies you use, and specifically, what tactics would you use if you feel like your voice isn't being heard?

Tina: Yeah, so this is actually something I don't struggle with that much anymore. Joy said she's an introvert. I'm an extrovert, I'm loud, I interrupt. Anyone who's worked with me probably knows that I actually work on the opposite side of that right now, which is not interrupting people's voices, but I do find that sometimes people still don't listen, or they don't change or come my way.

And in that case, I frequently have found that it's often because they have a real constraint or they have a fear that's preventing them. And so can you get to the root of that fear? Is it that they don't have time, that they're worried that this won't work out, that they have prior experience saying this is a bad idea, and how can you identify that and then relieve that, right? So that for me is about feeling your voice isn't heard. If you're a little bit more soft-spoken, maybe ask somebody else, perhaps.

In terms of communication strategies or around decisions, I often walk into a room and I assume that I'm the least informed person there and that my job is not to make the decision. My job is to moderate the decision, and if it doesn't come to a conclusion, then I'll make it. But how can we make sure that the people who are the closest to the problems are the ones who are making the decision?

Because, like Joy said earlier, then they'll feel ownership of it. Like Vanessa said earlier, then they'll understand why it was made. And the one thing I'll add to that is in the transparency of why it's made, I really like to emphasize when can you challenge a decision and reopen it, because that's a piece that can be really freeing. If a decision feels final, then it feels very constrained and hard, but you don't want to be remaking the same decisions over and over and over again.

So I have a framework for that, which is, if your goals, your constraints, and your assumptions haven't changed, then neither has your decision. But if you can tell me that one of those previous things changes, great, let's reopen it.

Tessa: That's a great framework. Joy, you shared that it can take longer for women to gain credibility in leadership positions, and effective communication and visibility can help combat that. What are strategies that you've used to overcome these challenges?

Joy: Yeah, a few things. So I guess first of all, one thing I'm always aware of is that...it matters less internally, because you get to know people, but maybe at a large company or for me, externally at other companies, the title actually matters quite a bit. If I come in with just a software engineer title, people are going to be like, oh, how many years experience does she have? Does she really know what she's talking about, whatever.

But if I come in with the principal engineer title, they're usually like, okay, she probably has some idea of what she's talking about. She got to at least that level. Even if they underestimate me, it is still going to be much higher than if I came in with that lower title level.

So that's part of why, despite the fact we don't have titles at my current company, I specifically asked my manager and was like, what title can I use externally?

If I'm giving a talk, what can I say my title is, so that people take me seriously initially? And he didn't just give me some overblown title just for this purpose. It was definitely a discussion of, I think this makes sense. And so I do feel like that is more or less the title I should have, but it's this nice way of expressing that to other people in a very succinct small way.

Along with that, I sort of alluded to this, but...so I started writing a blog. The first one was actually about why I left management, and it got this weird viral pickup, which I was kind of shocked by at the time. But because of that, I sort of kept working on that. And every time I get an opportunity to speak, and I try to write somewhat regularly, although I've fallen off recently, I should get back on that.

But every time I get an opportunity to speak, I usually try to take it as a way to, again, get this visibility, get myself out there, and it's a little scary. I'm not going to lie. I've gotten a lot more comfortable with it, but it's this way of forcing my way to be there.

The other thing I would say is that, or kind of a double thing, is that leadership doesn't always look the same in everyone. And to what I was saying before, know your strengths, know how to use them. For me, it's the blog, it's the speaking, those are things I'm good at. But if those are not things you're good at, if those are things you hate, you obviously don't need to do it that way. But be aware of those and try to emphasize the things that are going to help you get out there.

And the other thing related to that, is that I had a conversation with my manager at some point where he made some comment kind of off the cuff about, oh, I realized the other day that leadership doesn't have to be the same for everyone, basically what I just said. But it was this sort of realization to me that sometimes you need to teach your manager that too, just sort of line up the dots of, I may not look like your typical leader, but this is how I'm accomplishing the same things. This is how I'm being effective, even if I'm not stereotypical, this is how the work's getting done. So being not afraid to do that can also be very powerful.

Tessa: Thank you for that. So we're nearing the end. We have a couple more questions and then Q and A. So the first question, and I'll just ask you to answer this in the chat while the other panelists are speaking, is all of you are busy with your day-to-day demands of tech leadership. But how do you stay informed about emerging technologies and trends, and do you have any specific resources you could share just by dropping them in the chat that others can maybe use to stay on top of emerging tech? And then the question I'll ask you to answer out loud is, what's one key takeaway you would like for the audience to remember from this discussion? And I'll start with Tina.

Tina: Okay. I won't drop in the chat just yet, then. So I think one of the things that I've been learning for myself, we talked about ambiguity and working through that, I'm working on the concept that leadership is actually, in part, or in large part, about making clarity for yourself and for others.

So I think the piece of advice that I'd give you if you want to practice leadership is, don't just take what we say and go with it. Don't over-index on your company's lovely rubric or the staff eng book or what we are saying today. Take all of those as inputs to inform you, and then practice for yourself what it means to create your own leadership philosophy. Take the pieces that resonate with you and see if you can construct your own set of beliefs and systems that then you'll adhere to.

So this goes back to all the things we've been saying, right? The thing that you create yourself is the thing you believe the most, right? It's a practice for your own self to work in ambiguity and make clarity from things. It's a practice and listening to others' expertise where you don't have it yet yourself. So highly recommend doing that for your....

Tessa: Vanessa. One key takeaway.

Vanessa: Yeah, one key takeaway, and I was multitasking. I was just putting in the chat as well, the recommended. Thanks. Okay. Yeah. So one key takeaway, well, I hope it's that tech leadership looks different.

You've heard different perspectives from all of us today that have joined today's panel. In a nutshell, my approach to tech leadership is really, do what's needed. And so don't be too narrow or specific in your definition of what tech leadership is. And I think that that can really take you places, generally speaking.

And then if you're interested in really doing tech leadership at scale, so progressing from teams to programs to organization and whatnot, then fully embrace putting in the necessary constructs and guardrails to scale yourself, because they're actually necessary for you to do that. Do technical leadership at scale.

So things like really clear roles and responsibilities, having paved roads for engineering, really clear tech strategy and vision, and having the right level of technical and architecture governance, the right level that makes sense for your organization, is really critical to scaling tech leadership over time.

Tessa: Yeah, thank you. And Joy, one key takeaway you'd like people to take.

Joy: Yeah, I think I've said this enough times that hopefully it's obvious that I'm going to say, get to know your strengths and weaknesses, and really have an eye on that. And along with that, knowing what problems need to be solved at any given time, and kind of think about how your strengths can play best into solving them. And if they don't, then maybe looking for a coworker who balances you out. Well, I have one who's much more of a perfectionist than I am, much more extroverted than I am, and it's a good way to sometimes lean on him. I would say make sure they don't become a crutch, but kind of find the coworkers who can help in the areas that you're weaker in, and then you can, together, hopefully be better.

Tessa: Great. So we have some questions in the Q and A section, and I'll just read through some of these, and some of them are kind of linked in interesting ways. So if we don't get to all, hopefully your question is somewhat covered by an earlier one, but the first one would be, what are some tips you all have for navigating an interest and desire to expand influence as an IC without much support for doing so? And if anybody has some thoughts on that, feel free to jump in. So, tips for if you want to expand your influence, but you're not really feeling a lot of support, I assume, from your manager.

Tina: Sure. I can jump in on this. I like to take this from the perspective of, what skill am I looking to grow? So, for instance, let's say as a technical leader, I think that eventually I want to be making presentations in front of the entire company or in front of the entire world through an external event.

Well, what skills do I need for that? I need to be better at presenting my thoughts. I need to be clearer in my articulation, things like this. So then I take that and I scope it down to what opportunities are nearby in my own organization. This might be something like, let me give a demo in a team meeting, or let me run that team meeting, or maybe I'll create my own slot and share this thing.

So trying to find that opportunity nearby where you are, that's enough of a stretch that it'll grow your skill, but enough of an adjacency so that it's kind of undisputable that it's okay for you to do that. And if you're not finding that opportunity or somebody is quashing you down, making it explicit and saying, Hey, I'm doing this because I want to learn how to present better. Could you give me opportunities to present better, or at least not stop me when I take that opportunity?

Joy: To build on that, gaining visibility can be really important because if you're the one giving the demo, if you're the one always talking about something, people are going to start coming to you with questions, and then they'll start listening to you, and you're kind of gaining that street cred basically, so that when you do have a thought, and you do want to push something, they'll be more likely to listen to you rather than, who is this person that came out of left field and is trying to tell me to do something? So yeah, finding ways to get visibility is important.

Tessa: The next question is kind of tied to this. So, specifically, how do you spot those high-profile projects and growth opportunities? And this person's wondering, specifically in a situation where your direct supervisor tends to handle tasks personally and prefers that you primarily collaborate within your own team. So spotting those high-profile projects, and I guess, yeah, making sure that they are...Vanessa, you brought up where something was engineered for an engineering reason, not because there was a true need for it. So, how do you spot those projects that are actually needed and are high-profile?

Vanessa: Well, I think general advice here is invest in your network. Always invest in your network and building your network. So say, within ThoughtWorks where I work, there's lots of engineers that I lead that could be successful in different parts of the organization, so as a leader, we want to encourage 'em to find their career path, and I certainly never block engineers if they want to move into something different, but a big part of how they get those opportunities is they're making those connections proactively.

They're staying informed and building up their network so that the opportunities come their way. So I know we don't have much time, so I won't go too much beyond that, but networking is super, super important if you want opportunities to come your way.

Tessa: And okay, another question that is here is, what if you feel like you're the best one to lead in this situation, but there are people who are more senior than you on your team? Is it fair to expect that leadership will recognize that? Or how do you go and seize that opportunity? Joy, any thoughts for this one?

Joy: I would say, I personally, maybe I'm lucky where I've worked, but I personally have sort of philosophy of don't be afraid to ask for what you want. The worst that's going to happen is they're going to tell you no. So possibly even trying to work with the more senior person being like, look, I really want this growth opportunity, and I think I would be great because of X, Y, Z reasons. Can you help support me in allowing me to do that, or something like that.

And as a more senior person, often they should be delegating more than they probably are. And so having somebody come to them, and especially if the person is, help me lead this. I want to do it, but support me in the back a little bit if you can, that's a great opportunity for them as well. So it's not necessarily like you're taking something from them, and be aware of that, and don't be afraid to ask.

Tina: Yeah, if I can hop on, this is an opportunity for them, too, to grow in their own way of getting you into that position. And so maybe you can say, oh, could they reverse shadow me? Or things like that. Think about it from the perspective of the senior person and the leadership. You can say, I'm ready for this next growth step and this will take the load off of you, or things like that.

Tessa: Great. Thank you all so much for your insights here. I've learned a lot during this. I hope everyone found it valuable, and I'm going to open up the survey and see you in the next sessions. Thank you again so much.