How to Keep Up Your Technical Skills Without Annoying Your Teams

It's been a great It's been a great day. Right. And you all have been an fantastic audience. You've really been great at participating with the different things that folks have been asking of you. And I really love this model right? Where we're, we're talking together about these things. And we're kind of trying to read the room to understand where you're at.

Earlier you heard about essential ism from Erica, and now I'm going to totally stress you out because you know, this is kind of attention. How, how do you keep up technical skills now that you've taken this engineering role as a manager? And so essential ism is actually going to be a really important part of making trade-offs and putting those.

Big boulders in the jar, if you know that analogy and thinking longterm, so it's intention, but these two things can go together. So again, polling the audience. I want to get a sense here. Let's talk about coding. Hands-on. I want to know how many people in this group are currently. Hands-on coding either in your team's code base or you're active on an open source project, or you are actively developing some side project this week or last week.

Can you raise your hand and keep them up? Okay. Now over the last six months, you've done some active coding in one of these categories. Raise more hands if you've done it in six months, and then how about a whole year? Raise your hands. Anytime in the last year you've done some coding. I think this looks like about 50% of the people who are, have not done any coding.

And that includes me. Haven't done any coding in the last year hands-on and so if you were coming back here in a year from now, there's going to be fewer hands raised, right. And a year from then, because you're moving forward in your engineering career and in your manner. Roles and responsibilities.

And so you're probably getting less time to cook. So what are we going to do about it? We're going to use as a visual indicator of this pattern, my get hub, which is a little scary, and I feel a little vulnerable. And maybe you feel a little bit of this as well. So who am I? So I'm Kathleen, Danielle and I work at Twitter.

I am a director and platform engineering, and I work with infrastructure teams and our public cloud services team. And so we together are charting our hybrid cloud future at Twitter. Awesome and exciting. And before I came to Twitter, I worked at wired where I was an engineer and then the tech lead and the manager and the director.

So we're going to look at the, my span just because, you know, that's the story I have to tell you. So let's look at the stats graph in GitHub. We're going back to 2014. I was still at wired. I was the tech lead on my team. And I'm obviously doing a lot of contributions. Hands-on coding even after August when I became the manager of the team.

So that includes some of you here, you're still actively coding. Right? And then we get to 2015 and I'm still managing, but I'm still actively coding, but it's starting to drop off a little bit. And then we get to 2016. What happened? Well, so what happened was I left wired and I went to go work at Twitter and Twitter's get is not in good it's we have our own gifts.

So even if I was actively coding, you would not see that. But the truth is that's what it would look like. So, and you can probably extrapolate. And so we'll talk about that later, the future after 2016, okay. You get the picture. So who cares? Right. We know why we chose to be managers and we knew that we were going to have to go.

A little bit stepped back from the code. We were going to let our tech leads take more of a lead. We are going to give people autonomy. So we don't, we know this is going to happen to us. So why does this matter? Well, that's the reason this matters is because we face a pretty real danger that our technical skills are going to become obsolete in pretty short order.

Right. And meanwhile, our teams are looking to us. To provide technical direction and strategy and guidance. So according to a study by Benjamin arts', Amanda Goodall and Andrew Oswald of 35,000 employees, the benefit of having a highly competent boss is easily the largest positive influence on a typical worker's level of job status.

No pressure, but okay. What do we do about this? So when engineers look up the management chain and they see competent technical leaders, they like their jobs better. The study goes on to describe why doctors should lead hospitals. Why scholars should leave universities and why basketball players should be coaches, but here's the deal.

If you were a basketball player, you can probably rely on the things that you learned 20 years ago. Those rules are pretty much the same in basketball, right. But if you got your computer science degree and you know, 20 years ago, and then you didn't do any more coding, and now you're trying to give people some technical guidance, how would you even begin to do.

Right. There's a lot that has happened in the time in between. So let's take some examples, some real examples. So again, these are just my timelines, because that's the story that I'm able to tell. You could probably pick other dates, but I was at wired from 2012 to 2016. And while I was there, we went from taking a zip file and FTP in it, deploy.

I saved a copy on my laptop so I could roll back. Right. I was heavily deployed then we had, and then we had Jenkins and then we added puppet and then we started building API APIs, and then we moved to AWS and then we went through many different JavaScript libraries and landed on react. Right? These, each of these things you could take and give a whole talk about how these have fundamentally shifted the way we work, the way we deploy, the way we test, the way we cope.

And now if we look at. My time at Twitter. When I started Twitter graph, QL was the big thing it's changing the way we think about API end points and machine learning is huge. And how do we manage our data pipelines now with machine learning as a focus, Twitter is going through a change where we are doing more and more in AWS and GCP.

