IT does not just buy technology: four roles, four types of risk

This comparison condenses the source fields for main pain point, greatest fear, evidence, preferred route and desired outcome. It describes broad role profiles, rather than every person with a particular title.

After the purchase, the IT manager still owns day-to-day operations. A new capability is attractive only if it does not turn a small team into a permanent incident-response unit. The CIO is accountable to senior leadership and sometimes oversight bodies, so architecture, strategic fit and risk must hold up over years.

A CTO is responsible for engineering quality and delivery speed. A platform may look impressive today but create years of technical debt tomorrow. The head of IT is often building a professional function on top of systems that grew without a plan. If you ignore those different accountabilities, you end up explaining features while the buyer is asking about evidence, control or freedom to build.

The source card describes excessive tickets and daily operational tasks in an undersized team. The emotional cost is feeling like a firefighter rather than someone with time to improve the environment. Selling another tool without specifying who will run it may sound like another burden.

The IT manager expects proven technology, clear documentation, responsive support, managed implementation and references from similar organisations. A credible promise starts with stable operation and fewer tasks, not an abstract claim that everything becomes smarter. Ask how many tickets the team handles today and who owns each responsibility after launch.

The CIO faces legacy systems, fragmented applications and pressure to modernise with limited resources. Their greatest fear in the source profile is a major security incident, data breach or failed migration under their responsibility. They need to understand architectural compatibility, governance, risk ownership and the total cost of the decision.

A polished product demo is not enough. The card explicitly calls for an architecture review, security documentation, total cost of ownership, enterprise references and an appropriate procurement process. Rejecting a weakly governed implementation is not resistance to progress. It is a different definition of responsible progress.

The CTO wants higher development speed and quality without buying a platform that constrains future decisions. Technical debt, scaling limits, cloud costs and lock-in are stated objections, not abstract concerns. Strong documentation, open benchmarks and access to engineers can therefore be more persuasive than an executive-only return-on-investment presentation.

The card describes a route through technical communities and trusted peers, followed by a proof of concept the CTO or team can run themselves. Provide APIs, explain trade-offs and agree on a technical stop condition. The strongest demonstration shows not just what your product does, but what their team can independently build with it.

The head of IT often works in a growing organisation where technology choices were made ad hoc before there was formal IT leadership. The central problem is an estate that is no longer sufficiently secure or scalable. Their greatest fear is an incident that could have been prevented with better foundations.

This buyer wants control, security and a realistic path to professionalisation. A reference from a growing company, relevant certifications, practical guidance and a phased roadmap carry more weight than a presentation full of impressive capabilities. The key question is not just whether the platform scales, but whether the current team can safely implement and operate it.

The values come from the IT & Technology audience cards, rows 44-46. BIS and BAS use separate descriptive 0-10 dimensions in these profiles. The k parameter concerns the relative weighting of delayed outcomes and has its own scale. It is not a percentage, probability of purchasing or a BIS/BAS score.

The CIO has the highest BIS of the four profiles at 8 and the lowest k at 0.08. That is consistent with multi-year, strategic risk control. The CTO has the highest BAS at 8 and k at 0.30, with greater emphasis on technical opportunities and nearer-term engineering progress.

That does not mean CIOs dislike innovation or CTOs ignore risk. The CTO card explicitly flags technical debt and lock-in as unacceptable. Nor does k tell you how many weeks a particular person needs to sign a contract. The figures help formulate better first questions; the actual product and decision context determine what to test next.

Suppose you offer a platform that automates operations, exposes APIs and simplifies cloud management. This is an illustrative sales scenario, not a recorded research observation.

The IT manager asks who handles incidents, how much migration work will fall on the team and whether ticket volumes will go down. The CIO asks how the platform fits architecture, security standards, total cost and governance. The CTO asks whether engineers can run a meaningful proof of concept through the APIs without lock-in. The head of IT asks whether this safely replaces ad hoc processes with scalable operations without overwhelming the team.

Four buyers, one platform. If everyone sees the same feature deck, they must do the work of translating the promise into their own responsibilities.

A useful role profile should change what you prepare for the meeting. Start from the existing card, then check which responsibilities, systems, decision rights and buying constraints actually apply.

These are editorial examples derived from the source-card themes. They are not experimentally tested headlines or verbatim participant quotations.

Real technology purchases often involve several of these roles. A CTO can strongly favour a tool while relying on the CIO to validate architecture and risk. The IT manager must still operate the service. A head of IT may have to turn an ambitious roadmap into something a small team can actually deliver.

Avoid inventing four incompatible value propositions. Build one documented case around the problem, intended outcome, implementation and constraints, then provide a different evidence layer for each stakeholder. Make trade-offs explicit, such as faster releases versus additional operational exposure, or engineering flexibility versus governance. That creates room for a defensible collective decision.

The source cards show activity on LinkedIn across these functions, alongside different information sources. The IT manager also consults industry media, Tweakers and vendor newsletters. The CIO follows business technology publications and analyst research. The CTO uses technical communities including GitHub and Hacker News as well as podcasts and other technical channels. The head of IT consults communities, webinars and vendor expertise.

That suggests a concise operational case for the IT manager; a detailed architecture and risk perspective for the CIO; a technical walkthrough with documentation for the CTO; and a phased modernisation example for the head of IT. These are role-based communication recommendations, not measured channel conversion rates.

For further reading, see tone of voice and handling buyer objections, followed by our deeper comparisons of CIO versus CTO and IT manager versus head of IT.

One IT buyer must prevent incidents. Another needs to defend the architecture. A third wants engineers to build at higher speed without long-term debt. A fourth must professionalise a growing estate. Each asks a different question of the same offer.

A strong technology proposition explains more than what a platform can do. It shows which consequence improves for that buyer, which risk remains under control and what evidence can justify moving forward. Start with the decision, not the feature list.