People Management for CTOs: Build a Leadership System

People Management for CTOs: Build a Leadership System

In 2026, a 120 person engineering org can ship 20 times a day and still feel stuck. The bottleneck isn’t code. The bottleneck is inconsistent people decisions. Hiring varies by manager, leveling drifts by team, and performance feedback shows up six months late (which is basically the same as never).

A Business CTO scales by building a leadership system. That system turns people decisions into something closer to an operating model: consistent calls, predictable growth, fewer surprises. It runs on a few mechanisms, a meeting cadence, and a small set of shared rubrics.

Engineering leadership meeting cadence

A leadership system needs a heartbeat. Without a cadence, you run on interrupts and the loudest problem wins. With a cadence, you make the same class of decisions the same way, every week, even when things get noisy.

The common mistake is “we need to communicate more,” so the calendar fills up. That move fails fast. The goal is fewer meetings with higher decision density, and clear inputs and outputs so people can get back to building.

A weekly cadence will feel heavy. It usually takes about two weeks. Then the org stops re-litigating the same topics in side chats, and deep work shows up again.

The core hub meeting

I treat the engineering leadership meeting as the core hub. It’s a working session, not a status parade. Will Larson pushes for a weekly engineering leadership meeting in most orgs, and only relaxes that at very small companies under 20 engineers or slow moving businesses (Meetings for an effective eng organization).

A good default attendee list is your directs plus two partners. Larson describes a Stripe example that included an HRBP and a recruiter, and he also argues for including a small number of senior engineers in the same room with clear trust rules (Should you include engineers in your leadership meetings?).

A practical agenda that scales past 50 engineers looks like this:

• Metrics and risks, 15 minutes
• Staffing and org changes, 15 minutes
• Hiring pipeline and offers, 15 minutes
• Performance and growth cases, 20 minutes
• One decision topic, 25 minutes

The trick isn’t the agenda. The trick is the input packet. Every topic needs a one page pre read with a clear ask. If the packet is missing, the topic slips. That rule feels strict until you realize it’s the only thing standing between “leadership meeting” and “group therapy.”

The minimum meeting set for teams

Team level cadence should protect flow and surface risk early. Zenhub’s list is a decent baseline for agile teams, with standups, planning, review, retro, refinement, and a weekly sync (7 Essential Meeting Cadences).

I don’t copy that list as a template. I use it as a menu. The system rule is simple: meetings exist for decisions and learning. Status moves async, or it becomes a tax on everyone’s attention.

Here’s a lightweight set that works for most product teams:

• Daily standup, 15 minutes, only blockers
• Weekly planning, 45 minutes, commit to a small slice
• Weekly demo, 30 minutes, show real work
• Retro every two weeks, 45 minutes, pick two fixes

And here’s the platform team variant:

• Weekly intake triage, 45 minutes, accept or reject requests
• Monthly roadmap review, 60 minutes, align with product leads
• Quarterly reliability review, 60 minutes, SLOs and incident themes

If you want a place to track the outputs, a portfolio view helps. Command Center can hold the decision log, risks, migrations, and team capacity in one place (/command-center).

Org design choices for platform and product teams

Org design is where people management turns into a systems problem. Bad design forces heroics. Good design makes normal work feel… normal. That’s the bar.

CTOs get stuck here because every option has a cost. Platform teams can turn into ticket factories. Product teams can fragment architecture. The right shape depends on what you ship and how often you change it, not on what looked good at your last company.

I use three questions to pick a shape. What’s the rate of change in product surface area? What’s the rate of change in infrastructure? What’s the cost of inconsistency across teams?

Platform vs product teams, and the “thin platform” rule

A platform team should own paved roads. A platform team should not own every road. The thin platform rule is my default: the platform team builds the smallest set of shared services that remove repeated toil.

A thin platform usually owns CI and deploy pipelines, observability standards and tooling, identity and secrets plus baseline security controls, and shared runtime patterns like service templates. That list stays short on purpose. The moment the platform owns “everything,” you’ve created a dependency magnet.

Product teams own customer outcomes. Product teams also own the on call for their services, unless you run a dedicated SRE model. That ownership line matters because it keeps incentives honest. Teams that carry the pager tend to ship fewer footguns.

The failure mode is easy to spot. Platform work becomes a queue, and product teams fork the platform. The fix is also clear: platform work needs a product manager, an intake policy, and published SLAs.

Staff ratios that prevent management debt

Staff ratios aren’t a vibe. Staff ratios are a control knob.

A few ratios that keep systems stable:

• 6 to 8 engineers per engineering manager in steady state
• 1 staff or principal engineer per 12 to 20 engineers, depending on complexity
• 1 product manager per 6 to 10 engineers for product heavy orgs

The exact number shifts by domain. A payments org needs more senior technical leadership than a marketing site. The move that matters is picking a ratio, publishing it, and reviewing it quarterly. If you don’t, the org “chooses” for you, and the choice usually looks like overloaded managers and invisible tech leadership.

Where architecture lives

Architecture fails when it has no home. Architecture also fails when it becomes a committee that meets to argue about style guides.

I like a split model:

• Staff engineers own architecture for a bounded area, tied to a roadmap
• A small architecture forum reviews cross cutting changes
• The CTO owns architecture principles and escalation

The architecture forum should meet on a cadence, not ad hoc. A biweekly 60 minute review works for most orgs. The forum should decide on interfaces, data contracts, and shared runtime patterns. The forum should not bikeshed internal code style.

If you want to make dependencies visible, a map helps. Microservices Dependency Mapper can show service coupling and call paths, which makes org boundaries easier to set (/tools/microservices-dependency-mapper).

Hiring and leveling system for engineering teams

Hiring scales when you stop relying on taste. A hiring system uses role scorecards, consistent interview loops, and leveling principles that survive manager turnover.

McKinsey frames a “people operating system” as more strategic, more fluid, and more data driven, with a centralized hub for people and org metrics (A new operating model for people management). I agree with the direction, but I care most about one outcome: the system has to make decisions repeatable.

Role scorecards that stop the “clone me” hire

A role scorecard is a one page contract between the hiring manager and the interview loop. It defines what good looks like at 6 and 12 months, not what “feels strong” in the room.

A scorecard should include:

• Mission, one sentence
• 3 outcomes with numbers, like “reduce p95 latency from 450ms to 250ms”
• 5 competencies, with observable behaviors
• Non goals, like “does not own the data platform roadmap”

The scorecard also sets the leveling anchor. If the outcomes require cross team influence, the role isn’t senior. The role is staff.

Interview loops that produce evidence

Interview loops fail when each interviewer uses a private rubric. Interview loops also fail when you test trivia and call it “signal.”

A loop that scales past 30 hires a year needs a shared rubric per competency, a trained bar raiser rotating quarterly, and a debrief format that forces evidence. Without that structure, you’ll get confident opinions and inconsistent decisions.

I like a debrief rule: every “yes” and “no” must cite two concrete signals. “Strong communicator” isn’t a signal. “Drove a design review with three teams and resolved a conflict” is a signal.

Leveling principles that survive growth

Leveling drift is expensive. It creates pay inequity, promotion fights, and attrition. It also quietly trains managers to game the system.

A leveling system needs three published principles:

• Scope: what systems and teams the person affects
• Autonomy: what decisions the person makes alone
• Impact: what changes in metrics or risk

Calibration is where the system becomes real. If you avoid calibration because it feels political, politics still shows up. It just shows up in backchannels.

Quality of hire is the feedback loop that keeps hiring honest. TekRecruiter suggests a checkpoint cadence at day 30, 60, and 90, using signals like onboarding confidence, early code review feedback, pull request throughput, and defect escape context (Quality of Hire Metrics). TekRecruiter also notes a reference target of 75 percent meeting or exceeding expectations at 12 months, and 90 day retention above 90 percent in stronger systems, citing Metaview benchmarks as a reference point (Quality of Hire Metrics).

I treat those numbers as guardrails. The move is picking your own targets, then reviewing them quarterly.

If you want to instrument this without turning it into surveillance, keep the data coarse. Track outcomes, not keystrokes. A simple dashboard can live next to your delivery metrics in an engineering metrics view (/tools/engineering-metrics-dashboard).

Performance and growth system for engineers and managers

Performance management breaks when it becomes an annual event. Growth breaks when it becomes a perk. A leadership system makes expectations explicit, feedback frequent, and low performance quick to address.

Borderless and McKinsey both argue for a more personal and more tech enabled people model, with better access to people metrics and more tailored development paths (Borderless summary, McKinsey full article). The tech part matters, but the operating rule matters more: managers have to give feedback while there’s still time to change behavior.

The “expectations ladder” artifact

I use one artifact per role family. I call it an expectations ladder. The expectations ladder lists behaviors by level, with examples people can actually recognize in the day to day.

An expectations ladder for engineers should cover:

• Delivery: sizing, sequencing, and follow through
• Quality: testing, review, and operational ownership
• Collaboration: design reviews, conflict handling, and writing
• Scope: component, service, domain, org

The ladder becomes the shared language in 1:1s, promos, and calibration. Without that shared language, every conversation turns into “I feel like…” and nobody wins.

Feedback loops that don’t wait for review season

I want three feedback loops running all year:

• Weekly 1:1s for managers and reports
• Monthly growth check, 30 minutes, tied to the ladder
• Quarterly calibration for leveling and pay

The monthly growth check isn’t a second 1:1. The growth check answers one question, and only one: what behavior change will move this person up a level?

If you need a place to capture action items from reviews and postmortems, keep it close to incidents and delivery. Our incident tooling can help you turn outages into coaching moments without blame, using a consistent format and follow ups (/tools/incident-postmortem).

Handling low performance fast

Low performance is a systems problem and a human problem. The system part is speed. Waiting six months is unfair to the person and the team, and it drags everyone into ambiguity.

I use a simple timeline:

• Week 0: name the gap, in writing, tied to the ladder
• Week 2: check for behavior change, and remove blockers
• Week 4: decide on a formal plan or a role change
• Week 8: exit or stabilize

The manager’s job is clarity. The CTO’s job is consistency across teams.

A weekly leadership cadence makes this possible. You can review two cases a week without drama. You can also spot patterns, like one manager with three struggling hires.

Manager development system for EMs

Managers scale your org, or they break it. A CTO can’t outwork weak management. A leadership system sets requirements for EMs, and it inspects outcomes without hovering over every Jira board.

N2Growth describes the modern CTO role as broader than technology, with a real focus on building and retaining a diverse, capable team (The CTO: Evolving the Role). That framing is fine, but it skips the hard part: you need a system that turns “be a good manager” into observable work.

What you require from EMs

I require five things from every EM:

• A weekly 1:1 cadence with every report
• A written team plan for the quarter, with risks
• A hiring plan tied to a role scorecard
• A growth plan for each engineer, tied to the ladder
• On call health, tracked and discussed

An EM doesn’t need to be the best engineer on the team. An EM needs to run the system.

How you inspect without micromanaging

Inspection isn’t control. Inspection is how you learn whether the system is working.

I inspect four outputs:

• Delivery predictability, like planned vs shipped per sprint
• Quality signals, like incident count and repeat causes
• People signals, like regretted attrition and time to fill
• Hiring signals, like 90 day retention and 12 month ratings

Shoury Bharadwaj mentions a Say Do ratio target of 70 percent or more at sprint and OKR levels, and a KTLO target of 15 to 20 percent as healthy (LinkedIn post). I treat those as example numbers, not universal truths. The move is picking your own targets, then reviewing them in the same meeting every week.

If you want a tool to make capacity visible without turning it into theater, Team Scaling Calculator can help you model headcount and manager load (/tools/team-scaling-calculator).

The Leadership System Scorecard (link-worthy)

Here’s a definition you can reuse.

A leadership system is the set of cadences, rubrics, and decision logs that make hiring, org design, and performance decisions repeatable across managers.

I track the system with a simple scorecard. The goal is trend, not perfection.

TekRecruiter’s reference points can seed the hiring targets, but you should set your own baselines and adjust by role type (Quality of Hire Metrics).

If you want to connect this to your broader operating model shift, Part 1 covers the delegation spine and the weekly scorecard rhythm in detail, and you can link the leadership system scorecard to that same cadence (Part 1: What Changes When You Become a Business CTO).

A 30 day install plan for your leadership system

A system needs a starting point. A 30 day install plan gives you one. The plan also creates proof that the org can change its habits, which matters more than the docs.

We already covered the business learning loop and the personal advisory bench in Part 2, so I won’t repeat it here. The leadership system uses those artifacts as inputs, not as extra work (Part 2: How CTOs Learn the Business Fast Without Faking It).

Week 1: pick the cadences and artifacts

Start with the minimum set:

• Weekly engineering leadership meeting, 90 minutes
• Biweekly architecture forum, 60 minutes
• Monthly hiring review, 45 minutes
• Quarterly calibration, 2 hours

Artifacts:

• Role scorecard template
• Expectations ladder per role family
• Leadership system scorecard

Week 2: lock org design and architecture ownership

Make three decisions and write them down:

• Platform team charter, and what it will not do
• Product team ownership boundaries, including on call
• Architecture forum membership and decision scope

If you are renegotiating vendor tooling as part of this, Part 3 covers the contract to backlog move and the 48 hour technical risk review, which keeps procurement from derailing your people system (Part 3: Contract Negotiation for CTOs Who Are Not Lawyers).

Week 3: standardize hiring and leveling

Install the loop:

• Every open role has a scorecard
• Every interview uses the same rubric
• Every offer includes a leveling justification

Then add the quality of hire checkpoints at day 30, 60, and 90. Keep the signals light and diagnostic, as TekRecruiter recommends (Quality of Hire Metrics).

Week 4: run performance and manager inspection

Run a real calibration, even if it feels early. Pick three growth cases and one low performance case. Use the expectations ladder as the anchor.

Then inspect managers using outputs, not activity. If a manager can’t produce a team plan, a hiring plan, and growth plans, you found the real bottleneck.

The CTO decision you need to make

The hard part isn’t writing templates. The hard part is holding the line when a strong leader wants an exception. Exceptions feel kind in the moment, and they rot the system.

Pick one rule you won’t bend for 90 days. A good candidate is the role scorecard rule: no scorecard, no opening. That single constraint forces clarity in org design, leveling, and performance.

The next part, Executive Influence for CTOs: A Decision Framework You Can Run Weekly, will show how to carry these people decisions into exec rooms without turning them into HR debates.