How I Hired the Engineer Who Raised Our Standard

The early engineer whose judgment you trust does not only write code.

They help set the default standard for everyone who joins after them. They shape, often without realizing it, what "good enough" means in your company. They make the next engineer better or worse. They either protect your taste or slowly lower it until every sprint becomes archaeology.

I learned this at Scrimmage.

When I joined, the product already had an engineering team. The team and process were still maturing, and the codebase had grown faster than the engineering culture around it.

I came from an environment where clean code, refactoring, review, and deliberate structure mattered a lot. So the gap was painful. It was not only a matter of taste. In my view, the product was struggling because the system around the engineers could not consistently produce the quality it needed.

At first, I tried to fix the system without changing the team.

I introduced peer reviews. I pushed for linting. I talked about cleaner architecture. I sent learning resources. I had one-on-one calls explaining why this mattered. I even considered paying people for learning time because the return seemed obvious to me. If a few hours of deliberate learning prevented weeks of rework, it was not a cost. It looked like the most practical engineering investment we could make.

But tools do not create standards by themselves.

A linter can reject code. It cannot make someone care. A pull request template can ask for context. It cannot create judgment. A clean-code video can explain principles. It cannot create the internal discomfort that makes an engineer rewrite something because they know it is not good enough yet.

After a few months, I felt I was spending more time explaining, reviewing, and repairing than building. The calendar was full, but the code quality barely moved. That is when I learned a hard lesson: a bigger team can make a startup slower if the team does not share the same standard.

More engineers do not automatically mean more progress.

Sometimes one aligned engineer is faster than three misaligned ones.

Firing people is not an abstract management decision

My management style was always peer-based. I wanted people to feel that I was one more person in the team, not a cold authority figure sitting above them. I have my own tired days, motivated days, mistakes, and emotions. I like building loyalty and trust. I want people to feel they can tell me the truth without being punished for it.

That style has advantages. Work becomes more human. People are more open. Problems surface earlier.

It also makes firing emotionally difficult.

When you build a real relationship with someone, letting them go does not feel like updating a spreadsheet. I remember my first firing meeting because I needed time to calm myself down and accept that the decision was correct. The company needed a different standard, but the human part was still heavy.

This is one reason I now think founders should be slow to hire in the beginning. Every early hire becomes emotionally expensive. If the person is not right for the standard you need, you either pay with product quality or pay later with a painful conversation.

Eventually, we reduced the team to the smallest group we could support, and for a while the product became easier to move. That shocked me at the time, but it should not have. Reducing coordination drag and repair work can create more speed than adding headcount.

The next hire mattered a lot to me.

I knew we had budget for one more engineer. I also knew I did not want to hire someone who merely filled a seat. I wanted someone who would raise our technical standard.

And I knew one person like that.

The engineer I kept returning to

I knew a former colleague whose technical judgment I trusted, and I kept returning to the possibility of working together. He was honest. He was dedicated. He cared about engineering in a way that was obvious from his behavior, not from his CV.

The biggest signal was simple: he had strong technical taste.

I do not mean this as a universal requirement. People can be excellent engineers and still have boundaries, families, hobbies, health problems, or seasons where they need work to stay at work. I do not believe startups should exploit "passion" as an excuse for unpaid labor.

But in his case, the pattern was real. He genuinely liked learning how systems work. Some people talk about growth mindset. Some people keep improving their craft because the problem itself stays in their head.

When you meet the second kind of person, pay attention.

I stayed in touch and kept returning to the idea of working together. For a while the answer was no. Then one day it was yes.

By that point, my co-founders trusted my judgment enough that the conversation was mostly between him and me. I had to sell him on Scrimmage, but in the most awkward possible way: we knew each other, and I trusted him too much to lie.

So I told him the truth.

The product was promising. The engineering process was still maturing. The opportunity was real, but the technical situation needed serious work.

This is not how hiring calls are usually supposed to go. You are expected to make the company look clean, exciting, and under control. I made it sound like a rescue mission.

He almost walked away.

In retrospect, I still think honesty was the right move, but I would frame it better now. Do not tell a strong engineer "the code is terrible" and stop there. Tell them the truth plus the mission: the current code is painful, the product deserves better, and the person joining now can help define the engineering culture for everything that comes next.

