In 2009, I was a twenty-year-old kid from Detroit writing PHP for a regional insurance company. My desk was in a basement. My senior developer had been at the company for nineteen years and still printed out code changes to review on paper. I thought I had chosen the right career. I had no idea what I'd actually signed up for.
Sixteen years later, I run Ryshe. We build software that matters to the people who use it. We have a small team of people I respect deeply. We're profitable. I work on things I care about with people I genuinely like. By any measure I would have articulated at twenty, I've made it.
What I want to do in this piece — and what I've been putting off writing for about two years — is be honest about how that happened. Not the LinkedIn version. The real version. The version with the embarrassing decisions and the burnout and the stretches of time when I had no idea what I was doing and was terrified someone would notice.
Most career retrospectives are written from a place of security, which makes them safe and therefore useless. So I'm going to try to write this from the perspective of the person I actually was at each stage — the uncertainty included.
But First: What Didn't Matter
Before I get to what did matter, let me clear some brush.
Your choice of framework didn't matter. I've been deep in Rails, then AngularJS, then React, then Vue, then back to React, and now I spend half my time in Next.js with a TypeScript stack. Every one of those was the "right" choice at the time. None of them determined my trajectory. The people who agonize over choosing the right tech stack are usually avoiding the harder decision of actually building and shipping something.
Your degree didn't matter. I have one. I know brilliant engineers who don't. I know mediocre engineers with PhDs from schools you'd recognize. The correlation is weak to nonexistent in my experience.
The brand names on your resume mostly didn't matter. Yes, certain logos open certain doors. But doors are just the beginning — what happens once you're through them is entirely about who you are, not what's on your badge.
Okay. Here's what actually mattered.
1. Learning to Say No
This is first because it took me the longest to learn, and the cost of not knowing it was the highest.
I spent the first eight years of my career being relentlessly agreeable. Not because I'm naturally a pushover — I'm not — but because I'd internalized a belief that saying yes to everything was the path to career advancement. Take the extra project. Stay late. Pick up the slack. Be the person who never lets anything drop.
What I was actually doing was training people to see me as a resource rather than a person. And I was spending my finite creative and cognitive capacity on a thousand things that didn't matter at the expense of the handful that did.
The inflection point was brutal. In 2017, I was engineering lead at a mid-sized SaaS company, managing eleven people, running two projects simultaneously, and consulting on a third on the side. My doctor told me my cortisol levels were abnormal. I was sleeping five hours a night and calling it discipline. One morning I sat in my car in the parking garage for thirty minutes because I genuinely could not make myself go inside.
That was burnout. Real, physiological burnout — not the word people use when they're tired. And it forced a reckoning I'd been avoiding for years.
The practice of saying no is not about being difficult or disengaged. It's about being accurate. It's recognizing that your time and attention are finite, that committing to something you can't do well is a disservice to everyone involved, and that the most respected people I know in this industry are remarkably consistent about what they will and won't take on.
Since I learned to say no — really learned it, not just intellectually agreed with the concept — I've done better work on fewer things. The quality gap is not subtle.
Saying yes to the wrong things is not generosity. It's a slow drain on everyone who's counting on you to show up fully for the right ones.
2. People Over Technology
Here's a thing that is obviously true and that almost no one actually believes: the technology is almost never the hard part.
I don't mean that technology is easy. I mean that the limiting constraint on every meaningful project I've been part of has been human — alignment, communication, trust, motivation, conflict — not technical. The projects that failed didn't fail because we chose the wrong database. They failed because two senior people couldn't get in the same room and agree on the goal. Or because one person's ego was more important to them than the outcome. Or because nobody was willing to have an uncomfortable conversation until the deadline had already passed.
I learned this at about year five, when I watched a technically brilliant system get shipped to zero users because the product and engineering leads hadn't spoken meaningfully in four months. The software worked. The relationship didn't. The outcome was the same as if the software had never been built.
Since then, I've made a practice of treating relationship maintenance as a first-class engineering concern. I do one-on-ones religiously. I have hard conversations early — not because I enjoy them (I don't), but because the cost of delay compounds faster than technical debt. I try to understand what people actually want from their work, not just what I need from them.
This became the core principle behind how I built the team at Ryshe. We're small deliberately. I know everyone I work with. I know what motivates them, what frustrates them, and what they're trying to build toward in their careers. Not because I'm a particularly empathetic person by nature — I'm not — but because I've learned, through repeated costly experience, that knowing this is prerequisite to building anything that lasts.
Hire for character, train for skill, and never let a broken working relationship fester under the false premise that everyone is "being professional." Professionalism does not fix misalignment. Honest conversation does.
3. Shipping Beats Perfection
I am, by disposition, a finisher. I care about details. I re-read my own code. I think about edge cases. These are useful traits in an engineer and constant enemies of a founder.
The version of this lesson that's usually shared is some variation of "done is better than perfect," which is true but not quite precise enough to be actionable. The more accurate version is this: user feedback on real software is worth infinitely more than internal certainty about hypothetical software.
I have lost count of the number of times I've been convinced that a feature was necessary — convinced enough to argue for it in planning, to design it carefully, to build it well — only to discover that users either didn't want it, didn't understand it, or wanted something adjacent but meaningfully different. The only way to find out is to ship it.
The corollary is equally important: shipping fast requires excellent taste about what to ship. Speed without taste produces noise. The discipline is learning to distinguish between the details that matter to users (ship those carefully) and the details that matter only to your internal sense of quality (timebox those or cut them entirely).
At Ryshe, we've adopted a rule: any feature that can be built in a week should be shipped at the end of that week, to real users, regardless of how it feels internally. Not half-built — genuinely usable, genuinely in front of people who might care. The discomfort of that timeline is a feature. It forces clarity about what actually needs to be in v1 and what is you hedging against user judgment.
4. Compounding Skills
This is the one that the internet talks about the most, which means it's both the most understood intellectually and the least practiced in reality.
The idea is simple: skills compound. An hour of learning today is worth more than an hour of learning in five years, because today's learning has five years to be applied, adapted, and built upon. The implication is that the choice of what to learn matters enormously — not just for where it gets you this year, but for what it makes possible in year ten.
When I look back at my career, the learning investments that paid off most weren't the ones that were most obviously useful at the time. Learning to write well — really write, not just document — returned value continuously in ways I never predicted: in proposals, in emails that persuaded, in a voice that made people trust what I was saying. Learning basic accounting and financial modeling when I had no business doing so (pun intended) became essential when I had to make decisions about Ryshe's runway and growth. Learning to give a presentation to a room full of people when I was deeply uncomfortable doing so unlocked client relationships that became our first meaningful revenue.
The skills that compound most reliably are not the ones on the job description. They're the meta-skills: communication, clear thinking under uncertainty, the ability to learn new things quickly, the capacity to build trust with strangers. Every domain-specific skill you ever develop sits on top of those foundations.
My practice: I allocate four hours per week to deliberate learning — not catching up on industry news, not watching conference talks passively, but active learning on something I don't yet know well. I've kept this practice through funding crunches, through product crises, through the chaos of the early Ryshe years. It is the single habit I'm most protective of.
5. Building Something You Own
This one is the most personal, and I debated including it because I don't want it to read as a pitch for entrepreneurship. It's not. Plenty of people build long, meaningful careers without starting companies, and I have enormous respect for deep craft practiced inside organizations built by others.
What I mean by "building something you own" is more fundamental than equity or legal ownership. It's about the difference between executing on someone else's vision and taking genuine creative responsibility for something.
For the first eight years of my career, I was a very good executor. I built things other people had imagined. I did it skillfully and I was rewarded for it. But I noticed that my best work always happened when I felt genuine ownership — when the problem was mine, not just assigned to me. When the solution wasn't prescribed but discovered. When the outcome mattered to me personally, not just professionally.
That feeling is what drove me to eventually start Ryshe. Detroit shaped a lot of that — growing up in a city that had been abandoned by the institutions that were supposed to sustain it, I'd watched what happened when people waited for someone else to build the future for them. The answer was: nothing good. The people who made things better were the ones who stopped waiting.
Starting Ryshe was terrifying in the specific way that only "this might fail and it will be entirely my fault" can be terrifying. The first year was a masterclass in all the things I didn't know. But the ownership — the direct connection between my choices and the outcomes — produced a quality of engagement I had never found working for someone else.
You don't have to start a company to find this. Open source projects, writing, mentorship programs, internal initiatives that you champion past the point where anyone else would — all of these can carry genuine ownership if you let them. The question is whether you treat them as assignments or as yours.
The Thread Through All of It
Reading back through these five things, I notice a common thread that I didn't intend but that makes sense: they're all about taking responsibility. Saying no is taking responsibility for your attention. Prioritizing people is taking responsibility for the conditions that make work possible. Shipping is taking responsibility for learning from reality rather than hiding in planning. Compounding skills is taking responsibility for your future capability. Building something you own is taking responsibility for the outcome.
There's a version of a tech career that is entirely about reducing your exposure to responsibility — specializing narrowly, never making the call, always having someone above you to defer to. That path is safe and it is real and there are people who thrive in it. I tried it for a while. It made me slow and small in ways I didn't notice until I'd been doing it long enough that the slowness felt normal.
The path that has worked for me is the opposite. More responsibility, taken earlier, held more directly than is comfortable. The discomfort is not a bug. It's the signal that you're operating at the edge of your current capability, which is the only place growth actually happens.
Sixteen years in, I'm still uncomfortable most of the time. I've just learned to read that discomfort differently. It doesn't mean I'm failing. It means I'm still going.
If you're early in your career and reading this hoping for a shortcut: there isn't one. But the path is knowable. Start with the thing that scares you most. Take responsibility for the outcome. Learn continuously, especially in the domains that feel unrelated to your current job. Be ruthless about who gets your best hours. And ship something — anything — that is genuinely yours.
That's it. Sixteen years, five things. Everything else was noise.