Video details

You Don't Have to Be a Manager

Career
08.18.2022
English

Presented by Women Who Code Mobile Tech Summit Playlist link: https://youtube.com/playlist?list=PLVcEZG2JPVhf_iA733UhMxPS0H8iCoouj Speaker: Stacy Devino, Senior Principal Engineer @ Stitch Fix
You are a fabulous Senior Engineer and you love what you do, but you feel stagnated. We have all heard it before: “Why don’t you become a manager?” Moving up the corporate ladder doesn’t mean that you have to move out of a technical role. Advancing past “senior engineer” doesn't lead you to a crossroads — but to finding yourself in the middle of possibilities. There are many roles in tech that are still “technical” available, and this session will go over some of those options and what is involved in those roles. You will also hear the speaker's first-hand experience of how you can make those roles your own and how they can differ significantly from one employer to the next.
💻 WWCode Digital Events: https://www.womenwhocode.com/events 🔎 Job Board: https://www.womenwhocode.com/jobs​​​​ 💌 Make a Donation: https://www.womenwhocode.com/donate

Transcript

Hello, Sierra. How's it going? Great. I'm so excited to be introducing you today and that you're joining us. For those that don't know her, Stacey Devenault is a multifaceted international speaker noted for her her work in diversity, advocacy, tech, democracy, real talk, personal and technical development, and as a keynote speaker, which we are so grateful that she's joining us here today, as she's been an Android developer for over a decade and has worked on nearly every aspect of the ecosystem. Currently specializing in rich, engaging media experiences for customers at Stitch Fix, where she's a Senior Principal Engineer, her work has been featured on sites like Wired, Gizmodo and Geek.com. In addition to being mentioned directly in published books, stacey is an Intel Innovator GDG Organizer women Who Code Evangelist, women Techmakers Ambassador, former Women Techmakers North America mentor, former Google Developer Expert for Android, and former Google Developer Group mentor. I'm so excited to be hosting Stacy today as our opening keynote, where you don't have to be a manager. Well, that was a lot. I didn't realize you're going to read the whole thing. Oh my God. I want everyone to know there are. Like five or six other things I knocked off of there. Like, I'm just, like, going, this reads really terribly. Like, who is this braggart person? But also, just like I think it also goes into a little bit of that imposter syndrome, like, qualify yourself before you get in the room kind of thing. But here today, I am so excited to tell you why you don't have to be a manager. And why might this be a thing? Well, I'm pretty sure that, like, you all I have heard this over and over again. If you want to move up in your career, you have to become a manager. And it's usually from a bad manager. What they're really talking about is that you need to become a, quote, people manager. And that's not necessarily the case. Right. There are so many things available to you that it's not about giving up. It's about deciding what you love most. And I really want you all to key in on some of the color changes here. It's about not giving up what you love, weighing what you really care about, versus something that it's fine. Right. Everything, when it comes to life is about decision making. And decision making is very rarely a pure yes or no answer. It's all about weighing the options. So I want to start with the tech path specializations. These are the things that you're probably the most familiar with from the path that you're kind of currently on from a Senior Engineer perspective. Right. So where can you go from being a Senior Engineer? First we'll go through Staff Engineer, then Principal Engineer, distinguished Engineer, and I'm not going to touch on the last one in there called a Fellow, only because it's practically mythical and it is God tier. So I don't know how you get there because I know only a handful and it seems very much like circumstances and luck play into capability as well. And I kind of grayed out some other ones that we're going to go over a little further on in this presentation. But let's just start with what is a staff or a lead Engineer. This is a group or feature leader that makes platform level decisions. And I'm also going to preface that I have a bunch of different categories that are ranked kind of like one to five, one being the least, five being the most, and it's all done with emojis. So in terms of meeting and pairing, you're going to have more pairing and more planning meetings than you did when you were a Senior Engineer. Yeah, to be expected, right? You're going to be spending a lot more time individually working with folks technical skills. So whereas a Senior Engineer is kind of a three out of five, staff or lead Engineer is a four out of five, you are considered a domain expert in your given platform in terms of coding time code is spent in time teaching others and doing core deliverables. So when it comes to the things that everybody in your platform is specifically using, especially around that feature or that group, that's what you're organizing and very often kind of putting together the kind of core pieces for everyone else to jump into. Terms of leadership, you're starting to technically oversee others and working with product to develop timelines. So this means that you're making sure you're the point person when it comes to PRS. Right. It's important that you're paying attention to the quality of work and how people are actually putting things together so that you can make sure that it lines up with what the expectations are. Terms of responsibility first to jump on emergency issues in your domain and primary contact for your domain. Terms of documentation. Doing the work no longer matters as much unless you document the why, the how, and the result. You are not just implementing, you are planning and strategizing in terms of the drunk drawer you have to go through and do things like monitoring crash logs and kind of those unsexy development tasks, including especially bug tasks, especially the really nasty ones, and oftentimes bring in more meetings and pairing around those so that you can help scale up other people. In terms of soft skills, you're starting to do more presentation internally and externally. And as kind of an internal leader, it's really important that you start developing some of those positive communication skills that help unite your group yourself with the alignment of the company. All right, now we're into Principal Engineer territory. So I'm a senior Principal, so this is an area I have a lot of current experience in, but I've had this position kind of before as well. But it's really a platform leader that makes the architecture decisions in their domain and starts to touch in on other domains. So that means that you might be doing I'll throw an example, android and API, not just necessarily in defining schema, but defining kind of standardization and other things might be touching into your platform, but are not part of your platform inherently in terms of meeting and pairing more planning meetings, you're working with other leaders. You're setting tech direction across multiple individual areas. Technical skills. You are a domain expert now with the knowledge of system architecture. And very often you have had to learn other types of coding in order to do this and be effective in multiple areas. As an example, I've had to learn some more Ruby and ReactJS and some Golang and a bunch of other things related to server systems and sometimes just a little bit of brush up coding time. Here's where the hit is. So you've skilled up in meeting and pairing technical skills, but your coding time is less because really you're just focusing in on core deliverables and organization of coding and really kind of some of these other areas around leadership. You are the symbolic leader for your entire platform. Internally, externally, all of those things. You have high levels of responsibility because it's your platform, your architecture, your people, your teams, because you're very often leading teams that have their own lead engineer or staff engineer that are working on a specific feature capability, and you have to organize that documentation. Oh my gosh, diagramming systems. And you are ultimately the one who is responsible for your entire platform, which means you better have some documentation to back up some of your decisions, as well as honestly making it easy for people to onboard. How good the onboarding experience is into your given platform falls on you as a principal engineer. Part of that documentation. In terms of the junk drawer, there's kind of a little bit more than staff, but you're really managing different systems than kind of bug fixes because you're really doing kind of backup resiliency. You're looking at how well are Endpoints actually performing right now? Oh, identify this, move back through messaging, CI, CD systems, how do I optimize builds, how do we make testing work better. In terms of soft skills, you're the representative of your platform internal and to senior leadership. And senior leadership might just be kind of more the Director of VP level, maybe not in the C suite, but you are that liaison for everything that's going on in your given area. All right, this is the high level one, right? So distinguished engineer, software architect, responsible for setting the direction of engineering as a whole, and architecting shared systems. So you might have a particular domain that you're in charge of, but you ultimately are also setting direction for all of engineering, and you have to do so in a group and understanding how everything else really works in terms of meeting and pairing. Pretty darn high. Right. Because you're working with other tech leaders to set tech direction. Technical skills. We haven't necessarily leveled up in terms of technical capability from the principal level because it really is not necessarily about that. You might build up in terms of architecture skills, but it's not that your technical skill overall is significantly higher in terms of coding time. Yes, it's lower because you are taking on a lot of leadership tasks. You are the technical leader for your entire discipline to the senior company leadership. You have high level of responsibility because you might have several principal engineers underneath you managing their platform. So now you're not just managing a platform, you're managing multiple doing multiple architectures. Managing multiple people in terms of technical actual deliverables and ultimate accountability for all of them falls on you in terms of an engineering capacity. Documentation. Oh my gosh, such high documentation because your decisions are setting the direction of everyone else. That has to be very explicitly documented in a very concise way so that people can actually enact what your vision is. If you don't have documentation, you don't have a vision in terms of the junk drawer, you get the flaming junk drawer. Tech debt is your job to identify and fix across edge and balance that tech debt in terms of prioritization and really kind of instead of implementing CICD systems, actually developing CICD systems, soft skills, I'm giving this like kind of four teddy bears and an actual bear because you are the representative, basically of engineering to the whole C suite for your entire area. Right. So it's not unusual for you to have meetings with the CTO, or at least especially at a group level. All right. Tech domain, specializations, these are things that are open but maybe aren't obvious. There are so many areas that you can go into from a senior engineering background where that is extremely valuable and gets you a premium. What? Somebody said money. Said money. I swear somebody said money. It's true, right? So you having technical skills, especially wanting to look at some of these areas, brings a much higher set of desirable traits for some of these areas. So with that, let's start with the technical product manager. This is a product manager with strong tech skills to manage technical aspects of a product and engineering teams. And that means you're going to have more meetings in pairing. Your job is people, product management and timelines. So in terms of technical skills, where you may have been kind of like a three as a senior engineer, you're actually maybe going down a little bit because you're not physically implementing the solution, know how it works, you know necessarily how to do it for the most part, but you're not physically doing in terms of coding time. It's really only going to be enabling other teams or other pieces of the actual product. So it might be some scripting setting up some third party libraries or features things along those lines. In terms of leadership, you're the voice in the room that your engineering teams are not in. So that means you have to be a strong advocate. In terms of responsibility, you're responsible for the success of the product and meeting the timelines that you set. That's a big one. In terms of documentation, you document and present the work on a product level to the whole company. So documentation is really key because again, if it's not documented, it doesn't exist. In terms of a junk drawer, you're really going to just kind of manage and monitor kind of the core systems for trending data and any alerts that are generally non technical but are important to the success of your product. In terms of soft skills, you need to have high verbal and written communication skills in order to set the strategy and as part of doing that actual technical planning work. In terms of a project manager, you are the person who defines the scope and timelines of a project while also being responsible for resourcing and unblocking. So, whereas before technical product manager was actually just managing the product from a technical standpoint, which might mean that they're working with multiple different teams and engineering factions, the project manager is potentially overseeing multiple product managers, which means you're going to have a lot of meetings and bearing. So your job is the whole project. So you will probably be in personal product and leadership meetings consistently, really just being the voice in terms of technical skills, you know, enough to be effective for the project and to have the correct perspective. But again, you're not implementing and you're really relying on a lot of your product managers and engineering leaders to kind of handle a lot of that detail work. In terms of coding time, pretty similar, right? If any is spent in verification or testing to make sure that the project is meeting expectations, in terms of leadership, it is higher. So you're the voice of the entire project, inclusive of engineers, designers, and product groups. You're bringing it all together and it's not like you're just delivering on, quote, a product, you're delivering on an entire project. So as like an example, in Mobile, you would have multiple factions working on Android Studio, right? So you'd have multiple product managers, but you might have one project manager for all of Android Studio. But each of those tools probably has somebody in product surrounding maybe one or two of those. In terms of responsibility, you are the one ultimately responsible for all aspect of the project. Success or fail falls on your shoulders. The ability to push that information, communicate that information, and take responsibility where appropriate is really key invitation. You are not necessarily documenting to the same degree that a product manager is, but you are organizing a lot of the documentation that everyone else is actually creating and putting it into a more cohesive storytelling style, you have more gentle, right? So it is heavy communication to continuously identify and move to eliminate blockers in debt and a little bit of kind of looking into the future in order to make sure that you are planning effectively so that these issues are already taken care of before anybody has to see them. In terms of soft skills, this is the highest, right? High verbal networking and written communication skills are required to fulfill this need. All right, so we're going to go into a totally different area. So technical sales, it's basically a product manager. Oh shoot, I think I have the wrong version here. But anyway, in terms of technical sales, you know the product inside it out as well as how to sell internal and external meetings. In terms of technical skills, you know how to connect products with capabilities at a technical level. In terms of coding time, this can be pretty variable depending on if you're working for a SAS company or if you're working for a large company versus a small company. I can tell you that there is a good friend of mine who has been in technical sales for a long time and he still physically does planning and architecture and all of these kinds of very technical pieces to the implementation and that is at a very well known tech company. So technical sales can actually be very technical in terms of leadership. You organize and prioritize, but generally you don't kind of lead anyone. You might have a small team and you might work directly on the implementation, but it is what it is. So in terms of responsibility, your job is to sell and maintain relationships with customers for general follow through, terms of documentation, lots of pricing, general accounting, technical documentation of their solutions. Jump Drawer it's really about maintaining client relationships and being the point person for all the little things, getting all that little stuff that they might mention kind of taken care of. In terms of soft skills, this is sales. Sales is the ultimate soft skills. So you need those communication capabilities in all categories, but especially in networking and your ability to sell at the end of the day. Technical Account Manager I don't know what's going on with the slides with the second things, but hey, we're working on it. So actually a technical Account manager is really the liaison for an entire account when it comes to kind of like SAS companies or even just general sales. So where we had somebody who was a technical salesperson, now we're into a technical account manager. That's really the maintenance side of that relationship and the full implementation side of that relationship. So in terms of meetings and pairing, you are maintaining relationships and instructing teams while keeping leadership informed as to the project, actually moving forward, or multiple projects that are for a single company or for whoever that client might be. In terms of technical skills, you're going to have actually quite a bit of technical skills in most of these situations because you know how the whole architecture works together in each piece as part of the client solution. So while you might not be coding very much, you might actually be doing a lot in terms of architecting how all of your different products interact and kind of also tapping in a little bit to some of those continuing sales leadership. You're often organizing multiple teams internally around engineering and product in order to meet the client needs. Terms of responsibility. You're responsible for everything for your client, even if it's beyond your control. That's a tough pill to swallow, but it's true. Any discourse that your client is feeling, you are the point person for that. Even if it's something that you can't make move faster, it's your responsibility to kind of say, hey, we're working on it and this is what the real timeline is. We didn't necessarily scope this. How can we make it better? Right? Really put mine to these documentation. If you don't document the implementation details, especially what you did and the technical requirements for the client, it doesn't exist. It doesn't happen. Junk drawer maintenance as a daily habit, watching logs, analytics and staying at top market trends so that you can help the client get the best solution. This last one, since you are the liaison on behalf of the client and on behalf of the company, each faction needs to feel that you are on their side. So this is a difficult one in terms of maintaining relationships, but kind of important. So we went through all of these. I lied, but also not sorry because everyone becomes a manager. It's all about who and what you are managing. So when we looked at the technical track, you're managing tech, you're managing people in their technical growth, you're managing your platform. While people may not directly report to you in terms of their promotion, you're absolutely part of those conversations, your feedback's invaluable. It's your job to help them grow. You should be working with their people manager to be another faction of their people management. And when we look at the nontech usual tracks of the tech domain tracks, you're managing relationships, you're managing architecture, you're managing product, you're managing projects, you're managing multiple people well, they might not directly, quote, report to you. You're ultimately responsible and they are responsible to you as well. So everyone, as part of moving up in some capacity, becomes a manager. So as an overview, what have we learned? There are multiple paths for your tech career. Senior engineers just the start to so many options you really need to invest in soft skills. It's not all about, quote, grinding lead code. It's about how you communicate value. Either value in relationships, value of the work that's being done, prioritization strategy, being able to communicate those effectively is important to every single job that's available. Moving up is scaling up, you're a whole person. You bring that package to what you do. If you noticed in every single capacity, the number of things that you had to increase, you physically went up by multiple points from where the previous position was every single time. So again, it's tying into that kind of second slide. It's all about weighing what it is that you love most and deciding where you want to scale up, how you want to scale up, but everywhere along the path, you're learning and growing. And one thing that I will definitely bring in as part of my piece here is that you ultimately define the role. Whatever your title is doesn't define you, and how you can make the role your own. So while I have definitely had multiple different titles within my career path, I've also had totally different roles in terms of what the expectations are. I've done everything from being the UI UX lead to being the actual kind of lead and platform engineer for multiple teams and developing things that are super deeply technical and almost nothing to do with UI to things that are very UX and experience based. And ultimately, what you do is really how you move in that particular space. There are a lot of principal engineers who are very product focused and really deliver on high communication skills and optimize on the value of the people that they lead. But then there's also principal engineers just looking at my own capacity that are very indepth in a very technical, specific area, and they are the point person for anything that touches into that. So there's multiple ways to define what a role is, and the title doesn't always mean what you think it means. And lastly, you have to look at your career and personal life at the big picture level. It's a marathon, not a sprint. Doing that helps me feel okay during the weeks when One Part of My Life Overwhelms the Other by Joanna Horns Nail so you got this. Don't worry if it takes time, it takes time. I've definitely gone back and forth, and quite honestly, I've had pretty much the same title for most of the last decade in some capacity. So don't worry about it. If you're a senior engineer for three years, five years, ten years, if that's where you're happiest and you don't want to move forward, you don't have to. It's ultimately about making the best decisions for your life and lifestyle. And with that, apologies for the interruption, but this is my information, and special thanks to my employer for giving me some time today in order to speak with you all. And please fulfill the survey to give me some additional feedback. Thank you so much, Stacey, for being here with us today and giving this fantastic presentation. Before we have a few minutes for Q and A, I wanted to pull out that our next set of sessions is getting started in the sessions tab and our Paul Hudson talk that will follow us directly on stage. It's just going to be pushed back a couple of minutes so that we can have some Q and A with Stacey first. But if you're interested in all those other sessions, those are getting started and you can rewatch the Q and A in the recording as well. Again, thank you so much, Stacey, for that presentation. A lot of really good feedback in our comments, a lot of people agreeing with everything that you're seeing and sharing, that was their experience with their companies as well. A big theme of the Q and A that we have had so far is looking for resources to look into these other roles and to gain some of the skills, particularly resources for growing your soft skills. Do you have any recommendations there? So one of the best things I can say in terms of soft skills is to start with your immediate network and see if there is a mentorship, either through your local Women Who Code, because I know I do that with my local women Who Code. WhatsApp people? Hey, that is a great place to start. Slack channels. We're all on the women who code mobile. Shout out to my Dallas folks. What's up? Thank you for supporting, but really it's starting with your immediate network to do kind of everything around. Learning to present my first technical presentations were to my local Google Developer group, and I also refined those skills with my Women Who Code and multiple other groups locally. That gave me the confidence to start submitting my name to bigger places. So working on those presentation skills, that's a great place to do it. Also, improv classes, ironically enough, are great. Just learning to be okay with messing up or quite honestly, what happened to me today, where just like, everything shut down and you're like, oh no. And I totally can see how at a different point in my career, I would have probably just broken down, right? Like, you're like, oh no, oh God, I failed. Everything is failing. Oh, my God. I can't do this. And what you realize is like, nobody tried to hurt you, right? Just life and circumstances happen and you kind of have to push through it. So that's a great place to go there. In terms of some other soft skills, I highly recommend getting a career coach and then once you're a little bit further in your career, getting an executive coach. I have an executive coach. It totally has been awesome. It's expensive, but investing in yourself will always pay dividends. So if you're going like, oh, I could get this jacket, or I can spend $300 on some coaching, like a couple of coaching sessions, you're going to be able to buy five of those jackets from what you just got in terms of coaching. So really consider that career coaching can be done at a group level. It's very important. I brought this up in previous talks to make sure that you're taking care of yourself first before you start refining on any of these other skills. Therapy is great even if you don't have anything kind of ongoing, just to have somebody to get your crap out to once a month who's not a friend or a loved one that you are ruining a relationship of by complaining to you about the crazy stuff that goes on in your head of just like not crazy stuff, that's a bad word. But just the nonsense that you're just wondering about. And you're like, oh, was I overreacting? Do I not overreact? Should I be reacting more? I don't know. In terms of coaches, first place to start LinkedIn, see who's got a coach in their title and who, you know, that they know and go, hey, you know, so and so, they're a coach. Do you have any experience with them? No, but I can hook you up with so and so who. I know who. That's a great place to start because it's coming from a sense of like, security and you can kind of get some low key information prior to it. Really good resources in that answer. The other kind of theme of some of the questions that were asked is what kind of background do you need to grow in these roles? And I haven't a guess of what your answer is going to be, but I am going to go ahead and ask it. As you move up in some of these higher level of roles that involve architecture, can boot camp trained programmers grasp these requirements? Or should people I computer science training in order to realistically expect to elevate to these kinds of positions one day? No, learning is lifelong. It doesn't just happen in four years with a degree. Right? Like, I didn't learn system architecture in college, so don't think that you're missing out in those regards. But yeah, have an understanding of how primitives work, how binary trees and all those kinds of things because those core concepts are important. But it's only when you start looking at, oh, well, shoot, a binary tree is just a kind of system, isn't it? Right? And then a binary search tree is just a different kind of system, right? So when you start thinking about it at that level, it helps. But yeah, you can scale up in all these things. I didn't learn none of this. Excuse me. Sierra was android taught in college. I have a computer science degree. Right now. Look at Sierra. Come on, example number one, and you'll see that I've got somebody on my team right now who I'm just going to brag a little bit on her, but she came in from a boot camp for not android. Spend a little bit of time with some folks on the team scaling up an android. I mean, we're talking a couple of. Months of spare time, not like every day or anything like that. And she came in as SC one, and she is performing equally to so many other people on the team in terms of a technical capacity, and she's just asking these questions, right? Like, hey, what do you mean by PDP? Oh, you mean the product display page? What do you mean by the word primitive? Right? So just being willing to openly ask is how you level up. I have no problem being an idiot, and I brought this up in a channel that Sierra and I are on. But never be afraid of asking stupid questions to people you know, or whatever your group might be, or even in women who code in order to look smart to the people that sign your paycheck. That's it. At the end of the day, right? You want to present value consistently, and scaling up happens through being a beginner multiple times and never giving up on learning. I am a crap, okay, I'm not going to say crap. I am a relative novice developer in a bunch of other capacities like web and Ruby and all of these other kinds of things. But my gosh, does it have such a value add for my ability to assist my teams or work across multiple boundaries? And being okay with being bad at things is important to growth. What? You can't be all the things all the time, but I'm continuing to grow in those areas. I'm going to continue to get better at it. The more you do system architecture, the better you get at it. I give system architecture exams to people that are prepping for interviews and help people with interview prep all the time around this. It's not impossible. Use the resources. We're all here. What's up? Thank you so much again, Stacy, for joining us today. That is all the time that we have for questions for this session. Thank you for joining us. Thank you for sharing all your knowledge. Thank you for the phone fantastic answers during our Q and A Nd. Please reach out to Stacey on Twitter amazing Twitter account to stay in touch with her. Again, thank you so much, Stacey, and thank you to everyone in this session. Thank you. Bye.