How I Turn Regular Developers into 10x Engineers

The execution system that helps engineers own their growth, nail refinements, and actually deliver on quarterly goals

A while back, I wrote about how journaling changed the way I work. Daily prompts, a simple routine, a habit that took months to pay off but eventually reshaped how I think about my own decisions.

I Journaled for 90 Days with AI—Here's My Exact System (Templates Included)

I’m not repeating that article here. What I want to show you is what happened when I handed the same system to a handful of developers on my teams - and connected it to AI.

Not everyone. Not even most people. But for the ones who wanted it, the results were worth writing about.

---

---

Why journaling comes before AI

I’ve been running this with hand-picked developers for several months. People who showed genuine interest in getting better, not people I picked to fix.

That distinction matters more than anything else in this article.

If someone’s burned out, this isn’t for them. They need recovery, not another system to maintain. I tell developers upfront: commit to at least 2-3 months of consistent journaling before you expect to see anything. Four months is better.

Why so long? Because that’s roughly how long it takes to actually see your own patterns. Your false beliefs. The mistakes you keep making without noticing.

AI doesn’t replace that timeline. It makes what you find during it more useful.

I won’t repeat the journaling prompts here - they’re in the earlier article. What’s new is what happens once a developer has that habit and I hand them an AI advisor on top of it.

---

---

How to build an AI advisor for your engineers

Beyond journaling, I have developers build what I call their “Gem” - an AI assistant configured specifically for their role. Part solution architect, part tech lead, part advisor.

I recommend Gemini because we run on Google Workspace and developers are already there. But the tool doesn’t matter. You could build the same thing in Claude Projects or a custom GPT. The method is what matters, not the platform.

Why bother at all? Because developers need someone to think through problems with before code gets written. In an ideal world, every developer has constant access to a senior architect asking hard questions. In reality, that doesn’t scale. An AI advisor does.

The Gem alone isn’t enough, though. It needs two layers of context to be useful instead of generic.

Knowledge Base. This is the organizational reality a developer works in - who reports to whom, what roles people play, how the company actually functions. Feed the AI your real environment and it stops giving generic advice.

I don’t ask developers to map the whole org chart. Nobody needs a Gem that knows the VP of Finance exists. What actually matters is what’s close: the immediate team, the manager, the two or three stakeholders who show up in decisions every week, and a few sentences on the project itself.

I have developers write this as a single document, structured roughly like this:

## Team
- Who's on it, what each person owns, how decisions get made
  (consensus, tech lead calls it, manager decides)

## Manager
- Written by the developer, from their own perspective
  (this is the piece I never read - more on that below)

## Key Stakeholders
- Product Manager: priorities, how they like requirements framed
- Tech Lead: what they're strict about in review, what they let slide
- Anyone else the developer regularly needs sign-off or input from

## Project Context
- What the team is building, in a few sentences
- Current priorities for the quarter
- Known technical constraints or recurring friction points

If you’ve used Claude Code, this will look familiar - it’s the same idea as a CLAUDE.md file. One document that gives an AI the standing context it needs, so you’re not re-explaining who your tech lead is every single conversation. I tell developers to treat it the same way: write it once, update it when something real changes, and let every prompt inherit it automatically.

The version quality matters more than the length. A three-paragraph document that’s actually accurate beats a five-page org chart nobody keeps current.

Advisory Board. These are expert personas the developer wants advice from - not real people they message, but voices that guide their daily reflections. I suggest four:

• Martin Fowler, for software design and refactoring

• Grace Hopper, for practical engineering and debugging

• Elon Musk, for ambitious, first-principles thinking

• Their engineering manager - me, in this case

The value here is simple: one journaling session, four different lenses. Without this, a developer reflecting alone tends to think in circles - the same instincts, the same blind spots, every time. With the Advisory Board, the same entry gets read through a design lens, a pragmatic engineering lens, an ambition lens, and their own manager’s known priorities. That’s not four opinions for the sake of it. It’s the closest thing to a room full of senior people reviewing your thinking, on demand, every single day.

The full Gem configuration - including exactly how to wire this into journaling - is in the prompts section at the end of this article.

---

Why I never read what engineers write about me

