A 12-Week Coding Refresh Plan for Engineering Managers Moving to FDE

A 12-Week Coding Refresh Plan for Engineering Managers Moving to FDE

You have been in management for 2, 5, maybe 10 years. You can still read code. You can still review designs. You can still debug at a high level. But you know — and your fingers know — that you are not the engineer you used to be.

This plan is designed to rebuild your hands-on production skills in 12 weeks. It is not a "learn to code" guide. You already know how to code. This is a "get back to production speed" guide. The difference matters: you do not need theory. You need reps.

The atrophy inventory

Before building a plan, understand what has actually degraded:

Skills that usually survive management

• Architectural judgment. You still know how to evaluate a system design. This skill is exercised in design reviews and technical strategy work.
• Code reading. You can still read code and understand what it does. This skill is exercised every time you review a PR or investigate an incident.
• Technical communication. You can still explain complex systems clearly. This skill is exercised in every meeting, doc, and presentation.

Skills that usually atrophy

• Code velocity. You cannot write code as fast as you used to. Your fingers have lost the muscle memory, and your knowledge of current tooling is stale.
• Tooling familiarity. The build tools, testing frameworks, and deployment pipelines have evolved. You are 1–3 years behind.
• Debugging speed. You can still debug, but you delegate it now. The speed and patience required for deep debugging have diminished.
• On-call reflexes. Production incidents used to be your domain. Now you manage the response rather than execute it.
• Infrastructure operations. You used to set up servers, configure networks, and manage deployments. Now you have a platform team for that.

This plan targets the atrophied skills specifically. It does not waste time on things you already know.

Week 1–2: Rebuild coding velocity

Goal: Write code daily until it feels natural again.

Week 1: Choose your stack and start coding

Actions:

• Choose the language you will use for FDE work. If you have no preference, pick Python — it is the most versatile for FDE tasks (scripting, APIs, data work, integrations).
• Set up your development environment: editor, debugger, linter, formatter.
• Complete 30 easy coding challenges on LeetCode or Exercism. Do not optimize for algorithmic brilliance — optimize for speed. You want to write correct code without hesitation.
• Build a small CLI tool: a log parser, a CSV analyzer, or a task manager.

Checkpoint: You can write a correct, clean solution to an easy problem in under 10 minutes.

Week 2: Build something real

Actions:

• Build a REST API with 5 endpoints. Include authentication, error handling, and input validation.
• Write tests for every endpoint. Use a testing framework appropriate for your language.
• Deploy it locally with Docker. Set up a database and connect it.
• Time yourself. How long did the entire process take? Record it — this is your baseline.

Checkpoint: You have a working, tested, containerized API. You know your current speed.

Week 3–4: Modernize your tooling

Goal: Close the tooling gap created by years away from daily engineering.

Week 3: Learn the current ecosystem

Actions:

• Research the current standard tools in your language's ecosystem:
  • Python: uv (package manager), Ruff (linter), pytest (testing), FastAPI (web framework)
  • TypeScript: pnpm (package manager), Vitest (testing), Hono or Express (web framework)
  • Go: standard tooling is largely unchanged
• Migrate your Week 2 project to use the current standard tools.
• Read 3 blog posts or watch 3 talks about the current state of your language's ecosystem.

Checkpoint: You are using current tooling, not the tools you remember from 2020.

Week 4: CI/CD and deployment

Actions:

• Set up a CI/CD pipeline for your project using GitHub Actions.
• Configure the pipeline to: lint, test, build, and deploy.
• Deploy your API to a cloud platform: Cloudflare Workers, Fly.io, Railway, or AWS Lambda.
• Set up monitoring and logging in the deployed environment.

Checkpoint: You have a fully automated pipeline from code push to production deployment.

Week 5–6: Debugging practice

Goal: Rebuild the debugging stamina and speed you had as an active engineer.

Week 5: Structured debugging

Actions:

• Find 5 open bugs in open-source projects. Pick projects you use or know well.
• For each bug: read the issue, reproduce it, diagnose the root cause, and submit a fix.
• Time yourself for each one. Track your speed and accuracy.
• Write a brief analysis for each: What was the symptom? How did you find the root cause? What tool did you use?

Checkpoint: You can diagnose and fix a real bug in under 30 minutes for simple issues.

Week 6: Production debugging simulation

Actions:

• Ask a friend or colleague to introduce a bug into your deployed API. Do not tell them what kind of bug.
• Set a timer for 45 minutes. Find and fix the bug using only logs, monitoring, and debugging tools.
• Write a postmortem: Timeline, root cause, fix, and prevention measures.
• Repeat with a different bug type (performance, security, data).

Checkpoint: You can diagnose a production issue within 45 minutes using systematic debugging.

