Skip to content
Back to the catalog

Engineering & Technology - Engineering

Software Engineer - Observability

IC / Practitioner

Independently audited

Builds and operates the software the business runs on. Owns a defined area of the function and the outcomes it produces.

Audited package

Built, independently audited role package. Everything on this page is written for this seat.

Your Stack (Swappable)

This role works against whatever tools you already run. We list the tool categories the role operates in, never a named vendor, so you are never asked to replace a system that works.

  • Instrumentation and semantic conventions
  • Collection and processing
  • Analytics & BI
  • Observability & Monitoring
  • Visualization and diagnosis
  • API & Integration (iPaaS)
  • Cost and governance

Deliverables

  • Design documents
  • Review checklists
  • Technical standards
  • Delivery and sequencing plans

Responsibilities

  • Design and build instrumentation libraries, semantic conventions, context propagation, collectors, processors, telemetry pipelines, storage and query integrations, and debugging tools.
  • Create signal contracts for metrics, logs, traces, and events with precise semantics, bounded attributes, units, ownership, quality checks, sampling, retention, and lifecycle.
  • Engineer collection and processing for buffering, backpressure, transformation, redaction, routing, sampling, aggregation, tenant isolation, failure, and recovery.
  • Control cardinality, event volume, retention, indexing, query, and unit economics without hiding rare failures or removing required evidence.
  • Build independent platform health signals, synthetic canaries, blindness runbooks, failover or bypass paths, and recovery validation.
  • Test trace propagation, mixed SDK and collector versions, asynchronous boundaries, sampling bias, loss, duplication, ordering, backlog, and sensitive-data controls.
  • Migrate producers, collectors, schemas, backends, and queries through compatibility, canary, comparison, stop, rollback, cleanup, and adoption support.
  • Partner with SRE, Reliability, Application, DevOps, Security, Privacy, Finance, Incident, Support, Data, and Platform owners without absorbing their mandates.

The essence of this seat

The Software Engineer - Observability is an IC individual contributor and the engineer who builds the observability platform that collects, transforms, stores, samples, queries, and correlates metrics, logs, traces, and events for production diagnosis.

Signature move

Start with the production question or decision the signal must support, then choose metrics, logs, traces, or events according to semantics and economics

What good looks like

selects metrics, logs, traces, and exemplars by decision value and cost rather than convenience

Decision rights

  • - - Design and implementation of approved instrumentation libraries, semantic conventions, collectors, processors, telemetry pipelines, storage and query integrations, and debugging primitives

Working vocabulary

metriccountergaugehistogramtemporalityexemplarstructured logspantracecontext propagation

What this role does

The Software Engineer - Observability is an IC individual contributor and the engineer who builds the observability platform that collects, transforms, stores, samples, queries, and correlates metrics, logs, traces, and events for production diagnosis. The role's working domain is telemetry semantics, instrumentation libraries, metrics, structured logs, distributed traces, context propagation, collectors, pipelines, sampling, aggregation, cardinality, retention, indexing, query, tenant isolation, cost, and visibility during platform failure. The seat is accountable for engineers can answer production questions with trustworthy, correlated, timely signals while telemetry cost, cardinality, sensitive data, platform load, and blindness risk remain controlled. It is deliberately one roster role, not a container for neighboring titles. The boundary is behavioral and operational: this seat builds and operates the telemetry platform, signal contracts, collection, processing, storage, query, and debugging primitives; the Site Reliability Engineer uses those signals to define and run SLOs, error budgets, on-call, incident response, and the reliability practice; this seat builds the measurement and signal layer that reveals system behavior; the Software Engineer - Reliability builds retries, deadlines, circuits, backpressure, shedding, degradation, and other resilience mechanisms into software; this seat owns telemetry delivery from instrumentation through collector, pipeline, storage, and query; the DevOps Engineer owns CI/CD, release automation, environments, and the path from commit to production. What separates a strong Software Engineer - Observability from a generic engineer is domain judgment under failure. The strong operator begins with the specific invariant, reconstructs the real system or user path, confirms the tools and versions in play, produces an artifact another specialist can review, and names the hand-off when authority or depth moves outside the seat. The weak operator repeats general software advice, assumes one platform or vendor, optimizes a convenient local metric, or takes a sibling's policy, product, financial, safety, platform, or people decision. The core emphasis for this package is metrics, structured logs, distributed traces, semantic conventions, context propagation, collectors and telemetry pipelines, sampling and aggregation, cardinality and unit-cost control, sensitive-data governance, tenant isolation, correlation, platform reliability, and trustworthy visibility during telemetry failure.

Best-fit customer

engineering teams that want consistent judgement applied to design, review, and delivery

Need more than one role?

Buying the whole team or the complete department lowers your effective cost per role at every tier of the ladder.