85 posts tagged with "engineering-management"

A newly hired VP of Engineering has three things the org watches closely: what they cut, who they keep, and how fast they announce a plan. Get the sequence wrong and credibility is gone by week 4 — the org decides you're either a reorganiser or a lame duck before you understand the codebase. Michael Watkins' The First 90 Days is the foundational reference, but it's written for general executives. Engineering orgs have specific traps.

The counter-intuitive move: announce less in the first 30 days than you think you should. Not "listening tour" theatre — an actual measured pause while you read the org's calendar, incident history, and deploy pipeline.

An insurtech CTO once told me: "We're not a SaaS company. We're a SaaS company that sells a financial derivative." The distinction matters because insurance software doesn't just ship features — it ships risk models that regulators will probe on a five-year horizon. A bug in a claims service is a customer-support ticket. A bug in a pricing model is a filed regulatory complaint, a potentially mis-priced book of business, and a cleanup that measures in quarters rather than sprints.

Deloitte's 2024 Global Insurance Outlook reported that 47% of insurers cite legacy system modernization as their #1 engineering constraint. The teams doing that modernization are walking a tightrope: the regulators (EIOPA in the EU, NAIC in the US, Bank of Russia and Kazakhstan's AFSA in CIS markets) don't care that you adopted continuous deployment. They care that you can prove which version of your actuarial model priced a policy on a given date.

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 Solidity engineer pushing a mainnet contract has less forgiveness than a SpaceX launch engineer. Once deployed, the code is immutable, auditable by anyone, and often controls more value than the engineer's employer has in their treasury. Total Value Locked across DeFi protocols crossed $200B in Q1 2026 (DefiLlama data). Engineering metrics built for web2 SaaS break here.

Deployment frequency means nothing when the "deployment" is a proxy upgrade that requires a 48-hour timelock vote. Lead time means nothing when the last stage is a $200K external audit. We worked with 3 Web3 teams — two L2 rollup teams, one DeFi protocol — and rebuilt the metric stack around constraints web2 doesn't have.

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.

LinearB built one of the most opinionated tools in engineering analytics. The dashboards are good. The DORA reports are accurate. But the real product is the workflow engine: gitStream rules, auto-PR-routing, slack-bot reminders, custom team initiative tracking. That layer is what justifies the $30-50/seat price tag. The question every renewal cycle asks: is the workflow engine actually changing behavior, or are we paying premium for a dashboard?

If you're typing "linearb alternative" in 2026, you've probably already asked yourself that.

Swarmia is the cleanest Git-driven engineering analytics tool you can buy. It pulls commits, PRs and deployments, computes DORA, surfaces team-level cycle time, and stays out of your way. Most teams that buy it stay happy for a year or two. Then a question arrives that the tool was never designed to answer (usually one about money, on-prem, or what coding actually looks like outside the PR), and the search begins.

If you're typing "swarmia alternative" in 2026, this is the question we'll work through.

WakaTime ships the best personal coding tracker on the market. 500K+ users, plugins for 40+ editors, and a year-end "Wrapped" recap that the community actually waits for. The Premium plan is $9/month, a fair price for a single developer who wants to know "how much did I code today?". The trouble starts the day a team lead opens that same dashboard and asks a different question: how is my team performing, what is delivery costing, where is the bottleneck?

That question is not what WakaTime was built to answer. It is also exactly the question Google sends our way when somebody types "wakatime alternative" in 2026.

Your best SRE quit last quarter. She didn't say "burnout" in the exit interview, but her last three months included 14 after-hours pages, 2 weekend incidents, and a 3am call on her birthday. A 2021 Catchpoint / DevOps Institute survey of 500+ on-call engineers found 67% reported burnout symptoms tied directly to paging load. Google's SRE book sets an internal ceiling of 2 incidents per on-call shift before a rotation is declared unhealthy — most teams we measure blow past that in week one.

On-call is fixable. It's a scheduling and sociotechnical problem, not a personality flaw in the people who can't hack it. Here's a 9-rule playbook that keeps your SLA intact and keeps your best engineers on the team past their second rotation.

The average post-mortem takes 4 hours to write and generates zero action items the team actually completes within 30 days. We looked at 120 post-mortem documents from three of our on-prem customers before rebuilding this template. 83% of action items were still "open" six months later. That's not an incident review — that's a document graveyard.

A post-mortem is worth writing only if it changes something. Everything else is CYA.