Assessing Technical-Manager Competencies and Development Gaps

Welcome back. In the previous lesson, you turned a job description into a concise role brief: eligibility gates, role-defining accountabilities, differentiators, and context. That brief is the input for today’s work.

You will now assess your own experience against the capabilities required in a specific first-line technical-manager role. The aim is not to assign yourself a flattering title or to prove you meet every possible requirement. It is to produce an honest, usable picture of:

• evidence you can already present credibly;
• experience that transfers but needs careful framing;
• genuine development gaps;
• formal requirements that cannot be solved through better wording alone.

This will give you a practical basis for choosing roles, tailoring your résumé, and focusing your limited preparation time over the next three months.

---

A competency matrix is a map, not a score

The Engineering Manager competency map below is deliberately broad. It includes technical leadership, people management, delivery, stakeholder work, operational responsibility, hiring, and organizational change. It is useful as a reminder that management is a system of responsibilities, but it is too broad to use as a personal checklist all at once.

A useful competency matrix has three properties:

1. It is role-specific. Start with the blue and red items in the role brief from the previous lesson, rather than a generic “engineering manager skills” list.
2. It describes observable behavior. “Strong communicator” is vague; “explains a delivery risk, options, and recommendation to product and engineering stakeholders” is assessable.
3. It separates capability from formal authority. Leading a project can demonstrate planning and influence. It does not, by itself, demonstrate performance management of direct reports.

The Engineering Ladders framework offers a compact way to organize this assessment. Its five axes—Technology, System, People, Process, and Influence—are particularly useful because they prevent technical experience from crowding out the rest of the role.

For a technical-manager transition, those five axes can be translated into a focused first-line-manager matrix:

Capability area	What a target technical-manager role may require	What credible evidence looks like
Technical and systems judgment	Make sound architecture, reliability, security, and operational trade-offs without personally owning every implementation	A production decision, reliability improvement, incident response, or technical plan with stated trade-offs and results
Delivery and process	Help the team turn priorities into predictable outcomes; surface risk early; improve how work flows	A project you coordinated through ambiguity, dependencies, milestones, changing scope, or a delivery recovery
People growth and team health	Coach, give feedback, support growth, and create conditions in which engineers can succeed	Mentoring, onboarding, actionable peer feedback, facilitating a difficult team conversation, and evidence of another person’s growth
Influence and stakeholder partnership	Align engineering with product, operations, security, or leadership around decisions and trade-offs	A cross-functional decision, disagreement resolved, risk communicated, or roadmap outcome shaped
Formal management responsibilities	Run one-to-ones, support performance and career growth, hire, and make staffing decisions	Direct-report management, formal feedback, performance processes, interviewing, hiring, or structured onboarding ownership

The first four areas often contain substantial transferable evidence for someone with backend, AWS, DevOps, and project-lead experience. The fifth may contain a real gap when you have not yet had direct reports. That is not a failure of the matrix; it is exactly the distinction the matrix should reveal.

---

Define the target level before judging yourself

A common assessment mistake is comparing yourself to a senior director’s responsibilities because they appear on an engineering-management ladder. Your target is a first formal management role, not an organization-wide leadership role.

Artsy’s published ladder is one company’s model, not a universal standard, but it makes the transition point unusually clear. It describes management as a balance between people leadership and delivery responsibility, while recognizing that early managers need support in some areas.

There are two important conclusions to draw.

First, management readiness is not measured solely by whether you have had a manager title. The Artsy ladder expects a first manager to improve delivery, monitor team health, help engineers grow, and connect their work to organizational goals. Project leadership can provide relevant evidence for parts of this.

Second, job titles and transferable experience are not interchangeable. If a role requires someone to independently manage six engineers, run a hiring pipeline, handle performance issues, and establish career paths, experience coordinating a technical project may be relevant—but it is not equivalent. State the overlap and the boundary accurately.

This distinction is particularly valuable in your applications. A job description demanding “three years of people management” is an eligibility issue. A role looking for evidence of team delivery, operational leadership, technical judgment, and mentorship may be a credible transition opportunity even if formal people management is still developing.

---

Turn a memory into evidence

“I led the migration” is a useful starting point, but it is not yet evidence. An interviewer or hiring manager needs enough detail to understand the scope, your authority, your decisions, and the impact on the team or business.

