DEV Community: Ctrl Zed

The Real MVPs Are Your Quiet Engineers—Not the Guy Who Talks the Most in Standup

Ctrl Zed — Wed, 16 Jul 2025 13:00:00 +0000

Some folks treat standup like an audition for a podcast.

But while they’re monologuing about everything from architecture to what they had for dinner, your quiet engineer just pushed a fix that solved three sprint blockers, and only said, “Yesterday: bug fix. Today: unit tests.”

🫢 Loud ≠ Leader

There’s a myth in tech that the loudest person in the room must be the one getting the most done.

Reality check:

Loud ≠ leader
Verbose ≠ valuable
Volume ≠ velocity

Your best engineers might not say much. But their Git history? It tells the story loud and clear.

🧠 Why Quiet Engineers Matter

They:

Ask fewer questions because they already looked it up
Write clean, scalable code instead of big docs about future plans
Support teammates without the “Look at me!” energy

They don’t need applause. They need a leader who notices.

🚨 What Leaders Need to Do

Pay attention to outcomes, not airtime
Give credit to contributors who don’t self-promote
Make space for everyone, not just the confident speakers

🚀 TL;DR

Quiet ≠ invisible
Loud ≠ impactful
The real MVPs often say the least

Want more unfiltered truth about leadership in tech?

Read the full post at LeadDon'tCtrl.com

Your Team Is Not Lucky to Have You, You’re Lucky They Haven’t Quit Yet

Ctrl Zed — Wed, 02 Jul 2025 12:15:00 +0000

Your Team Is Not Lucky to Have You

You’re Lucky They Haven’t Quit Yet

If you start believing your team is “lucky to have you,” let me stop you right there.

You’ve got it backwards.

They show up every day. They deal with shifting priorities, Slack pings at 9PM, process chaos, and you.

You are not their hero. You're not their guru. You're just part of the system.

They are not lucky.

You are.

The Ego Trap

Being a leader is not about soaking in praise and claiming credit.

It’s about:

Owning failure
Sharing wins
Protecting your team from the firestorm
Lifting people up and letting them lead

If You Think This Isn’t You…

Let me ask:

Do you praise your team more than you praise yourself?
Do you listen, or do you wait for your turn to talk?
Have you ever taken responsibility for something you could’ve blamed on someone else?

If not, you're leading with ego. And your team is not going to stick around.

Final Thought

Your title doesn’t make you a leader. Your actions do.

And if you want loyalty, innovation, and trust—you’d better earn it every damn day.

👉 Read more no-BS leadership rants at leaddontctrl.com

What I Wish I Knew Before Starting Computer Science in College

Ctrl Zed — Tue, 01 Jul 2025 23:14:20 +0000

What I Wish I Knew Before Starting Computer Science in College

Starting CS in college? Congrats—and brace yourself. You’re about to learn a lot of code, and even more about yourself.

Here’s what I wish I knew when I started:

You're not expected to know everything

You don’t need to memorize every language's syntax. Real developers Google stuff all the time. You’re here to learn how to learn.

Learn to be a developer, not just a coder

Anyone can write code. But being a developer means:

Solving problems
Communicating ideas
Working on teams
Knowing how to debug and test
Writing code someone else can understand

Bad code is better than no code

Seriously. Write the ugly stuff. Break things. That’s how you learn. Bad code teaches you more than blank files ever will.

Debugging is your superpower

Most students treat debugging as punishment. But it’s actually one of your most important tools. Learn to debug well and you'll level up faster than anyone around you.

Learn your tools

Your IDE. Your terminal. Your debugger. Your version control system. These aren’t extra—they’re essentials. Mastering your tools will make your life so much easier.

Fundamentals beat trends

Languages change. Frameworks come and go. But things like loops, conditionals, data structures, and algorithms? They’re forever. Learn them deeply.

You're not alone

Imposter syndrome is real. Everyone’s faking it a little. Find your people, ask questions, and remember—you’re not supposed to be perfect.

Final Thought

You’re not just learning to write code. You’re learning how to think like a developer. And that’s a skill you’ll carry for life.

You’ve got this. 👊

👉 Read more no-BS tech advice at mullins.io

Delegating Isn’t Ditching

Ctrl Zed — Sun, 29 Jun 2025 18:00:00 +0000

Delegating Isn’t Ditching

You Can’t Hand Off a Mess and Call It Leadership

Let’s get one thing straight: delegation is not just yeeting tasks off your plate like you’re cleaning up for a surprise performance review.

If your idea of delegation is dropping an assignment on someone’s lap with zero context, no support, and a shrug that says “you got this,” congratulations, you’re not leading. You’re ditching.

And your team knows it.

The Dirty Truth About “Delegation”