That last board member works differently than the first three, and it’s the part people ask about most.

I tell developers to describe their manager: how they see me, how I work, what I care about. I don’t check it. I don’t ask about it. I don’t look.

Here’s why that restriction matters. It forces the developer to articulate their own mental model of what I expect - and once that’s explicit, on paper, in their own words, the AI can actually work with it.

Say I’ve mentioned in one-on-ones that I pay close attention to error handling in code review, and that it traces back to a past production incident. A developer will likely write that their manager “pays close attention to quality” or “often nitpicks” - and mention why.

From there, the Gem starts suggesting things like: check that PR extra carefully, make sure the edge cases are covered, your manager looks closely at error handling.

That’s not surveillance. That’s a developer teaching their own AI to help them meet expectations they already understood - just never operationalized.

---

2 ways this system actually pays off

I’ve watched developers use this Gem for a lot of things. Two produced results consistently enough that I now recommend them by default.

How to Prep for Refinement Faster

This is where I’ve seen the fastest, most obvious impact.

Most developers walk into a refinement having skimmed the requirements for a few minutes. Nobody has systematically worked through edge cases, architectural implications, or hidden dependencies. So the first twenty minutes of the meeting gets spent figuring out what questions we should even be asking.

Two ways to get the requirements in front of the AI these days. The manual one still works: export the epic from Jira as a CSV, paste it in, run the prompt below.

The other option is MCP - but worth being precise about where it applies. Gemini Gems don’t support MCP connections, so if your Gem lives in Gemini, the CSV export is still your path. If you’re running this through Claude or Claude Code instead, you can connect Jira via MCP and just ask for a ticket by ID, no export needed. Neither is objectively better - it’s a question of which tool your advisor lives in.

Whichever way you get the data in, the value is the same:

Developers who do this show up with a page of specific questions. They’ve already compared two or three technical approaches. They’ve flagged what’s ambiguous. Refinements turn into actual decision-making sessions instead of discovery sessions.

If you want repo-level context on top of that, connect a GitHub or GitLab MCP server too, or run the same prompt through Claude Code first - either way you’ll surface existing patterns worth reusing, live from the actual codebase instead of what the developer remembers about it.

How to Make Quarterly Goals Stick

This one’s more subtle, but I’d argue it matters more long-term.

I run a cascading OKR model: company goals feed team goals, team goals feed individual goals. The typical failure mode is well known - people agree to a goal in week one, then sprint work swallows it whole. By the quarterly retro, the goal barely moved.

How to Set Quarterly Goals That Your Team Actually Achieves

The usual fix is manager check-ins. Weekly “how’s your goal going” questions in one-on-ones. It works, but it makes ownership feel external - like I’m responsible for their goal, not them.

The Gem builds an actual execution system instead. Since it already has the developer’s context from the Knowledge Base, it focuses entirely on building a sustainable routine: block Wednesday mornings, 9 to 11am, before standup - not “sometime this week.” Draft a weekly update template for the team channel so sharing progress stops requiring willpower. Prepare specific questions for the next one-on-one instead of vague status updates.

It even routes through the Advisory Board. Stuck on a technical approach - that’s Fowler’s territory. Feeling demotivated - Hopper’s pragmatic voice fits better. Wondering if you’re being ambitious enough - Musk chimes in.

The goal becomes part of the weekly rhythm instead of something remembered during review season.

---

---

Who this system is not for

Most productivity systems fail because they’re too complex to maintain past week two. This one avoids that trap because the Gem does the heavy lifting - the developer just shows up with honest reflections.

But it only works for people who genuinely want to grow. I’ve watched solid contributors become exceptional through this. Not a personality transformation - consistent self-reflection paired with intelligent prompting. They start noticing what energizes them, what drains them, where they consistently underestimate effort.

If someone’s recovering from a rough period, or simply isn’t interested in structured self-development right now, this isn’t for them. That’s fine. Not every tool fits every person at every point in their career.

For developers hungry to level up, though - try it for a quarter. See what happens.

---

Ready-to-Use Prompts

Refinement Prep Prompt

