Player → Coach → Architect for Technology Leaders

The CEO course's three-role model transfers to the technology executive with one change: the roles map onto the size of the estate and the team, not only the company, and the security half of the job punishes the transitions harder than the build half does.

FRAMEWORK The Player is the technology leader of a small business or a managed-service firm: hands-on, vendor-managing, often fractional, personally the architecture and the on-call rotation. The Coach runs a mid-market function: hires the first security lead, builds cadence, writes decision rights, picks the five numbers. The Architect runs an enterprise function: governance, portfolio, platforms, capital allocation, board reporting.

HYPOTHESIS Each role has a dominant danger. The Player's is insufficient action — the MFA rollout postponed, the restore never tested. The Coach's is the inability to let go, which is a competence problem rather than a control problem. The Architect's is isolation and dashboard fiction: a picture of the program that is filtered on the way up and symbolic on the way down.

In the Effectiveness Equation — Traits × Behaviors × Organizational Context × Current Moment — this module works on Organizational Context: the same leader, the same traits, a different-sized job.

The best engineer in the building is rarely the best CIO in the building — and the CISO who personally reads every alert has built a program that fails when they sleep.

Neither sentence is about talent. Both are about scale: personal excellence is the product at forty people, a bottleneck at four hundred, and nearly irrelevant at four thousand, where the design of who decides what is the whole job. Each stage rewards exactly the behavior the next one punishes.

RESEARCH FINDING Bandiera, Prat, Hansen and Sadun (2020, from the CEO library) collected time-use diaries from 1,114 manufacturing CEOs in six countries and reduced hundreds of activity types to an index running from "manager" behavior — one-on-ones with operational staff, site visits — to "leader" behavior, meaning multi-function meetings with senior executives. A one-standard-deviation move toward the leader end was associated with about 7% higher sales, and the difference became significant only about three years after appointment; they estimate about 17% of firms had a CEO whose type did not fit the firm. One week of diaries per CEO, manufacturing only, and the authors caution this is a matching story rather than proof that leaders beat managers. INTERPRETATION Read as fit rather than ranking, it is this module's spine: behavior types differ, mismatch is common, and the payoff arrives slowly enough that a leader who delegates in January and panics in September is measuring the wrong thing.

RESEARCH FINDING Graham, Harvey and Puri (2015, from the CEO library) surveyed more than 1,000 CEOs and CFOs on delegation and capital allocation. Executives delegated more when overloaded or distracted by major events such as acquisitions, and less when they had long tenure or financial expertise. Self-reported, cross-sectional, no causal identification. INTERPRETATION The direction is what matters here. Expertise reduces delegation, so for an engineer-turned-CIO deep domain knowledge is the fuel of the hands-on trap, not the cure for it.

RESEARCH FINDING Bloom and Van Reenen (2007, from the CEO library) scored 18 management practices — monitoring, targets, incentives — through double-blind interviews at 732 medium-sized manufacturing firms in four countries, and found practice scores strongly associated with productivity, profitability and survival. Survey-based and correlational. INTERPRETATION These are the Coach's artifacts: at mid-market scale, measured practices replace the founder's personal attention.

RESEARCH FINDING (Tier 3, practitioner). Weill and Ross (2004), research-based practitioner work from a study of about 250 enterprises, define IT governance as the framework of decision rights and accountabilities for IT decisions and report that firms with superior governance earn more than 25% higher profits given the same objectives. Not peer-reviewed; the comparison is descriptive and the selection of top performers is the authors' own. INTERPRETATION Cite it for decision rights as a design choice, not as proof that governance causes profit.

RESEARCH FINDING Three studies explain why the Architect's picture degrades. Milliken, Morrison and Hewlin (2003, from the CEO library) interviewed 40 employees: 85% could recall an occasion when they felt unable to raise an important issue with a superior. Detert and Edmondson (2011, from the CEO library) identified taken-for-granted beliefs that speaking up is risky, which predict silence even where the environment is objectively safe. Edmondson (1996) adds the security-relevant twist: across eight nursing units in two hospitals (146 respondents), units with better team climate and more manager coaching reported higher detected error rates, manager coaching correlating with detected errors at r = .74. Small samples, correlational, none measuring executive information environments directly. INTERPRETATION If people withhold from a boss one level up, an executive five levels up should assume the incident numbers on their dashboard have been filtered several times — and that a falling number may be a reporting story rather than a security one.