Real talk? Most people in leadership positions aren’t delegating, they’re dodging. They pass off chaos, hope someone else sorts it out, and then act surprised when it doesn’t magically turn into a beautiful deck or a bug-free feature.

Delegation isn’t about doing less work.

It’s about doing different work.

More strategic. More supportive. More human.

What Real Delegation Looks Like

Clarity of Purpose

Don’t just assign a task. Explain why it matters.
Clear Expectations

Define success. No mind-reading allowed.
Ongoing Support

Stay present. Don’t ghost.
Ownership, Not Abdication

They own the task, you still own the outcome.
Debrief and Feedback

Learn. Improve. Repeat.

👉 Want more no-BS leadership posts like this?

Read the full archive at leaddontctrl.com

The Work Will Never Love You Back, But People Might

Ctrl Zed — Sat, 21 Jun 2025 14:30:00 +0000

Let’s be real for a second:

You can give your job everything—your nights, your weekends, your mental bandwidth, and it’ll still lay you off with a LinkedIn post and a blank stare.

Because the work doesn’t love you.

It doesn’t care that you stayed late. It won’t remember that you “just popped on” during PTO. It won’t ask how your kid’s recital went.

But your team might.

Your people might.

Humans might.

🚫 Output Isn’t Legacy

You won’t be remembered for your velocity metrics or how many Jira tickets you crushed.

You’ll be remembered for the moment you said, “Take care of yourself first.”

For shielding someone from a dumpster fire.

For making someone feel like they belonged in tech when everything else told them otherwise.

That’s leadership.

🧠 Want to Make a Real Impact?

Stop giving your soul to the sprint board.

Start showing up for your people.

Protect their time.
Model boundaries.
Celebrate them without needing to be the hero.

Because at the end of the day, your code won’t show up at your funeral. But your teammates might.

👀 Want more hard truths and rebellious leadership content?

Check out LeadDon'tCtrl.

Permission to Be Weird: Why Authenticity Is a Leadership Superpower

Ctrl Zed — Wed, 18 Jun 2025 14:15:00 +0000

Let’s be honest—some of us just don’t fit the “executive” mold.

I’m not wearing a blazer. I don’t talk in Agile poetry. My leadership voice is mostly sarcasm, blunt honesty, and a dash of nerdy pop culture references. And yes, I wear graphic tees and shorts to work. Every. Single. Day.

And guess what? It works.

For too long, leadership has been sold as a costume. Button up. Fall in line. Use phrases like “circle back” and “drive alignment.” But here’s the real deal: teams don’t want a parody of leadership. They want a human being.

Someone honest.

Someone consistent.

Someone real.

You don’t build trust by pretending. You build it by showing up with all your quirks and contradictions intact.

So here’s your permission slip: Be weird. Be you.

Wear the t-shirt.

Skip the corporate filter.

Say what you mean.

Lead by example.

Authenticity is your superpower. Own it.

Read the full post on LeadDon'tCtrl for the full breakdown.

Hats Off (And On Again): The Ridiculous Art of Tech Leadership

Ctrl Zed — Sat, 31 May 2025 16:55:40 +0000

Being a tech leader means juggling flaming hats while dodging meetings and shielding your devs from corporate nonsense. Let's talk about it.

🧢 The “Visionary” Hat

(a.k.a. Making up the plan as you go)

You’re expected to “steer the ship” with a smile and a vaguely confident roadmap you assembled 20 minutes before your standup. Fake it. Then figure it out. That's the job.

🧙 The Translator Hat

(a.k.a. fluent in C-suite buzzword and junior dev anxiety)

One hour you're decoding “synergize agile growth,” the next you're explaining to your devs why you're not switching the whole stack to Rust. Again.

🪖 The Human Shield Hat

You protect your team from scope creep, chaos, and every “quick fix” idea that lands in Slack at 4:57pm. It's not glamorous, but it's necessary.

👑 The Culture Curator Hat

Spoiler: Culture isn't ping pong tables and pizza Fridays. It's trust. It's listening. It's making space for real humans with real thoughts. Radical, right?

🪙 The Final Hat: The Anti-Hero

You’re not here to be a boss. You’re here to lead.

That means throwing out the old leadership playbook and building something better.

🔥 Read the full post at LeadDon'tCtrl

✊ Burn the playbook. Lead loud. Lead weird.

Stop Asking for Estimates Like You’re Ordering a Pizza

Ctrl Zed — Thu, 29 May 2025 22:45:09 +0000

"Just give me a quick estimate."

Cool. You want fries with that too?

If you’ve ever worked as a developer, you know the question.

How long will this take?

Give me a ballpark.

Just need a quick number for planning...

Let’s be clear:

Asking for an engineering estimate without requirements, context, or time to think is like ordering a pizza without saying what toppings you want—or if you even have an oven.

And then being mad when it’s late, cold, and full of regret.

