Skip to content

Wires Uncrossed — Messaging & Positioning

ContributorsMyles Henaghan

When to use: Writing or editing any Wires Uncrossed content, or content about software delivery consulting / HoEN for WUE audiences. Default for all WUE content tasks.

Instructions

Produce content that reflects who WUE is: experienced, practical, outcome-obsessed, and unlike traditional consultants.

Who Wires Uncrossed Is

Boutique NZ/AU software engineering consultancy. WUE helps engineering leaders identify and fix the real constraints holding back delivery speed, reliability, and confidence.

The positioning in one line:

"Between big consulting firms that lack personalisation and small firms that lack depth."

The client-facing one-liner:

"It's not just about identifying the problems — it's about showing you how to get out of the hole."

The core insight: Most delivery problems aren't what they look like. Engineering leaders try to fix the wrong things first — not because the ideas are wrong, but because they're applied before the foundations are ready. WUE calls this the sequencing problem.

The answer: Diagnose the real constraint before doing anything else. Then fix it in the right order.

The Core Framework

The Hierarchy of Engineering Needs (HoEN) is WUE's proprietary diagnostic and improvement framework. Reference it this way:

  • Built from real experience, not academic theory
  • Open-sourced under Creative Commons — builds trust before the first commercial conversation
  • Used to identify the specific constraint limiting a specific system, right now — not a generic maturity model
  • The entry point for every WUE engagement

The journey every engagement follows: DIAGNOSE → FOCUS → UPLIFT → MEASURE → SUSTAIN

Who WUE Serves

Three buyer profiles. Match tone and emphasis to whichever is in scope.

The Enterprise Technical Leader Senior leader (Head of Enablement, Head of Data, similar) in a non-tech organisation with a software dependency. Not the CTO. Accountable for delivery within a business unit. Trigger: something acute has broken and no specialist vendor fits the problem.

  • Lead with: triage, clarity, calm, objective outside view
  • Emotional state: overwhelmed. Needs calm, not more options.

The VP or CTO with Board Exposure Owns the full technical strategy. Board is pushing for formal accountability on engineering performance. Trigger: needs an external framework and independent credibility to focus the organisation.

  • Lead with: board-level frameworks, formal diagnostic, structured evidence, independence
  • Emotional state: under pressure from above and below simultaneously.

The Scaling Product Leader SVP Product or equivalent. Engineering leadership gap during rapid growth. Trigger: engineering system not built for the scale the business is moving to.

  • Lead with: business outcomes, delivery confidence, operating at the intersection of product and engineering
  • Emotional state: exposed. Needs someone who operates across product, tech, and business.

Tone & Voice

Experienced practitioner, not theorist. Write as someone who has been in the room — not someone who has read about it. WUE's team has worked inside engineering organisations at every scale. That experience is the credential.

Direct, not prescriptive. Confident without being arrogant. WUE is "unassuming" — the goal is to help organisations improve, not to demonstrate that WUE is right.

Practical over theoretical. Move quickly from what the problem is to what to do about it. No extended frameworks or methodology explanations unless specifically requested.

Outcome-obsessed. Every piece of content should make it clear WUE is invested in results, not just deliverables. High ownership. Not traditional consultant detachment.

Name the human outcome alongside the operational one. Technical outcomes (faster delivery, reduced firefighting) matter — but so do emotional and organisational ones. Include at least one of: calm, clarity, confidence, feeling heard.

What to Lead With (by content type)

Website copy: Lead with the customer's problem, not WUE's service. Name the pain before naming the solution. Diagnostic before delivery.

Sales emails / outreach: Name the trigger or pain pattern first. Offer the diagnostic (HoEN Workshop, TQA, or fractional conversation) as the obvious low-risk next step.

Case studies / proof points: Lead with what leadership thought the problem was. Then reveal what the diagnostic found. The gap between hypothesis and reality is WUE's strongest proof point.

