cat README.md

Working With Matt Cullerton

CTO README


Why This Exists

Starting a new role is a rare chance to set expectations explicitly. This document tells you how I think, how I lead, and what you can expect from me. It's not aspirational marketing - every claim here is grounded in how I actually show up in meetings, 1:1s, and under pressure. If you see me drifting from what's written here, call me on it.


Who I Am in a Sentence

I take complex things and make them simple, and I'm incredibly pragmatic in the way I approach things.

That's not a tagline. It's how my brain works. Everything can be reduced to something tractable. Every initiative should start with: what does success look like? And every piece of technology we build should serve a business outcome, not the other way around.

If I'm explaining something complicated, I'll reach for an analogy. I'm always trying to make the abstract concrete. I can't help it -- it's how I find understanding and alignment.


Where I Come From

I've been an engineer for over 20 years. My first job was with Northrop Grumman building dispatch software for police, fire, and EMS. Quite literally life-and-death software. It gave me perspective, and an understanding of quality that never left.

From there I moved through early-stage product companies and engineering leadership roles - from writing code to managing engineers to leading engineering organizations. I kept coming back to a first principle: engineering is problem solving. I can't solve a problem I don't understand. So before I think about solutions, I need to understand the business's problems - and more importantly, the customer's problems. Technology is never the starting point. The problem is.

I'm still an engineer at heart. I care about technology choices and architecture - I genuinely enjoy the craft. But that's the area I trust you to own. My role is making sure we have the right systems in place - frameworks, cadences, workflows, processes - to ensure those things are happening to the standard the business needs, and so the team can do their best work.

Building my own business reinforced what it means to be a pragmatic leader. The right answer is the one that works, not necessarily the one that's most elegant. I focus on business value. I care about putting the right people in the right seats, and then collaborating to find the best outcomes - because nobody gets there alone.


How I Lead

Trust But Verify

This has been my core operating model for years. It's a named framework I use deliberately:

  • Trust: I want everyone to have autonomy. I will assume positive intent. I will give you room to run. I won't hover over your shoulder or re-do your work.
  • Verify: Autonomy comes with accountability. Plans should be written down. Tradeoffs should be documented. Commitments are real. If you say it'll be done Thursday, I'll trust you - and I'll notice Thursday.

This isn't about suspicion. It's about building a system where nobody is guessing and nobody is hiding.


What You Can Expect From Me

I will come prepared. I show up to meetings with a point of view and I'll try to state it clearly. But the best ideas win, not titles - if you see it differently, I want to hear it. I check alignment in real-time, and if I'm restating your points, it's because I'm making sure we're on the same page.

I will be direct. I don't hide behind corporate language. When I don't know something, I'll say "I don't know." When something is my gut instinct, I'll say "this is my gut." When I'm about to say something uncomfortable, I'll say "this is going to sound controversial" - and then I'll say it.

I will call it when something isn't working. I'll frame it as curiosity before conclusion - "help me understand" before "here's what's wrong." I won't ambush you with feedback, but I won't dodge it either.

I will share context. You will have more information than you expect. I believe people do their best work when they understand the why - the business reality, the financial picture, the strategic reasoning. I'm not going to guard information that helps you make better decisions. At some point, it's just math - and I'd rather you see the math than operate blind.

I will start with you, not the task. Every meeting begins with a human connection. We'll talk about your weekend, your kids, your ski trip, whatever is on your mind. This isn't wasted time. It's how I build the relationship that makes everything else work. Relationships are everything. We can have the most thoughtful approach in the world, but if the relationships don't form early, everybody's going to have a problem with something.

I will hold myself to the same standard I hold you to. Everything in the "What I Expect From You" section applies to me too. When I fall short, I'll say so - and if you see me fall short, call me on it.

I will support your growth. I care about building great engineers and great leaders, not just shipping products. I'll demonstrate tools and approaches, then invite you to own them. I'll offer input on your work with a promise: "I won't change anything, but I'll give you a couple of thoughts."

When you come to me with a problem, my default question is "how can I support you?" - not "why isn't this done?"


What I Expect From You

Ownership. Not "someone should" - instead, "I will." If you see a problem, own it. If you committed to a deadline, honor it or raise the flag early. I don't want to accept the performance we get - I want us to raise the bar together.

Honesty. Bring problems early. Don't spin alone. If you disagree with me, I want to hear it. If something feels off, tell me. I can handle bad news. What I can't handle is finding out about bad news late. I would rather have an awkward early conversation than a catastrophic late one.

Integrity. Say what you mean and follow through. If confidence is high, say so. If it's low, say that too and explain why. Don't tell me what you think I want to hear - that erodes trust faster than anything.

Engage with the future. AI is fundamentally changing how we build software. I expect you to lean into that. The engineers who thrive will be the ones who embrace this shift. I'm a broken record on this, and I know it.

Visibility. Write things down. Plans, tradeoffs, progress, risks - make them visible. I shouldn't have to ask where things stand, and you shouldn't have to explain from memory. If it's not written down, it didn't happen.

Business awareness. Understand why your work matters. Ask for context. If you don't know how what you're building connects to a business outcome, that's a conversation we should be having. Technology for technology's sake is the one anti-pattern I'll always pull us back from.