So that's a big thing for us right now, even though many of y'all have probably done that earlier and Kubernetes, right? Like, you'll get your server. It just, you know, it just dies and you know, you have to. For that reality, that's a fundamental shift. So these things are happening in our industry all of the time and we have to keep up, but it's so hard, right.

We're managers and we're, so there's many challenges to this. So let's talk about some of the reasons why this is very hard for us. So some of the problems with being hands on, some of you may be feeling a little bit of this. The big blocks of maker time. I don't know how Billy Sue does that. With those chunks of time in her calendar that she's able to block out.

I have tried that. I'm not as good. I don't know. I just can't find maker time. And maybe you feel that too times that I have tried to do a little side thing and like teams code base. So one time. Yeah. I'll take it. I was new to the group Twitter, and I thought, you know, I should probably try to get a little bit hands-on, you know, really understand what my team's doing.

And so I thought I'll just take this thing from way down in the bathroom. Nobody really cares about it, but I'll just, it'll be a good project, a little teeny thing. I can do five line Yammel change, no big deal. And it's even in a code base that like nobody needs to, it's not looking anything. I swear. And so I make the change.

I kick off a build and then run off to meetings, meeting, meeting, meeting, meeting, meeting, and then guess what happens when I come back? The build failed. Oh, that's no big deal. I'll just kick it off again. And then go off to meetings and come back. The build's still failing. I do not have time to troubleshoot this build.

I don't even know about the bill. I've never even run this process before. And like a couple of days passed by and I'm not able to deal with it cause I'm so busy. And one of my engineers pings me and says, Hey Kathleen, do you want me to come and do your, your bill for you and fix it? And I'm like, Ugh. Yes, of course.

Yes. I don't have time to do this. And also now this is a highly skilled engineer who was working on much more important stuff and she had to stop what she was queuing to clean up my manager mess lesson learned. Okay. Anyway so when you get to hands-on, sometimes you're just really not letting your team step up and take charge and have that autonomy and ownership.

So moving on leadership priorities, how are you going to focus your. Probably you didn't get much management training in computer science, school engineering school, whatever you did before. Right. And so when you become an engineering manager, it's like, Hmm, okay. Management, no idea. Right. Let's that's how I felt the first time I did it.

So we don't have a lot of knowledge in this area. That's part of why all of us are here. And so if we're going to spend time learning things. A lot of the time going to be in the management space, it's going to be in strategic thinking. It's going to be on developing our soft skills and that doesn't leave a lot of time.

We're also developing our technical skills. And then finally these tech trends, they change really, really fast. And there's a lot of new things to learn and almost too many things to learn. And how would you pick? And I remember. Backbone, should we do backlog angular, Amber react. And you know, those of us who spent time in backbone?

Oh, well, not a great investment, right? If you picked react early, whew. You know, that was a good use of your time, but we're always figuring out these trade-offs right. Like what to learn. It's hard. All right. So you've got to choose growth because your choices are not really choices. Right? You can either just stick with whatever it was.

You studied in school or whatever you did as an engineer. And kind of like, okay, that's my base knowledge. And now I'm managing, but at a certain point that's kind of running out on you. And so you really have to choose to continue to grow. All right. So if we take an example list of like all the things that I'm interested in learning, and then other people have shown us like that.

This is the calendar, right? And this is the work calendar. And this doesn't take into account. My family, my kids, my hobbies, sleep, exercise brands, hobbies, you know? So how does one even find time? And this looks different for everyone. So some people can do the thing where you're like code 15 minutes a day, and some people can do the thing where you block out the maker.

That's awesome. And if that works for you, that's awesome. That just never worked for me. So what has worked for me has been kind of spurts sporadic chunks of time, wherever I can grab it. And so I tend to think more quarterly what's what's, what's a thing I can do sometime this quarter. And from quarter to quarter to quarter, it's different.

Sometimes it might be a side coding project. Sometimes it might be just a little scripting. Sometimes it might. A class, a workshop. So is something a little bit different, but over time, if you have that long view building skills over time. So this, this is what works for me. It's like noticing that I've got a free weekend coming up.

I'm like Saturday, I'm going to try and do a little project end to end. I gotta be done. But at the end of the day, cause I don't have any other time. So that works for me. So you have to kind of think, how are you going to slot this? Now we're coming to the part of the talk. We're just going to throw a million ideas at you.

Don't get overwhelmed. What I really want you to do is just think that I'm trying to give you ideas. I'm just trying to help you pick one thing. Just start with one thing. All right. So the first category of things you might be able to do to improve your technical skills are understanding the systems and the people that you manage.

