What Makes a Company Worth Working For? (Here’s What We Figured Out at MEV)

A practical look at how clear processes and human culture change the developer experience

There’s a moment most engineers hit at some point: you’re working late on a feature no one needs, following a spec that doesn’t make sense, knowing full well it’ll be scrapped in the next sprint. That moment usually ends with a quiet, exhausted thought: “It doesn’t have to be this way.”

And it doesn’t.

Curious About a Better Way to Work?

This is it

At MEV, we’ve spent years trying to answer one question: What if the work environment helped you do your best work – instead of getting in the way? Below is what we’ve learned.

1. Clear thinking beats fast guessing

You know the pattern: “Just ship it” turns into “Let’s redo it next sprint.” Not because the code was bad—but because priorities were fuzzy, goals weren’t aligned, or no one stopped to ask the right question at the start.

At MEV, we’d rather go slower in planning so we can go faster in delivery.

Here’s what that can look like:

A developer notices a new requirement that doesn’t quite fit how the product actually works. Instead of coding around it, they ask, “Why are we adding this again?”. It turns out to be a misinterpreted business request. The team simplifies the feature and ships something better—in less time.

What you can do today:
Before you start your next task, ask yourself: Do I know why this matters? If not, take 5 minutes to clarify it with your team. That’s often all it takes to avoid hours of cleanup later.

2. No guessing. No grandstanding. Just facts.

When something breaks, it’s tempting to go with your gut. Or fix the part that looks wrong. Or run with the loudest opinion in the room. We don’t do that.

We check. We verify. We make decisions based on reality, not assumptions.

One way this might unfold:

A client flags performance issues. Rather than jumping into the codebase, the team checks logs, metrics, and real user data. The culprit? A misconfigured client-side cache. Nothing needed fixing on our end—just a quick explanation and support on theirs.

What you can do today:
Next time you hit an issue, pause before you code. List two things you know to be true about the problem—and one thing you’re assuming. Challenge that assumption.

3. Burnout doesn’t build good software

The “always on” hero culture? We’re not into it. Doing great work consistently matters more than pushing past your limits once a week. We design for sustainability. A normal day shouldn’t feel like a crisis.

Here’s a typical approach:

It’s Thursday evening and a dev runs into a blocker. Instead of powering through solo, they leave clear notes and flag it for review. By the next morning, someone else picks it up—with a fresh brain, coffee in hand—and solves it in 30 minutes.

What you can do today:
If your current task is pulling you into overtime, ask: Is this a process issue or a priority issue? Either way, bring it up in your next retro. If you’re doing heroic work weekly, something’s broken—and it’s not you.

4. Remote works—when culture makes it work

We’ve been remote-friendly long before it was standard. Not because we’re hands-off—but because we trust people to manage their time, and we set up systems that actually support it.

Here’s how it can evolve:

A developer in a different time zone mentions that daily standups are breaking their focus. The team tries async check-ins and moves live meetings to once a week. Nothing gets missed, quality stays high—and nobody’s drained by back-to-back calls.

What you can do today:
Look at your last three meetings. Could any of them have been handled with a thoughtful async message and a 5-minute reply window? Suggest trying it once—and see what happens.

5. You don’t have to be a robot to be respected

New teammates often say, “I didn’t expect everyone to be this normal.” It’s one of our favorite compliments.

You won’t be expected to tone yourself down to “look professional.” Bring your humor, your weird side project, your awkward dog photos. We like knowing who we work with.

Something that could happen:

A developer shares a small tool that turns error logs into pirate-speak. It gets a laugh, becomes a Slack bot, and even ends up in a team demo. Around here, creativity like that doesn’t distract from the work—it makes it better.

What you can do today:
Bring one piece of yourself to work that you usually hide. A playlist, a side project, a conversation starter. Great teams aren’t built on sameness—they’re built on trust and variety.

Want to know if a company’s worth your time?

Forget the perks page. Ask these instead:

• What happens when engineers disagree with a spec—can they challenge it without pushback?
• How does the team handle work-life boundaries when deadlines are tight?
• When was the last time someone took initiative and changed a process? What happened next?
• How is feedback delivered—formally once a year, or casually as part of the day-to-day?
• What kinds of side projects, personal interests, or non-work conversations show up on Slack.

‍

These questions reveal how the company thinks—not just how it markets itself. Listen closely to the answers. That’s where the culture lives.

‍