Building a career at Revni means having your reasoning checked as often as your output — real ambiguity is treated as part of the job here, not a problem to eliminate before someone starts.
This page describes what that's actually like, not what it's supposed to sound like.
Who This Is For
Revni tends to suit people who'd rather find out they're wrong on a Tuesday than protect being right until Friday — people who want their reasoning checked, not just their output. It's a less natural fit for someone who wants a settled process to execute inside; there's real ambiguity here, and it's treated as part of the job rather than a problem to solve before someone starts.
The Kind of People Who Succeed Here
The people who do well here tend to say "I don't know yet" out loud, in front of a client, without treating it as a failure — because an untested assumption left unspoken is the thing that actually causes damage later, not the admission itself.
They write things down before anyone asks them to, not because they're told to, but because they've noticed that a decision without a reason attached gets re-argued by someone who wasn't in the room. The writing isn't overhead to them; it's just how they think clearly.
When two of them disagree, they go looking for the fact that's missing rather than defer to whoever has more experience or a louder opinion — and they're comfortable being the one who turns out to be wrong, because that's cheaper to discover early than late.
They notice a broken process and fix it before automating it, rather than the other way around — the same instinct that shows up in how Revni approaches technology shows up first in how these people approach their own daily work.
What It's Actually Like Day to Day
Disagreement isn't smoothed over here — if a team agrees quickly on a hard problem, that's usually treated as a sign a step got skipped, not as consensus. A junior engineer's observation carries weight based on the evidence behind it, not their years on the team.
When something breaks, the conversation afterward asks what signal was missed and what would catch it sooner next time — not who to blame. That only actually works because it gets practiced when it's uncomfortable, not just claimed when it's convenient.
A senior person saying "I got this wrong" in front of the team isn't rare or dramatic here — it happens often enough that it doesn't cost anyone their standing to say it.
What We Expect From Ourselves
Regardless of role, a few things are expected of everyone here, every week, not just at review time: document the decision at the point it's made, not after someone asks why; say "I'm not sure" the moment it's true, rather than after it's already caused a problem.
Ask for a second set of eyes on something before it ships, even when nobody's requiring it — and when something goes wrong, the instinct is to fix the system that allowed it, not to find who's at fault. Whoever picks up something you built next should find it easier to understand than you found it, not harder — that's the actual test, not whether it works today.
Honestly, About Hiring Right Now
There are no open roles at Revni right now. When that changes, this page will say so plainly, with a real listing rather than a vague "always looking for great people" line. If what's described above sounds like a fit, reaching out anyway is welcome — there's no pipeline to apply into today, just a real conversation if the timing turns out to be right.