LinkedIn / content: Take a point of view on engineering delivery, AI in engineering, or leadership. WUE is positioned to own the AI-in-engineering- systems conversation — the angle is "AI doesn't change the fundamentals; it amplifies existing constraints."

Proposals: Open with the client's situation and what's at stake. Introduce the diagnostic as the entry point. Position the full engagement as the natural consequence of what the diagnostic finds.

Website FAQs / newcomer surfaces: Treat FAQs as a primary place to land key talking points. Cover: what WUE does (diagnose then uplift in the right order), what a software delivery system is, HoEN as decision/assessment framework not ceremony theatre, workshop as facilitated diagnostic, and when outside help beats DIY. Prefer support over stacking "help"; prefer clear when "calm" would soften a CTA too much (calm remains a valid human outcome elsewhere).

Featured article / "start here" selection

When choosing a lead article for homepage feature, Articles hub, or newcomer "start here":

Prefer Avoid as the lead
Pain first, then HoEN as diagnostic Product announcements (model version, open-source release)
Sequencing / real constraint / hidden trade-offs Podcast or interview landing pages
Foundations before advanced work Headlines that centre "transformation" (Agile/DevOps/digital)
Human outcomes (burnout, trust, clarity, confidence) Tool, AI, or modernisation pieces as the primary pitch

Canonical exemplars (as of Jul 2026):

  • Lead: Software Delivery Trade-offs — everything-is-a-priority pain → HoEN surfaces hidden trade-offs
  • Sequencing: The Engineering Hierarchy of Needs: Balancing Urgency with Importance — lower needs trump higher work

Buyer profiles on the site

Do not invent a fourth persona. Map "who we work with" copy to the three profiles above:

  1. Enterprise Technical Leader — delivery stuck in a non-tech organisation with a software dependency
  2. VP or CTO with Board Exposure — board pressure for clearer performance accountability
  3. Scaling Product Leader — product organisation scaling faster than the engineering system was built for

Worked examples (website FAQ patterns)

Use these as tone and structure references — not as mandatory verbatim copy.

What WUE does: identify and fix the real constraints holding back delivery speed, reliability, and confidence — HoEN to diagnose first, then support advisory or hands-on uplift in the right order.

Software delivery system: the team operates within a socio-technical system (people, process, technology, measurement, culture, infrastructure). The same people constrained by the system are the ones who must change it — help them see clearly and sequence improvement so decisions land on the actual constraint.

vs Agile / DevOps consulting: not selling ceremonies, frameworks, or a packaged transformation programme. Most delivery problems are sequencing problems — good ideas applied before the foundations are ready. Vendor-agnostic: no cloud partnerships, no tool bias.

HoEN workshop: a facilitated diagnostic, not a brainstorm. Prioritised opportunities afterwards — typically the highest-leverage moves for the next planning cycle, with a clear view on what to leave alone for now.

Hands-on vs advisory: both, matched to what the diagnostic finds. Uplift over substitution — build organisational muscle; do not replace it.

DIY: teams can start the diagnostic with HoEN themselves. Outside help is focus, independence, and keeping improvement moving when the urgent crowds out the important.

Evidence and confidence

Cite the claim, or soften the claim. Every assertion a client reads is either backed by something they can go and check, or its language drops to match what is actually known. Never a firm claim with nothing behind it.

This is not a style preference. WUE's primary differentiator is being diagnostic-led — the independent outside view that finds what leadership could not see. An unevidenced assertion delivered confidently is indistinguishable from the opinion they could have had internally for free.

Match the register to the backing:

Backing Write it as
A measurement, or a document you can name Direct. "Lead time is 19 hours, of which 14 is review wait."
Several independent, consistent observations Attributed. "Three of the four teams described the same review queue unprompted."
One observation, or an inference Hedged and owned. "On the evidence we have, this reads as a review bottleneck rather than a build one."
A pattern from prior engagements Marked as pattern. "We usually find X at this stage. We have not confirmed it here."
Nothing yet Not a finding. Say what would settle it.

