My README

A practice that's emerged with managers is to publish a document explaining what's important to them and what it's like to work with them, inspired by the README files that accompany software. I'm joining North as an engineer, not a manager, but the idea is just as useful between teammates. Here's what you'll learn about me: my background, my beliefs, how I work, my strengths and weaknesses, and how to give me feedback.

My background

Most folks here won't see my resume, so a bit of context. I've spent most of my career as a software engineer, several years as an engineering manager, and a few more as a product manager, at companies like Disney, Next Big Sound (acquired by Pandora), and Pandora/SiriusXM. That mix means I care as much about why we're building something and who it's for as I do about how it's built. I'm here as an engineer, but I'll naturally bring a product and process lens too.

My beliefs

I'm biased by my experience, like everyone is by their own. I try to recognize this by staying open to other perspectives and evolving my own as a result. Still, there are a few ideas I hold more strongly than the rest:

• Assume positive intent. "Be kind, for everyone is fighting a hard battle." Everyone is trying their best with what they have, so be kind, and be curious rather than judgmental. When things don't go well, give people the most generous interpretation of their actions instead of the most malicious. It's us versus the problem, not each other. This is one of the beliefs I hold most deeply.
• Everything can be changed. Nearly everything we use today was created by people like you and me. Changing things just takes time and pressure. When things don't change, it's not because they can't, but because someone gave up first.
• Everything can be learned. Nobody was born knowing how to play the piano or design a rocket. More important than any specific skill is learning how to learn. Learning faster than anyone else is the key to success.
• The most impactful people care about the why. Hunger to understand the reasons behind things is what separates chefs from cooks. Cooks implement; chefs create. You can't create well without understanding how things work, why, and what need you're actually trying to satisfy.
• Resilience requires diversity, and diverse solutions come from diverse inputs. The quality of your ideas reflects the quality of the information and debate that went into them.
• In the long run, you can't tell people what to do. Power by authority is short-lived. To make lasting change you have to persuade people and then design a system that reinforces the change you want.

How I work

• Solve the right problem. The highest-leverage work happens early, in defining the problem and designing the solution, not just implementing it. I'd rather spend an extra hour asking "what are we actually trying to solve?" than a week building the wrong thing. Asking questions takes less time than doing the wrong thing.
• Ship to learn. Speed drives quality. Quality comes from contact with reality, not from thinking alone, so I get things in front of people early, even painfully early. A boxes-and-lines sketch, a signatures-only draft PR, a rough prototype. If the first time someone sees my work is when it's "done," that's already too late.
• Use AI as a force multiplier, not a replacement for judgment. It's great for synthesizing feedback, prototyping, and the mundane parts of implementation. But shipping the wrong thing 10x faster is still the wrong thing, and code is a liability. Every line I don't understand is a line I'll have to maintain forever.
• Communicate directly. Start with the why: I do better work when I know why something is needed, not just what. I'm an inbox-zero practitioner, so if you message me, I'll respond. My calendar is always current: if it says I'm free, I can meet.
• Collaborate in the open. I prefer working together in realtime over passing handoffs back and forth. Decisions get made faster by pairing on a prototype than by mailing a spec around. I learn in the open so anyone can give feedback or learn too.
• Improve as I go. I try to leave things better than I found them, whether that's fixing the docs I just read, cleaning up nearby code, or sharing a better mental model in a review. Small improvements compound. When I join a team, I focus on learning how things work and earning trust first, then proposing changes — not showing up with a list of fixes on day one.

My strengths

• I'm receptive to feedback and apply it fast. Critical feedback is the clearest signal I have for how to get better. You shouldn't see me get defensive, and you'll rarely see me make the same mistake twice.
• I don't take things personally. My work isn't my identity. It's a snapshot of my current skill and understanding, both of which improve with feedback.
• I do what I say. A high do-vs-say ratio is how trust gets built. If I commit to something, I'll deliver it or renegotiate early, never go quiet and miss it.
• I'm relentlessly curious and proactive. How do things work? Why are they this way? What would it take to change them? I'd rather set the tempo than wait to be told what to do.

My weaknesses

• I think in systems, which means I can over-generalize a specific situation. My mind is always looking for patterns, but some situations are just unique.
• My real-time answers to hard questions are low quality. I'm more susceptible to cognitive biases under time pressure (most people are). Give me a bit of time and I'll come back with something much better.
• I can overcommit, especially on a new team where I want to build trust and make a good impression. To counter it, I'm deliberately starting small, saying "not now" more often, and ramping up the yeses while keeping my quality bar.

And I hate blind spots, the weaknesses I'm not yet aware of. If you spot one, please tell me.

How to give me feedback

Early, often, and bluntly. There's no such thing as "negative" feedback to me. All of it is useful. The channel (Slack, email, face-to-face) is up to you; I'll probably follow up in person to learn more. These are my preferences, though, and I know others don't all share them, so I try to be thoughtful about how I give feedback to you.

And on that note, what feedback do you have about this README?