14.8 — The Industry Decoded

Two engineers with the same skills. One is measured on how many hours they billed a client last month. The other is measured on whether the feature they own reduced churn.

They will develop into very different engineers, and neither is a better person. The difference is where the money comes from, and that single fact explains most of what feels arbitrary about how a company behaves.

1. Service companies

A consultancy or systems integrator sells people's time.

The economics, which drive everything else:

Billable hours — hours charged to a client. Utilisation is the fraction of your time that is billable, and a target of 80–90% is common.

The bench — time not assigned to a client. A person on the bench is a direct loss, which is why reassignment is fast and why a project ending without another lined up creates visible pressure.

The rate card — what the client pays per hour, by level. Margin is rate minus cost, so the two levers are charging more and paying less.

Pyramid staffing follows directly: a few senior people and many junior ones, because juniors bill at a lower rate but a rate well above their cost. This is why consultancies hire in large graduate cohorts — the pyramid needs a base.

Location-based rates. Offshore, nearshore and onshore delivery are priced very differently, and cost-of-living adjustments mean the same role is paid on a local scale. A team is often assembled to hit a blended rate rather than picked purely on fit.

Contract types matter to how you will work:

• Time and materials — bill for time. Scope can flex; the client carries the risk.
• Fixed price — one price for a defined scope. The supplier carries the risk, so scope is defended tightly and change requests become a formal process, which is where the reputation for rigidity comes from.
• Managed service — ongoing operation for a fee, usually with service-level commitments.

What it is genuinely good for: exposure to many industries and systems in a few years, learning to work with clients, and seeing a great number of ways things go wrong. It is a fast education.

What it costs: utilisation pressure means training and internal work are squeezed, you often leave before living with the consequences of your decisions, and long-term code quality has a weaker advocate — because the person who will maintain it is frequently not in the room.

2. Product companies

A product company sells software, and the numbers are different:

• Revenue per employee and gross margin — software margins are high, which is why engineering headcount is treated as an investment rather than a cost to minimise.
• Cost of revenue — mostly infrastructure, which is why the cloud bill (Chapter 13.1) is an engineering concern with executive visibility.
• Annual recurring revenue, churn, acquisition cost and lifetime value — the subscription metrics that decide priorities.

The consequence for how you work: you own what you build, you live with its maintenance, and long-term quality has an obvious advocate — you, next quarter. Depth in one domain is rewarded over breadth across many.

Two other shapes worth naming. Internal IT at a non-technology company is a cost centre: success is measured by cost and reliability, budgets are defended annually, and the estate looks like Chapter 13.9. Startups trade cash compensation for equity and offer far more scope than experience would normally allow — and equity is a lottery ticket with a strike price, a vesting schedule and a tax treatment you should understand before valuing it at the number in the offer letter.

3. Support tiers

Most organisations run a tiered model, and knowing where you sit in it explains a lot.

L1 — first contact. Triage, known issues, documented procedures, password resets. Resolves the majority by volume, and escalates what it cannot.

L2 — deeper technical support. Reads logs, reproduces problems, changes configuration, applies known fixes. The largest real technical filter.

L3 — engineering. Code changes, root cause, genuinely new problems. Usually the team that built the system.

L4 — the vendor, when the fault is in third-party software.

What this means for an engineer: L3 rotation is often part of the job, and it is the fastest feedback loop you will ever get on your own design decisions. Being paged for something you built teaches more about operability than any review.