For every experience you place in the matrix, create an evidence card:

Evidence-card field	Capture
Situation	The business or technical context, including the problem and constraints
Responsibility	What you were accountable for—not merely what the team did
Actions	The decisions, coordination, communication, coaching, or technical judgment you personally applied
Outcome	A measurable result where possible: reliability, speed, cost, risk, quality, customer effect, or team capability
Scope	Systems involved, people or teams involved, duration, ambiguity, and decision authority
Corroboration	Metrics, project documents, stakeholder feedback, peer feedback, or a manager who can validate the account
Reflection	What you learned, changed later, or would handle differently

The distinction between activity and outcome matters. Consider these two descriptions:

Coordinated the AWS migration and held regular status meetings.

Coordinated a phased migration of three backend services to AWS, made dependency risks visible to product and infrastructure stakeholders, and introduced rollback checkpoints. The team completed the migration without customer-facing downtime and reduced deployment recovery time from [baseline] to [new measure].

The second statement is not better because it has more words. It establishes the responsibility, actions, scope, and result. Only use metrics you can substantiate; if you do not have a precise number, use a truthful operational outcome instead.

Classify evidence by closeness, not optimism

For each competency, use one of these labels:

Classification	Meaning	How to use it
Direct evidence	You performed the target behavior with comparable scope and authority	Lead with it in your résumé and interviews
Transferable evidence	You performed a closely related behavior, but without the same formal authority or scope	Explain both the overlap and the boundary
Exposure	You participated, observed, or supported someone else doing the work	Treat it as context, not proof of independent capability
Development gap	You lack a meaningful example of the behavior	Create a focused development action
Eligibility gate	The role explicitly requires a credential, authorization, domain background, or duration of formal management that you do not have	Do not average it away; target roles accordingly

For example:

• Facilitating a retrospective that led to an owned process improvement can be direct evidence of process leadership.
• Mentoring a junior engineer informally may be transferable evidence for coaching, but not direct evidence of conducting one-to-ones or performance reviews.
• Sitting in on an interview panel is exposure to hiring; independently defining a scorecard and making a calibrated recommendation is stronger evidence.
• Managing production incidents or improving deployment safety is likely direct evidence of operational leadership, assuming you can describe your decisions and outcomes.
• “Three years managing direct reports” is an eligibility gate if a posting makes it a minimum qualification.

A useful rule is: do not convert proximity into ownership. Being near a manager’s work can teach you a great deal, but it does not establish that you held the responsibility.

---

Build your one-page role-specific assessment

Take one target job description and its role brief. Then create a matrix with only the capabilities that recur in that role. A first draft should fit on one page.

Role-defining capability	Target behavior	Your strongest evidence card	Classification	Gap or next action
Delivery leadership	Establish milestones, make risks visible, coordinate dependencies	[Initiative, scope, outcome]	Direct / transferable / gap	[Evidence to retrieve or skill to build]
Operational judgment	Balance reliability, cost, and delivery in production systems	[AWS or DevOps example]	Direct / transferable / gap	[Evidence to retrieve or skill to build]
Stakeholder influence	Align product and engineering around a trade-off	[Decision or conflict example]	Direct / transferable / gap	[Evidence to retrieve or skill to build]
People growth	Help an engineer make progress through coaching or feedback	[Mentoring or onboarding example]	Direct / transferable / gap	[Evidence to retrieve or skill to build]
Formal people management	Hold one-to-ones, set expectations, manage performance and career growth	[Direct-report example, if any]	Direct / transferable / gap	[Development plan or role-targeting decision]
Hiring and staffing	Evaluate candidates, define needs, support hiring and onboarding	[Interview or onboarding example]	Direct / transferable / gap	[Evidence to retrieve or skill to build]

Keep explicit eligibility gates in a separate box above the matrix. They are not competencies to average with technical strengths.

A provisional starting assessment

Based on the experience you described—five years in backend engineering and DevOps, strength in JavaScript and AWS, and project/technical coordination—your first draft may look something like this. Treat it as a hypothesis to validate with your own evidence cards, not as a claim to copy into an application.

