Anoop Soman

About

Anoop Soman

Engineering leader. Builder. Curious about how things work.

17+ years building software and leading engineering teams — from writing code to scaling a 65+ person org, and back to hands-on building. Currently exploring AI-assisted development and what engineering looks like when implementation gets cheap.

Journey

Engineering

2008
Raw Engineering · Senior web engineer
Customer-facing apps
2012
Railsdata · Senior software engineer
Enterprise web platforms
2018
Railsdata · Technical analyst
Enterprise platforms

Architecture & leadership

2019
Entropik · Frontend architect
Owned system-level decisions
2022
Entropik · Associate director
Delivery across 2 SaaS products
2024
Entropik · Director of engineering
Scaled org 20 → 65+

Building again

2025
Independent · Builder
Hands-on again, end to end
2026
Open source · Builder
Building tools in the open

As teams grow, the hardest problems stop being technical — they become about clarity, ownership, and communication.

What I believe

Context over instructions

Give people the goal and the constraints, and they'll usually make better calls than a manager deciding everything for them.

Systems over heroics

If a release keeps needing someone to stay late and save it, that's not heroism — it's a system that needs fixing.

Ownership beats process

Process should make good decisions easier, not replace judgment.

Speed needs direction

Moving fast isn't useful if it's in the wrong direction.

Build leaders, not dependencies

The best sign a leader is doing their job: more things can happen without them.

Things experience taught me

0→1 needs a different operating system
Ship first. Add guardrails when the cost of not having them becomes real.

Early in one product line, getting something into customers' hands mattered more than a polished process — and that was the right call. As the product and team grew, those same habits started creating friction, and we had to add ownership, guardrails and visibility we didn't need before.

Remote management exposes weak communication
Remote work doesn't create communication problems. It exposes the ones that were already there.

Managing a distributed team through remote hiring and onboarding meant things I used to solve through proximity had to become explicit — written context, clear ownership, and regular visibility, instead of hallway conversations.

Visibility isn't the same as more meetings
If a meeting exists mainly to prove work is happening, something's probably wrong.

Introducing a pod-based delivery model was partly about clearer ownership and visibility across teams. But visibility can quietly turn into ceremony — standups are useful when they surface blockers and decisions, not when they become a status report nobody asked for.

Scaling means changing how you lead
The job shifted from making decisions to creating the conditions for good ones.

What worked when I was close to every technical call stopped working once I was responsible for multiple teams and products. Scaling meant fewer dependencies on me, and more on clear ownership and people who could decide well without me in the room.

Technical debt isn't automatically bad

Sometimes taking on debt is the right business decision. The problem isn't debt — it's pretending it doesn't exist.

Simplicity is an engineering feature

Every abstraction, service, dependency and process has a cost. I try to ask whether the complexity is buying us something worth paying for. If not, remove it.

Leadership sometimes means making difficult decisions
Leadership isn't only about helping people succeed. Sometimes it's about making the decisions nobody wants to make.

Part of leading through the org's harder stretches meant making difficult calls about team size when the business needed it. Those decisions don't get easier by avoiding them — they get more honest by owning them, communicating clearly, and taking responsibility for what follows.

Building again

After years focused on leadership, I stepped back into hands-on development — partly because I missed building, and partly to understand what modern software development feels like from the builder's side.

hueglint

npm

Accessible-by-default heatmap library — CVD-safe color palettes, keyboard navigation, ARIA data table, diff-mode comparison, axe-core gated CI.

  • #accessibility
  • #color

ladderline

CLI

Local-first CLI for engineering managers — logs work as it happens, builds a grounded case for promotion cycles.

  • #eng-management
  • #local-first

trailvine

npm

SVG timeline and route generator — framework-agnostic core, thin bindings for React and vanilla JS.

  • #svg
  • #timeline
See everything I'm building →

AI changed how I build

I use AI coding assistants for exploration, prototyping, implementation, tests, and docs — but I don't outsource engineering judgment to them.

AI can produce code. It doesn't own the engineering decision.

Technology

Tools I reach for often, or that I stay close enough to to make good calls about — not a certification list.

ReactTypeScriptNext.jsNode.jsHonoPostgreSQLAWSDockerCI/CD
ArchitectureDesign systemsDeveloper experienceObservabilityPerformance

Now

Building
Open-source tools and small products
Learning
System design, AI-assisted coding, developer tooling
Exploring
AI-assisted development, agentic workflows
Thinking about
Staying fast as teams grow

Elsewhere

Kerala-born, Mumbai-raised, Bangalore-settled. I've been a Liverpool supporter since 2005–06, so I've seen my share of rebuilds, comebacks, and good times. These days, I'm also learning a whole new kind of patience — raising a three-year-old daughter.

Are we building something worth building?