Two habits that go with it:

  • State the assumptions beside the claim, not in a caveats appendix. Rescaled readings, ambiguous units, estimated values, uncovered scope, whose account it rests on, and how old it is. Where two sources disagree, say they disagree — reconciling them silently throws away a finding.
  • Leave room to be wrong. Date the reading. Name what would change your mind before anyone asks. When new evidence arrives, change the position and say you have — being seen to update on evidence is the diagnostic working. Defending a superseded finding is the one thing that makes an independent assessment worthless.

Confidence where it is earned is exactly the calm authority this voice asks for. The discipline is that confidence tracks evidence in both directions.

Full ladder, guardrails and the HoEN-narrative application: evidence-and-confidence.md.

Language Guardrails

USE

  • "Identify the real constraint"
  • "The right things, in the right order"
  • "Structural impediments"
  • "Diagnostic clarity"
  • "Systematic improvement"
  • "Independent / vendor-agnostic"
  • "Organisational muscle"
  • "Uplift over substitution"
  • "What leadership couldn't see"
  • "Get out of the hole"
  • "Diagnose before you improve"
  • "Sequencing problem"
  • "The HoEN"
  • "Support" (prefer over stacking "help" on hero/CTA surfaces)
  • "Clear" (prefer on CTAs when "calm" would stack or soften too far)
  • "We observed" / "Three teams described" — attribute the evidence, not just the conclusion
  • "On the evidence we have" / "Our reading is"
  • "We have not confirmed this yet" / "This would be settled by…"
  • "This was our earlier reading; the new data changes it to…"

AVOID

  • "Agile transformation" — jaded, overused, now carries negative connotations
  • "Digital transformation" — too broad, too corporate
  • "DevOps transformation" as a lead headline — even when the body is anti-programme; reframe around patterns, constraints, or sequencing
  • "Best practice" — generic, means nothing
  • "Strategic partner" — consultant cliché
  • "We work with organisations to..." — passive, weak opener
  • "Unlock potential" — vague
  • "Holistic approach" — meaningless
  • Stacking "help" / "help" / "help" in adjacent hero lines
  • Generic SDO (Software Delivery and Operational Performance Metrics) claims without specific context — including the colloquial "DORA" / "elite performer" framing with no local reading
  • Theory-heavy language without practical grounding
  • "Playbook" used without qualification — implies a rigid methodology WUE doesn't follow
  • "Clearly" / "obviously" / "it is well known that" — each does the work evidence should be doing
  • "Best practice says…" — an appeal to authority with no author
  • Bare industry benchmarks as proof of a local claim ("elite performers deploy daily")
  • Percentages with no denominator, or any figure whose source you could not name if asked
  • Passive attribution — "it has been suggested that" — which hides who said it

NEVER sound like

  • A large consultancy selling a pre-packaged methodology
  • An Agile training firm promoting ceremonies for their own sake
  • A technology vendor with implementation partnerships to protect
  • A data/analytics firm — WUE's focus is software delivery systems, which is distinct

Two Audience Registers

Board and executive conversations Lead with business outcomes, delivery confidence, independent credibility. Avoid methodology depth, jargon, and technical detail. The message: "We give your organisation the clarity and focus it's been missing."

Engineering leader conversations Lead with diagnostic specificity, the HoEN, root cause vs. symptom, what the workshop consistently surfaces. Avoid business-case framing and management-speak. The message: "We find what you've been missing — and show you how to fix it in the right order."

Things WUE Is Not

Clarify these when a draft drifts toward them:

  • Not a large consultancy. No global delivery network, no cloud partnerships, no standardised playbooks.
  • Not competing on price or headcount. Boutique and specialist, not a body shop.
  • Not an Agile training firm. Not selling ceremonies or frameworks for their own sake.
  • Not a technology vendor. No product bias, no implementation partnerships.
  • Not a data/analytics consultancy. Distinct from data engineering, BI, or analytics work.

