10 Ways to Stay Technical as an Engineering Manager
10 Ways to Stay Technical as an Engineering Manager
Shake off the technical rust when you feel occupied with the manager’s schedule without affecting your management responsibilities.
Source: Unsplash
The irony of being a software engineer is that I wanted to get into management at some point. However, when I finally moved to management, I was doing less of the technical ”maker” work I used to do as a software engineer. That shift has bothered me. How can I acknowledge with full conviction that I am a “software engineering” manager?
As a manager, for the most part, your organization has a different set of expectations for you compared to when you were an engineer. Your organization expects you to manage people and do a little bit of everything. Your responsibilities could include coaching and mentoring your team, people management, project management, technical roadmap planning, goal setting, appraisals, stakeholder management, hiring, budget planning, headcount planning, etc. You might feel that your managerial role is pulling you away from the reason you became a software engineer in the first place — to write code and build software.
Many times in my career as an engineering manager, I felt rusty as a technical contributor. The “rust” became more apparent for me when I started to go for technical interviews. I wish I had dealt with it sooner.I predominantly marked my weeks with a manager’s schedule and a tiny block of amaker’s schedule. There were long periods when I needed to spend a bit more time on people management. During these periods, I stopped contributing to my team’s core code base so I didn’t potentially block the team’s progress. As such, I barely contributed anything technical to the team.
Being an engineering manager is a continuous balancing act between “engineering” and “management.” It can give you the flexibility to decide where to focus depending on your organization’s needs. The flexibility itself is also its pitfall. If you are not deliberate, you will end up neglecting the “engineering” side of your role.
The good news is there are high-output tasks that can help you stay technically sharp without neglecting your management responsibilities. I’ll walk you through these different ways in no particular order.
Some Context
What I’ll share in this article is also applicable to:
- Engineers at any level
- First-line engineering managers
- Tech leads
These are tasks that you can slice into smaller chunks so they can still fit into your manager’s schedule. They shouldn’t hinder your team’sprogress in contributing to your core code base. I wish I had deliberately blocked more time for these types of tasks sooner in my career.
Where I’m coming from:
- I based this article on my experience as a first-line engineering manager. I have managed between 4-6 software engineers (individual contributors) of varying levels for more than three years.
- The companies that I have worked for require first-line engineering managers to contribute technically to the team to a certain degree. However, the role’s priority is still people management and leadership.
- The “engineering manager” role is not the same for every company. Some companies require their engineering managers to manage a group or team of managers.
1. Technical Interviews
As a manager, your role requires you to get involved in your team’s hiring, from headcount planning to conducting interviews to make hiring decisions. You are also most likely already conducting cultural fit interviews at this point. Since you are already involved, block some time on your calendar to perform some of your technical interviews — be it coding or a systems design interview.
Preparing the interview problems requires research as well as feedback from other engineers. The preparation process allows you to review various technical topics that could include algorithms and systems design. On top of that, conducting the interview helps you learn more about the specific technical problem you present to the candidate. You will also learn different ways to solve the problems from the candidates. Keep iterating on the technical questions that you are presenting to keep them relevant. Imagine the compounding benefits of the continuous cycle of learning and finding the best candidates.
2. Engineering Design Reviews
Design documents serve as the blueprint of the services that your team owns. They contain the detailed technical specs of your services. Your help in preparing and reviewing these design documents will be valuable to your team. You are providing the team with an “outsider’s view” of the system. You will have unique input because you are not as attached to the services involved compared to your team.
Facilitate the overall design review process. Participate in your design brainstorming session. Dive deep into the details to help you understand more about the software architecture, the components that make up your team’s services, and how they interact with each other. Spot possible improvements to your systems’ design and discuss them with your team. If you have worked on a similar service before, share the mistakes you made so your team will avoid making them.
Do be clear to your team that you are not there to provide the sign-off on the design. You are a collaborator and a facilitator here. You have no intention of blocking the design decisions that your team needs to make.
3. Logging, Reporting, and Analytics
Making data-driven decisions involves gathering data, extracting common themes and patterns from your data, and then taking action based on the extracted results (assuming that your data collection is on point). Your team will not rely on intuition. They will make better decisions using the gathered actual data.
Gathering the data needs proper logging set up in your services. Ensuring that these loggers are in the right place is an important step. You can help your team by going through the code base and identifying where these logs should be recorded or missing. Ensure that logging is implemented correctly throughout the code base. If your team doesn’t track or log anything, this will be your chance to lead this initiative.
Logging is also straightforward to implement. If you already have a wrapper or SDK that calls the logging service, you’ll only need to find out where to invoke the logging calls. When writing these log invocations yourself, you familiarize yourself with your team’s code base while ensuring proper data collection.
These logs are stored in a data warehouse to query them at the end of the pipeline (e.g.DatabricksorRedshift). Write the SQL queries (or Python script) to extract the data in a meaningful way. Use the extracted data to help your team make data-driven decisions (e.g. whether a new feature is worth considering or whether an experiment is successful).
4. Minor Patches With Documentation Updates
Documentation usually lags behind the code we write. Libraries get upgraded and code gets added. However, the document stays stagnant. I always experience this when I join a new team or get on board a new project. I would follow a step in the README file that doesn’t work. It turned out that the instruction was obsolete.
Help your team in ensuring that your code andREADME.mdare in synch. Start by picking a “small”-size ticket that is either a bug or a chore from your backlog. To close this ticket, you will need to set up one of your team’s repositories to run locally. If you don’t have time to work on a ticket, skip straight to running the repo locally. Pretend that you are a new engineer joining the team, figuring out how to run your services locally. More often than not (especially for inactive code repositories), you will encounter undocumented “gotchas.” Document these gotchas and make the necessary changes until you are satisfied with the README.
Raise a pull request for your “doc update” or patch. Keep doing these to the repositories under your team’s watch.
5. Monitoring and Alerting Tools
Your team will be responsible for ensuring that your services are running around the clock, depending on your organization. Your team’s services have to maintain a high standard of observability. I’ve led teams where we were responsible for ensuring our service’s availability around the clock. Monitoring and alerting tools could impact:
- Your team’s life outside work
- Your service and business metrics
There should be dashboards that contain sufficient information that will help you monitor your service’s health. There should be alerting criteria configured so that your on-call is alerted if a failure pattern meets the threshold (e.g. page an on-call engineer if 5xx errors have reached x%).
Regularly evaluate your services’ observability. Familiarize yourself with the observability tools that your team uses. Help create the Grafana dashboards that your team can use to monitor the error rate of your service. Help your team in setting the correct alerting criteria using Bosun. Manage the 24/7 on-call rota and escalation policies using services likeVictorOpsandPagerDuty.
Gaps are unavoidable in your monitoring and alerting. Services will evolve and scale. Therefore, your observability tools will need to adapt. Getting on top of your services’ observability helps your team monitor your services 24/7 effectively.
6. Prototyping API Clients
External service dependencies are inevitable in the world of microservices. Your team’s service will consume another team’s service. Dependencies are applicable — especially for web or mobile apps.
I’d look at our product roadmap or tasks for upcoming sprints and determine which features will have service dependencies. I’d then follow the API documentation (if there is any). Sometimes if I’m lucky, there could be a test harness included. My goal is to make the API consumption as clear as possible. I’d then prototype the API client if there are a lot of unknowns.
My favorite tool for this is iPython Notebook. I use it with theRequests library. Python’s syntax is also pseudo-code-like, which makes prototyping feel like taking down notes. iPython Notebook also allows you to write markdown notes and blocks of code, making it a useful prototyping tool. When your prototype code blocks with notes are ready, please share them with your team. They can use these notes as a reference in their task that requires them to use the API.
You are writing some client code here while at the same time enabling your team by providing them a head start on how they can write a client for a service dependency.
7. Weekend Open Source Projects
Writing open source projects is an obvious one if you are serious about honing your craft as a software engineer. Unless you are one of those lucky developers with an open source project supported by your company, building open source software (OSS) demands a timeslot outside your full-time job.
Ideally, your weekend OSS project complements what you do at work. For example, if your team uses TypeScript, it makes sense to write your OSS in TypeScript to learn more about the language. It would be even better if your OSS was something that your team can use (of course, without disclosing any intellectual property).
For example, I built a Python library calledAPIWrapperfor one of my previous companies. It’s a simple library written in Python with a generic functionality reused in any Python application while not disclosing any intellectual property.
If done right, the benefits of this task are enormous and even compounding in the long run:
- You are leveling up in the programming language/s or tech that could help level up your team.
- Your OSS could potentially be useful to your team’s services.
- Your OSS could potentially help the community that might need the same software.
Notice how I use the word “potentially.” Writing open source is the easy part. Building something useful to other developers is the hard part.
8. Hackathons
Set aside time for hackathons with your team. I was lucky that a previous employer had one work day allotted for a hackathon every six months.
Plan in advance what you want to achieve in the hackathon with your team. Don’t plan during the hackathon. I’ve made this mistake before and it ate up a quarter of the time we should have spent writing code. The three main criteria of what to work on will be:
- What will add the most value?
- What is achievable within a day?
- What will keep the team excited?
First-line managers or leads should use hackathons to write code without any other interruptions. You are building a potentially useful feature or tool alongside your team. Writing code for an entire day is a luxury if you are a manager or lead.
9. Code Reviews
Code review is another productive way to keep yourself up to date with your team’s repository. Code reviews are not about who is the most senior, the best, or most experienced “rockstar code monkey.” Being experienced does help. However, code review is about having each other’s back so we don’t fall into bad practices, leading to undesirable short- and long-term results.
Use your “maker time” or block some time in your calendar for code review. Let your team know you intend to do this. Assign yourself the pull requests that you are sure you can review adequately and accommodate within your allotted time.
Set a good example in terms of best programming practices. Just like in design reviews, use your experience to help your team avoid the same mistakes you made in the past. Show your team what a useful code review comment looks like (e.g. clear and constructive comments) and appropriately mark if it’s anit.
By doing this, you help your team maintain specific coding standards while keeping your coding skills as sharp as possible.
10. Internal Tools
Build or adapt internal tools that could help your team’s productivity.
For example, there are repetitive manual tasks that customer support has been asking your team to complete. These manual tasks take a chunk of your engineers’ time. Furthermore, your team doesn’t have enough capacity to build the tool to automate the task. Help your team build the internal tool to solve this problem if you happen to have spare blocks of time in your calendar.
There are cases when you don’t have to build your internal tools from scratch if there are free, open source tools that you can reuse. Some examples are developer productivity tools (code linting,code review chores, andautomated end-to-end tests.
Since these are internal tools and a lower priority than other services you own, there is a bit of leeway for you here. Focus on getting the tool to work during its first few iterations. Share the prototype with your internal customer to get their feedback. If all is well, polish the tool in multiple iterations after getting feedback from your team.
You help boost your team’s productivity by automating the manual tasks that they do while writing code. You could also be learning something new along the way (e.g. a new web framework or library).
Conclusion
It’s still essential to stay technical to a certain degree. You don’t have to do all of the tasks above. Your mileage may vary. Pick and choose what suits your current situation. For example, if you are a new manager, you could pick two or three items above. On the other hand, if you are an experienced engineer and manager, five or more items from the list will work out fine.
The examples I gave have varying impacts on you being an engineer and a manager. It’s up to you which ones you prioritize. It’s all about execution. Put these in your calendar, get them done, and keep iterating.
Keep an eye on items #3, #5, and #6 because they could be candidates for automation. Part of item #9 is already automated, for example, withDanger.
Check out my other article: