Herding Cats, Dogs, and That One Engineer Who Still Uses Vim
Understanding the different personality types on your team
The cast of characters (yes, your team has these)
If you manage engineers long enough, you learn a comforting truth: it is never just “the work”. It is always the work plus personalities, habits, preferences, fears, egos, and that one person who can quote a compiler error from 2009 but cannot find the “Join call” button.
So let’s name the recurring characters you are herding.
The Cat: independent, proud, allergic to being told what to do, will ship something brilliant at 2:13 a.m. and then disappear for three days.
The Dog: collaborative, loyal, wants to be useful, thrives on clear goals and praise, will ask if there is anything else they can do (there is always something else).
The Turtle: careful, slow, risk-aware, does not like surprises, will find the edge case you missed, and will also take a week to open a pull request.
The One Engineer Who Still Uses Vim: this is not about the editor. This is about identity.
Before anyone writes me an angry email: yes, Vim is fine. So is Emacs. So is Notepad if you are a chaos goblin with strong unit tests. The problem is when “I use Vim” turns into “I refuse to change anything, ever, and I will argue about it like it is a human rights issue”. That is how you get stuck.
What these personalities are really signalling
Most “personality issues” at work are actually one of these:
Autonomy needs (cats)
Clarity and belonging needs (dogs)
Safety needs (turtles)
Status and identity needs (the Vim archetype)
Your job is not to sand down everyone into one bland corporate shape. Your job is to build a team that can ship, learn, and not slowly poison each other.
That means you need a management approach that is:
flexible in style
consistent in expectations
explicit about what success looks like
You are not running a daycare. You are running a system.
The Cat: give goals, not instructions
Cats do not want micromanagement. They want a problem worth solving and room to solve it.
What works:
Clear outcomes and constraints (what good looks like, what must not happen)
Minimal process, maximum accountability
“Show me” checkpoints instead of status theatre
What does not:
Daily “what did you do yesterday” interrogations
Performative Jira grooming as a substitute for thinking
Treating questions as a sign of weakness
Cats will either thrive and ship, or they will quietly become ungovernable. If a cat is repeatedly dodging alignment, it is not “their personality”. It is a trust or accountability problem.
The Dog: protect them from chaos and let them lead
Dogs keep teams running. They hold things together. They also burn out because they absorb everyone else’s mess.
What works:
Clear ownership (so they are not doing invisible glue work forever)
Praise that is specific (impact, not vibes)
Opportunities to lead a project or mentor
What does not:
Letting them become the default “help desk”
Dumping every urgent thing on them because they are reliable
Rewarding their helpfulness with more chaos
Dogs are the people who make your team feel human. Treat that like the critical infrastructure it is.
The Turtle: slow is not the same as bad
Turtles are usually your quality and risk bar. They are also the people most likely to be labelled “difficult” by someone who wants speed without consequences.
What works:
Pre-briefing (share context early, not at the last minute)
Breaking work into smaller chunks
Explicit risk budgets (what is acceptable to ship imperfectly)
What does not:
“Just move faster” as feedback
Surprise deadlines
Punishing caution by ignoring them until production explodes
If your turtle is consistently slow, check the system. Are requirements messy? Is the codebase fragile? Are they doing extra work because nobody else cares about correctness?
The Vim Engineer: identity is the hidden boss fight
This archetype often has deep craft pride. That is not a problem. The problem is when pride turns into gatekeeping, stubbornness, or reflexive contrarianism.
What works:
Respect the craft, then set the expectation: “We standardize for team speed”
Give them a place to contribute expertise (tooling, performance, reliability)
Set boundaries around debates (time-box, decide, move on)
What does not:
Letting them derail every decision
Treating the loudest opinion as truth
Making exceptions that force the whole team to pay a tax
Standardization is not oppression. It is how teams scale.
Now add AI tools, and the whole dynamic gets louder
Here is the uncomfortable part: AI will not replace most engineers tomorrow. But engineers who can ship faster, reason faster, and unblock themselves faster will outcompete engineers who refuse to adapt.
The replacement story is mostly hype. The productivity story is real. And that is why “slow to adopt AI coding tools” is not a cute quirk. It is a career risk.
If this feels like yet another treadmill moment, it is. I wrote about that dynamic already in AI Burnout: When “AI All the Things” Becomes a Cult: the tools are not the problem. The new baseline is.
The real difference: throughput, not brilliance
In most teams, the difference between “great” and “good enough” is not genius. It is throughput under constraints.
AI coding tools can:
cut the time to explore an approach
generate boilerplate without your soul leaving your body
surface documentation and examples in seconds
help you write tests you were going to avoid
translate “I have an idea” into “I have a working starting point”
If one engineer can do that and another refuses because it feels like cheating, guess who looks more “high impact” in the next performance cycle. Not because they are more talented. Because they are more efficient.
Why some engineers resist (and why yelling at them will not help)
Resistance tends to come from a few places:
Fear of deskilling: “If I use this, I will forget how to do it.”
Fear of irrelevance: “If this can do part of my job, what am I worth?”
Taste and quality concerns: “The output is mediocre and I do not want to clean it up.”
Trust concerns: “I do not want proprietary code anywhere near a black box.”
Identity: “Real engineers do not need this.”
Only some of these are rational. All of them are human. So instead of lecturing, do what managers are paid to do: make the change safe and the expectations clear.
A practical management policy for AI coding tools
This is the part where we stop hand-wringing and act like adults.
1. Define approved use cases
Make it explicit what is allowed.
Examples of responsible use:
generating scaffolding and boilerplate
drafting tests, then reviewing and correcting
explaining unfamiliar code paths
summarizing a diff or a module before touching it
proposing refactors, then validating them
Examples of not allowed use:
pasting proprietary code into unapproved tools
generating production code with zero review
using AI output as a substitute for design thinking
hiding behind “the tool wrote it” when things break
2. Standardize the workflow, not the ideology
You do not need everyone to love AI. You need a consistent way of working.
Pick the approved tools.
Write a short internal guideline.
Add a “AI usage” note to code reviews: what was generated, what was edited, what was validated.
This makes it boring. Boring is good. Boring scales.
3. Pair the resisters with the pragmatists
Do not create an “AI elite” and a “legacy group”.
Pairing works because it converts a philosophical debate into a concrete workflow:
“Here is how I use it to get unstuck.”
“Here is how I sanity-check the output.”
“Here is where it is wrong and why.”
The goal is not conversion. The goal is competence.
4. Update expectations honestly
This is the sentence managers avoid because it feels harsh. Say it anyway.
“AI will not replace you. But if you are consistently slower because you refuse modern tools, you are choosing to compete at a disadvantage.”
That is not a threat. That is math.
5. Reward judgement, not raw output
If you only reward speed, you will get fast garbage. So measure what matters:
fewer incidents
easier maintenance
readable code
clear reasoning in reviews
thoughtful designs
good tests
AI can help with speed. Humans are still responsible for judgement.
Herding is not controlling. It is designing the environment
You cannot “fix” cats, dogs, turtles, or the Vim archetype by willpower. You can:
set clear outcomes
build guardrails
create feedback loops
choose tools and workflows that reduce friction
make expectations explicit
protect the team from performative nonsense
If you do that, you are not herding personalities. You are managing a system that lets different personalities do good work.
And if someone insists on being the noble holdout while everyone else becomes more efficient, that is their choice. Just do not pretend it is harmless.
Because AI will not replace them. But the engineer shipping twice as fast absolutely will.