IICTPIICTP

About the profession

What is a technical practitioner?

The people who design, build, run and lead technology work, and answer for the technical decisions in it. Here is what that means, how it differs from related roles, and how IICTP recognises it.

Is this you? See the exams
Hands-ontechnical depthDelivery andrisk judgementPeople and teamleadershipTechnicalpractitioner

Where the three circles meet

The short answer

The short answer

A technical practitioner builds, runs or leads technology work and is answerable for the technical decisions in it. They choose designs, weigh risks and trade-offs, set quality bars, and take responsibility when a system fails.

01

Technical depth

They can do the work, or read it well enough to judge it.

02

Delivery and risk judgement

They know how systems reach production safely, and what can go wrong on the way.

03

People and team leadership

They shape how a team works, even without a manager title.

Someone strong in one circle alone is a specialist. The practitioner is where all three meet.

Compared with

How it differs from related roles.

Titles vary by company. These are typical emphases, not rules, and real jobs often blend them.

The subject of this page

Technical practitioner

“What is the best technical decision here, and who does it affect?”

Typical output
Designs, risk calls, quality bars, systems that run

Software engineer

“How do I build this correctly?”

Typical output
Working, tested code
Relation
Becomes a practitioner when they also own design and delivery decisions.

Project manager

“Will the work finish within its scope, time and budget?”

Typical output
Plans, schedules, status, stakeholder alignment
Relation
Understands the technical plan; need not make the design decisions.

Architect

“How should the system be structured?”

Typical output
Architecture, standards, decision records
Relation
At lead level, practitioners do architecture as part of delivery.

Engineering manager

“How do I help this team deliver and grow?”

Typical output
Team health, hiring, delivery
Relation
The practitioner track covers the technical judgement a manager needs.

In practice

What a technical practitioner actually decides.

The work shows up as judgement calls. Here are six, with the thinking behind a good answer.

Technical risk

A dependency owned by another team keeps failing, and a release is due on Friday.

Good thinking

Treat it as a shared risk with an owner and a deadline, and gate the release on a stated error budget. Retries alone hide the signal; freezing everything is out of proportion.

Architecture

Should we split the monolith into services?

Good thinking

Decide from the boundaries of the teams and of change, not from fashion. Information hiding (Parnas) and the link between team structure and system structure (Conway) are the guides.

Applied AI

A team wants to use AI code generation across the whole codebase.

Good thinking

Decide where it helps and which checks must exist before code merges. Faster code can strain testing and review, so the guardrails come first.

Infrastructure and security

A production incident is under way at 2 a.m.

Good thinking

Contain the blast radius, restore service first, then hold a blameless review that fixes the system, not the person.

People leadership

Two teams keep blocking each other.

Good thinking

Look at ownership and team boundaries before blaming individuals. Structure shapes behaviour.

Governance and delivery

Releases take three weeks.

Good thinking

Measure lead time and batch size, shrink the batches, and automate the quality gates so speed and stability rise together.

The body of knowledge

Five areas every exam draws on.

IICTP’s TPBOK™ organises the profession into five domains. Each IICTP exam tests them, in different proportions.

Domain 1Architecture & Systems DesignHow systems are divided, how parts talk to each other, and how they keep working as they grow.
Domain 2Engineering Governance & Agile DeliveryHow work flows from idea to production: small batches, quality gates, and honest measurement.
Domain 3Applied AI & Emerging Tech IntegrationUsing new technology, including AI, where it helps, and verifying what it produces.
Domain 4Infrastructure & SecurityRunning systems safely: least privilege, observability, recovery, and limiting the damage when things fail.
Domain 5People Leadership in EngineeringTeam structure, blameless learning, mentoring, and keeping the cognitive load on a team manageable.
Read the TPBOK guide

Ways of working

Habits that mark a practitioner.