So how can you do in the context of your job, some of these things. So probably a lot of you are reading design docs fair, and some of you are doing code review, as long as it's not about. You might be setting up the dev environment running through the bill, just so you know how that works. And now you've got a local environment that you can play in, and that can be really satisfying.

You could prototype, maybe play around with different ideas for your team. And I I've talked to different people. Like what do you do when one guy told me like, oh yeah, I build prototypes. One of the managers that I managed came onto our team and he was brand new and he was smart, so smart because in those first weeks he sat down in pair programs with every engineer.

And so he learned about the person and he learned about the code. And I need to say that it's so important to do it in the beginning because it's very hard, six months down the road to go, Hey, can you hi pair program with you? And you're like, what? Why are you looking at me? My shoulder? Like, it's a weird thing.

The further out you get from being new. But if you do it when you're new, that's a really precious time. Don't waste it. Take the time to learn. When the team does a brown bag or a code walkthrough, or if I encourage this to happen, I'm like, yeah, it's good for all of you to do a code walkthrough. I'll just sit back here, watch.

Cause I'm learning. Right. And one other ideas somebody gave me is that she used to like to go through and just clean up janitorial style. Those libraries that nobody was using that old code, those services that nobody had stopped to clean up. And that was a value to the team and also a way for her to exercise her.

Understood. What was connected to what? So next we have automating management tasks. So I know a lot of engineering managers to get very excited about these little tools. So setting up system dashboards and metrics, writing scripts, I know an engineering manager that I work with who has used Google API APIs with a calendar API and.

So when there's a meeting, there's a automatically attached template that has an agenda. And then when the meeting's over it pre-populates, you know, anyway, he's gotten really into Google app scripting, just as a fun side thing that makes his job easier. It's coding, but it doesn't have anything to do with his team.

I talked to one friend, she told me that someone in her group had built a Chrome extension to go in Lincoln. And pull out information about somebody they wanted to recruit for their team to like do an auto-populated email. Oh, that's pretty cool. And it'd be fun to build a Chrome extension. There's lots, you know, Lexis.

I FTT I know one engineering manager who built the whole pipeline for interview code challenges, where they'd send the code challenge out to the candidate candidate, sends it back, and then they just run it through a process that would do automatic grading for them. And he built that on the side as a manager, right?

Just little things to speed processes. And of course you can always do some interesting third party software integration work. This is all things you can do outside of the scope of the team. There's always side projects. I know. Not always do we have time for side projects. What I do is I sometimes make commitments to give a technical talk that I don't know anything about, and then I have to learn it.

So I did that once for Grace Hopper I needed to give a technical talk for our Twitter recruiting event. And so I said, okay, I'm going to build a Twitter. No idea how to do that. And so, because I made the accountability step of promising something to someone I spent the weekend and I built a Twitter bot and it was really cool to learn more about our API, to learn more about our terms of service hackathons this week is Twitter's hackathon.

And I missing today. I'm missing the science fair, which is one of the most fun days at Twitter self, but there'll be another one, but hackathons are a good opportunity. If you can, to just put, take off the manager. And just sit down and do a little bit of coding, do some sort of a project contributing to open source.

We mentioned that before I had a lot of fun on my team with our code challenge because we let candidates work on that code challenge in any programming language they wanted to. And then we would run a test script to do a performance assessment. And so we'd have to write the test scripts in the language.

So I wrote that thing in Haskell. I wrote it in Scala. I wrote it in Python. I wrote it. Yeah. You know, it was small and short, but it was cool. Cause I had to figure out how to install the language, how to do a little bit of, you know, writing of these different types of code, what was needed. And a friend of mine had a son in high school and was taking a coding class and he got stuck on something.

So he called me up and we spent two hours debugging his little Khan academy, Java script application. And again, it's just like little things, little things to re you know, keep the muscle memory of coding. And remembering how it all works together. So whenever I go to a conference in terms of keeping up with trends, all the things we do for that, I try to do the hands-on workshops.

So for example, I went to velocity and I did a Lambda workshop. So it was all, you know, working with AWS and building a Lambda function and then deploying a web application that way. And just getting to do that through a step, the forcing myself to sign up for this workshop, which gave me maybe the time and then having an elemental picture of how Amanda functions work.

Or I did a Kubernetes workshop a couple of years ago that spinning up pods and shutting them down. Like, oh, that's what they're talking about. I don't know about you, but I got it. I got to see it. It's I just reading an article is not enough for me. So I really look for those opportunities. I have also use the technique.

Again, this is an accountability trick where I will set up a class and then invite a whole bunch of people. And now I have to go. So anything I can do to like force that into my schedule, I'm looking for those another idea that somebody gave me was to go to conferences and actually go around to those demo booths and do more than just get their sweat.

