hueglint
npmAccessible-by-default heatmap library — CVD-safe color palettes, keyboard navigation, ARIA data table, diff-mode comparison, axe-core gated CI.
About
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.
As teams grow, the hardest problems stop being technical — they become about clarity, ownership, and communication.
Give people the goal and the constraints, and they'll usually make better calls than a manager deciding everything for them.
If a release keeps needing someone to stay late and save it, that's not heroism — it's a system that needs fixing.
Process should make good decisions easier, not replace judgment.
Moving fast isn't useful if it's in the wrong direction.
The best sign a leader is doing their job: more things can happen without them.
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 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.
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.
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.
Sometimes taking on debt is the right business decision. The problem isn't debt — it's pretending it doesn't exist.
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 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.
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.
Accessible-by-default heatmap library — CVD-safe color palettes, keyboard navigation, ARIA data table, diff-mode comparison, axe-core gated CI.
Local-first CLI for engineering managers — logs work as it happens, builds a grounded case for promotion cycles.
SVG timeline and route generator — framework-agnostic core, thin bindings for React and vanilla JS.
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.
Tools I reach for often, or that I stay close enough to to make good calls about — not a certification list.
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?