The Engineering Manager Playbook

3.3 - Seeing potential and mastering delegation

One of the hardest habits to break when moving from Architect to Engineering Manager is the belief that "If I want it done right, I have to do it myself".

If you hold onto all the complex, interesting technical work, you become a bottleneck. Worse, you starve your team of the opportunities they need to grow. Delegation is not about dumping boring tasks on junior developers; it is about strategically matching challenges with human potential.

Building the team with the SFIA framework

When mapping potential and building a team from the beginning, the SFIA (Skills Framework for the Information Age) is an invaluable tool. It allows you to objectively measure an engineer's Autonomy, Influence, Complexity, and Business Skills.

By aligning your delegation matrix with SFIA levels, you ensure that every assigned task is a stepping stone toward the engineer's next career milestone:

  • High Skill + High Motivation: Delegate the outcome, not the process. Give them a complex architectural goal and get out of their way. Act only as a sounding board.
  • Low Skill + High Motivation: This is a growth opportunity. Pair them with a senior engineer or provide clear, step-by-step guidance. This is where you invest your coaching time.
  • High Skill + Low Motivation: They are bored. They have done this a hundred times. Delegate this task to someone else if possible, or automate it. If they must do it, explain the critical business "why" behind it to reignite purpose.
  • Low Skill + Low Motivation: You have a performance or alignment issue. Do not delegate critical path work here until you debug the root cause in a 1:1.

Delegating using S.M.A.R.T. goals

When you hand off a major technical design, the anxiety of losing control can trigger micromanagement. To prevent this, establish "Guardrails, not Gates" by relying on S.M.A.R.T. goals for their delegated KPIs and OKRs:

  1. Specific: Define the "What" and "Why", not the "How". Explain the business requirement (e.g., "It needs to handle 10k requests per second") and let them design the implementation.
  2. Measurable: Establish metrics to track progress objectively without hovering over their shoulder.
  3. Achievable: Allow safe failures. If their proposed architecture meets the requirements but is slightly less efficient, let them build it. The learning experience is worth it.
  4. Relevant: Connect the task to the broader business OKRs so they understand why their work matters.
  5. Time-bound: Set Checkpoints, Not Deadlines. Instead of saying, "Show me the finished code on Friday," say, "Let's review your database schema draft on Tuesday before you start coding".

🎯 Self-Reflection for You

  1. Look at your task list. Are you holding onto a complex coding task right now just because it feels comfortable?
  2. Who on your team is ready for a bigger challenge, and what are you afraid will happen if you give it to them?

Mastering delegation requires letting go of your ego as the "smartest coder in the room". If you are struggling to hand over the technical reigns, let's build a safe delegation framework in a virtual coffee chat.

Build: 4