Engineering & Technology - Engineering
Software Engineer - Observability
IC / Practitioner
Independently auditedBuilds 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
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.