You can actually ask for a demo. And it is pretty interesting to see, like, what's the new Relic demo. What's the data dog demo. What are they doing right now? What are they building? And what are their customers asking for? Like, there's a metal load level of information to be had there. That's helping me understand where things are going.

All right. Now we're going to talk a little bit about what does this all have to do

with your career path?

I'm pushing it. What do you want me to do? Whoa. Okay. Okay. Whatever. I'm thinking really broadly about my career path and I'm thinking how all of these little pieces over a long period of time are building my competency technically toward bigger things. And so a lot of times, especially at a big tech company that tends to move you from the spectrum.

To the generalist over time. And so looking for those opportunities to do something that is technically unfamiliar or stepping into a new technical domain is going to provide a lot of learning. A year ago, I went from managing full stack engineering teams. I was a full stack engineering engineer, so that felt very comfortable to me.

And I stepped into managing core infrastructure, less comfortable, and it was a huge risk. And I thought, well, I'm not going to pretend to these engineers that I am stepping in as an expert in core infrastructure. Cause I'm not. But the problem to be solved in that group had a lot to do with collaboration.

And I felt well equipped to help build relationships with our peer teams that had been broken and. I told everyone I'm going to need time to learn. And people did give me that time to learn. And in this year it's been an incredible opportunity to learn and to be immersed and to read all the design docs and also to take a lot of training.

I took Google cloud architect training recently, you know, just trying to shove these things. And, oh, and I want to tell you one other thing about that. I have tried twice to take the Google cloud architecture training. The first time was about a year ago when I inherited all these things. 40 people, all this new domain.

And then I signed up for the training and I couldn't complete it. It was just too much. And so it would also say that sometimes you're going to try to fit these things in and it's just not going to work. And that's okay. You keep trying like maybe 25% of the time, it's a mess. Didn't get to do it. I try to put in my calendar, it didn't work out 75% of the time I'm getting it done 75 or 10% of the time it is happening.

So don't give up on the. People talk about this IC manager pendulum. And I always really wants to encourage people who want to go back and forth. Like that's a great opportunity, right? If an IC was a manager and then goes back to being an IC, they're a fantastic IC who understands the challenges of managers.

Right. And if they're a manager and then they go back to IC for a while and come back to management, like now they have new technical skills. Like it's, win-win when you might, I've heard of people taking, learning sabbaticals where they have a side project or an app. They've always wanted to build that, that side thing.

And it just is an itch they want to scratch. So they just take some time off and they go build the thing and come back. And they get new technical skills doing that. And I see how people get different opportunities based on whether there's startup or a large company. Or do you want scale or do you want to wear the hats?

So these are things to think about as you take these opportunities. What kind of technical development are you going to get as you go along? All right. So moving on, what am I doing? I'm pushing the wrong button. So now we're going to go back to my GitHub. So I promised you, it would look like this. You knew it was going to look like this.

So here's the thing. This is what I decided to do. I decided to give myself credit for all this stuff I've been doing over the last three years. Yeah. So the first category is orange it's technical conferences. The yellow is technical classes in tutorials I've taken the red is projects, coding, scripts, backfill jobs.

I, one time ran bug fixes, whatever. And blue is design. Yeah. So, this is a picture of my technical development. I feel much better about this, and it just reminds me that I have been investing over the long haul quarter after quarter, little by little to make sure that I'm keeping up with the changes in our industry.

And also the other thing about this is it reminds me that I can. If you go a year without learning anything new, you start to doubt that you can keep learning new things and the longer you let that go, the harder it's going to be to, to really remember like, oh, I know how to do this. I know how to learn new things.

I can still get back on that horse. All right. So we talked about some ways to take care of your future. I want to show you a few other reasons, right? So you don't have to read this whole thing, but this is a career. And it's for a director. And I just want you to notice that it says technical competencies required for a director.

Strong technical background is required contributing to architecture and design efforts yeah. And scaling. And then if we look at a job description, this happens to be from Google for a director position. This is looking for sound technical decision-making architecture, design discussions, and detailed technical guidance at the director level.

So you're starting to see, this is not just a nice to have. This is something you need for your career development. These are engineering manager questions from Google, from Glassdoor. This is an example. But we're looking at distributed key store value question or key value questions, a Unix, internal questions, data structures.

What have you very technical. Right? So we are expected even though like our day job is pretty separated when we are ready for the next step ready for the next move. Like we have to demonstrate our technical competencies. So I encourage you to stay relevant. It's for the benefit of your company. It's for the it to improve the job satisfaction of your engineers and it is to invest in your future.

So I gave you a lot of ideas number, just choose one. Don't get overwhelmed, just choose one, pick a thing. What are you going to learn next? Thank you so much for your time. And I hope you tweet at me.