Area	Likely current position	What would make the evidence credible
Technical and operational leadership	Potentially direct evidence	Identify an AWS, deployment, reliability, cost, or incident example where you made a trade-off and can show the result
Project delivery and coordination	Potentially direct evidence	Show how you structured work, handled dependencies or risks, communicated status, and improved the outcome for the team
Cross-functional influence	Likely transferable to direct evidence	Document a concrete decision involving product, operations, security, or another engineering team, including your role in reaching alignment
Mentoring and peer support	Transferable evidence, if you have actual examples	Describe who you supported, how you adapted your guidance, and what changed for that person or team
Formal people management	Genuine development gap if you have not managed direct reports	Do not claim performance management, career ownership, or recurring one-to-ones without having done them
Hiring and structured evaluation	Unknown until inventoried	Record any interviewing, candidate feedback, onboarding, or role-definition experience; otherwise classify it as a gap

Your technical and delivery background can be compelling for technical-manager roles that need operational maturity. The key is showing that your effect was not only “I solved a difficult technical problem,” but also “I enabled a group to make a better decision, deliver more safely, or operate more effectively.”

This short interview segment reinforces why this distinction matters: evaluators look beyond prior titles for real leadership actions, difficult situations, and demonstrable impact.

---

Name the gap correctly, then prioritize it

Not all gaps need the same response. Mislabeling them wastes preparation time.

Gap type	Example	Best response over the next three months
Presentation gap	You led delivery well but your résumé says only “built” or “implemented”	Retrieve outcomes, write evidence cards, and prepare a concise leadership story
Experience gap	You have never facilitated a cross-team planning or risk discussion	Seek a legitimate opportunity to own or co-lead one
Scope gap	You led one project but have not influenced across teams	Target a broader initiative, or frame your current scope honestly while pursuing junior-manager roles
Formal-authority gap	You have mentored peers but have never handled performance management	Do not disguise it; learn the practice, seek supervised responsibility where appropriate, and apply to transition-friendly roles
Eligibility gap	A posting requires several years of direct people management	Prioritize other roles rather than trying to “close” a time-based requirement through wording
Domain gap	The role requires experience in a specialized area such as data streaming or security	Decide whether your adjacent experience is sufficient, then study or target accordingly

For your situation, the highest-return work is likely to be split between making existing evidence visible and creating carefully chosen people-leadership experience.

A practical sequence is:

1. Inventory three technical/delivery stories. Choose examples involving AWS operations, backend systems, project coordination, incident learning, or cross-functional delivery. Capture the evidence card for each.
2. Inventory two people-impact stories. These may involve mentoring, onboarding, helping resolve a disagreement, improving team process, or giving feedback. Be exact about your authority.
3. Seek one legitimate stretch responsibility. Possibilities include owning onboarding for a new engineer, facilitating a retrospective, coordinating an initiative with multiple contributors, or mentoring with explicit agreement from your manager and mentee. The point is to practice people and process leadership, not to perform unofficial management.
4. Calibrate your self-assessment. Ask a trusted engineering peer, cross-functional partner, and manager for feedback on one or two evidence cards. Ask what impact they saw, what you did well, and what they would need to see to view you as ready for greater leadership scope.
5. Target roles intelligently. Favor postings where technical judgment, delivery leadership, and mentorship are core, while recognizing that a hard formal-management gate may make some roles poor targets today.

Feedback is especially important because self-assessment can fail in both directions. You may understate valuable leadership because it felt like ordinary teamwork, or overstate a contribution because you remember the pressure of the work more vividly than your actual authority. External evidence corrects both errors.

---

Key takeaways

A role-specific competency matrix turns an abstract management ambition into an evidence-based transition plan.

• Build the matrix from the role brief, not from a generic list of management skills.
• Assess technical judgment, delivery, people growth, influence, and formal management separately.
• Use evidence cards that establish situation, responsibility, actions, outcome, scope, corroboration, and reflection.
• Classify each capability honestly as direct evidence, transferable evidence, exposure, development gap, or eligibility gate.
• Do not treat project leadership as identical to formal people management, even when both involve coordination and influence.
• Prioritize gaps differently: improve presentation gaps quickly, create legitimate experience for behavioral gaps, and target around hard eligibility gates.

Next, you will use the strongest evidence from this matrix to rewrite a résumé bullet so that it demonstrates quantified leadership impact rather than task completion.