RESEARCH FINDING Angst, Block, D'Arcy and Kelley (2017) supply the other half of dashboard fiction. In a matched panel of over 5,000 US hospitals and 938 breaches from 2005 to 2013, hospitals classified as symbolic rather than substantive adopters of security practices saw the effectiveness of their investment diminished and an increased likelihood of breach. One sector; adoption depth inferred rather than observed; reported breaches only. INTERPRETATION An Architect's design can be adopted symbolically three layers below and still report green.

RESEARCH FINDING (Tier 3, descriptive). Two practitioner sources describe the Player's world. The Verizon 2025 Data Breach Investigations Report, drawn from a non-random contributor sample of 12,195 confirmed breaches, reports third-party involvement in 30% of breaches and ransomware present in 88% of SMB breaches. The IANS and Artico State of the CISO 2026 survey of more than 600 security leaders reports 52% of CISOs at companies below $100M in revenue holding executive-level titles, and 52% overall saying their responsibilities are not manageable with current resources. Self-selected samples, base rates only. INTERPRETATION The Player's posture is largely somebody else's engineering, and the Player's title frequently outruns the function beneath it.

Where the evidence is weak

No peer-reviewed study follows technology executives through the Player-to-Coach or Coach-to-Architect transition. The three roles are a FRAMEWORK assembled from time-use, delegation, management-practice and silence research plus practitioner observation; the dominant danger at each scale is HYPOTHESIS. The two qualitative anchors used later — Peppard (2010) on CIO performance as a function of the CEO's and top team's IT savviness, and Ashenden and Sasse (2013) on CISOs' own reports of low perceived power — are small, interview-based and interpretive. The delegation ladder in Section 4 is a design tool, not a tested intervention.

Three jobs, one title

FRAMEWORK The Player leads technology in a company of roughly ten to a hundred and fifty people, or leads it for a managed-service or business-process firm whose clients are that size. They are the architecture, the vendor manager, the auditor's contact and the after-hours escalation. The stack is largely vendor-managed — remote monitoring, managed detection, a cloud identity platform, a backup provider — so much of the real posture is somebody else's engineering, which is why the Verizon (2025, Tier 3) figures on third-party involvement and SMB ransomware read as a job description rather than a statistic. Many Players are fractional, holding the vCISO role across several client companies at once, with an executive title and little function beneath it (IANS, 2026, Tier 3) — the structural version of the low perceived power Ashenden and Sasse (2013) heard from CISOs directly.

HYPOTHESIS The Player's dominant danger is insufficient action: the MFA rollout postponed a quarter, the restore never tested, the managed-detection vendor never asked what it actually monitors, the contract signed with a security schedule nobody read. Small organizations rarely fail from bad architecture. They fail from things that never happened.

The Coach runs a function of roughly a hundred and fifty to two and a half thousand people. The work is hiring the first real security lead and then not being them. Four artifacts mark the transition: the hire; a cadence — weekly operations, monthly risk, quarterly owner or board update; written decision rights covering who approves an exception, who can take a system offline and who signs a vendor; and five numbers everyone sees. Bloom and Van Reenen (2007) is the backbone — measured practices replace personal attention.

HYPOTHESIS The Coach's dominant danger is the inability to let go, and it is a competence problem rather than a control problem: you still read a packet capture faster than your security lead. Graham, Harvey and Puri (2015) found delegation falling with tenure and expertise — the trap is competence pointed at the wrong level.

The Architect runs an enterprise function: governance, portfolio, platform strategy, capital allocation and board reporting. Weill and Ross (2004, Tier 3) is the working frame — decision rights and accountabilities as a design object. The Architect's personal effort on any one problem is close to irrelevant; their design of who decides what, on what evidence, is close to everything.