🧠 Devs Aren’t Psychic

You can’t expect accurate answers to questions you haven’t finished asking.

When someone says:

“How long to integrate this third-party tool?”
“What’s the ETA on this bug?”
“Can you guess how long the refactor will take?”

...and provides zero detail, the only honest estimate is 🤷‍♂️.

🚫 Weaponizing Estimates Is a Leadership Fail

Bad estimates aren’t the problem.

Using estimates as commitments, ammo, or leverage—that’s the problem.

We see it happen all the time:

PM gets an offhand guess, puts it on a timeline
Feature explodes in complexity
Devs are blamed for “slipping”

That’s not leadership. That’s corporate gaslighting.

🔍 Want Real Estimates? Do This Instead:

Give clear requirements
Let devs break down the work
Encourage “I don’t know yet” as a valid response
Ask for ranges, not single-point answers
Don’t use estimates as truth—use them as a conversation

If it sounds like more effort… that’s because it is.

But it also means your team will trust you more, deliver more accurately, and spend less time rage-Googling “how to undo a commit from 6 days ago.”

🍕 TL;DR

Don’t treat dev time like takeout.

Stop asking for estimates like you’re ordering pizza.

Estimation isn’t fast food—it’s forecasting.

And if you're not bringing context, collaboration, and a little patience,

you’re just setting the table for a delivery disaster.

✊ LeadDontCtrl.com

Rebellious tech leadership. Delivered hot.

How to Lead Without Knowing the Whole Codebase (Because You Never Will Again)

Ctrl Zed — Mon, 26 May 2025 19:12:18 +0000

“Let me just deep-dive the whole repo before I start leading…”

Cool story. You’ll be dead before you’re done.

Here’s the truth they don’t tell you in leadership onboarding (if that even exists):

You will never fully understand the codebase again. And that’s okay.

This post is for every developer turned leader who’s struggling to let go of “knowing everything” and embrace leading anyway.

Let’s talk about how.

🧠 Step 1: Ditch the ego

You’re not less valuable because you can’t quote line 342 of utils/helpers.js. You’re more valuable when you know who can, and you make space for them to do it well.

Leading isn’t about being the best coder in the room.

It’s about making the room better.

🛠️ Step 2: Focus on context, not control

You don’t need to memorize code—you need to understand purpose.

What is the system trying to do?
Where are the danger zones?
Who built what and why?

If you can navigate the big picture and support the people owning the details, you’re doing your job.

👥 Step 3: Build a trust network

You don’t need to know the whole codebase—because your team does.

Lead like a network router, not a single point of failure. Ask questions. Show curiosity. Let your engineers teach you (spoiler: they want to).

A leader who admits what they don’t know builds a team that fills in the gaps.

🧭 Step 4: Be a decision compass, not a debugger

When you stop clinging to the code, you start having time to:

Remove blockers
Advocate for better processes
Defend your team’s time
Spot architecture drift
See the human bugs before the ones in production

Your value shifts from “I fixed it” to “I made sure it didn’t break in the first place.”

🔥 Step 5: Redefine what ‘technical’ means

Tech leadership is still technical. Just not in the way you’re used to.

It’s systems thinking. Risk mapping. Translating between humans and machines (and other humans). Prioritizing. Synthesizing. Communicating.

If you still think “real leaders write code,” congrats—you just volunteered to be your team’s bottleneck.

🧨 TL;DR

You’ll never know every line again. That’s not the goal.

Knowing who does, why it matters, and how to support them? That’s leadership.

Let go of omniscience.

Lead with clarity.

Control is a crutch.

Lead. Don’t Ctrl.

✊ leaddontctrl.com

Rebellious tech leadership. No code coverage required.

Stop Gatekeeping and Start Leading: How Real Leaders Support Junior Devs

Ctrl Zed — Thu, 22 May 2025 22:22:23 +0000

Let’s get this out of the way up front:

If you’re calling yourself a leader but treating your junior devs like interns with Stack Overflow accounts — you’re not leading. You’re just delegating down and hoping for the best.

Junior devs aren’t liabilities. They’re high-potential humans still figuring out how this industry works while we dump half-documented codebases and broken CI pipelines on them like it’s a rite of passage.

Time to do better.

Here’s how real tech leaders actually support their junior devs:

🔍 1. Stop Hiding Context Like It’s a Trade Secret

Don’t just toss a JIRA ticket and bounce. Give them the why, not just the what.

“This feature helps us reduce user churn by tightening onboarding”

is miles better than

“Add this button to the modal because the PM said so.”

Juniors thrive when they understand the system they’re working inside. Give them vision, not just tasks.

💬 2. Normalize Questions Before the Panic Sets In

If the only time they feel safe asking for help is after two hours of spiraling in Slack drafts… congrats, you’ve built a fear-based culture.

