[{"content":"I\u0026rsquo;m Matthew Norgren, a software engineering leader based in Portland, Maine, with more than two decades building software and the teams that ship it. I specialize in organizations where execution is inconsistent. I take on turnarounds, re-architectures, and the broken systems and strained cross-team relationships that slow companies down, and I build the practices that make delivery faster, more predictable, and higher quality. I work from measurable data like cycle time, flow, and quality signals, and I aim for predictable delivery without heroics. I take ownership from diagnosis through delivery, and I\u0026rsquo;m not done until the team and the systems keep running well without me.\nToday I\u0026rsquo;m Director of Software Engineering at CloudZero, where I lead a product engineering team and our Developer Experience group. I joined as the company scaled. During my tenure the engineering organization has roughly quadrupled and the customer base has grown about 2.5x. I\u0026rsquo;ve scaled my own scope to as many as four teams, hired and developed engineering managers, and kept teams delivering through layoffs, reorganizations, and shifting priorities.\nWhat I do best Turnarounds. I stabilize underperforming teams, restore delivery confidence, and repair the cross-functional relationships that have broken down. At CloudZero I led a company-wide effort that cut support escalations to engineering by over two thirds, from 34 a week to 9.5, and earned a Lighthouse award for leadership and impact. Operational transformation. At Bittrex I more than doubled the rate of new blockchain integrations by changing process and taking down barriers between teams. At MapLarge I cut production regressions by roughly two orders of magnitude with trunk-based development, continuous integration and mandatory PR gates. I also shortened release cadence from 12-20 weeks down to two. Scaling organizations. I\u0026rsquo;ve hired engineers and engineering managers, built team structures around clear ownership, and coached ICs and managers into leaders. Leading through change. I keep teams delivering through layoffs, reorganizations, and strategic pivots. At Bittrex I sustained delivery and morale through an SEC lawsuit and the company\u0026rsquo;s exit from the U.S. market. Putting AI to work. I rolled out AI tooling across all of Engineering and built and deployed multiple AI agents for issue classification, support triage, and documentation-drift detection, saving an estimated 75 hours of manual work a week. Experience in brief CloudZero: Director of Software Engineering (2024-present) and Principal Software Engineer (2023-2024). Led the company\u0026rsquo;s web platform re-architecture from QBR approval through on-time delivery, and built Connection Doctor, a hackathon project now a company-wide internal tool for platform connection visibility. Bittrex: Director of Platform and Operations (2022-2023). Hired to run the fiat-payments and blockchain-integration teams, then promoted to lead the Platform and Operations group spanning blockchain and fiat integrations, DevOps, backend APIs, and keeping nodes running for hundreds of blockchains. MapLarge: Director of Software Operations and earlier engineering roles (2016-2022). Ran day-to-day operations for a 40-person engineering team and scaled a public AWS platform from 200,000 to 23 million requests per hour. Unidesk: Principal Developer and Scrum Master (2008-2016). Core contributor from 10 employees through a successful acquisition. Built low-level systems including a Windows filesystem mini-filter driver in C for desktop virtualization. EMC: Software engineer on CLARiiON storage arrays, where performance-optimization work led to two U.S. patents. Background B.S. in Computer and Systems Engineering from Rensselaer Polytechnic Institute. Two U.S. patents (7,281,097 and 7,739,470) for controlling data-storage performance with genetic and nonlinear control algorithms. Fully remote since 2016, leading distributed teams across time zones with a high-trust, high-autonomy approach. I work across Python, C#, C++, Kotlin, and JavaScript, on AWS and Azure.\nWhat drives me I\u0026rsquo;m drawn to the messy, ambiguous situations where the path isn\u0026rsquo;t obvious yet. I measure my work by what keeps running after I move on: resilient teams and processes that stay strong without me. Getting something working well is valuable. Getting it working well without you is the real win. I care about empowered teams, blameless continuous improvement, and giving people the conditions to do their best work.\nContact LinkedIn: linkedin.com/in/matthew-norgren Location: Portland, Maine ","permalink":"https://norgren.org/about/","summary":"\u003cp\u003eI\u0026rsquo;m Matthew Norgren, a software engineering leader based in Portland, Maine, with more than two decades building software and the teams that ship it. I specialize in organizations where execution is inconsistent. I take on turnarounds, re-architectures, and the broken systems and strained cross-team relationships that slow companies down, and I build the practices that make delivery faster, more predictable, and higher quality. I work from measurable data like cycle time, flow, and quality signals, and I aim for predictable delivery without heroics. I take ownership from diagnosis through delivery, and I\u0026rsquo;m not done until the team and the systems keep running well without me.\u003c/p\u003e","title":"About"},{"content":"I\u0026rsquo;m a systems person. The work I\u0026rsquo;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\u0026rsquo;ve moved on.\nThat 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.\nSo for a long time my answer to almost any problem was another system. Interrupts eating the team? Bucketize the issues, fix the root causes, write the docs, give support a tool they can run themselves. Quality slipping? Tighten the gates. It works, it\u0026rsquo;s satisfying, and it scales.\nHere is what I had to learn the hard way: systems shape behavior at the margins, but they do not fix a person.\nIf you have an engineer who is checked out, no amount of tooling is going to turn them into the engineer you need. Cutting your test run from ten minutes to five will not do it. A cleaner backlog will not do it. The friction you are removing was never the thing holding them back. I used to reach for the process lever anyway, because I am conflict-averse by nature and building a new automation is a lot more comfortable than having a hard conversation. It took me a while to see that for what it was. It was avoidance, dressed up as engineering.\nThe hardest leadership lesson I have learned is that some problems only move when you talk to the person directly. Empathetic and direct. You tell them where they actually stand, what has to change, and by when. You do not soften it into nothing, and you do not hand it off to a system that was never going to carry that weight. People deserve the truth about how they are doing. They cannot fix what no one will tell them.\nI still build the systems. I will always build the systems. But I have stopped using them as a place to hide from the part of the job that only I can do. The highest-leverage thing in any given week is often the conversation I have been putting off.\n","permalink":"https://norgren.org/writing/what-systems-cant-fix/","summary":"\u003cp\u003eI\u0026rsquo;m a systems person. The work I\u0026rsquo;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\u0026rsquo;ve moved on.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e","title":"What systems can't fix"},{"content":"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.\nSo 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.\nIt is easier than ever to trick yourself into thinking you can do something. I felt it myself during a hackathon. I built an application over a weekend that genuinely impressed people, and impressed me. It felt like magic. But there is a wide gap between a demo that impresses a room and a system you would actually stand behind, and AI is very good at getting you across the first gap while hiding the second. The dopamine arrives long before the real work is done.\nI have seen the same thing show up in ordinary work products. The project plan that is ten times longer than it needs to be. Confident, well formatted, but oddly twisted, redundant and filled with facts that have quietly drifted away from true. It reads well. That is exactly the problem. Slop is plausible, polished. It passes the skim test. Polished and wrong is dangerous. Polished and wrong gets waved through when what we needed was accuracy.\nSome of what\u0026rsquo;s changed is where the cost sits. Producing volume used to be expensive, so a thick document was a decent signal that someone had done the work. Now volume is free. The scarce thing is judgment: knowing what good looks like, and being willing to throw away three pages of confident text because it is subtly off.\nWhen I coach an engineer who is getting bad output, the problem is almost never the model. It is that they did not understand the problem well enough to ask for the right thing. The work did not disappear. It moved. You still have to build a real grasp of what you are doing, or the machine will happily hand you something that only looks like what you need.\nSo yes, I want my teams using AI aggressively. I also want them to be the people who can tell the difference between something that works and something that just looks like it. That discernment is not a nice-to-have. It is the job.\n","permalink":"https://norgren.org/writing/it-looks-like-it-works/","summary":"\u003cp\u003eI 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.\u003c/p\u003e\n\u003cp\u003eSo 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.\u003c/p\u003e","title":"It looks like it works"}]