HYPOTHESIS The Architect's dominant danger is isolation and dashboard fiction. The silence research (Milliken et al., 2003; Detert & Edmondson, 2011) makes the upward filter structural rather than personal, Edmondson (1996) makes a falling incident count ambiguous, and Angst et al. (2017) makes a well-designed control adoptable symbolically three layers down. An Architect can be wrong for two years and see nothing but green.

The hands-on engineer trap

FRAMEWORK The trap is a progression, and it starts from a virtue.

Stage one is "I'll just fix it myself." At twelve people this is correct. Stage two is "I'll fix it faster than you will." Someone now owns the problem, and you still solve it first, because you can and because waiting hurts. Stage three is "Send it to me before you push it." You no longer solve everything; you check everything. This feels like delegation. It is a review bottleneck with a friendly face. Stage four is "Nothing ships without me" — decision rights were never designed, only assumed, and the organization has learned that initiative without your blessing is a career risk. Stage five is "Nobody else can be trusted with this," which by then is nearly true, because the people who could be were trained out of trying.

INTERPRETATION Each handover is an identity threat disguised as an operational question. Letting someone else own the identity platform admits you are no longer the best engineer in the building — and for most technical leaders, that was the basis of their authority before the title existed. Owens and Hekman (2012, from the CEO library) identified modeling teachability and spotlighting others' strengths as observable humble-leader behaviors; here they cost something specific, because they transfer the thing you were respected for.

Mismatch in both directions

INTERPRETATION Picture an enterprise CIO — twenty years, four thousand people, a governance calendar — who takes the technology chair at a forty-person managed-service firm. She asks for the configuration-management database. There isn't one. She schedules a change advisory board and a quarterly architecture review. Meanwhile a client's tenant still has legacy authentication enabled, the backup for two clients has been failing silently for eleven days, and both senior engineers have taken recruiter calls. The firm needs someone to disable legacy auth this afternoon and take the engineers to lunch. Her dial is set to delegation where the job rewards hands-on, and to patience where it rewards urgency — Peppard's (2010) point about context in its sharpest form.

Now the reverse. The Player who built a forty-person firm's stack takes over technology for nine thousand people. He keeps domain administrator rights "for emergencies," approves firewall changes personally, calls a plant's system administrator directly about an alert, and cancels the architecture review board because "we'll just decide faster." Each was right at forty people. At nine thousand, each destroys a coordination mechanism: every direct call teaches the hierarchy that the chain of command is optional, and every personal approval tells the process its authority is provisional.

The delegation ladder for security operations

FRAMEWORK Delegation is not a disposition, it is a setting, and the setting belongs to an activity rather than to a person. Six rungs:

• 0 — You do it, and nobody else sees it happen.
• 1 — You do it, narrated. Someone shadows and writes the runbook.
• 2 — They do it, you approve each instance before execution.
• 3 — They do it inside a written standard; you review a sample afterward.
• 4 — They own the standard; you review exceptions weekly and the standard quarterly.
• 5 — They own the outcome and the budget; you see a metric and a trigger list, and re-enter only on a named trigger.

INTERPRETATION The common error is running the whole function at one rung. In a three-hundred-person company a reasonable spread is: alert triage at 5; endpoint containment at 4 with thresholds written down; identity and firewall change approval moving from 3 to 4 across two quarters; vendor security review at 4 against a tiering standard you still own; exception granting held at 2, because exceptions are where risk concentrates and where standing distorts judgment; incident command at 3, so your lead runs severity-two and below while you run severity-one until they have run three alongside you; and the materiality recommendation at 0, because that accountability is not delegable.

Containment authority is the version that has to exist in writing before the incident: any analyst may isolate a single endpoint; the shift lead may isolate a subnet or disable an account; only the security lead or the executive may take a revenue-bearing system offline; nobody wipes an endpoint before evidence capture.

Two rules keep the ladder honest. A rung you have not written down is not a rung — unwritten authority defaults to 2, because people ask. And you may drop an activity down a rung after a failure, but you must say in advance for how long, or the drop becomes permanent and the ladder becomes a story you tell about yourself.