Tools change every few years. These habits have held across decades of engineering practice and appear in many different frameworks.

  1. 01

    Close the feedback loop

    Plan, act, check, adjust. Work is inspected against a baseline, and the result changes the next step (Deming’s Plan-Do-Check-Act).

  2. 02

    Keep batches small

    Small changes are easier to understand, test and undo. The DORA research programme links small batches with better delivery outcomes.

  3. 03

    Separate what from how

    Someone decides what value is wanted; the people doing the work decide how to build it. Mixing the two is a common source of failure.

  4. 04

    Define “done” so it can be checked

    A quality bar a reviewer can verify, not a feeling.

  5. 05

    Surface risk early

    Royce warned in 1970 that a single sequential pass is risky and recommended building a pilot first. Find the hard part before it finds you.

  6. 06

    Respect human limits

    Adding people to a late project can make it later (Brooks). Systems tend to mirror the communication structure of the organisation that builds them (Conway).

  7. 07

    Be open about failure

    Blameless reviews and psychological safety are how an organisation learns from incidents instead of hiding them.

Where IICTP fits

A credential for each stage of the work.

They are peers, not rungs you must climb in order. Pick the one that matches the work you do now.

Early career, 0–2 yearsATP®Associate Technical PractitionerLeading a team, 3–7 yearsCTP®Certified Technical PractitionerLeading programs across teams, 7–12 yearsPgTP®Program Technical PractitionerResponsible for a portfolio, 12+ yearsPfTP®Portfolio Technical Practitioner
Or go deep in one area:AIP® · AI PractitionerCAP® · Cloud Architecture PractitionerADP® · Agile Delivery PractitionerIESP® · IoT & Embedded SystemsLLMP® · Local LLM PractitionerCSTP® · Clean Software Telemetry
Compare requirements and pass marks

Self-check

Is this you?

Tick what is true. It is a rough guide to how your work compares, not an eligibility check.

0/7TICKED

The more you tick, the more your work looks like a technical practitioner’s.

Check your eligibility

FAQ

Questions, answered.

Short answers on the term, the credentials and what they do and do not promise.

Is “technical practitioner” an official job title?

No. It is the term IICTP uses for a role that many companies call something else: software engineer, tech lead, engineering manager, architect, site reliability engineer, technical program manager. It is not a legally protected title, and holding an IICTP credential does not change anyone’s job title.

Do I have to manage people?

No. Tech leads and senior engineers who own technical decisions fit as well as managers do. The ATP credential assumes no leadership experience at all.

How is this different from a project management certification?

A project management credential generally centres on managing the work: plans, schedules, scope and stakeholders. IICTP’s exams centre on technical judgement: design, risk, delivery and operations. They answer different questions, and some people hold both.

Do I need a degree?

For the ATP you need a secondary degree or equivalent and 23 contact hours of technical education. For the CTP you need a bachelor’s degree and 36 months of technical leadership, or 60 months without a degree. See the exam facts page for every credential.

Is this the same as being a software engineer?

They overlap. An engineer builds the thing. A practitioner is also accountable for the decisions around it: what to build, how to release it safely, and what to do when it breaks.

Will a credential get me a job or a raise?

No credential can promise that, and IICTP does not. What it offers is a checkable record, in a public registry, that you passed a defined exam.

Is IICTP accredited?

No. IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Sources and further reading (11)
  1. Beyer, B., Jones, C., Petoff, J. and Murphy, N. R. (eds.) (2016). Site Reliability Engineering. O’Reilly Media.
  2. Brooks, F. P. (1975). The Mythical Man-Month. Addison-Wesley.
  3. Brooks, F. P. (1987). “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer 20(4).
  4. Conway, M. E. (1968). “How Do Committees Invent?” Datamation 14(4).
  5. Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study.
  6. Evans, E. (2003). Domain-Driven Design. Addison-Wesley.
  7. Forsgren, N., Humble, J. and Kim, G. (2018). Accelerate. IT Revolution Press.
  8. Parnas, D. L. (1972). “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15(12).
  9. Royce, W. W. (1970). “Managing the Development of Large Software Systems.” Proceedings of IEEE WESCON.
  10. Saltzer, J. H. and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE 63(9).
  11. Skelton, M. and Pais, M. (2019). Team Topologies. IT Revolution Press.

This page describes how IICTP uses the term “technical practitioner”. IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Next step

See which credential fits the work you do.

Explore the credentials Read the blog