In partnership with
As I mentioned last week, I recently started an Industrial-Organizational Psychology master’s program at the University of Georgia (Go Dawgs!), and I said I'd start pulling my insights into this newsletter. This is the first iteration. Let me know what you think!
I ran a Shopify agency for nearly a decade. For a while, I couldn't figure out why some genuinely good engineers kept building the hard way. I was also new to managing engineers and still had many leadership surprises ahead of me. This is one of those stories.
This takes place back in maybe 2019 or 2020, so pre-AI building. The Shopify ecosystem had a unique way of approaching software development: many common practices today around compiling and deploying apps just weren't a thing. I recently hired an engineer with a more traditional software engineering background and tasked him with building a new subscription management experience for one of our clients.
Our typical solution here would be a basic middleware app to run API requests through, and a UI for the customer management experience. This engineer started building something I'd describe today as a traditional app, but it felt overly engineered for this particular client's needs. It also took far longer to reach testing, and by the time we reached the testing phase, it was hardly functional. Every fix seemed to lead to more complications. The client and I were both frustrated, but so was the engineer.
It wasn't laziness or carelessness. If anything, this particular engineer tried harder than most, working late, rewriting things that already worked, chasing an edge case that didn't need chasing. But the work kept coming out heavier than it needed to be. If you come from traditional app engineering, none of Shopify's intricacies were obvious. You had to have run into those walls yourself to know why they were there.
At the time, I read it as a fit problem. He wasn't conforming to how we built things. I'd explain the pattern, he'd nod, and the next iteration would come back overengineered again. After enough rounds of that, I started assuming it was a willingness issue. He didn't want to build it our way.
A thank you from this week’s sponsor:
Privacy-first email. Built for real protection.
Proton Mail offers what others won’t:
End-to-end encryption by default
Zero access to your data
Open-source and independently audited
Based in Switzerland with strong privacy laws
Free to start, no ads
We don’t scan your emails. We don’t sell your data. And we don’t make you dig through settings to find basic security. Proton is built for people who want control, not compromise.
Simple, secure, and free.
It wasn't until I dug in further that I saw what was actually happening. He wasn't choosing to ignore how we built things. He didn't understand why we built things that way in the first place. Nobody had actually explained the constraints Shopify put on us, the reasons a simple solution was usually the right one, the tradeoffs that made "traditional" engineering instincts actively wrong in this context. He had the skill and the motivation. He was missing the one piece that made the other two usable: the knowledge of why.
That distinction cost us. This was pre-AI engineering, so there was no fast way to close a gap like that; you either already knew the constraints or you learned them slowly, project by project, usually the expensive way. For this client, we got far enough into a build with the wrong mental model that there was no clean way back. I ended up refunding the project in full. It was a loss for the agency, but it was also a rough experience for an engineer who'd been trying the whole time, and a real gap in my own management, because I was newer at this than I wanted to admit and didn't have a way to name what was actually broken.
I couldn't undo that one. What I could do was change how I hired after it, and how I onboarded people into a codebase that didn't behave like anything they'd worked in before. That shift didn't happen all at once. It's been reshaped 24 times since, and it's still not finished.
Yesterday I was doing some assigned reading for my I-O psychology master's program, and I ran into a model that finally gave language to what I'd been operating on by instinct. Performance comes down to three things:
Declarative knowledge: knowing what to do and why, the facts, principles, and constraints of the environment
Procedural knowledge and skills: knowing how to actually execute
Motivation: the choice to put in effort, at what intensity, and for how long
Note: studies have debunked a multiplicative effect; the multiplier is mostly decorative :) The factors are more additive in nature than multiplicative.
This model tracks with what I lived through: motivation and skill without an understanding of why don't go very far, and effort without knowing why can turn into exactly what I watched happen, more work, in the wrong direction.
Here's what I wish I'd had at the agency, the three questions I run now before I decide what kind of problem I'm looking at:
Does this person understand why this matters, not just what to do?
Have they actually done this specific kind of work before, in this specific kind of environment?
Are they choosing to try?
Most of the time, when something reads as a willingness problem, it's actually the first question going unanswered. Resistance is easy to see; an unanswered why isn’t.
I still think about this situation several years later, about the refund, and about how much faster I could have gotten him to competence if I'd had this model back then instead of years later. I can't go back and fix that one. But the way I hire and onboard now carries every version of that lesson I've learned since.