Matthew Norgren

If you spend hours every day reading LinkedIn posts and Substacks about software engineering like I do you’ll notice everybody has decided that coding is no longer the bottleneck. I’ve read some version of that sentence a dozen times this month. What I haven’t seen is much agreement about what replaced it. What folks are saying: Problem-finding. Jensen Huang: “The purpose of a software engineer is to solve known problems and to find new problems to solve. Coding is one of the tasks.” He said nothing would give him more joy than if none of his engineers were coding at all. ...

Over the years I’ve noticed I keep solving the same kind of problem. Too many support requests. Too many connection failures. Too many customer escalations. Too many flaky tests. The thing itself changes, but the process I use doesn’t change very much. Sometimes it’s handed to me as a quarterly goal, sometimes it’s a problem I inherit, and sometimes it’s something I notice because the people around me keep running into it over and over. However it comes to my attention, the approach is usually the same. Recently, it took support escalations to engineering from 34 a week down to 9.5, a reduction of over two thirds, across a six month period. This is the process I used to get there. ...

Eighteen months ago, I wouldn’t have guessed we’d be removing Peer Review on pull requests. Over the last several months I’ve watched this team spend increasing effort trying to get pull requests reviewed. Not because people were avoiding reviews. Quite the opposite. They reminded each other in Slack, randomly assigned reviewers to beat the bystander effect, coordinated schedules, built skills and nudged each other throughout the day. Eventually I realized what this optimization of the review process was telling me. ...

Six months ago we stood in front of product and executive leadership and asked for time to build a new web platform. Our frontend was like an archaeological site. Four design systems layered on top of each other like strata, each one added with good intentions, none fully removed. Dig into any component and you weren’t sure what design system you’d hit. Three different state management technologies from three different eras of React thinking. Cross-feature work meant tying together technologies that were never meant to work together. Pages took too long to load and weren’t reactive. Our head of sales told us we’d lost two million dollars in deals over the past year because of the UI. ...

I’m a systems person. The work I’m proudest of is the kind nobody notices: the test suite that catches the bug before review, the pipeline that makes the safe path the easy path, the process that quietly turns the right thing into the default. Get it right and the improvement compounds. You fix something once and it stays fixed, long after you’ve moved on. That instinct has served me well. When a team is slow and chaotic, the fix is usually structural. At one company we took release cycles from three or four months down to two weeks, not by asking people to try harder but by moving to trunk-based development, wiring up CI, and putting real quality gates in the path. The system became automatic. It was the default. People did the right thing because the right thing was the easy thing. ...

I build with AI every day, and I have pushed my teams to do the same. We have rolled out AI tooling across engineering, built production agents for the boring work, and I spend real time coaching engineers on how to get more out of these tools. I am not a skeptic. I think this is the biggest shift in how we build software in my career. So I want to be careful about how I say the next part, because it is not a complaint about AI. It is a warning about what AI does to us. ...