Advisory

Independent technical judgement for consequential technology decisions.

I provide independent technical analysis for infrastructure and security decisions that have not yet been made, at the level where they are taken: the evidence, the assumptions and the trade-offs, written down before the decision.

The technology is the domain expertise. What you are buying is decision quality.

Domain
  • Enterprise networking
  • Cybersecurity
  • Application delivery
  • Identity
  • Infrastructure
When
Before you commit to the architecture, the supplier, the platform, the migration or the budget.
What you receive
A written decision analysis that states the assumptions, the trade-offs, the risks, the operational consequences and the questions that still need answers.

The problem this exists for

  1. The pace

    Organisations are being asked to make decisions about technology that their own business models did not prepare them to make, at a pace that does not allow the expertise to be hired and grown in-house first.

  2. The material in the room

    The result is familiar: the decision gets made from the material supplied by the people selling into it, because that is the only material in the room. Much of what reaches the table comes from parties with a commercial interest in the outcome, and every reference is chosen; some of it comes from internal teams, open-source communities and engineers with no transaction attached, and the first job is knowing which is which.

  3. The referee

    Commercial interest does not invalidate expertise. It does change the context in which a recommendation should be evaluated, and the internal team, who may be excellent, is being asked to referee a game where they only see one side's playbook.

That is the gap this practice exists to close, and nothing more.

What it does

Put an independent, experienced technical reading in front of the people who have to sign, in time for it to change the decision rather than explain it afterwards.

What it does not

  • Replace the team
  • Run the project
  • Become another supplier with a diagram

Your advisor

Rodolfo Nützmann

Thirty years on the supply side of enterprise networking and security, from inside vendors, value-added resellers and distributors, consulting practices, and direct engagements with the customer: implementing, supporting, deploying and teaching what those companies sell, rather than selling it. That is the whole basis of the advice: my job was to make the thing work afterwards, so I have always had to live with the answer. The analysis is mine and it carries my name; how an engagement is contracted is stated plainly further down this page. The credentials, the career record and what past clients and students say are a click away, because a claim you cannot check is not worth making.

When this tends to be useful

The people who get the most out of an engagement usually arrive in one of five situations.

  • Infrastructure, security and technology leadershipA CIO, CISO or head of infrastructure with a technically consequential decision, and either too little independent expertise in-house to test it or the wish for a second opinion before signing.
  • Steering committees and executive sponsorsA group that has to turn technical assumptions into defensible business trade-offs, and needs them stated by someone who can be questioned in the room.
  • Procurement teamsRequirements worth asking for, proposals interpreted on their merits, and scoring that suppliers cannot steer.
  • Organisations in an architecture transitionData-centre modernisation, SASE and SSE, vendor consolidation, a network redesign, application-security architecture, WAN transformation, a firewall refresh, hybrid and cloud connectivity, a major platform migration.
  • Organisations after a serious incidentNot the response, which has its own people: the independent reconstruction afterwards, and what the organisation should learn from it.

One advisory model, applied to several kinds of consequential decision

These are shapes, not packages. The question, the inputs, the deliverable, the dates and the fee are agreed in writing before the work starts, and an engagement that sits between two shapes is usual rather than a problem.

  • Decision review

    The questionShould we approve this architecture, or this proposal?What you getA decision memorandum.

    An independent second reading of a supplier's quotation and diagram, in writing: what is actually being proposed, what it leaves out, what it assumes about the environment it will land in, and which questions to put back before anything is signed.

  • Comparative assessment

    The questionWhich of these approaches, or vendors, fits us?What you getAn options and trade-off analysis.

    Stay or move, consolidate or keep two, on-premises or as a service. A defined question, the trade-offs stated in the terms of the organisation rather than the vendor's, and a defensible answer with the reasoning attached, so the decision survives the person who made it.

  • Architecture challenge

    The questionWhat are we overlooking before implementation?What you getArchitecture findings and a risk register.

    Reading a proposed design before it is built and paid for: what it assumes, where it will strain, what it will cost to operate rather than to buy, and which of its assumptions are load-bearing. The failures that matter are rarely in the product; they are in what the design took for granted.

  • Procurement and RFP advisory

    The questionWhat should we actually ask suppliers to deliver?What you getRequirements and a scoring framework.

    Writing what to ask for. A specification or request for proposal that describes the outcome precisely enough to be scored fairly, and closes the gaps a supplier would otherwise be free to interpret in their own favour. Most bad procurement is decided at this stage rather than at the bid.

  • Estate review

    The questionWhat do we actually have, and what depends on it?What you getA map of the estate, with the parts nobody can explain marked.

    An inventory that becomes a map: what is connected, what each thing actually does, what depends on it, and which parts nobody can currently explain. Named a review rather than an audit, because audit carries assurance meaning this does not claim. Most estates contain something load-bearing that no one has looked at in years.

  • Post-incident review

    The questionWhat failed, and what should materially change?What you getAn independent engineering review.

    Not incident response: the review afterwards, when the fire is out and somebody has to give an honest account of what happened and what would prevent it recurring. Written to be read by people who were not there, and without the search for someone to blame that makes most such documents useless. The scope is an engineering learning review. It is not a forensic investigation and not a legal or regulatory analysis: where litigation, insurers, regulators or evidence preservation are in play, those need their own specialists, and the written scope says which kind of review this is before it starts.

  • Ongoing executive technical counsel

    The questionWe face decisions like these repeatedly.What you getRecurring decision support, written each time.

    For the organisation where consequential infrastructure and security decisions reach the executive table several times a year. Described below, under the retained arrangement.