day. Right. And you all have been an fantastic audience. You've really been great at participating with the different things that folks have been asking of you. And I really love this model right? Where we're, we're talking together about these things. And we're kind of trying to read the room to understand where you're at.

Earlier you heard about essential ism from Erica, and now I'm going to totally stress you out because you know, this is kind of attention. How, how do you keep up technical skills now that you've taken this engineering role as a manager? And so essential ism is actually going to be a really important part of making trade-offs and putting those.

Big boulders in the jar, if you know that analogy and thinking longterm, so it's intention, but these two things can go together. So again, polling the audience. I want to get a sense here. Let's talk about coding. Hands-on. I want to know how many people in this group are currently. Hands-on coding either in your team's code base or you're active on an open source project, or you are actively developing some side project this week or last week.

Can you raise your hand and keep them up? Okay. Now over the last six months, you've done some active coding in one of these categories. Raise more hands if you've done it in six months, and then how about a whole year? Raise your hands. Anytime in the last year you've done some coding. I think this looks like about 50% of the people who are, have not done any coding.

And that includes me. Haven't done any coding in the last year hands-on and so if you were coming back here in a year from now, there's going to be fewer hands raised, right. And a year from then, because you're moving forward in your engineering career and in your manner. Roles and responsibilities.

And so you're probably getting less time to cook. So what are we going to do about it? We're going to use as a visual indicator of this pattern, my get hub, which is a little scary, and I feel a little vulnerable. And maybe you feel a little bit of this as well. So who am I? So I'm Kathleen, Danielle and I work at Twitter.

I am a director and platform engineering, and I work with infrastructure teams and our public cloud services team. And so we together are charting our hybrid cloud future at Twitter. Awesome and exciting. And before I came to Twitter, I worked at wired where I was an engineer and then the tech lead and the manager and the director.

So we're going to look at the, my span just because, you know, that's the story I have to tell you. So let's look at the stats graph in GitHub. We're going back to 2014. I was still at wired. I was the tech lead on my team. And I'm obviously doing a lot of contributions. Hands-on coding even after August when I became the manager of the team.

So that includes some of you here, you're still actively coding. Right? And then we get to 2015 and I'm still managing, but I'm still actively coding, but it's starting to drop off a little bit. And then we get to 2016. What happened? Well, so what happened was I left wired and I went to go work at Twitter and Twitter's get is not in good it's we have our own gifts.

So even if I was actively coding, you would not see that. But the truth is that's what it would look like. So, and you can probably extrapolate. And so we'll talk about that later, the future after 2016, okay. You get the picture. So who cares? Right. We know why we chose to be managers and we knew that we were going to have to go.

A little bit stepped back from the code. We were going to let our tech leads take more of a lead. We are going to give people autonomy. So we don't, we know this is going to happen to us. So why does this matter? Well, that's the reason this matters is because we face a pretty real danger that our technical skills are going to become obsolete in pretty short order.

Right. And meanwhile, our teams are looking to us. To provide technical direction and strategy and guidance. So according to a study by Benjamin arts', Amanda Goodall and Andrew Oswald of 35,000 employees, the benefit of having a highly competent boss is easily the largest positive influence on a typical worker's level of job status.

No pressure, but okay. What do we do about this? So when engineers look up the management chain and they see competent technical leaders, they like their jobs better. The study goes on to describe why doctors should lead hospitals. Why scholars should leave universities and why basketball players should be coaches, but here's the deal.

If you were a basketball player, you can probably rely on the things that you learned 20 years ago. Those rules are pretty much the same in basketball, right. But if you got your computer science degree and you know, 20 years ago, and then you didn't do any more coding, and now you're trying to give people some technical guidance, how would you even begin to do.

Right. There's a lot that has happened in the time in between. So let's take some examples, some real examples. So again, these are just my timelines, because that's the story that I'm able to tell. You could probably pick other dates, but I was at wired from 2012 to 2016. And while I was there, we went from taking a zip file and FTP in it, deploy.

I saved a copy on my laptop so I could roll back. Right. I was heavily deployed then we had, and then we had Jenkins and then we added puppet and then we started building API APIs, and then we moved to AWS and then we went through many different JavaScript libraries and landed on react. Right? These, each of these things you could take and give a whole talk about how these have fundamentally shifted the way we work, the way we deploy, the way we test, the way we cope.

And now if we look at. My time at Twitter. When I started Twitter graph, QL was the big thing it's changing the way we think about API end points and machine learning is huge. And how do we manage our data pipelines now with machine learning as a focus, Twitter is going through a change where we are doing more and more in AWS and GCP.

