Organization, Leadership Systems, and Operating Model

7.1 Organization Design Basics You’ve Lived (Roles, Spans, Shifts, Duty Rosters)

In business, “organization design” is often discussed only after something breaks—confusion about ownership, too few decision makers, or staffing models that don’t match demand. In the military, you address these issues, even if you never call them org design. Every time you adjusted a watch rotation, consolidated responsibilities, created a new cell, or rebalanced supervision, you were designing the organization.

Start with roles. A role is not a title; it is a bundle of responsibilities, decision rights, and interfaces. Capture what each key role owned, what it produced, and who depended on it. If you redistributed responsibilities across shops or clarified who signs off, that is operating model work.

Next, capture the span of control. Record your typical number of direct reports, the peak span you managed, and what you changed when the span became too wide (quality drift) or too narrow (slow decisions). Then document your shift model. Duty rosters and watch bills are workforce planning under constraints such as coverage requirements, fatigue, skill mix, qualification gates, leave, and surge capacity. If you built schedules, record the rules you used and the trade-offs you made.

Org Design Snapshot: Use this for each role where you run a team.

• Mission: what the team delivered daily and what “failure” looked like.
• Structure: the teams/sub-teams and how work was divided.
• Span and staffing: direct reports, total headcount, and shift/rotation design.
• Interfaces: the top handoffs to other teams and where friction occurred.
• Design changes: what you changed, why, and the measurable result.

When you translate this later, lead with the problem you solved, not the org chart. Examples include stabilized coverage, reduced handoff errors, improved supervisory capacity, or accelerated training throughput. Then name the design move—clarified roles, redistributed workload, adjusted spans, or redesigned shifts.

7.2 Governance: Decision Rights, Battle Rhythms, and Accountability

Governance is the system that makes decisions reliably. In business, weak governance shows up as endless meetings, unclear approval paths, and decisions that get reopened without closure. Military governance is often stronger because it is explicit about who can decide, what gets escalated, and how leaders stay informed.

Decision types: Begin by listing the decisions you influenced—prioritization, resource allocation, risk acceptance, maintenance deferrals, cyber change approvals, training waivers, or vendor coordination. For each decision, capture three elements—authority, required inputs, and escalation thresholds. This becomes a decision-rights map.

Decision-rights template: Capture governance in plain language.

• Decision: what is being decided.
• Owner: who has final say.
• Contributors: who provides analysis or recommendations.
• Trigger: what forces the decision or escalation.
• Cadence: where it is decided (daily standup, weekly review, ad hoc escalation).
• Record: how the decision and rationale are captured.

If you run a “battle rhythm,” translate it as an operating cadence. Document the purpose of each meeting, the decisions it produced, and the mechanism that made follow-through real. In consulting, accountability means owners, due dates, and visible tracking, not punishment. If you maintained an action tracker, readiness tracker, inspection discrepancy log, or corrective action register, you have governance evidence.

Also capture escalation as a safety feature. Provide one example where early escalation prevented a larger failure, and one example where you contained an issue within pre-set guardrails. When translating, use language of clarity and speed, such as shortened decision cycle time, reduced rework from late approvals, improved predictability through defined decision rights, and created a repeatable cadence for performance and risk reviews.

7.3 Cross-Functional Coordination (Staff Functions as an Operating Model)

Consulting work is cross-functional by default. Clients rarely have a single owner for an outcome; they have multiple functions with competing priorities. Military staff and shops are a training ground for this reality. Whether you served on a staff or led a shop that depended on others, you have practiced aligning functions that don’t move together.

Map the functions you coordinated with and translate them into civilian equivalents such as operations, supply chain, finance, HR, IT, security, safety, quality, compliance, and external partners. Then identify recurring coordination failures, including mismatched timelines, incomplete information, unclear handoffs, and “everyone agrees” without anyone owning the next step.

Your value is the mechanism you used to coordinate. Examples include an integrated planning meeting, a shared dashboard, a single intake and triage process, a synchronization schedule, or clear decision rules. Capture both the work flow and the social system that made it work.

Cross-functional map: Build this for two situations you can discuss safely.

• Outcome: what the organization needed (readiness, uptime, on-time delivery, compliance).
• Functions: who contributed and what each owned.
• Handoffs: where work moved and where errors/delays occurred.
• Coordination mechanism: cadence, artifact, or decision rule that resolved friction.
• Result: what improved (time, quality, predictability, risk).

Cross-functional influence is especially powerful when you lack formal authority. Record what you used as leverage, such as shared metrics, shared risk, senior sponsorship, or mutually beneficial trades. That is “influence without authority” in consulting language.

7.4 Building and Running Management Systems (Meetings, Metrics, Routines)

A management system is the minimum set of routines that keeps performance on track. Many organizations confuse a calendar full of meetings with a true system. If you have run daily standups, weekly reviews, quality boards, safety councils, or training pipelines, you have built management systems, especially if your routines produced closure.

Document your system as a loop—observe performance, decide actions, assign owners, track closure, and adjust. Then capture the artifacts that made it real, including dashboards, action logs, trackers, and decision records.

Meeting Charter: Create this for one or two recurring forums you led.

• Purpose: what decisions the meeting exists to make.
• Inputs: what data is reviewed and who provides it.
• Outputs: actions, owners, deadlines, and escalation triggers.
• Rhythm: frequency, standard agenda, and time boxes.
• Follow-through: how actions are tracked and what happens when they slip.

Finally, note how you improved the system over time. Did you remove unnecessary meetings, tighten metrics definitions, simplify dashboards, or focus attention on the few measures that drove outcomes? Consultants are often hired to do exactly that: keep accountability while reducing friction.