Fictional composite. Harborline Business Services is a business-process and managed-service firm headquartered in Hartford, with offices in Providence and outside Boston: $46M revenue, 340 employees, and about 180 small-business and mid-market clients across the Northeast in financial services, healthcare, professional services and retail. It runs back-office operations for those clients and, for roughly half, their IT and security stack.

Nadia Okonkwo co-founded Harborline as its network engineer and is now its CIO and CISO. At sixty people she was excellent. At three hundred and forty, five things were true: she approved every firewall and identity change across the client estate; she was the named security contact in sixty client contracts; she completed about ninety client security questionnaires a year herself; she was the after-hours escalation for every alert; and her team had grown to twenty-two, nine reporting directly to her.

The trigger was not insight. In March a broker-dealer client had credential abuse on an administrator account at 2:14 a.m. Harborline's analyst identified it in nine minutes, could not reach Nadia — she was on a flight — and had no written authority to disable the account. He waited. The account was disabled at 6:40 a.m. The client's summary to its regulator was accurate and unflattering: the provider detected it in nine minutes and acted in four hours and twenty-six minutes. Two months later the same client, ahead of a FINRA examination, asked for a named vCISO with defined escalation authority and a documented incident process. Nadia's honest answer was that the escalation authority was her phone.

The transition took fourteen months. First, she hired a security lead — Ray Delgado, from a regional bank — and paid above her own band for him. Second, they wrote containment thresholds and posted them in the operations channel: any analyst may isolate an endpoint or disable a non-privileged account; the shift lead may disable a privileged account or isolate a client subnet; only Ray or Nadia may take a revenue-bearing client system offline. Third, they set the ladder per activity and wrote the current rung beside each item on a one-page table: triage at 5, change approval moved from 2 to 3 to 4 over three quarters, questionnaires at 4 against a standard answer library, exceptions held at 2 with Nadia approving.

Fourth, a cadence: a Monday operations review Ray ran, a monthly client-risk review, a quarterly session with the founders. Fifth, five numbers on one page every week — mean time to contain, percentage of client estates with phishing-resistant MFA, restore tests completed against plan, overdue exceptions, and clients where Harborline itself held an unreviewed privileged path. Before this, only Nadia knew any of them, and only approximately.

The hardest change was the contracts: removing her name as security contact from forty-one of sixty agreements took two quarters, three conversations that went badly and one that nearly lost an account.

Eighteen months on, mean time to contain was thirty-eight minutes against four hours and twenty-six, questionnaire turnaround had gone from eleven days to three, and Ray had run two severity-one incidents without her. Nadia worked fifty-two hours a week instead of seventy, and spent about a third of it on things a Player would consider waste: hiring, a pricing conversation about the security service line, and a two-day argument about which client segments to stop serving.

INTERPRETATION Nothing here was an attitude change. The mechanisms — written containment authority, a rung per activity, a cadence, five shared numbers — made delegation the default rather than a daily act of will. Nadia's Player instincts had not been wrong. They had been calibrated for a sixty-person firm and carried, unexamined, into a firm five times that size.

Take Harborline in March, hours after the 2:14 a.m. incident, and put three archetypes in Nadia's chair.

The SMB / MSP Technology Leader (Player) reads it as an availability problem and fixes availability: a second phone, a backup escalation number, herself on a formal rotation. Fast, cheap and wrong at this size. The gain is that the next 2 a.m. call gets answered. The cost is that the firm has re-confirmed that the executive is the control, and the next failure arrives when she is in a client meeting rather than on a plane. The Player's danger is not laziness — it is doing the available small thing instead of the unavailable large one.

The Mid-Market CIO (Coach) hires the security lead and writes the containment thresholds, which is what Nadia did. The gain is a function that works when she sleeps. The cost lands in months two through six, when Ray makes calls she would have made differently and two of her direct reports test whether the ladder is real by escalating around him. A Coach who does not hold the line converts a real delegation into an expensive second opinion, and the organization learns that the table on the wall is decorative.