Before the decision reaches the table

Executive briefings

The questionWhat does this shift mean for us, and what will it ask of us?What you getA closed-door briefing for the leadership team, and a short written brief to keep.

For a board, an executive committee or a steering group that needs a technology shift set out in the organisation's own terms before it arrives as a decision: what it is, what it changes here, which decisions it will bring, and the questions worth putting to suppliers. A move to SASE, a vendor consolidation, a data-centre modernisation, a major platform migration. Prepared for one organisation, with the same independence as every engagement on this page.

Not a talk: a talk is written for an audience, a briefing for one organisation and its decisions. Talks for conferences, company events and team gatherings have their own page: Speaking

What you receive

A written answer, made to be circulated and defended internally rather than presented and forgotten, and a call to walk through it. The document follows a fixed structure, so that a reader who was not in the room can follow the reasoning and challenge it.

  1. The executive question
  2. Current state
  3. Assumptions
  4. Evidence reviewed
  5. Constraints
  6. Options
  7. Trade-offs
  8. Risks
  9. Dependencies
  10. Cost and operational considerations
  11. Unknowns
  12. Recommendation, or the conditions for proceeding
  13. Immediate actions
  14. Questions for the supplier

Read a complete example memorandum

The example is fictional, assembled to show the structure and the level of detail. No client document is ever published.

Three ways to engage

The first is the flagship, and it is what most engagements are. The other two exist for questions that do not fit inside one decision.

  1. Independent decision review

    One decision. Defined inputs, a written memorandum, a walkthrough, a fixed fee. The easiest engagement to buy, and the one the rest of this page describes.

  2. Executive technical advisory

    Larger questions that span several decisions: an architecture, a technology roadmap, the vendor landscape, a transition strategy, the risks and the operational consequences. Still scoped, still written, still non-operational.

  3. Retained technical counsel

    For a small number of organisations, access over three, six or twelve months: recurring decision sessions, challenge of architectures and vendor proposals, participation in steering meetings when a decision reaches them, review of important proposals, interpretation of technology risk, and a written brief each time. Access means recurring decision support over the agreed term, with the cadence, the availability and the scope written into the proposal; it is not an open line for whatever comes up. When consequential infrastructure and security decisions reach the executive table, another person on your side of it. What it is not: line management, helpdesk escalation, project management, operational ownership, availability around the clock, or implementation labour.

How the money behaves, since the figures themselves come only after scoping: a decision review and an executive technical advisory engagement are scoped first and quoted as one fee for that scope, never as an open hourly meter; retained technical counsel is quoted for an agreed term, cadence and scope. In every case the proposal and the invoice come from Red Education.

What independent means here, exactly

Independence is a property of the analysis, and it is worth stating precisely rather than broadly.

  • Claimed

    Independence of the analysis

    The analysis is written by me and carries my name. I hold current instructor authorizations across four vendors' platforms, and I do not personally sell or resell the technologies being evaluated. There is no version of this engagement that pays me more if you buy one thing rather than another, and if the honest answer is that your incumbent is right, that is the answer. You can verify each authorization independently, which is the point of naming them.

    Attached to the technology the analysis favours:

    • no sales quota
    • no resale margin
    • no referral commission
    • no implementation award
  • Not claimed

    Commercial independence from every company in the ecosystem

    Engagements are contracted and invoiced through Red Education, which sells authorized training and professional services across several vendors' platforms. Where either is a candidate for what follows a decision, the document says so in plain words, and the choice of who does that work stays yours.

  • In practice

    Context, on both sides of the table

    Commercial interest does not invalidate expertise. It does change the context in which a recommendation should be evaluated, and knowing exactly what that context is, on both sides of the table, is part of what you are paying for. It also means the review is not a weapon against suppliers: a supplier confident in its proposal can suggest the review itself, because a proposal that holds up under independent scrutiny is easier for its customer to approve, and one that does not is cheaper to fix before deployment than after.

Where this comes from, in the client's words

I spent the first twenty-four years of my career, from 1996 to 2020, doing this work for leading organisations across many segments: financial institutions, government agencies, service providers of every sort, large multinational conglomerates in commerce and services, and industry across a wide range. Delivered, been responsible for, overseen, collaborated on, led and taken part in, many times over, from inside vendors, distributors and integrators. These engagements are no longer what I sell. They are what the advice above is made of.

