Do you even code anymore? How to keep up your technical skills without annoying your team(s)
In a crowd of attendees at the O’Reilly Velocity distributed systems conference a couple of months ago, I asked a room of mostly managers how many of them had coded within the past week; within the past 6 months; or within the past year (including side projects, open source contributions, etc.). With all three of those categories, we had about 40% of people in management raising their hands. This means that 60% of the folks at a major distributed systems and dev ops conference hadn’t coded in a year or more. Of course, if we were to gather that same group again in a year, or two years, that number of people who had not coded in a year would grow and grow. You get the pattern.
If we don’t think too much about it, the natural tendency of engineering management is to code less, and less, and less over time. As just one indicator of this pattern, I used the contributions stats on my github profile page. Back in 2014, I was the tech lead at WIRED, and we moved our version control to github. There’s plenty of activity for me in 2014 — even after August, when I became the manager of my team.
In 2015, contributions remain the same, pretty busy and still hands on coding as a manager, but I’m starting to let go, and there’s some drop off, a few more lighter green squares.
Then, here comes 2016. My Github contributions drop off a cliff! Part of that is because I changed jobs when I took a new role as a senior engineering manager at Twitter. Now, even if I was hands on coding at Twitter you wouldn’t see it here because we have our own git. But the reality is, it would still be very sparse.
If we project out to the future, and those contributions continue to recede into my past… we know this is only going to get worse.
So who cares, right? At this point, I’m managing managers, and I’m spending all my time going to meetings and managing people. Why should this even matter?
Well.. have you ever been in a meeting discussing the architecture of a new project where someone suggests incorporating an innovation that you aren’t really familiar with yet? And that someone turns to you and says, “Kathleen, what do you think about… [insert new tech hotness here]? Do you think we should migrate?” Gulp. While I may understand containerization in a general way, my knowledge might not be deep enough (yet) to apply to this situation. Or maybe you’re in a meeting and you make a suggestion based on outdated ways of thinking that are incompatible with the current architecture. You see the look in the eyes of your engineers… Gulp. You should have known that — you would have known that, in your area of expertise. It’s a terrible feeling, and it doesn’t really help to say, “I’ve been meaning to learn about that…”
If you’ve already established a high level of technical competence, then it’s fine when this happens. No one can know everything, right? So it’s not that I feel I have to get it right every time. But what I worry about, and what you may worry about, is getting to a point where all of my knowledge is obsolete — effectively deprecated, and then that’s the only experience I am going to have, and I won’t be able to contribute effectively to architectural conversations anymore.
This becomes not just a problem for my pride, but it affects my engineers’ confidence in me. That’s because, according to a study by Benjamin Artz, Amanda Goodall, and Andrew J. Oswald of 35,000 randomly selected employees and workplaces, “The benefit of having a highly competent boss is easily the largest positive influence on a typical worker’s level of job satisfaction.” (from Harvard Business Review’s If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work)
When our engineers look up the management chain and see competent technical leaders, they are more satisfied in their jobs as engineers.
“Imagine if you’re being assessed by a manager who has no idea about the kind of job that you’re doing, doesn’t really understand it, hasn’t walked the proverbial walk before you. For them to assess what you’re doing and to help you advance in your career, it becomes very, very difficult. And this is a major, major finding, is that we find that if your boss understands the nature of the work, then they can actually help you. They can assess you well, and they can encourage you in the right direction to advance in your career, and that is a very important element for job satisfaction.” — Amanda Goodall, HBR Podcast: “Why Technical Experts Make Great Leaders”
Goodall uses her research to describe why doctors should head up hospitals, scholars should lead universities, and all-star basketball players should manage teams.
And that’s all well and good — most of us fit this pattern: engineers who manage engineers. But the catch is, our industry moves much, much faster than healthcare or education or sports. It’s reasonable to think that a basketball coach could base his or her knowledge on the rules of the game from 20 years ago, and not much would have changed. But if you stopped learning anything new in software or computer science for 20 years, you’d be completely lost. Obviously 20 years is way too long a time range to even consider for us. I was at my last job from 2012 to 2016. During that time, our company adopted Jenkins, Puppet, AWS, REST APIs and React.js. The environment I worked in just five years ago is completely obsolete.
It’s not just languages that come in and out of favor — Java, C, PHP, Go, Scala. There are fundamental shifts that happen. It used to be, in web development, we “separated our concerns,” right? This was a standard, a rule. HTML, CSS, JS and ne’er the twain should mix or meet. Along comes React, and now the same file contains all three, and we’ve discovered web components, and it’s changed everything about the way we think about front end web development and how we manage state.
Seeing this, and starting to think about the implications on latency and network requests, thinking about how we might migrate to such a system — there are shifts in the way we as managers will consider what resources we need, how long projects will take, what future maintenance and scalability will look like, and what kind of skills and team members we will need in 6 months, a year, two years from now. We have to get to the right level of technical depth to understand the implications; get our hands a little dirty, play with the possibilities or limitations. We can’t just take something because it’s new. I can think of lots of misappropriation of NoSQL databases when that was all the rage, and the problems with scalability and querying some of those solutions presented.
But even when we are convinced we need to grow, and learn, and continue to develop ourselves, it’s still really, really hard.
The closest/most obvious opportunity might be the wrong opportunity
If we do a lot of hands-on coding on our teams’ codebases, we can create some headaches.
- If we have a lot of meetings, then we don’t have enough maker time. A few months ago, I decided to go ahead and make a minor code change for something that wasn’t that urgent but I thought should get done. I tested, I committed, I deployed to staging… then went of to the first of a series of meetings. Next I checked, the build had failed. I restarted the build a few hours later… Nope. Squeezed in another restart, and yes, there was something wrong with the build that I didn’t have time to investigate. The next day, I was in yet another meeting, when one engineer pinged me: “want me to commandeer that build for you?” Sigh. “Yes, please.” Even the simplest thing is never simple, right?
- When we work on anything moderately important, we block the team. Luckily, in that example I gave, it was absolutely non-blocking work. But if it were, my team would have been extremely frustrated with me for my lack of availability, and I would have both jeopardized successful completion of other work and wasted engineering time.
- Another thing that’s hard is that if I want to learn something about our code base, I’m at the mercy of the engineers on the team, and because I know that manager technical capability is important to people, it’s hard to be a complete noob. On the other hand, it’s important to model vulnerability and continuous learning, but it can leave you feeling a little exposed.
- Finally, there’s team autonomy. I know that as a manager, I should invest more in individual team member growth than in my own growth. I’m willing to make this sacrifice, and it’s the right thing to do. If I back off, the engineers have more autonomy to learn, to make mistakes, and to take ownership. But it definitely gives me one more reason to stay out of their code, and one more obstacle to keeping my skills current.
Problems with hands-on:
- Lack of maker time
- Risk blocking team
- Credibility
- Loss of team autonomy
Personal development priorities
In management, a lot of times we’re focusing all our growth and development on leadership and soft skills. As engineers, we usually come into the management job without much in the way of training or support, and there’s a huge learning curve when you have an entirely different set of responsibilities. If you’re going to do a class or read a book, it’s probably going to be in leadership. This makes it even harder to find time for technical development.
Leadership challenges:
- Lack of prior knowledge
- Strategic focus
- Soft skills development
Overwhelmed by all the trends
Even when we are willing to invest our time and energy in technical development, what should we pursue? There are a million things to learn at any given time. I remember deciding to invest in React instead of Angular, Ember, or Backbone (as one example). Why? I noticed how the conference focus for front end development was changing to React. I noticed that we could implement React one component at a time, which made it easier to adopt than the other frameworks. I noticed something similar at O’Reilly Velocity: there were a LOT of talks about Kubernetes — that’s a good clue where things are headed. And even when I do have my narrowed down list, prioritizing that can be hard.
Changes in tech trends:
- Industry moves fast
- Too many options
- Want guaranteed ROI
- Competing priorities
So here’s the ultimatum. You can fall into the easy trap of sticking with what you know, like a COBOL programmer waiting for the next Y2K. You can focus only on leadership, squeeze all you can out of your current technical expertise, and then retire when that runs out (or take up woodworking or something). OR, you can adapt. Grow. Invest in new technologies and ideas.
Choose growth. Avoid becoming irrelevant.
When I want to solve a problem I start with a list. Here’s an example of topics an engineering manager might be interested in ramping up on.
But now we hit another problem: if you’re like me, your calendar looks like this:
And that’s just working hours — I also have a husband, two kids, and plenty of household responsibilities, not to mention sleep, exercise, hobbies, and friends.
Get creative with time
I’ve found it takes some really creative thinking to figure out how to do this, and I want to share some ideas, in hopes it helps you generate some of your own. The first two are commonly recommended, but if that doesn’t work for you, don’t give up. Choosing a finite goal over a finite time period works much better for me — especially if there’s a deadline, like prepping a conference talk. We’ll talk about some of these as we go through specific examples.
- Book daily/weekly work calendar slots
- Book daily/weekly personal calendar slots
- Schedule a class and invite others
- Commit to giving a talk (brown bag, conference)
- Prioritize workshops over presentations
- Capitalize on sporadic nights and/or weekends
- Meetups
- Company hackathons
Understanding the systems you manage
What can we do to understand our systems better, and end up managing our people better at the same time?
- Read all design docs
- Code review (non blocking)
- Set up the dev environment, build, deploy
I think many engineering managers do these first three (design doc review, code review, deploys), since these are activities you probably did as a tech lead. For teams I’ve led when I wasn’t an engineer or tech lead on that team, I focus on these at the beginning to ramp up on the systems and code base.
- Pair program, fix bugs
- Build prototypes on local
I noticed one of my manager reports pair programmed with the team when he came onboard, and found that highly effective. I wish I’d done more of this and resolve to do it in the future.
I spoke to a VP of Engineering of a startup recently who uses his dev environment to prototype ideas with his product team.
- Encourage team brown bags for new learnings
- Encourage code walkthroughs
I encourage my teams to share at lunchtime brown bags and through team code walkthroughs, with the ulterior motive of learning more myself.
- Remove/delete dead code
One engineering exec told me he loves to go through and remove dead code.
Automating management tasks
How can we take time spent as a manager on repetitive tasks to generate time for automation?
- Set up system health dashboards
The first time you troubleshoot a problem, you can create a set of process steps that can become a system health dashboard.
- Set up queries for success metrics
When setting team quarterly goals, taking the time to set up queries and instrumentation for success metrics will give you powerful data to understand results.
- Write scripts (Python, Google App Scripts)
I know managers who’ve written python scripts for everything from automatically handling their code challenge grading process, to choosing a facilitator for the next meeting, to processing results of google survey forms. Google App Scripts have become a popular way to easily manipulate data in spreadsheets. One of our ICs set up a mail merge for our engineering mentorship matching process using Google App Scripts.
- Build chrome extensions (ex: recruiting)
I met a fellow engineering manager who told me about her colleague who wrote a Chrome Extension to scrape LinkedIn profiles for custom email messaging, significantly reducing the time they were spending on sourcing candidates.
- Bots (Slack, Alexa skills, IFTTT)
Did you know you could create a meeting on your Google calendar using Alexa? Lots of teams use slack bots for digital standup updates, but I know a tech lead who set up a slack bot that asks a question of the week to his team members, like “what’s your favorite ice cream? or board game?” to get people to know each other better — automated team bonding. And there’s an IFTTT recipe that will schedule a Google calendar reminder if you star an email.
- Build interview questions, solutions, rubrics
One of my colleagues has fully automated his code challenge process, from submission through grading.
- Third-party software integrations (Jira/Tableau)
Last year when I attended Calibrate, which is an engineering manager conference in San Francisco in the fall, Nick Caldwell, VP of Eng from Reddit, showed some Jira and Tableau third-party integrations that blew my mind. I fantasize about getting that integration going at Twitter.
Working on side projects
Let’s talk about side projects. This can be a controversial topic. I don’t mean to suggest that side projects are in any way required, and I know not everyone has the luxury of time to do them. I’ve managed to find some ways to incorporate them, albeit sporadically, into my busy life, and they significantly help me keep on trend.
- Give a conference talk or brown bag about a side project
Last year, I was asked to put together a technical talk for the Grace Hopper Celebration of Women in Computing, so I chose to write a Twitter bot, which is something I hadn’t done before, to understand our API a little better. There was an imposed deadline — I had to have it done by the conference. When I was asked to speak at North Bay Python on leadership, I extended a Python word cloud script I found on github and included dynamically generated word clouds in my talk.
- Participate in hackathons (company or outside)
I try to participate in at least one hackathon a year, and for that period of time, I take off my manager hat and participate in actually building something new. At Twitter, this involved working on our mobile web client in React. In my previous job, we built a search engine optimization publishing tool that won first prize at the all company event of over 200 people, and on that project I learned to build ember components.
- Contribute to open source
I have plenty of friends and colleagues who contribute to open source, of course.
- Build a new interview code challenge: grade it, solve it
One of our tech leads put together the interviewing code challenge for our team. Since we allow candidates to solve it in any language, I’ve had some fun figuring out how to test and run the code challenge solutions in Haskell, Java, React, Node, C, Ruby/Rails and Scala!
- Volunteer at code camps and meetups
One of my team members regularly tutors at Coder Dojo; at Twitter, we have a community center where we provide free coding workshops with employee volunteers.
- Tutor your kids, niece, friends’ kids
About a month ago, I got on a Google hangout for two hours to help my friend’s son with his high school coding assignment on Khan Academy, which helped me see what curriculum is being used at that high school. I also auctioned off a night of coding for some of my son’s friends to raise money for his school.
Keeping up with trends
- Attend conferences
It’s important to make time for conferences to keep up with the latest use cases and discoveries for various technologies.
- Attend tutorials/workshops
At the O’Reilly Conference where I presented this talk, I prioritized attending the tutorial day, where I attended the AWS Lambda functions talk and the Kubernetes 101 talk. They were both valuable because they were hands on, and those kinds of things help me keep from getting rusty.
- Take a class (set a goal, tell someone)
Continue prioritizing taking classes. I either take online classes, or technical training classes offered at Twitter. It helps to set a goal (quarterly, semi-annually, yearly) and tell someone. I take classes every year, and try to keep a 1:1 ratio between management training and technical training. Try to choose things you can immediately apply so the concepts stick. Once, I scheduled 4 early morning distributed systems classes over the course of a couple of weeks for myself and invited my team, which provided great accountability for me. Last year I did 3 technical classes during O’Reilly Safari 90 day free trial period, which acted as a good forcing function deadline, and I liked it so much, I subscribed for the year.
- Read a new technology book
Of course there are always new books! I have stacks of them at home and at work.
- Tech blogs, podcasts
Some of my favorite tech blog and podcast ideas are listed in this github repo.
- Tool demos from third party providers
Pay attention to new tools (CI, CD, logging, etc.) by getting demos from vendors.
- Slack channels (Rands #architecture, #tech-chat)
Use those networks. Get opinions on tooling decisions from your engineering manager network through people met at conferences, colleagues at work, and the famous Rands leadership slack; in general, keep lists of pros/cons of technologies.
Customizing your career path
Consider ways you might direct your career path to provide avenues for learning.
- Move from specialist to generalist
For me, the move from specialist to generalist has me moving from a focus on full stack web development to learning more and more about distributed systems. Perhaps for an iOS client engineer, it could look like managing multiple client teams across web, Android, and iOS.
- Take on a project in unfamiliar territory
Look for opportunities to tackle a specific project that will increase your technical knowledge. For me, it was spending the last four months on a GDPR project where I had to deep dive on the technical nuances of our data storage systems. I learned a ton over a relatively short period of time.
- Manage a team in a new technical domain
If you’ve been managing for a long time, perhaps you could stretch yourself by managing a new technical domain — for example, moving from a product engineering team to a platform or infrastructure team, or vice versa.
- Consider the individual contributor/manager pendulum
I’d love to see the industry be more supportive of the engineer/manager pendulum, as described here by Charity Majors.
- Take a learning sabbatical
After working for several years at one company, it could be rejuvenating to pause and take a sabbatical to get a new degree or certificate or work on a side project full time. You don’t always have to change companies to learn new things.
- Alternate between startups and large companies
At a startup, you potentially have the chance to wear many hats, and be more hands on. At a larger company, there can be larger teams to manage and less maker time. Some engineers purposely alternate between the two.
- Try reciprocal mentoring relationships
Lately, I’ve been experimenting with adding a learning component into my mentoring processes by asking mentees who work in other departments to teach me about the technical work they’re doing. Quid pro quo: I mentor you, you teach me.
A lot of small efforts add up over time
If we go back to github, here are my contributions in 2017 and 2018. Sad.
However, if we take a bunch of the ideas above into account and represent them on my github contributions chart, it looks a little more like the version below. Much better!
- Orange: technical conferences and workshops
- Yellow: technical classes and tutorials
- Red: projects, coding, scripts, backfill jobs, bug fixes
- Blue: design doc review
Another reason to invest: taking care of your future
Overcoming bias or discrimination (ageism, sexism, racism)
If I encounter bias or discrimination since I’m a member of an under represented group in tech, it helps if I’m current and up on the trends; even if you’re not a member of an under represented group now, you will be. Ageism is real. It is very hard to get a job in tech when you’re in your 50’s and 60’s. Our investment in learning will be important as we all grow older and want to stay relevant and employable.
Career ladders for engineering managers require technical skills
If you look at career ladders that set expectations for engineering management, technical expertise continues to be a requirement all the way up the hierarchy. Here’s an excerpt from the director portion of the Rent the Runway engineering ladder as an example.
“However, the engineering director is responsible for their organization’s overall technical competence, guiding and growing that competence in the whole team as necessary via training and hiring. They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry. They will be expected to help debug and triage critical systems, and should understand the systems they oversee well enough to perform code reviews and help research problems as needed. They should contribute to the architecture and design efforts primarily by serving as the technically-savvy voice that asks business and product questions of the engineers on their teams, ensuring that the code we are writing matches the product and business needs and can scale appropriately as those needs grow.”
Job descriptions
If you look at job descriptions for engineering management, technical expertise continues to be a requirement all the way up the hierarchy here as well. An excerpt below is from a Google job description for Director, Engineering, Chrome Web Platform.
“Preferred qualifications: Master’s degree in Computer Science or a relevant field; Experience developing high-growth, consumer / user-centric technology platforms; Strong engineering leadership and ability to attract top talent, motivate people, instill accountability and get best out of the team; Ability to contribute to architecture/design discussions and make sound technical decisions; Ability to set and drive the “big picture” strategy while also having the capability to provide detailed technical guidance to the team, enabling them to execute more effectively and deliver products on time and within budget.”
Interviews
Don’t forget that managers are still frequently expected to do live coding during interviews for roles both at places like Google and many startups! Here are questions posted on Glassdoor.com for Google engineering manager interviews:
- Design a distributed key/value store
- What’s the search complexity of…
- Data structures
- Implement an algorithm using MapReduce
- UNIX internals
- When’s the last time you pushed to github?
Where will you begin?
I’ve just thrown a bunch of ideas at you. Consider choosing just one new idea to start. If you want some accountability, you can tweet at #managerswhotech.
Stay relevant with your technical skills now for the benefit of your company, to improve your engineers’ job satisfaction, and to invest in your own future.
Conference talk slides are here: https://tinyurl.com/managerswhotech
The list of all ideas above is here on github: https://github.com/kvignos/managerswhotech
This article is also published at kathleencodes.com.