So that's a big thing for us right now, even though many of y'all have probably done that earlier and Kubernetes, right? Like, you'll get your server. It just, you know, it just dies and you know, you have to. For that reality, that's a fundamental shift. So these things are happening in our industry all of the time and we have to keep up, but it's so hard, right.

We're managers and we're, so there's many challenges to this. So let's talk about some of the reasons why this is very hard for us. So some of the problems with being hands on, some of you may be feeling a little bit of this. The big blocks of maker time. I don't know how Billy Sue does that. With those chunks of time in her calendar that she's able to block out.

I have tried that. I'm not as good. I don't know. I just can't find maker time. And maybe you feel that too times that I have tried to do a little side thing and like teams code base. So one time. Yeah. I'll take it. I was new to the group Twitter, and I thought, you know, I should probably try to get a little bit hands-on, you know, really understand what my team's doing.

And so I thought I'll just take this thing from way down in the bathroom. Nobody really cares about it, but I'll just, it'll be a good project, a little teeny thing. I can do five line Yammel change, no big deal. And it's even in a code base that like nobody needs to, it's not looking anything. I swear. And so I make the change.

I kick off a build and then run off to meetings, meeting, meeting, meeting, meeting, meeting, and then guess what happens when I come back? The build failed. Oh, that's no big deal. I'll just kick it off again. And then go off to meetings and come back. The build's still failing. I do not have time to troubleshoot this build.

I don't even know about the bill. I've never even run this process before. And like a couple of days passed by and I'm not able to deal with it cause I'm so busy. And one of my engineers pings me and says, Hey Kathleen, do you want me to come and do your, your bill for you and fix it? And I'm like, Ugh. Yes, of course.

Yes. I don't have time to do this. And also now this is a highly skilled engineer who was working on much more important stuff and she had to stop what she was queuing to clean up my manager mess lesson learned. Okay. Anyway so when you get to hands-on, sometimes you're just really not letting your team step up and take charge and have that autonomy and ownership.

So moving on leadership priorities, how are you going to focus your. Probably you didn't get much management training in computer science, school engineering school, whatever you did before. Right. And so when you become an engineering manager, it's like, Hmm, okay. Management, no idea. Right. Let's that's how I felt the first time I did it.

So we don't have a lot of knowledge in this area. That's part of why all of us are here. And so if we're going to spend time learning things. A lot of the time going to be in the management space, it's going to be in strategic thinking. It's going to be on developing our soft skills and that doesn't leave a lot of time.

We're also developing our technical skills. And then finally these tech trends, they change really, really fast. And there's a lot of new things to learn and almost too many things to learn. And how would you pick? And I remember. Backbone, should we do backlog angular, Amber react. And you know, those of us who spent time in backbone?

Oh, well, not a great investment, right? If you picked react early, whew. You know, that was a good use of your time, but we're always figuring out these trade-offs right. Like what to learn. It's hard. All right. So you've got to choose growth because your choices are not really choices. Right? You can either just stick with whatever it was.

You studied in school or whatever you did as an engineer. And kind of like, okay, that's my base knowledge. And now I'm managing, but at a certain point that's kind of running out on you. And so you really have to choose to continue to grow. All right. So if we take an example list of like all the things that I'm interested in learning, and then other people have shown us like that.

This is the calendar, right? And this is the work calendar. And this doesn't take into account. My family, my kids, my hobbies, sleep, exercise brands, hobbies, you know? So how does one even find time? And this looks different for everyone. So some people can do the thing where you're like code 15 minutes a day, and some people can do the thing where you block out the maker.

That's awesome. And if that works for you, that's awesome. That just never worked for me. So what has worked for me has been kind of spurts sporadic chunks of time, wherever I can grab it. And so I tend to think more quarterly what's what's, what's a thing I can do sometime this quarter. And from quarter to quarter to quarter, it's different.

Sometimes it might be a side coding project. Sometimes it might be just a little scripting. Sometimes it might. A class, a workshop. So is something a little bit different, but over time, if you have that long view building skills over time. So this, this is what works for me. It's like noticing that I've got a free weekend coming up.

I'm like Saturday, I'm going to try and do a little project end to end. I gotta be done. But at the end of the day, cause I don't have any other time. So that works for me. So you have to kind of think, how are you going to slot this? Now we're coming to the part of the talk. We're just going to throw a million ideas at you.

Don't get overwhelmed. What I really want you to do is just think that I'm trying to give you ideas. I'm just trying to help you pick one thing. Just start with one thing. All right. So the first category of things you might be able to do to improve your technical skills are understanding the systems and the people that you manage.

So how can you do in the context of your job, some of these things. So probably a lot of you are reading design docs fair, and some of you are doing code review, as long as it's not about. You might be setting up the dev environment running through the bill, just so you know how that works. And now you've got a local environment that you can play in, and that can be really satisfying.