Ask them:

What did you learn this week?
What are you stuck on?
What confused you but you figured out anyway?

Create space. Ask first. Lead before they have to plead.

🛠️ 3. Build Systems, Not Saviors

Don’t be the “hero” leader who has to fix everything. Be the builder of systems — documentation, onboarding guides, pairing sessions, office hours — that empower junior devs to grow without needing a personal lifeline every five minutes.

Great leaders build frameworks that outlast their own 1:1s.

🧠 4. Teach Thought Process, Not Just Syntax

They don’t just need the answer. They need to learn how to think like a developer.

When they ask for help:

Don’t give them the fix.
Walk them through your mental model.
Explain why you eliminate certain hypotheses.

Lead with logic. Not ego.

✍️ 5. Give Feedback Like You’re Talking to Your Past Self

Because guess what? You were that junior once.

Don’t nitpick style guides before substance.
Don’t mock “obvious” mistakes — they’re obvious now.
Praise progress. Coach gaps. Encourage curiosity.

And whatever you do: don’t be the dev who posts “I could’ve done that in one line” on a junior’s pull request. That’s not mentoring. That’s just ego with a keyboard.

🚀 6. Promote Autonomy Before They Think They’ve Earned It

The biggest lie juniors believe? That they need permission to take initiative.

Show them they’re trusted. Let them lead small features. Own a bug cleanup. Give them space to fall, and a safe place to land.

Growth doesn’t happen when you’re micromanaged into mediocrity.

🔥 Final Word

If you're not building up junior devs, you're not building a future-proof team — you're just hoarding experience and calling it leadership.

Support them. Teach them. Empower them. And most importantly: stop gatekeeping the good stuff.

Because leading isn’t about control — it’s about letting go.

✊ Lead with intention. Lead with purpose. #LeadDontCtrl

Got tips, stories, or rants about supporting junior devs? Drop them in the comments. Let’s build better leadership together.

🔥 If you're into no-BS tech leadership, check out LeadDon'tCtrl — a blog where we challenge toxic norms and build leaders, not gatekeepers.

So You Just Got Promoted—Here’s How to Lead Without Screwing It Up

Ctrl Zed — Tue, 20 May 2025 23:46:46 +0000

How to Be a Good Tech Leader (Without Becoming the Boss Everyone Hates)

Most tech leads weren’t trained. They were promoted.

Some were the fastest coder. Others were just around when someone needed to “own” standup. And suddenly—bam—you’re the boss.

This guide is for you: the newly minted lead, the developer thinking about leadership, and the battle-worn senior who's seen some stuff and wants to do better.

🔥 1. Trust First, Always

Micromanagement is just control with a suit on. Trust your team. Give it before it’s earned—that’s how people rise to the occasion.

“If you have to control everything, you don’t need a team. You need therapy.”

🛠 2. Burn the Playbook

There’s no universal leadership checklist. Copying your old manager won’t work. Build your own way, then teach it to others.

🛡 3. Create Safety, Not Surveillance

Psych safety > metrics dashboards. If your team hides problems from you, it’s not a “dev problem.” That’s a culture problem.

⚙️ 4. Fix Systems, Not Just People

Bad systems break good people. Leadership isn’t just 1:1s—it’s debugging the processes that cause burnout, friction, and apathy.

🔊 5. Lead Loud. Listen Louder.

Visibility matters. But silence can be a leadership superpower. Speak less. Ask more. Share praise publicly, take blame privately.

🦄 6. Kill the Hero Culture

Stop celebrating 4:59pm fire saves. Build systems that don’t need heroes. Reliability > adrenaline.

“Don’t build around unicorns. Build around humans.”

🧑‍🏫 7. Coach, Don’t Command

You’re not a cop. You’re a coach. Give context. Ask better questions. Don’t babysit—mentor.

💻 8. Stay Technical (But Let Go)

Understand the system. Ask good questions. Don’t hog the keyboard. Teach, unblock, back off.

🙌 9. Share the Credit, Show the Work

Brag about your team, not yourself. Highlight the junior who shipped the win. Recognition builds trust faster than coffee budgets.

🚪 10. Lead Like You’ll Leave

Can your team thrive without you? That’s your leadership legacy. Build systems and people—not dependencies.

💡 Action: Pick one thing you’re clutching too tightly. Teach it. Delegate it.

👊 Final Thought

You don’t need to control everything.

You don’t need to follow the handbook.

You need to rewrite it.

Real leaders do.

And if you’re already doing that? You’re on the right track.

✍️ This post originally appeared on LeadDon’tCtrl.com

Want more leadership truth bombs? Come check it out.

💬 Discussion Prompt:

What’s one thing you wish someone told you before stepping into tech leadership?

👇 Drop it in the comments.