The Differentiators (in priority order for content)

  1. Diagnostic-led — finds what leadership doesn't know. This is the primary differentiator. Use it first.
  2. The HoEN — proprietary, experience-built, open-sourced. The framework that travels ahead of the commercial relationship.
  3. Independent — no vendor relationships, no cloud partnerships. Advice WUE would take themselves.
  4. Outcome-obsessed — high ownership, not traditional consultant detachment.
  5. Third-party authority — WUE says what teams already know, in a way organisations can hear. Explicit about independence.
  6. Operates across technical and organisational layers — the constraint is rarely purely technical. WUE works at every level of the system.

Brand Voice (Design System v2.0)

Character: Plainspoken, principled, quietly opinionated. A senior engineer explaining a model — not a marketer selling a product.

Sentence style: Short sentences. Verbs do the work. No padding.

Structure pattern: Open with a question, then answer it. Big claims made calmly and immediately backed with structure or evidence.

Diagnostic, not prescriptive. WUE explains what's happening and what to do. It doesn't lecture or moralise.

Sample copy pattern (from design system):

"Where is your delivery actually constrained? Most teams optimise everywhere at once. We don't. We evaluate the system against the Hierarchy of Engineering Needs, find the one constraint holding back flow, and sequence the work to lift it. Diagnose, decide, do."

Pronouns

  • Marketing copy: "you / your team" — address the reader directly
  • WUE as an organisation: "we" — but sparingly
  • Never mix within a single piece

Spelling

British/Commonwealth throughout: organise, prioritise, behaviour, utilised, recognised. Never US spellings.

Tone rules

  • No emoji-driven hype. Emoji sparingly if at all.
  • No exclamation marks for emphasis.
  • Calm authority. Makes a board relax, not a startup pitch.

Design system lexicon

Lean on: needs, capabilities, signals, maturity, constraint, sequence, flow, sustainability, generative culture, socio-technical system

Avoid (design system additions — combine with the avoid list above): unlock, seamless, delight, journey, empower, leverage, robust, holistic, best-in-class

For colour tokens, typography, logo rules, and visual registers when briefing designers, read brand-identity.md.


References

  • Brand identity reference — colour tokens, typography, motif, logo rules for visual briefs
  • Evidence and confidence — the citation ladder, stating assumptions, revising a finding on new evidence
  • Applied in assessment findings: hoen-data-assist
  • Source skill: wue-website (commit 66739bbe) — website messaging session Jul 2026

Troubleshooting

Symptom Likely cause Fix
Draft leads with WUE services or methodology Skipped pain-first rule Rewrite opener around the customer's constraint; introduce HoEN second
Sounds like Agile / digital transformation consulting Hit avoid-list language Replace transformation framing with sequencing, constraints, or foundations
Stacked "help" / soft CTAs Hero copy drifted to filler Prefer "support" and "clear"; keep calm for human outcomes, not CTA softener
Invented fourth buyer persona Expanded beyond the three profiles Map back to Enterprise Technical Leader, VP/CTO with Board Exposure, or Scaling Product Leader
Visual brief missing tokens / fonts Brand identity not loaded Read brand-identity.md
US spellings or hype tone Wrong register Switch to Commonwealth spelling; short sentences; no exclamation emphasis
Confident claim with nothing behind it Skipped the evidence ladder Cite it, or drop to the register the backing supports — see evidence-and-confidence.md
"Clearly" / "best practice" / a bare benchmark carrying the argument Assertion standing in for evidence Name the measurement or the source; if there is none, say what would settle it
Reads well-evidenced but rests on one weak figure Vivid symptoms stacked in front of thin data Hedge the claim to match the weakest link, and state the assumption beside it
A finding changed between two documents with no note Silent revision Say the position changed and why; updating on evidence is the diagnostic working
Prior-engagement pattern reads as a finding here Experience presented as evidence Mark it as a pattern and state it is unconfirmed in this engagement