You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 9 minutes
Key takeaways:
- Technical proficiency is no longer optional for engineering managers. It gives you credibility, protects your team’s focus time, and enables sound decisions without pulling engineers away from their work.
- Staying technical requires deliberate investment.
- You don’t need to be the best coder in the room: the goal is to understand what your team is building, why decisions were made, and what’s at stake – not to out-code your engineers.
As an engineering manager you’ve probably felt it: the creeping distance from the technical work your team does every day. James Stanier puts it plainly: “People management is necessary, but no longer sufficient on its own.”
So how do you close the gap? Before we can identify how to maintain technical proficiency, we must first define what it means.
What is technical proficiency?
Technical proficiency as an engineering manager is not necessarily the ability to code and contribute to the product/tech roadmap (although it can vary from company to company).
Technical proficiency is the ability to understand codebase architecture and identify technical bottlenecks. It’s having an understanding of the tools and technologies your team is using to make sound judgement calls, identify potential issues or areas for opportunity, and develop a sound technical strategy.
The importance of technical proficiency for engineering managers
Being technically proficient is no longer a “nice to have” in the field of engineering management. It’s a requirement. Beyond that, technical proficiency has four direct impacts in your work.
1. Gives you credibility with your team
Your engineers want to know that their manager has their best interests in mind when representing them to leadership. Having a complete understanding of the work and the challenges faced by the team gives the engineers confidence that you are able to properly speak on their behalf with key stakeholders.
2. Protects the engineer’s focus time
Instead of pulling in an engineer or two to discuss a technical topic, being technically proficient allows the engineering manager to make decisions without distracting the engineers from their daily tasks.
3. Reduces the feedback loop
As James Stanier discussed in his article, being technically proficient means you’re close to the details and can shorten the feedback loop with stakeholders.
4. Promotes effective hiring practices
As an engineering manager, part of your role is to hire great engineers. It’s much easier to do that when you have a complete picture of what the role of an engineer on your team requires.
Now that we’ve discussed what technical proficiency means and why it’s important, let’s dive into four ways you can maintain your technical proficiency as an engineering manager.
1. Master the art of prompt engineering
Prompt engineering is the practice of writing inputs to AI language models to get the most reliable and relevant outputs. For example, let’s suppose you want to evaluate the tradeoffs between two technical solutions.
An ineffective prompt would be: “what are the tradeoffs between microservices and a monolith?”
This is ineffective because the prompt is generic, short, and provides no context on the problem space.
In contrast, a good prompt would be:
“You are a senior software architect advising an engineering manager at a mid-sized SaaS company with a team of 12 engineers. We currently have a monolithic Rails application serving 500,000 users and are considering migrating to microservices. Our main pain points are deployment bottlenecks and team scaling. Evaluate the tradeoffs between continuing with the monolith versus migrating to microservices, considering our team size, operational complexity, short-term velocity, and long-term scalability. Present your answer as a structured comparison and end with a recommendation.”
This is a much more effective prompt because it:
- Asks AI to adopt a persona: senior software architect.
- Provides context: team size, technical stack, and user scale.
- Clearly describes the problem: deployment bottlenecks and team scaling.
- Details the evaluation criteria: which tradeoffs are most important.
- Clarifies the desired output format: structured comparison followed by a recommendation.
Effective prompt engineering will not only save you time, but can improve the quality of your outputs. As an engineering manager, some of the tasks you can leverage AI for to improve technical proficiency include:
- Triaging and potentially fix bugs in the codebase.
- Creating performance evaluation frameworks.
- Writing detailed technical strategies.
- Getting comprehensive overviews of the codebase architecture.
- Creating tooling diagrams.
To learn more about effective prompt engineering, I highly recommend Google’s Prompting Essentials Specialization on Coursera.
Of course, no AI model can truly replicate the institutional knowledge in your team’s heads. That’s where your second strategy comes in.
2. Pair with your engineers
One of the best ways to learn about the codebase, architecture, and tooling is by pairing with engineers on a task. An important note:you should not pair too often with a particular engineer as it would take time away from their own work. Use this power sparingly.
The best types of tasks to pair on are those that benefit the team/codebase but aren’t critical to the roadmap, as there is no timeline urgency but the task is useful to the team.
Some tips for pairing with an engineer:
- Be honest about your goal: by sharing your goal of improving technical proficiency, it removes ambiguity from the situation where the engineer may worry about being evaluated.
- Pick a time-bound or requirements-bound task: choose tasks that have clear boundaries (either time-boxed to 60 minutes or less, or with a clear outcome) to avoid a long-running session. Remember that this session mostly benefits you, so you must be cautious not to take too much time from your team.
- Determine who should lead: if your goal is to be able to triage and fix bugs and you have coding experience feel free to drive the session. If your goal is to learn more and see how an engineer would solve a problem, allow them to drive.
- Ask “why:” your goal should be to understand why you built the solution in a particular way and why certain choices were made.
- Document tasks or topics to follow-up on: during your session you will likely encounter other technologies you want to look into. Write them down for later investigation.
Some example tasks which could be good candidates for pairing include reviewing a pull request (PR) together and investigating a low-priority bug
Some tasks which might not necessarily be good candidates for pairing include incidents in production (time sensitive), investigating a new tool or technology (open-ended), and deep algorithmic or performance optimization tasks (too technical).
Pairing sessions are powerful, but they’re not consistent. You learn in temporary bursts tied to scoped tasks. In order to build deeper understanding, you need a more deliberate approach.
3. Become knowledgeable in a relevant domain
One of the best ways to feel technically competent is by slowly increasing the number of domains you’re knowledgeable about. Start by selecting one domain in your team space to gain knowledge in. Once you’re comfortable in that domain, pick another domain to learn about. Over time, your knowledge will compound such that you’re well-rounded in your technical expertise.
The domain you choose should be relevant to your team’s work:
- What does your team work on right now?
- Where do you feel the least confident in your judgement?
- Where do most technical decisions get made?
To build domain knowledge you should:
- Balance learning concepts with utilizing those skills in practice.
- Find a technical mentor on or outside of your team.
- Dive deeper into technical documents (from high-level blog posts to requests for comments (RFCs) and tech specifications).
- Timebox learning to be regular throughout your weeks.
For example, let’s suppose you want to become more competent in the area of observability.
Month one: learn the foundations
You ask a senior engineer to provide an overview on how the current logging and metrics work. You spend time reviewing the OpenTelemetry and Honeycomb docs and watch a few conference talks on distributed tracing.
Month two: gain hands-on experience
You ask the senior engineer to pair with you on adding basic tracing to part of the codebase. You also kick-off a personal project to learn more about telemetry.
Month three: apply your knowledge
You are more engaged in technical discussions and are able to contribute meaningfully when the team discusses adding a new service. When reviewing architecture RFCs, you’re able to identify observability gaps.
Over the coming months, you feel more confident about your observability knowledge. Once you gain confidence in this area, find a new area to lean into.
Domain knowledge provides you with a vocabulary. The next step puts it to work where it matters most: the rooms where your team’s most consequential technical decisions are made.
4. Engage in architecture and design reviews
Architecture and design reviews are where the most consequential decisions are made. They often affect scalability, maintainability, hiring, cost, and team velocity for years to come.
Before reviewing an RFC or preparing for an architectural/design proposal review, you should begin by reading the document or pre-work two times.
- First read-through: do not highlight or take notes. This pass is simply to put your brain in the right context. During this iteration, think about the implication on your team and the business.
- Second read-through: highlight important information and take notes on questions you may have, gaps you’ve noticed, or to highlight key takeaways. During this pass, think about the implication on the codebase.
If there is a live review, ask clarifying questions where appropriate (“can you help me understand why we chose Y?”), do not ask leading questions (“shouldn’t we just use X?”) or questions which aren’t relevant to the desired goal of the meeting.
Additionally you should consider secondary or tertiary implications of the proposed changes. RFCs often account for primary consequences, however secondary and tertiary consequences may not be as obvious.
For example, if your team is proposing replacing a set of synchronous REST API calls between internal services with an asynchronous event-driven system using Kafka, the consequences may be:
- Primary: reduced coupling between services, better handling of traffic spikes, or improved fault tolerance if a downstream service goes down.
- Secondary: with synchronous failures, failure is immediate and obvious. Failures with Kafka can be silent and delayed, thus a consumer may lag by hours before noticing and events could be processed in the wrong order. Debugging will now require correlating logs across producers and consumers with an unclear request trace.
- Tertiary: currently an engineer can read the REST APIs and create a mental model of how services communicate. With an event-driven system, the data flow is implicit, which will complicate onboarding for new engineers.
Technical proficiency for engineering managers
Technical proficiency as an engineering manager is not something you acquire once and keep forever. It requires active, ongoing investment. The good news is that you don’t have to do it all at once.
Small, consistent actions compound over time. Your engineers don’t need you to be the best coder in the room. They just need you to understand what they’re building, why it matters, and what’s at stake.