Week 7–8: System design and architecture

Goal: Rebuild the habit of thinking about systems, not just code.

Week 7: Modern system design

Actions:

• Study the current state of distributed systems: serverless, edge computing, event-driven architecture, and microservices patterns.
• Design 3 systems on paper: a URL shortener, a notification service, and a rate limiter.
• For each design, identify: the key components, the data flow, the scaling bottlenecks, and the failure modes.
• Review your designs with an active engineer. Get feedback on your assumptions.

Checkpoint: You can design a system and articulate the trade-offs.

Week 8: Architecture in practice

Actions:

• Refactor your API from Week 2 based on what you learned in system design. Add: caching, rate limiting, structured error handling, and proper database indexing.
• Set up a staging environment separate from production.
• Deploy changes to staging first, then promote to production.
• Document the architecture in a design doc format.

Checkpoint: You have a production-grade API with staging and production environments.

Week 9–10: Customer-facing skills

Goal: Combine your rebuilt technical skills with your existing management skills.

Week 9: Customer discovery

Actions:

• Conduct 3 customer discovery conversations. Use your existing stakeholder management skills — you already know how to ask questions and manage conversations.
• For each conversation, write a structured brief: What the customer needs, what they are currently doing, and what you would build technically.
• Review each brief with a technical colleague. Is the proposed solution feasible?

Checkpoint: You have 3 customer briefs that combine business understanding with technical feasibility.

Week 10: Build a customer solution

Actions:

• Pick the most promising problem from your customer briefs.
• Build a solution: an integration, a dashboard, a script, or a configured tool.
• Deploy it to production. Write a user guide for non-technical users.
• Create a short demo video (2–3 minutes) showing the solution.

Checkpoint: You have a deployed solution that demonstrates both customer understanding and technical execution.

Week 11–12: Packaging and interview prep

Goal: Convert your 12 weeks of work into interview-ready evidence.

Week 11: Portfolio creation

Actions:

• Create a portfolio that includes:
  • Your API and deployment pipeline (Weeks 1–4)
  • Your debugging postmortems (Weeks 5–6)
  • Your system design documents (Weeks 7–8)
  • Your customer briefs and deployed solution (Weeks 9–10)
• For each piece, add context: What was the problem? What did you build? What was the outcome?

Checkpoint: You have a complete portfolio that demonstrates current technical skills.

Week 12: Story preparation and resume update

Actions:

• Write 4 STAR stories:
  1. A time you made a technical decision and the trade-offs involved.
  2. A time you debugged a production issue (use your Week 5–6 work).
  3. A time you discovered a customer's actual need (use your Week 9 work).
  4. A time you translated technical work for a business audience.
• Update your resume to lead with: "Engineering leader returning to hands-on FDE work with current production skills."
• Practice each story until you can deliver it in 2–3 minutes.

Checkpoint: You have 4 polished stories and an updated resume.

Progress tracking

Common mistakes to avoid

1. Trying to learn everything. You do not need to become an expert in every new tool. You need to become proficient in the tools FDEs use daily.
2. Spending too much time on algorithms. FDE interviews test practical coding and system design, not competitive programming. Focus on building and shipping, not on LeetCode Hard.
3. Ignoring your management experience. Your stakeholder management, delivery discipline, and communication skills are assets, not liabilities. Frame them as strengths, not as things you are compensating for.
4. Not timing yourself. Speed matters in FDE work. You need to know your current velocity and track its improvement.

Your next step

Before starting this plan, take our free self-assessment. It evaluates your current coding velocity, tooling knowledge, debugging speed, and customer-facing skills — then gives you a personalized roadmap that adjusts the 12-week plan to your specific atrophy profile.

Start Free Assessment

Frequently asked questions

How much time per week does this require?

Plan for 12–15 hours per week. All activities can run alongside a full-time management job. The coding and debugging exercises can be done in the evenings or on weekends. The customer discovery conversations can be scheduled during work hours if your company supports it.

What if I have been in management for 5+ years?

Add 2–4 weeks to the plan. The longer you have been away from daily coding, the more time you need to rebuild velocity. The plan structure stays the same — you just spend more time in Weeks 1–4.

Should I use the language I used as an engineer or learn a new one?

Use the language that FDE roles at your target companies require. If your old language is still common (Python, Java, JavaScript), stick with it — you will recover faster. If your old language is less common in FDE work (C++, Ruby), switch to Python or TypeScript. The cost of learning a new language is less than the cost of being proficient in one that is not used.

Can I do this while still employed as an EM?

Yes, and you should. Staying employed gives you income, access to engineers who can review your code, and proximity to customers (if your company has them). The only reason to leave your job before completing the plan is if your management role is so demanding that you cannot commit 12 hours per week to skill-building.