Technical Curiosity
We explore why it is critical for engineering managers to be involved with the technologies their teams work on.
Hi, this is Peter with the next edition of the Professional Manager newsletter. I publish this newsletter to illustrate what decent, seasoned, professional engineering management could look like.
A missing pillar?
After you read the last edition, The Pillars, you were hopefully wondering about a critical missing piece. Everything I spoke about could be applied to any management position, but there wasn’t anything engineering-specific in the article.
An infinite technical curiosity that leads to engineering excellence is what sets aside engineering managers from other managers. While I believe this trait is paramount, I also think that it temporarily, for short periods, can take a backseat - think performance review season, company strategy and vision planning, interacting with customers, leadership offsites, etc.…
Why is an infinite technical curiosity paramount?
Builds empathy for the team
Engineers love to do what they are best at, sling code all day long. Engineering managers need to understand the pain points their team members experience while doing their jobs. We can grok some of these pain points via conversations and feedback, but that is insufficient. When an engineering manager can roll up their sleeves and contribute a little bit of code, it becomes easier to understand what engineers go through to do their jobs. Have you ever experienced
an app that takes forever to start up locally?
meaningless mocks in unit tests?
flaky integration tests?
a QA stack that was impossible to test your deployed changes on?
working from another part of the world and seeing the amount of time it took to “phone home”?
These issues will hurt morale, the flow time engineers desire, and productivity. The best engineers on the team will eventually get tired of dealing with the roadblocks and may just decide to leave the company.
Builds trust with the team
When you can ask intelligent and relevant questions about the technology your team is working on, your team will trust you more. They may even consider you as a “player-coach” vs. the detached pointy hair manager who has no idea about what the team is working on. Asking those good, and often elementary, questions will also encourage others to be vulnerable. After all, “If the boss asks these elementary questions, it’s ok for me to do so as well.”
Helps you get to know your team members
We expect engineering managers to get to know their teams in many ways. Some of these measures are qualitative, and some are quantitative. Seeing an engineer’s work product is arguably the best and most objective way to learn about the employee’s performance. The best engineers I have worked with produce pull requests that are easy to read and tell a story. Reading and working with their code has always made me feel like these top performers were sitting next to me, teaching me. These folks lead by example; their code is simple and easy to understand. The best way to recognize exceptional work products is through experiencing someone’s code firsthand.
When you develop a sense of technical excellence, it becomes much easier to coach your team. Since you can recognize technical excellence, you can work with individuals to get them there.
Your job is to represent your team
Depending on the level you are leading, leadership and stakeholders will inevitably ask you some of these questions
What would it take to build _____ new product?
How would you size _____ new product?
What additional headcount would you need to pull in the date?
What other engineering teams need to be involved?
Should we acquire _____ company?
Can you own all of product engineering at _____ company?
Capable engineering leaders should be able to answer these questions by themselves. They do not need to lug around a couple of engineers to represent their teams and answer these questions. The more an engineering manager can answer questions like the above, the more they can protect the engineers’ time. Be the first line of defense! Engineers don’t want to be in meetings; they want to spend their time in flow. Engineers will recognize when they have a technical manager to represent the team’s best interest. A manager’s technical curiosity will kickstart the virtuous trust cycle between the manager and the team.
Foster your passion
You are an engineering leader because you possess the unique mix of qualities we previously discussed. You have a strong passion for technology and are interested in the appropriate level of detail. If you forego your technical curiosity, your passion for technology may atrophy, and you will no longer be a qualified engineering leader. A few examples of this sad devolution I encountered with peers and superiors.
“Peter, I think it is ok not to write any unit tests. We could pull in delivery dates like that.” - an EM who didn’t believe in unit tests being part of the dev cycle.
“Peter, I am not interested in the details of how the API’s of our two companies connect” - a former peer Director of Engineering whose job it was to facilitate a partnership between our companies.
“I learn about the quality of work my engineers produce by talking to them in 1:1’s” - an EM when I asked how they understand the performance of engineers.
“We require EM’s to delete their IDE’s” - an engineering leader who was not aligned with my philosophy.
These folks no longer had technical curiosity and therefore could no longer perform their engineering jobs at the level I expected from them.
What we are not talking about
It is essential to touch on what we are not talking about when an engineering leader fosters their technical curiosity.
Don’t be the subject matter expert on technologies your team look after
That is not your job.
Technical curiosity cannot take priority over other job duties
Since writing code, reviewing designs, etc. are not strictly part of your job description, these activities to feed your technical curiosity can never take precedence over other managerial duties.
Don’t try to be the smartest person in the room
Engineers on the team are likely more competent than you.
Don’t be a bottleneck
You should never position yourself so that your team’s velocity depends on you. For example, you would not want to be a required reviewer on your team’s pull requests.
How can you nurture your curiosity?
There are many ways to nurture your technical curiosity. A few that worked for me before
Take a class on a relevant technology to learn the basics, and then
Enhance unit tests
Build a minor, non-critical feature that lives behind a feature flag
Have your team tear apart your pull requests
RTFC - Read The Freakin’ Code!!! Checking out the source code, understanding it, and running it locally are all helpful tactics.
Build dashboards to monitor production traffic
Understand the data - run queries, analyze the system of record
Review and deeply understand RFC’s or design documents
Seed an RFC or design document and hand it off to the experts
Be part of the on-call rotation (only do this if you can meaningfully tend to incidents)
Organize, facilitate, and understand technical leadership meetings
There are ways that I don’t believe are as helpful
Have a “hobby project” that is only marginally related to your day-to-day tech stack - a previous engineering leader I worked with used to boast about the Alexa skills he built. This technology was of no relevance to our job.
Be a required Pull Request reviewer - after all, you’re not the expert.
Summary
In this edition, we covered the importance and benefits of technical curiosity, we discussed some anti-patterns to foster this technical curiosity, as well as strategies to feed your inner nerd.