Blake Mulnix

Software Consultant

Hey, I'm Blake. I've been into computers since I was a youngster. If all those hours watching early YouTube and playing flight simulators taught me anything, it's that software can genuinely enrich people's lives. Today I build software for a living.

I'm a consultant at Source Allies, where I build software with a crew that's unreasonably good at it. We do plenty of coaching in addition to coding, helping teams and organizations pick up the practices that make delivery predictable.

How I Work

What I think a team needs to excel

A few things I believe are load-bearing if a team is going to excel over the long term.

01
Fast feedback loops
I would rather be wrong in an hour than right in a month.
Test driven development is the cornerstone of this mindset. Tests written after the implementation tend to describe whatever the code already does, while tests written first describe what it is supposed to do and code quality reflects that: smaller units, cleaner modules, and (of course) truly testable code.
I push my team to work closely and frequently with those upstream and downstream of us (customers, or teams we are partnering with). There are always unknown unknowns, I prefer to find them early rather than a week before a deadline.
Lastly, I believe in investing time in ceremonies to build and maintain a durable and healthy team: chartering a team early so we understand how each of us actually works + holding quality retros so that the real problems get acknowledged and resolved.
02
Self-organizing teams
The people closest to the work know how to be most effective.
Teams trusted to organize themselves and set their own direction consistently outperform teams waiting to be told. Direction should arrive as context and constraints, not as assignments.
That trust is not a reward for maturity, it is how maturity develops. A team never given the decision never learns to make it well.
03
Sustainable delivery
Engineers are the counterweight to the pull toward deliver, deliver, deliver.
Product's instinct to ship is healthy and necessary. Left unchecked it borrows against the system's future, because technical debt is often invisible in any single sprint. Engineers should spot these costs, and making them visible to leadership is part of the job.
The outcome is that the team delivers reliably for years rather than impressing stakeholders one quarter and fighting fires the next.
Of course, technical debt is unavoidable. The question is whether it is taken on deliberately and paid down, or accumulated unintentionally and discovered later.