46 posts tagged with "guide"

A CFO usually sees engineering on one line of the P&L: salaries. A headcount column, a loaded-cost multiplier, a big number growing faster than revenue. That's it. Deloitte's 2024 Global Technology Leadership Study put the gap at its starkest: only 31% of CFOs said they could tell whether their engineering investment was producing returns proportionate to cost. The other 69% were flying blind on roughly the largest discretionary spend in the company.

This is not a tooling problem. It's a question problem. The numbers exist. Your CFO peers just haven't learned which five questions extract them.

A LegalTech engineer doesn't just ship features. Every commit touches data that could be subpoenaed, privileged, or regulated under state-specific bar association rules. The global legal-software market crossed $29B in 2024 (Deloitte Legal Operations 2024 report), and with it came a compliance surface most SaaS engineering teams never see: attorney-client privilege, SOC 2 Type II as baseline, ISO 27001 for document handling, plus bar-association e-discovery rules in 50+ jurisdictions.

Productivity measurement in this environment is not a surveillance tool — it's an audit artifact. The same IDE telemetry that tells a SaaS EM "the team is healthy" is, in LegalTech, evidence of SDLC maturity in front of an enterprise law-firm client's IT security review.

A Security Operations Center running on MTTR alone is measuring the fire, not the fire department. IBM's Cost of a Data Breach Report 2024 found the average breach takes 258 days to identify and contain, and the teams that broke below 200 days didn't do it by responding faster. They detected earlier and spent less time on toil. MTTR was a side effect, not the target.

Cybersecurity engineering needs its own metric stack. Generic engineering KPIs under-weight the asymmetric cost of a miss, and pure InfoSec dashboards ignore whether the team is burning out or burning budget.

A mid-size team I advised last year had a standing rule: every ticket above 3 story points needed a design doc. Eight engineers, roughly four docs per week, each doc eating a half-day to write and another half-day in review cycles. That's 32 engineering hours per week — four full working days a week, spent on documents that most people scanned once and never reopened. The CTO thought they were a high-discipline shop. The data said they were documentation-heavy and velocity-poor.

The opposite extreme is worse. A 2019 report from Stack Overflow's Developer Survey listed "poor documentation of internal systems" as the #2 productivity blocker after technical debt itself. Skipping design docs entirely means every sixth-month refactor is an archaeology dig.

This is the framework I use to decide which changes deserve a doc, which deserve a 3-sentence RFC comment, and which deserve nothing at all.

The average engineering retro runs 60 minutes, produces five sticky notes, and ships zero action items into the next sprint. The Scrum Alliance's 2023 practitioner survey put "retros feel performative" as the #1 complaint from senior engineers. That's not a meeting problem. It's a measurement problem. Teams debate feelings because nobody pulled the data before the call.

This article gives you a 30-minute retrospective that opens with numbers, ends with named owners, and works on any team between 5 and 25 engineers.

According to the 2023 McKinsey developer productivity report, developers spend only 25-30% of their time writing code. The rest disappears into meetings, waiting, and process overhead. DORA metrics exist to make that invisible waste visible — and fixable.

If you're a CTO, VP of Engineering, or Engineering Manager who hasn't adopted DORA yet, you're managing by intuition in an era that demands evidence. This guide covers what each metric measures, how to benchmark your team, how to implement tracking, and the mistakes that make DORA data useless.