You could prototype, maybe play around with different ideas for your team. And I I've talked to different people. Like what do you do when one guy told me like, oh yeah, I build prototypes. One of the managers that I managed came onto our team and he was brand new and he was smart, so smart because in those first weeks he sat down in pair programs with every engineer.

And so he learned about the person and he learned about the code. And I need to say that it's so important to do it in the beginning because it's very hard, six months down the road to go, Hey, can you hi pair program with you? And you're like, what? Why are you looking at me? My shoulder? Like, it's a weird thing.

The further out you get from being new. But if you do it when you're new, that's a really precious time. Don't waste it. Take the time to learn. When the team does a brown bag or a code walkthrough, or if I encourage this to happen, I'm like, yeah, it's good for all of you to do a code walkthrough. I'll just sit back here, watch.

Cause I'm learning. Right. And one other ideas somebody gave me is that she used to like to go through and just clean up janitorial style. Those libraries that nobody was using that old code, those services that nobody had stopped to clean up. And that was a value to the team and also a way for her to exercise her.

Understood. What was connected to what? So next we have automating management tasks. So I know a lot of engineering managers to get very excited about these little tools. So setting up system dashboards and metrics, writing scripts, I know an engineering manager that I work with who has used Google API APIs with a calendar API and.

So when there's a meeting, there's a automatically attached template that has an agenda. And then when the meeting's over it pre-populates, you know, anyway, he's gotten really into Google app scripting, just as a fun side thing that makes his job easier. It's coding, but it doesn't have anything to do with his team.

I talked to one friend, she told me that someone in her group had built a Chrome extension to go in Lincoln. And pull out information about somebody they wanted to recruit for their team to like do an auto-populated email. Oh, that's pretty cool. And it'd be fun to build a Chrome extension. There's lots, you know, Lexis.

I FTT I know one engineering manager who built the whole pipeline for interview code challenges, where they'd send the code challenge out to the candidate candidate, sends it back, and then they just run it through a process that would do automatic grading for them. And he built that on the side as a manager, right?

Just little things to speed processes. And of course you can always do some interesting third party software integration work. This is all things you can do outside of the scope of the team. There's always side projects. I know. Not always do we have time for side projects. What I do is I sometimes make commitments to give a technical talk that I don't know anything about, and then I have to learn it.

So I did that once for Grace Hopper I needed to give a technical talk for our Twitter recruiting event. And so I said, okay, I'm going to build a Twitter. No idea how to do that. And so, because I made the accountability step of promising something to someone I spent the weekend and I built a Twitter bot and it was really cool to learn more about our API, to learn more about our terms of service hackathons this week is Twitter's hackathon.

And I missing today. I'm missing the science fair, which is one of the most fun days at Twitter self, but there'll be another one, but hackathons are a good opportunity. If you can, to just put, take off the manager. And just sit down and do a little bit of coding, do some sort of a project contributing to open source.

We mentioned that before I had a lot of fun on my team with our code challenge because we let candidates work on that code challenge in any programming language they wanted to. And then we would run a test script to do a performance assessment. And so we'd have to write the test scripts in the language.

So I wrote that thing in Haskell. I wrote it in Scala. I wrote it in Python. I wrote it. Yeah. You know, it was small and short, but it was cool. Cause I had to figure out how to install the language, how to do a little bit of, you know, writing of these different types of code, what was needed. And a friend of mine had a son in high school and was taking a coding class and he got stuck on something.

So he called me up and we spent two hours debugging his little Khan academy, Java script application. And again, it's just like little things, little things to re you know, keep the muscle memory of coding. And remembering how it all works together. So whenever I go to a conference in terms of keeping up with trends, all the things we do for that, I try to do the hands-on workshops.

So for example, I went to velocity and I did a Lambda workshop. So it was all, you know, working with AWS and building a Lambda function and then deploying a web application that way. And just getting to do that through a step, the forcing myself to sign up for this workshop, which gave me maybe the time and then having an elemental picture of how Amanda functions work.

Or I did a Kubernetes workshop a couple of years ago that spinning up pods and shutting them down. Like, oh, that's what they're talking about. I don't know about you, but I got it. I got to see it. It's I just reading an article is not enough for me. So I really look for those opportunities. I have also use the technique.

Again, this is an accountability trick where I will set up a class and then invite a whole bunch of people. And now I have to go. So anything I can do to like force that into my schedule, I'm looking for those another idea that somebody gave me was to go to conferences and actually go around to those demo booths and do more than just get their sweat.