Strong engineers do not need fake perfection. They need to know whether the mess is worth fixing.

Standards are contagious

After he joined, I saw his arrival as one of the forces that raised our technical standard.

Before he joined, I thought I had high standards. After he joined, I realized my standards could go higher. I would write something I considered clean, then see how he approached the same problem and feel the need to rewrite my own code.

That is the effect you want from an early engineer with real judgment. Not someone you constantly pull upward. Someone who pulls you upward too.

Within a few months, I felt the codebase moving differently. We introduced stricter linting, stronger reviews, more deliberate project management, and harder conversations about architecture. We tried to make the team structure work, but eventually we returned to the smallest group that could actually maintain the standard.

Then Scrimmage went through a major strategic shift. In my account of Scrimmage, the company moved from sports-betting analytics into Web3 gaming and later into B2B gamification and loyalty. That pivot gave us something rare: a reason to throw away old assumptions and rebuild the architecture with stronger abstractions, better types, and a cleaner foundation.

I do not think I would have approached it the same way without him.

I was built more like a founder. I cared about product, business, design, marketing, fundraising, and engineering at the same time. He was built more like a technical leader. He focused on programming principles, new technologies, and engineering craft with a level of depth I did not have.

That combination mattered. A startup does not need everyone to be the same kind of intense. It needs complementary intensity.

Your first hires become the culture

The first three people you hire create the culture more than any values document.

If the first people accept messy work, messy work becomes normal. If they ignore reviews, reviews become theatre. If they hide delays, estimation becomes fiction. If they do not learn, learning becomes optional. If they blame others, blame becomes the management language.

The reverse is also true.

If the first people take responsibility, responsibility becomes normal. If they rewrite code without being asked because the abstraction is wrong, quality becomes normal. If they explain tradeoffs clearly, clarity becomes normal. If they learn in public, the team learns faster. If they tell the truth early, problems become easier to solve.

That is why hiring "good enough" early is so dangerous. You are not only hiring current output. You are hiring the future behavior that everyone else will copy.

The mistake I made before hiring him was thinking I could install culture through process. Process helps, but culture spreads through people. A code review matters more when the reviewer has taste. A linter matters more when the team agrees that the linter protects something valuable. A roadmap matters more when engineers feel responsible for product outcomes, not only tickets.

An early standard-raising engineer should not be only a task executor. They should be a culture carrier.

Passion is not obedience

There is a dangerous version of this argument, so let me separate it clearly.

I am not saying you should hire people who accept bad boundaries, work unpaid nights, or replace their identity with your startup. That is not passion. That is a management failure waiting to become burnout.

The signal I care about is not obedience. It is ownership.

Ownership looks like curiosity when nobody is watching. It looks like asking why the architecture exists this way. It looks like noticing that a bug is a symptom of a deeper design problem. It looks like learning because the work itself is interesting, not because someone attached a bonus to a course.

In an early startup, this matters because there is no mature machine around the team yet. You do not have perfect onboarding, perfect specs, perfect QA, perfect management, or perfect product strategy. The early team has to build the machine while using it.

If an early engineer waits for everything to be defined, you will drown in definition work.

If an early engineer helps define the system, the company becomes easier to build.

What changed after Scrimmage

Scrimmage kept evolving after those early engineering lessons. In my account, it moved from sports-betting analytics into Web3 gaming, then into B2B gamification and loyalty infrastructure. Scrimmage's assets were later acquired by Xtremepush, and the technology became part of a broader loyalty, CRM, and gamification platform.

I am not going to pretend that one hire explains the whole company story. Startups are messier than that. Pivots, founders, markets, timing, funding, team, customers, and luck all matter.

But I can say this: I saw that engineering hire as one of the forces that changed the slope of the technical team.

He made quality feel normal to me. He made me sharper. In my interpretation, he helped turn engineering from a thing I was dragging forward into a standard the team could stand on. The next strong hires came into a culture that already had a shape.

That is the lesson I would give any technical founder:

Do not hire an early engineer only for capacity. Hire for the standard you want the company to inherit.

One great early engineer is not just one more person. They can become the beginning of your engineering culture.