The Enterprise CIO (Architect), imagined in this seat, designs the whole system at once: a governance model, a client-risk committee, a RACI covering forty activities, a quarterly attestation. Weill and Ross (2004, Tier 3) would recognize the instinct, and much of it is what Harborline eventually needs. The danger is that at 340 people the design outruns the operators, and decision rights nobody has practiced under pressure will not survive their first 2 a.m. test. Design without a rung-by-rung handover is dashboard fiction with a start date.

INTERPRETATION A fourth archetype, the Technical CISO, would go after the administrator account itself — privileged access management, just-in-time elevation, tighter conditional access. All correct, all worth doing, and none of it touching the four hours and twenty-six minutes. That is the module's asymmetry: the available technical answer competes with the unavailable structural one, and looks more responsible in the moment.

FRAMEWORK The Overuse Ladder — strength → overused strength → liability — climbs differently at each scale, because each role rewards a different strength.

At the Player scale the characteristic rung is humility → excessive hesitation, dressed as prudence: the MFA rollout waits for a quieter month, the vendor is not challenged because the relationship matters, the restore test is scheduled and re-scheduled.

At the Coach scale it is attention to detail → micromanagement and its partner persistence → stubbornness. The security lead is hired and then supervised at rung 2 on everything, and their first different-from-yours decision is reversed, politely, in front of the team. Within two quarters they are managing you rather than the function, and the good ones leave — which the Coach experiences as confirmation that nobody else can do this.

At the Architect scale it is optimism → delusion: the dashboard is green, the maturity score has improved, and the control exists on the slide rather than on the server. Angst et al. (2017) found symbolic adoption diminished the effectiveness of investment; Edmondson (1996) found better climates produced more reported errors, so improving numbers can mean improving silence. Its partner is vision → fantasy: a three-year platform strategy alongside a six-month-old critical vulnerability nobody escalated, because escalating is not what the culture rewards (Milliken et al., 2003).

INTERPRETATION The dangerous moment is not the failure; it is the promotion. Every transition asks the leader to stop doing the thing that earned it, and the evidence that they have not made the transition is usually two levels below them, and quiet.

Early warning signs

• The executive can name the last five decisions they made personally and cannot name five their team made without them.
• The new security lead's disagreements are answered with history rather than with evidence.
• Incident, near-miss or phishing-report counts are improving and nobody has asked whether reporting fell instead.
• The leader is the named contact, approver or escalation in more places than they can list from memory.
• A control has been on the board slide for three quarters and nobody has watched it operate.

1. Which role does your company's size call for, and which one are you actually running? Give three activities from last month as evidence, not a self-description.
2. Take the ten things only you can currently do. For each, write the rung it sits on and the rung it should sit on. Which one have you been protecting because it is the thing you are respected for?
3. Where are you on the five stages of the hands-on engineer trap? Name the person whose judgment you overrode most recently, and whether you were right.
4. If you were unreachable for seventy-two hours starting now, what would not happen? Which of those items is a genuine accountability and which is an unwritten rung?
5. Write your containment thresholds from memory. If you cannot, they do not exist, and your team's real authority is "ask."
6. Which of your improving metrics could be explained by less reporting rather than better security, and what would you look at to tell the difference?

• The Player is the technology function, the Coach builds one, and the Architect designs the system that runs it — and each role rewards the behavior the next one punishes.
• The dominant dangers are scale-specific: insufficient action at the Player scale, inability to let go at the Coach scale, and isolation plus dashboard fiction at the Architect scale, the last of which the silence and symbolic-adoption research makes structural rather than personal.
• The hands-on engineer trap runs from "I'll just fix it myself" to "nothing ships without me," and expertise is its fuel: Graham, Harvey and Puri (2015) found delegation falling with tenure and expertise, and each handover is an identity threat disguised as an operational question.
• Delegation is a setting on an activity, not a disposition. Write the rung, write the containment thresholds, and put a date on every temporary drop — because an unwritten rung is "ask," and "ask" is how a program becomes one person deep.