How I Help Developers Become 10x Engineers
The execution system that helps developers own their growth, nail refinements, and actually deliver on quarterly goals.
I’m pleased to welcome Karol Wójciszko as a guest contributor to Thriving in Engineering!
I’ve long believed journaling is one of the most underrated tools in leadership. The open question has been how it scales – especially for developers, not just managers.
What Karol shares here is something many engineering managers think about but rarely systematize: how do you help developers who want to grow actually do it?
10x Your Team
Hey everyone, I’m Karol — excited to be contributing to Alex’s publication for the first time!
I write about engineering leadership and team management over on my Substack, focusing on the messy, human side of leading teams. If this article resonates with you, I’d love to have you join me there.
A while back, I wrote about how journaling transformed my own productivity. That article included the exact prompts I used, my daily routine, and a practical guide to getting started. I’m linking to it at the beginning of this piece because the foundation matters — you can’t build this system for others if you haven’t experienced its impact yourself.
What I want to share today is how I’ve extended that same approach to selected developers on my teams, how the right people can use journaling and AI to become what people call “10x engineers” — genuinely productive contributors who consistently deliver more than their peers.
I’ve been testing this with hand-picked developers across my teams for several months now. People who showed genuine interest in self-development. This absolutely won’t work for everyone — especially not for burned-out team members who need recovery, not another system. But for developers hungry to grow? The results are worth sharing.
I know I’ve talked about this before. But I can’t stress enough how critical this practice is. For developers who want to grow — not everyone will — I recommend committing to at least 2–3 months of consistent journaling. Ideally, push it to four months.
Why? Because that’s how long it takes, actually, to see your patterns. Your false beliefs. Your recurring mistakes.
I won’t repeat all the prompts and instructions here — you’ll find those in the article I linked above. Instead, I want to focus on what’s different for developers.
The Developer’s AI Solution Architect
Beyond journaling, I have developers create what I call their “Gem” in Gemini. This is basically an AI assistant configured specifically for their role — their personal solution architect, tech lead, and advisor rolled into one.
I’m recommending Gemini specifically because we use Google Workspace, and developers are already there. But this isn’t about the tool — you could do the same thing with Claude Projects, ChatGPT custom GPTs, or any LLM that lets you set system context. The method matters more than the platform.
Why do this at all? Because developers need someone to think through problems with. Someone who asks the hard questions before code gets written. Someone who challenges their assumptions without judgment. In an ideal world, every developer would have constant access to a senior architect. In reality, that doesn’t scale. This does.
Here’s what makes this work: I’m including the exact Gem configuration I recommend for developers at the bottom of this article. It’s been refined through actual use — not theory. You can grab it and start using it today, regardless of which LLM you choose.
Building Your Knowledge Base and Advisory Board
But the Gem alone isn’t enough. Developers need two layers of context to make this truly useful.
Knowledge Base — this is the organizational reality they work in. Who reports to whom, what roles people play, and the company structure. Think of it as teaching the AI about your actual environment. This prevents generic advice and makes the guidance specific to your situation.
For example, if your team has a strong bias toward consensus decision-making (maybe from a psych test), the AI can factor that in. Or if your tech lead is particularly thorough about code reviews, that context shapes better advice.
Advisory Board — these are the expert personas developers want advice from. Not real people they message, but the voices that guide their thinking in daily reflections. This is where it gets interesting.
I mentioned both concepts in my previous article. Here’s who I specifically suggest developers add to their Advisory Board:
Martin Fowler
Grace Hopper
Elon Musk
Their current engineering manager (me, in this case)
That last one is important, and it works differently than you might think. I tell developers to describe their manager — how they see me, how I work, what I care about. I absolutely don’t check this. Don’t ask about it. Don’t look at what they wrote.
That’s entirely up to each developer. But here’s why it matters: it forces them to articulate their mental model of management expectations. And once that’s explicit, the AI can work with it.
Say you pay a lot of attention to details in code reviews, and you have frequent discussions about it in your one-on-ones. Your developer probably writes that their manager “often nitpicks” or “pays close attention to quality.” Maybe they even include that you’ve mentioned this stems from a past production incident.
Then the Gem will suggest in each journaling session: “Hey, maybe check that PR extra carefully. Make sure the edge cases are covered. Remember, your manager will look at error handling closely.”
That’s not surveillance. That’s the developer teaching their AI to help them meet expectations they already know about. It creates something interesting — personalized guidance based on their actual working relationship, not generic management advice.
Real Use Cases That Actually Work
Let me share specific scenarios where I’m seeing developers use this Gem to great effect.
Refinement Prep
This is the first major use case, and honestly, it’s where I’ve seen the biggest immediate impact. I’m including a ready-to-use prompt for this below.
Most developers show up to refinements having skimmed the requirements. Maybe they’ve thought about it for a few minutes. But they haven’t systematically worked through the edge cases, the architectural implications, the hidden dependencies. Then we spend the first 20 minutes of the refinement just figuring out what questions we should be asking.
Here’s how it works: export your requirements from Jira (you can export entire epics with subtasks as CSV). Drop them into the Gem with this prompt. It doesn’t need to know your codebase — instead, it asks you the hard analytical questions that surface risks and ambiguities before the refinement even starts.
What I’ve noticed: developers who do this show up with a page of specific questions. They’ve thought through different technical approaches. They’ve identified the ambiguous parts that need clarification. The refinements become actual decision-making sessions instead of discovery sessions.
You can also do this from Claude Code or Codex if you want immediate repo context. That gives you additional insights about existing patterns to reuse.
Prompts are at the end of this article.
Quarterly Goals
The other big use case: quarterly goals. This one’s more subtle but potentially more valuable long-term.
I don’t know if you work with OKRs or set quarterly objectives. I’m a believer in the cascading model: company goals → team goals → individual goals. Everything contributes to something larger.
So I’m a proponent of giving people quarterly goals. The biggest challenge I’ve seen? People understand and agree to the goals at the start of the quarter. Then they forget about them. Sprint work takes over. Urgent issues dominate. Three months later, we’re at the retrospective, and the goal barely moved.
The usual solution is manager check-ins. Weekly “how’s your OKR going?” questions in one-on-ones. That works, but it makes ownership feel external. Like I’m responsible for their goal, not them.
The Gem solves this by building an actual execution system. Since it already has the developer’s context from the Knowledge Base (their role, team structure, manager’s expectations), it can focus entirely on helping them build a sustainable routine.
It suggests blocking specific time — not just “work on your goal sometime” but “Wednesday mornings, 9–11am, before standup.” It creates weekly update templates for the team channel so sharing progress becomes frictionless. It prepares questions for 1-on-1s with their EM that are specific to where they’re stuck.
It even leverages the Advisory Board — asking which expert persona would help with different types of decisions. Stuck on the technical approach? That’s Martin Fowler territory. Feeling demotivated? Maybe Grace Hopper’s pragmatic perspective helps. Wondering if you’re being ambitious enough? Elon Musk chimes in.
The goal becomes part of their weekly rhythm instead of something they remember during review season.
Prompts are at the end of this article.
Making This Stick
The truth is, most productivity systems fail because they’re too complex or require too much manual effort to maintain. Developers try them for a week, maybe two, then quietly stop when things get busy.
What makes this different is that the Gem does the heavy lifting. Developers just need to show up with their honest reflections. The AI handles pattern recognition, connects dots between daily work and bigger goals, and surfaces insights that would otherwise stay buried.
But let’s be clear: this only works for people who genuinely want to grow. I’ve seen developers who were solid contributors become genuinely exceptional. Not through some magical personality transformation, but through consistent self-reflection combined with intelligent prompting. They start seeing patterns in their work — what energizes them, what drains them, where they consistently underestimate effort.
The journaling creates awareness. The AI turns that awareness into actionable guidance. The Knowledge Base makes the guidance relevant to their actual situation. The Advisory Board provides different lenses for thinking through problems.
If someone’s burned out, recovering from a difficult period, or simply not interested in structured self-development right now — this isn’t for them. And that’s okay. Not every tool works for every person at every time.
But for developers hungry to level up? For people who want to own their growth instead of waiting for it to happen to them? Try this for a quarter. See what happens.
The prompts are below. The configuration is ready. You just need the right people.
Ready-to-Use Prompts
[REFINEMENT PREP PROMPT]
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]
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 or ambiguous in these requirements?
- Where are different people likely to interpret this differently?
- What assumptions are hidden in this description?
- Which acceptance criteria need more detail?
2. **Edge Cases & Error Scenarios**
- What happens when things go wrong?
- What edge cases aren’t mentioned here?
- Where could user behavior surprise us?
- What’s the rollback plan if this breaks something?
3. **Technical Approach**
- What are 2-3 different ways we could solve this?
- What’s the simplest approach vs. the most robust?
- Where might we over-engineer this?
- What existing patterns in our codebase should we reuse?
4. **Dependencies & Integration**
- What other systems will this touch?
- Who else needs to be involved in this refinement?
- What needs to be ready before we can start this?
- What will this enable or block for other teams?
5. **Scope & Phasing**
- Can this be broken down smaller?
- What’s MVP vs. nice-to-have?
- What can we defer to a future iteration?
- Where are we trying to do too much at once?
6. **Risk Assessment**
- What’s the riskiest part of this work?
- Where are we most likely to underestimate effort?
- What unknown unknowns might we discover mid-sprint?
- What would make this take 3x longer than expected?
7. **Questions for Stakeholders**
- What must we decide in this refinement vs. later?
- What do we need from the Product Owner right now?
- Where do we need technical leadership input?
- What research or spikes should we do first?
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?
- Should we split this refinement into multiple sessions?[QUARTERLY GOALS PROMPT]
I have a quarterly goal that 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**
Ask me questions to understand this better:
- What are the major phases or milestones?
- What needs to happen first vs. what can happen in parallel?
- Where am I dependent on others vs. what I control fully?
- What’s the minimum viable version of success here?
2. **Weekly Work Routine**
Help me create a sustainable weekly pattern:
- How many hours per week should I realistically dedicate?
- What day and time should I block for this? (Consider: when am I sharpest? When are meetings lightest?)
- Should this be one focused block or multiple smaller sessions?
- What prep should I do before each work session?
- What does “done for the week” look like?
3. **Progress Tracking & Visibility**
- Should I share weekly updates on our team channel? What format?
- When should I do informal check-ins with my EM vs. waiting for 1-on-1s?
- What milestones deserve celebrating with the team?
- How do I show progress when work is invisible (research, learning, analysis)?
4. **Weekly Reflection Questions**
Create 3-4 questions I should ask myself every Friday:
- [Question about progress vs. plan]
- [Question about what’s blocking me]
- [Question about what help I need]
- [Question specific to this goal’s nature]
5. **Managing Conflicts**
- When sprint work conflicts with goal work, how do I decide?
- What’s the minimum I need to protect each week to stay on track?
- When do I escalate to my manager that this goal is at risk?
- How do I say no to things that threaten this goal?
6. **Risk Mitigation**
- What would make me fail this goal silently? (Warning signs I’m ignoring)
- At week 4, 8, and 10 - what should I have achieved to be on track?
- If I’m behind at mid-quarter, what’s my recovery plan?
- Who can I ask for help if I’m stuck?
7. **Leveraging My Advisory Board**
Based on my Advisory Board members, who would you consult about:
- Technical approach decisions?
- When I’m stuck or demotivated?
- When facing ambiguity or unclear requirements?
- When deciding between good and perfect?
Now create me:
- A weekly checklist for this goal
- A template for my Friday reflection
- A message template for my weekly team channel update
- Three questions I should 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 guest post by
|