If you’ve connected Jira through MCP, skip the export - just tell your AI advisor which ticket to pull (”get PROJ-482 with all subtasks”) and use the same structured prompt below on top of that live data. No MCP yet? The manual version still works fine:

I'm preparing for a refinement session. I've exported requirements from Jira (entire epic with subtasks as CSV) and need your help analyzing them to prepare better.

Requirements:
[paste exported CSV or requirements text here - or, if connected via MCP, say "pull ticket [ID] with all subtasks" instead]

Your job is to ask me the hard questions that will surface risks, ambiguities, and hidden complexity BEFORE we get into the refinement. Don't assume you know our codebase - instead, guide me to think deeper about what we're building.

Please analyze and ask me:

1. Clarification Questions - what's unclear, where will people interpret this differently, what assumptions are hidden, which acceptance criteria need more detail?
2. Edge Cases & Error Scenarios - what happens when things go wrong, what's missing here, where could user behavior surprise us, what's the rollback plan?
3. Technical Approach - what are 2-3 different ways we could solve this, simplest vs. most robust, where might we over-engineer, what existing patterns should we reuse?
4. Dependencies & Integration - what other systems does this touch, who else needs to be in the room, what needs to be ready before we start?
5. Scope & Phasing - can this be broken down smaller, what's MVP vs. nice-to-have, what can we defer?
6. Risk Assessment - what's the riskiest part, where are we likely to underestimate effort, what would make this take 3x longer?
7. Questions for Stakeholders - what must we decide now vs. later, what do we need from the Product Owner, where do we need technical leadership input?

After this analysis, tell me: which 3 questions are most critical to answer in the refinement, what's my biggest blind spot based on how these requirements are written, and should we split this into multiple sessions?

Quarterly Goals Prompt

I have a quarterly goal I need to own and deliver. You already have my context from the Knowledge Base (my role, team structure, manager's expectations). Now help me build a system to actually achieve this.

My quarterly goal: [describe your specific OKR or goal]
Success looks like: [concrete outcome]
Quarter deadline: [specific date]

Help me build an execution system:

1. Break down the work - major phases, what's sequential vs. parallel, what's dependent on others, minimum viable version of success.
2. Weekly work routine - realistic weekly hours, which day and time to block, one focused block or several smaller sessions, what "done for the week" looks like.
3. Progress tracking - should I post weekly updates, what format, when to check in informally vs. wait for 1-on-1s, how do I show progress on invisible work like research.
4. Weekly reflection questions - give me 3-4 questions to ask myself every Friday.
5. Managing conflicts - how do I decide when sprint work collides with goal work, what's the minimum I protect each week, when do I escalate that this goal is at risk.
6. Risk mitigation - what would make me fail this silently, what should be true by week 4, 8, and 10 to stay on track, what's my recovery plan if I'm behind at mid-quarter.
7. Leveraging my Advisory Board - who should I consult for technical decisions, for motivation, for ambiguity, for good-vs-perfect calls.

Now give me: a weekly checklist for this goal, a template for my Friday reflection, a message template for my weekly team channel update, and three questions to ask my EM in our next 1-on-1 about this goal.

Gem Configuration

You are a solution architect, tech lead, and technical advisor for a software developer.

Your role:
- Help analyze technical requirements and surface edge cases
- Guide refinement preparation and code review
- Connect daily work to quarterly goals
- Prompt reflection on code quality and architecture decisions

Advisory Board:
- Martin Fowler (software design and refactoring)
- Grace Hopper (practical engineering and debugging)
- Elon Musk (ambitious thinking and first principles)
- [Developer's Engineering Manager] (as described by the developer)

When the developer journals:
- Ask how today's work contributes to their quarterly goals
- Suggest specific quality checks based on their manager's known priorities
- Prompt reflection on what went well and what could improve
- Help identify patterns in their work and blockers

---

A quick note: this piece was originally published as a guest post for Alex Ponomarev ’s newsletter, Thriving in Engineering. You know how it goes when you come back to your own writing after some time - I couldn’t resist tightening up the language and structure a bit, so what you’re reading here is the revised version.

Either way, go subscribe to Alex’s newsletter if you haven’t already. I read it regularly myself, and it consistently delivers real value for my day-to-day work.