Two things make the model work. Runbooks — a documented procedure per known problem — are what let L1 and L2 resolve without escalating, and writing one is how an engineer stops being paged for the same thing (Chapter 14.6's postmortem action items usually include one). And service level agreements define response and resolution times by severity, which is what "P1" actually means: not "important" but "a defined clock is running".

Follow-the-sun support hands over between regions so nobody is on call overnight. It requires genuinely good handover notes, and it is worth asking about in an interview.

4. The roles nobody explains

Infrastructure-adjacent:

• SRE — reliability as an engineering discipline: error budgets, service objectives, automating operations away (Chapter 10.9). Originating at Google, and the term is often applied loosely.
• DevOps engineer — usually means pipelines and cloud infrastructure, which is a role name for something that was described as a culture, and the ambiguity is worth clarifying in any job description you read.
• Platform engineer — builds the internal platform other engineers deploy onto. The current name for the thing that actually scales an engineering organisation.

Architecture:

• Solutions architect — designs a solution for a specific customer or project, often pre-sales in a vendor or consultancy.
• Enterprise architect — standards and technology strategy across an organisation. Furthest from code.
• Technical architect — deep design within a system or programme.

Customer-facing engineering:

• Sales engineer / solutions engineer — the technical half of a sales conversation: demonstrations, proofs of concept, answering an architect's objections. Well paid, requires genuine technical depth, and is invisible to most engineers as a career option.
• Developer advocate / developer relations — and this one is worth explaining properly, because it is widely misunderstood.

What a developer advocate actually does: writes documentation, tutorials and example applications; speaks at conferences and produces content; supports a developer community; and — the part that matters and is least visible — carries feedback from developers back into the product. A good one is the reason an API's third version is usable.

How people get hired into it: a public portfolio. Talks, writing, open-source work, a following. It is one of the few roles where visible output substitutes for a conventional CV.

Its honest difficulty: success is hard to measure. Content views, sign-ups and community growth are proxies, and none of them is clearly attributable. The role is vulnerable in a downturn for exactly that reason, which is worth knowing before choosing it.

Product and delivery, distinguished:

• Product manager — what to build and why. Owns outcomes.
• Product owner — a Scrum role: backlog and priority. Sometimes a full product manager, sometimes a ticket administrator, and the difference is worth establishing early.
• Project manager — scope, schedule, dependencies, risk.
• Delivery manager — flow and impediments across teams, common in consultancies.

Engineering leadership:

• Tech lead — technical direction for a team, still building.
• Engineering manager — people, hiring, performance, delivery. A different job, not a promotion from engineer, and treating it as one is how good engineers become unhappy managers.
• Staff and principal engineer — the technical track, covered in Chapter 14.9.

Data:

• Data analyst — answers questions with SQL and dashboards.
• Analytics engineer — the modelling layer between raw data and analysts (Chapter 7.8.2's dbt work). A relatively new role and a very useful one.
• Data engineer — pipelines and platforms.
• Data scientist — statistical analysis and modelling.
• ML engineer — models in production (Chapter 12.9).

And three that are consistently undervalued: technical writers (a good one is worth several engineers of documentation effort), security engineers across application security, operations and governance (Chapter 8), and support engineers, who know more about how the product actually fails than anyone in the building.

5. Why domain knowledge is a moat

Technical skills transfer between industries. Domain knowledge does not, which is exactly why it is valuable.

An engineer who understands both distributed systems and how a clinical trial works is rare, hard to replace, and paid accordingly — because the constraint in a regulated industry is almost never the technology.

Life sciences is the clearest example, and worth walking end to end.

6. Life sciences, end to end

The value chain:

Discovery — finding candidate molecules. Heavy computation, laboratory data, increasingly machine learning (Chapter 12).

Preclinical — laboratory and animal safety studies under GLP (good laboratory practice).

Clinical trials — the expensive part, under GCP (good clinical practice):

• Phase I — safety, small number of healthy volunteers.
• Phase II — efficacy and dosing, a few hundred patients.
• Phase III — large comparative trials, thousands of patients, the basis of approval.
• Phase IV — post-approval monitoring in the real population.

Regulatory submission — an enormous structured dossier to the regulator.

Manufacturing — under GMP (good manufacturing practice), with batch records and full traceability.

Pharmacovigilance — collecting and reporting adverse events, forever, with statutory reporting deadlines.

The systems, by stage:

• R&D — ELN (electronic lab notebook) and LIMS (laboratory information management system) for experiments and samples.
• Clinical — EDC (electronic data capture) for trial data, CTMS (clinical trial management) for operations, eTMF (electronic trial master file) for the regulated document set.
• Data standards — CDISC, with SDTM for collected data and ADaM for analysis datasets. Submissions must conform, so this is not an internal preference.
• Regulatory — eCTD submission format and RIM (regulatory information management) for tracking registrations across markets.
• Manufacturing — MES (manufacturing execution) and serialisation for track-and-trace.
• Safety — an adverse-event database with regulated workflows.

The tools you will meet by name:

Documentum — enterprise content management, historically the backbone of regulated document control in pharmaceutical companies, with versioning, approval workflows and audit trails.

Veeva — the sector-specific cloud platform that displaced much of it: Veeva Vault for regulated content across clinical, quality and regulatory, plus a CRM for commercial. Its rise is a good case study in vertical software — a general platform loses to one that encodes the industry's rules.

Windchill — product lifecycle management, used for medical devices: design history, bill of materials, change control.

Privacy and health-data vaults — a category of product, of which TruVault is an example, that isolates identifiable health data behind a controlled service rather than spreading it through application databases. The engineering pattern is Chapter 8.7's classification made physical.

What this actually means for an engineer, which is the part that matters:

Validation. Systems affecting product quality or patient safety must be validated — IQ/OQ/PQ (installation, operational and performance qualification), with documented evidence that the system does what it is specified to do. This is why a change that takes an afternoon takes six weeks, and it is the single largest cultural difference from consumer software. The industry is moving from exhaustive computer system validation toward risk-based computer software assurance, which is a genuine improvement and not yet universal.

21 CFR Part 11 governs electronic records and signatures: audit trails that cannot be altered, signature meaning, record retention. Every regulated system needs an immutable audit trail (Chapter 8.7), and it is a design input rather than an afterthought.

Data integrity — ALCOA+: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available. A useful checklist for any audit-sensitive system, well beyond this industry.

Documentation is a deliverable, not a by-product. Specifications, test evidence and traceability matrices are part of what is shipped.

And it explains the cloud lag. Regulated workloads moved to the cloud years after everyone else, because validation, data residency and supplier qualification all had to be worked out first. The technology was never the blocker.

MedTech adds its own layer: IEC 62304 for medical device software lifecycle, a design history file, and software as a medical device — where the software itself is regulated as a device, with the approval process that implies.

7. Other domains, briefly

Finance — heavy regulation, audit requirements, and at the trading end genuine latency engineering (Chapter 9.7.25). Well paid, change-controlled.

Retail and e-commerce — extreme seasonality, so capacity planning and code freezes around peak periods dominate the calendar.

Telecommunications — enormous scale, long-lived systems, deep standards knowledge.

Public sector — procurement cycles, accessibility as a legal requirement, long timescales, and genuine public impact.

Gaming — different constraints entirely: real-time performance, client-side, and a release model closer to a product launch than a deployment.

The transferable point: every domain has a constraint that is not technical, and knowing it is what makes you effective rather than merely competent. Choose one deliberately rather than accumulating years in whichever one you landed in.

8. Credentials in this context

Chapter 13.10 covers certifications. Two additions specific to the industry structure:

Consultancies value certifications more than product companies do, because partner status depends on them and because a certified team is easier to sell.

Credly badges are verifiable — issuer, date, expiry, public link — which is why vendors use them and why recruiters filter on them. Add them to your professional profile, and pair them with something you built, because a wall of badges with nothing built behind it reads badly to the engineers who will interview you.

Recall

• Service companies sell time: utilisation targets, the bench as a direct loss, a rate card, and pyramid staffing — which is why they hire large graduate cohorts. Fixed price defends scope tightly because the supplier carries the risk. Great exposure; squeezed training and weaker long-term ownership.
• Product companies sell software: high gross margin, so engineers are an investment; infrastructure is cost of revenue, which is why the cloud bill has executive attention. You live with what you build, so depth beats breadth.
• L1 triage → L2 technical → L3 engineering → L4 vendor. Runbooks are how you stop being paged for the same thing, and L3 rotation is the fastest feedback loop on your own design decisions.
• Roles: SRE (reliability engineering), platform (the internal platform that scales an organisation), solutions/enterprise/technical architect, sales engineer (well paid and invisible as an option), and developer advocate — documentation, content, community, and carrying feedback into the product, hired on a public portfolio, and hard to measure.
• Engineering manager is a different job, not a promotion. Undervalued roles: technical writers, security engineers, and support engineers who know how the product actually fails.
• Domain knowledge is a moat because it does not transfer. In life sciences: discovery → preclinical (GLP) → trials I–IV (GCP) → submission → manufacturing (GMP) → pharmacovigilance, with ELN/LIMS, EDC/CTMS/eTMF, CDISC (SDTM, ADaM), eCTD/RIM, MES, and Documentum, Veeva Vault, Windchill and health-data vaults as the tools.
• Validation (IQ/OQ/PQ) is why an afternoon's change takes six weeks; 21 CFR Part 11 requires immutable audit trails; ALCOA+ is a good data-integrity checklist anywhere; documentation is a deliverable — and this, not technology, is why regulated industries reached the cloud late.
• Consultancies value certifications more than product companies. Pair a Credly badge with something you built.

Self-test: What does the bench explain about how a consultancy behaves? · Which support tier writes the runbook, and which one uses it? · What is the least visible and most valuable part of a developer advocate's job? · Which two letters of GxP apply to a clinical trial and to a factory? · What does 21 CFR Part 11 require of every regulated system? · Why did regulated industries adopt the cloud late?

Next: 14.9 covers what changes as a career progresses — what a staff engineer actually does differently, the management fork, and how to stay employable as the tools change underneath you.