I am an Engineering Manager, managing 15 to 25 engineers and product specialists at Career Team. A
manager is judged on five things. Each tab below says what one of them means, what I have done
about it, and what came of it. Every claim links to the note where the whole story is written
down, failures included, so you can check it rather than take my word for it.
Managing a team, in five parts
career-team / managing / leadership
Leadership
What it means: setting the direction and getting people moving on it without having to order them to.
I lead by showing, not assigning
I shelved a people-management app I had spent a month on, rebuilt the useful part in an afternoon as a dashboard, and demoed it to the team. Within two weeks two engineers had built tools of their own. Nobody assigned them.
What it means: the team ships more and waits less because of what I changed, and I can show the numbers.
I cut review wait from most of a day to three hours
I built a pull request review kit for the team. The slowest quarter of pull requests used to wait 17.6 hours for a first review; now they wait 3.0. Approval stayed with a human, and the note counts the one production break that got through anyway.
What it means: the work runs the same way on a bad week as on a good one.
I measure whether a safeguard actually runs
I rolled a start-of-session check out across a dozen repositories, then counted. In one project it had run once in 165 sessions. The cause was structural, not discipline, and I say in the note that I blamed discipline first.
What it means: the team keeps pace with better tools instead of falling behind them.
I have a staged plan for bringing AI into an organization
Capture the skills of the people who do the work, score them, trigger them, then chain them into loops, and watch for the six ways these systems fail without telling anyone.
The AI on this site uses the same controls a person does, writes through one door, and marks what it touched, so its work can be reviewed like a colleague's.
The bigger part of this is the AI workflow itself, which has its own section below.
People growth
What it means: people on my team get room to grow, and their ideas become team tools.
I give engineers room to own a problem
When our CTO asked us to move bugs to the left, my tech lead built an epic checker that compares tickets and open pull requests against the plan and sends each conflict to its owner.
I teach 150 to 300 college students a term, part-time, at Holy Angel University. I automated the grading onto a platform I built, so my time goes to the students rather than to paperwork.
The tools behind the management work are a workflow I built and run every day. It is
a cycle, and no single model is load-bearing in it: Claude, Codex and DeepSeek take turns writing, and the
parts that keep the work honest stay the same whichever one runs. Each stage is explained under the diagram.
1 · Brief
Every session starts from a written plan and the same instruction file, so the model begins from what the last session decided rather than from a blank page. A new machine is set up from one prompt.
Claude, Codex or DeepSeek does the typing. Which model runs is a routing decision about cost and fit, not a loyalty, because the rules around it do not change.
Hooks and gates run whether anyone remembers them or not, and I count whether they actually fired. One that ran once in 165 sessions taught me to measure the safeguard, not trust it.
A second model reviews the work the way I would, and it never approves anything; a person does. On the team, this took the slowest reviews from 17.6 hours to 3.0.
Every miss is logged and turned into a rule, so the next brief is better than the last. A count in August found 503 commits, each co-authored with an AI. The belief under all of it is that AI multiplies the engineer you already are.