by Peter Szarvas | Senior Software Developer and Consultant

From Code Monkey to Trusted Partner

There was a time when I thought being a good developer meant delivering features quickly, staying quiet in meetings, and doing what I was told. I optimized for speed. I crushed Jira tickets. But something kept bothering me.
I struggled to make the many local decisions developers face every day—without the right context or access to business insights. Domain experts weren’t available "on tap," and I often felt stuck making blind guesses. And we all know that:

“It’s not the domain expert’s understanding that gets released into production, it’s the developer’s interpretation of that understanding.”
— Alberto Brandolini
So I decided to take control and get more involved.
The Code Monkey Trap
“Code monkey” is a harsh label, but many of us start our careers here. It’s not about skill—it’s about mindset:
Executes without context
No deep knowledge of the domain
Low autonomy
No access to domain knowledge
Lack of awareness or business understanding
Minimal or no contact with customer/user
Focused on building the thing right
Perceived as an easy role, but easily replaceable
It’s safe. It’s efficient. And it’s the fastest way to be invisible.
Enter the Trusted Partner
Trusted Partners don’t just code. They:
Understand (business) problems and user needs
Have confidence in decision making
Show high awareness of impact and context
Think in terms of business consequences
Possess a broader overview of how systems interact
Build the right thing—not just the thing right
Maintain active contact with customers/users
Are seen as valuable contributors to the business
Take responsibility beyond technical tasks
Bring valuable business insights to the table
They are still developers—but with influence (and domain expertise).
The transition isn’t about a promotion. It’s about perspective and initiative.
Where Are You on the Spectrum?
It’s important to remember this isn’t black and white. Most of us operate somewhere along the spectrum between code monkey and trusted partner, and our position can shift depending on the project, team dynamics, or company culture.
The goal isn’t perfection—it’s progression. Being aware of where you stand helps you grow with intention.
Here’s a quick self-check:
Trait | Code Monkey | Trusted Partner |
---|---|---|
Task Execution | Follows specs | Questions and shapes specs |
Business Understanding | Minimal | Deeply engaged with domain experts |
Autonomy | Low | High |
Access to Knowledge | Limited or missing | Actively seeks and maintains access |
Awareness of Context | Narrow | Broad and strategic |
Conversations | Mostly technical | Balanced between business & tech |
Contact with Customer/User | Rare or indirect | Direct and regular |
Mindset | Build the thing right | Build the right thing |
Value to the Business | Low | High |
Responsibility | Avoided or unclear | Owned and visible |
Be honest. Where do you see yourself?
In the next section, we’ll look at how you can start moving forward—one mindset shift at a time.
Even with years of experience, it’s possible to fall into execution mode—especially in rigid structures. That’s okay. But you don’t have to stay there.
There’s no single golden path. Every developer has their own strengths, preferences, and pace. Some thrive in deep technical problem-solving, others in user collaboration or product thinking—and that’s what makes great teams. The goal isn’t to fit a mold, but to grow intentionally and expand your impact.
Broadening your perspective—whether technically, cross-functionally, or through the lens of the business—is one of the most powerful ways to learn and grow.
Strategy Meets Tactics
One thing that helped me connect Turn the Ship Around! with Domain-Driven Design is how both highlight the importance of clarity and competence—just from different angles.
In DDD terms:
Strategic design gives us organizational clarity — it answers what to build and why it matters.
Tactical patterns provide technical excellence — they help us build it well.
This also reflects the classic split:
Build the right thing → requires strategic clarity.
Build the thing right → requires technical skill.
Think of it like planning a road trip (strategy) versus navigating traffic and road signs while driving (tactics). When you understand both, you're no longer just steering—you know where you’re going and why it matters.
And to build both mindset and momentum, one of the most powerful tools is the Ladder of Leadership.
Climbing the Ladder of Leadership
The Ladder of Leadership, popularized by Turn the Ship Around! by David Marquet, represents a spectrum of ownership and initiative in how we communicate. It addresses a common challenge in teams: when developers feel disempowered or overly dependent on direction, they hesitate to act or grow.
The ladder introduces a shared language for growing initiative—shifting from passive execution to active ownership.

The goal is to move up the ladder —showing increasing ownership, confidence, and clarity. It’s not about authority. It’s about taking responsibility for your actions and decisions, even without a leadership title.
“Stop asking permission. Start taking ownership.”
Practical Steps to Level Up
Inspired by the leader-leader model from Turn the Ship Around! and enriched by Domain-Driven Design practices, here’s what helped me (and others) shift:
Start with “why” for every task.
Don’t just ask “What should I build?”—ask “Why does this matter to the user or the business?”Adopt the domain’s language.
Contribute to a glossary. Use domain terms in code to reduce translation friction.Facilitate or attend Event Storming workshops.
Start small: one use case, one hour, one whiteboard.
If you’re introverted, observe or contribute asynchronously.Use Example Mapping in refinement.
Turn vague requirements into concrete examples, rules, and questions.Embed with business users when possible
Shadow them, join support calls, or read customer feedback.Learn from experienced developers.
Seek out code reviews, pair programming sessions, or technical mentors who challenge you to grow. Technical excellence is a team sport—don’t just read blog posts, collaborate with and learn from people who’ve been in the trenches.Reflect with your team.
Use retrospectives or 1:1s to ask: “Where are we blind right now?”Practice “I intend to…” language.
Propose actions instead of asking what to do—invite feedback and build trust.
These shifts don’t happen in isolation—supportive environments and empowered roles make autonomy possible.
The key isn’t authority—it’s clarity and responsibility.
Real Impact, Real Growth
Once you start this journey, things change:
You become a trusted partner, not just a coder.
You influence product design, not just implement it.
You gain confidence in making hard decisions.
And maybe most importantly: you enjoy building again.
Final Thought
You don’t need to be the smartest person in the room. You just need to be the most curious.
Ask why. Collaborate deeply. And take control—not just of the code, but of your place in the system.
From code monkey to trusted partner—it’s a choice.