Most of what people say about me publicly concerns teaching, because that is what I have done most visibly since 2020. Below is the older, advisory-shaped part of the record: what clients and partners wrote about design, selection and procurement work, verbatim, each with the engagement it describes stated in one line. The full set, filtered by kind, is on the endorsements page.

  • Procurement and vendor selection for a financial-sector client, 2008: consulting, technology definition, the RFP and oversight of the commercial negotiation, then the point of contact through implementation and after it.

  • Design, conception and analysis of a high-availability IP telephony and recording solution for one of Brazil's largest brokerages, 2008, led across several suppliers.

  • A data-link capacity analysis, 2012, whose depth and presented results the partner credits for the project's outcome.

  • How the designs were made, in a security specialist's words, 2020: by applying the concept, not by trial and error.

All endorsements, filtered by kind

Inspect the reasoning before you hire it

This site shows how I approach technical questions: the evidence I use, the assumptions I make, and how I reach a conclusion. Tools that compute instead of guessing, each with its test vectors and its sources attached; several hundred technical articles that cite the documentation they rest on; a corpus on the discipline of running networks and support; and a history of the industry written from inside it. Read any of it before the first conversation. It is the same reasoning that goes into a decision memorandum.

What I do not personally provide

I do not use these engagements as staff augmentation, project implementation, managed operations, round-the-clock escalation or incident-response engineering. The separation is deliberate: the value of the engagement is independent technical judgement before a consequential decision is made, and that value falls the moment the adviser stands to do the work the advice creates.

Not offered here

  • Implementation and configurationI will review what is planned and audit what was built, but I am not the pair of hands that builds it.
  • On-call, standby, and operational dutyI do not sell hours, and I am not a name on a rota or an escalation path. Attendance during a maintenance window is not offered, on site or remotely.
  • Staff augmentationIf what is needed is another person on the team, that is a hiring decision rather than an advisory one.
  • Training and enablement, in any formI do not sell training as advisory work. I deliver official instructor-led courses under vendor authorization, and that is a separate engagement with its own scheduling and its own terms; ask and I will point you to it. What I offer here is judgement on a decision, not a curriculum.
  • Course material developmentI do not offer this. Slides, lab guides, speaker notes and assessment are a separate craft, commissioned on its own scope and its own terms, and it is not advisory time. Telling you whether a course should exist is work I will do. Writing the course is not.
Red Education, wordmark in use since 2025

When the decision leads to implementation

My role in these engagements is advisory: I review, challenge, analyse and document the decision, and I do not personally provide the implementation, managed service or operational support that may follow. That does not mean the engagement ends without a practical path forward. Red Education maintains a Professional Services capability, delivered by its vendor-certified engineers: installations, software and hardware upgrades and migrations, health checks, knowledge transfer, resident on-site engineers and consultants on demand. I work for Red Education full time, and where the work that follows a decision is work Red Education does, that is where I will propose it be done: I know the people who do it, and I believe in the company's commitment to quality and to the customer's satisfaction. The choice remains yours, your existing partner, your internal team or another provider included. What does not move is the analysis: where Red Education's professional services are being considered for the downstream work, the engagement says so explicitly, and the document stays on the technical merits, constraints, risks and requirements of the decision rather than on creating implementation work for anyone, Red Education included.

Red Education Professional Services

What I will not do

I will not tell you what to do before I understand your situation, and the first conversation exists to establish whether I can be useful at all, including the answer that I cannot, or that the question is better put to someone else. An advisor who is certain before they have listened is selling something. If the honest answer is that your existing supplier is right, that is the answer you will get in writing, and it will be the most valuable sentence in the document.

How an engagement runs

  1. A conversation about the decision you are facing, at no charge, to establish whether I am the right person for it.
  2. A written scope: the question, the deliverable, the dates and the fee. Fixed price per engagement rather than by the hour. For a post-incident review, the scope also says which kind of review it is.
  3. The work, with access to whoever holds the technical detail.
  4. A written answer you can circulate internally, and a call to walk through it. At close-out I ask whether an account of the engagement may be published later, named, anonymised, or reduced to the shape of the decision; a no is a complete answer, and nothing is published without a yes in writing.
Red Education, wordmark in use since 2025

How this is contracted

I work full time for Red Education. The advisory work described on this page is delivered personally by me and contracted through Red Education, which also issues the proposal and the invoice. The one thing I cannot tell you about is pricing: that comes only after a detailed scoping and expectations call, and is provided exclusively by Red Education. What I can tell you is that inside the engagement I am the main advocate for the best possible outcome for you: since 1996 I have consistently argued for what serves the end customer, not necessarily for what served the company I was working for at the time. If you need training, that goes through Red Education too.

If there is a decision on your desk

Write to me directly. The first conversation is with the person who will do the work, not with an account manager. The useful first message says what the decision is, who has to sign it, and when.

Start a conversation

Looking for a talk rather than advice? Talks have their own page: Speaking