You can actually ask for a demo. And it is pretty interesting to see, like, what's the new Relic demo. What's the data dog demo. What are they doing right now? What are they building? And what are their customers asking for? Like, there's a metal load level of information to be had there. That's helping me understand where things are going.

All right. Now we're going to talk a little bit about what does this all have to do

with your career path?

I'm pushing it. What do you want me to do? Whoa. Okay. Okay. Whatever. I'm thinking really broadly about my career path and I'm thinking how all of these little pieces over a long period of time are building my competency technically toward bigger things. And so a lot of times, especially at a big tech company that tends to move you from the spectrum.

To the generalist over time. And so looking for those opportunities to do something that is technically unfamiliar or stepping into a new technical domain is going to provide a lot of learning. A year ago, I went from managing full stack engineering teams. I was a full stack engineering engineer, so that felt very comfortable to me.

And I stepped into managing core infrastructure, less comfortable, and it was a huge risk. And I thought, well, I'm not going to pretend to these engineers that I am stepping in as an expert in core infrastructure. Cause I'm not. But the problem to be solved in that group had a lot to do with collaboration.

And I felt well equipped to help build relationships with our peer teams that had been broken and. I told everyone I'm going to need time to learn. And people did give me that time to learn. And in this year it's been an incredible opportunity to learn and to be immersed and to read all the design docs and also to take a lot of training.

I took Google cloud architect training recently, you know, just trying to shove these things. And, oh, and I want to tell you one other thing about that. I have tried twice to take the Google cloud architecture training. The first time was about a year ago when I inherited all these things. 40 people, all this new domain.

And then I signed up for the training and I couldn't complete it. It was just too much. And so it would also say that sometimes you're going to try to fit these things in and it's just not going to work. And that's okay. You keep trying like maybe 25% of the time, it's a mess. Didn't get to do it. I try to put in my calendar, it didn't work out 75% of the time I'm getting it done 75 or 10% of the time it is happening.

So don't give up on the. People talk about this IC manager pendulum. And I always really wants to encourage people who want to go back and forth. Like that's a great opportunity, right? If an IC was a manager and then goes back to being an IC, they're a fantastic IC who understands the challenges of managers.

Right. And if they're a manager and then they go back to IC for a while and come back to management, like now they have new technical skills. Like it's, win-win when you might, I've heard of people taking, learning sabbaticals where they have a side project or an app. They've always wanted to build that, that side thing.

And it just is an itch they want to scratch. So they just take some time off and they go build the thing and come back. And they get new technical skills doing that. And I see how people get different opportunities based on whether there's startup or a large company. Or do you want scale or do you want to wear the hats?

So these are things to think about as you take these opportunities. What kind of technical development are you going to get as you go along? All right. So moving on, what am I doing? I'm pushing the wrong button. So now we're going to go back to my GitHub. So I promised you, it would look like this. You knew it was going to look like this.

So here's the thing. This is what I decided to do. I decided to give myself credit for all this stuff I've been doing over the last three years. Yeah. So the first category is orange it's technical conferences. The yellow is technical classes in tutorials I've taken the red is projects, coding, scripts, backfill jobs.

I, one time ran bug fixes, whatever. And blue is design. Yeah. So, this is a picture of my technical development. I feel much better about this, and it just reminds me that I have been investing over the long haul quarter after quarter, little by little to make sure that I'm keeping up with the changes in our industry.

And also the other thing about this is it reminds me that I can. If you go a year without learning anything new, you start to doubt that you can keep learning new things and the longer you let that go, the harder it's going to be to, to really remember like, oh, I know how to do this. I know how to learn new things.

I can still get back on that horse. All right. So we talked about some ways to take care of your future. I want to show you a few other reasons, right? So you don't have to read this whole thing, but this is a career. And it's for a director. And I just want you to notice that it says technical competencies required for a director.

Strong technical background is required contributing to architecture and design efforts yeah. And scaling. And then if we look at a job description, this happens to be from Google for a director position. This is looking for sound technical decision-making architecture, design discussions, and detailed technical guidance at the director level.

So you're starting to see, this is not just a nice to have. This is something you need for your career development. These are engineering manager questions from Google, from Glassdoor. This is an example. But we're looking at distributed key store value question or key value questions, a Unix, internal questions, data structures.

What have you very technical. Right? So we are expected even though like our day job is pretty separated when we are ready for the next step ready for the next move. Like we have to demonstrate our technical competencies. So I encourage you to stay relevant. It's for the benefit of your company. It's for the it to improve the job satisfaction of your engineers and it is to invest in your future.

So I gave you a lot of ideas number, just choose one. Don't get overwhelmed, just choose one, pick a thing. What are you going to learn next? Thank you so much for your time. And I hope you tweet at me.

‍