I recently had a client lower their monthly services with us, and some of the financial modeling work has slowed. But on the positive side, I also had an existing client ask to expand their services with us and sign a monthly retainer. We have a proposal out for driving a leadership offsite, and we have other one-off projects in development. Anna and I have independently been invited to give talks later this year.
All that’s to say that this business won’t be a smooth climb up - we'll have our ups and downs - but we continue to do quality work for clients across a broad set of domains, and things are happening. I’m optimistic about the future, and we should be able to 4x revenue this year versus last year.
I have two big focuses right now: 1 - Business Development. Building partnerships, and selling to accounting firms and private equity portfolio companies is top of mind. 2 - Financial Modeling Capacity. Even if it’s slowed, I know this work is out there, so I need to find more capacity.
For the first, I’m working with existing clients, and I’m being much more intentional about systematizing our efforts to close net-new, non-partnership clients. Two more meaty clients like we have today is my near-term goal.
For the second, I’ve engaged a recruiting firm in South America and we’ve started interviewing.
In other news, I’ve built my second little app with Claude. I realized that I was spending a lot of time prepping my meetings for the week.
To start the week, I create daily notes in Obsidian, then I look at my calendar for each day, then I manually add my calendar events to each day in Obsidian - timestamp, date, and rough title. During the week, I create each meeting note and add metadata at the top; date, attendees, project codes. It’s simple and straightforward - but there’s no reason a computer program couldn’t do that work.
So, I fired up Claude Code, and got started. 45 minutes later, I had the pipeline working. From my terminal here on the Mac it would go look at all of my calendars, filter out certain events, create the daily pages in Obsidian, then create all the individual meeting notes for the week with metadata applied. Boom, just like that! It was almost as fast to build the app as it was to do it manually for one week. And I do this every week. That's 26+ hours a year I just got back.
What I haven’t done yet is actually turn it loose on my Obsidian vault. I wouldn’t want a bug in the program to accidentally delete other files. For now, the files go to a sandbox, and I and move the files over to my vault from there manually.
With two of these software projects done, I’ve generated a lot more confidence about what’s possible. It makes me more aware of problems I could solve with software, and how I can actually get something into production.
Please share what you’ve built! Email heykev@kevinnoble.xyz and tell me about your experience.
Kevin
A Quote
“
Leadership is mind-set and action dependent, not position dependent. You don’t need to manage anyone to be a leader. Conversely, you can manage thousands of people and not be a leader at all. It all depends on what you do! Do you figure out what you believe as if you were an owner, and do you act on those beliefs? Do you focus on adding value to others? You don’t need to have a specific title, position, or equity stake in order to do this. You don’t need a written invitation.
— "What You Really Need to Lead" by Robert Steven Kaplan
Paul describing meeting uncontacted tribes in Amazon was pretty crazy. And while this is a good podcast, it was even better in video form as Paul showed videos from those encounters. Also, there’s the young girl snacking on monkey face. It goes to show that what’s “normal” is relative.
How did I get to age 45 and not know there’s an immortal animal on this earth? It’s kind of like that “Ship of Theseus,” where parts of the ship are replaced over time. Is it the same ship? Is this the same jellyfish? Will humans ever benefit from this?
(please enjoy this 6️⃣ minute read)
Deep Dive on the Responsibility Liability
The leaders who care most about responsibility are often the ones most at risk of accidentally destroying it in others.
I know this because I’ve lived on both sides of it. I consider myself highly responsible, and I've accidentally removed agency in my team. I've also worked for leaders who have done the same to me.
Think about what draws people to leadership in the first place. For a lot of us, it’s a strong sense of responsibility. We care. We follow through. We don’t let things fall through the cracks. We get things done.
That’s a genuine strength. And it can also be a liability.
When you’re someone who cares deeply and executes reliably, the natural instinct - especially under pressure - is to take it on themselves. Someone drops the ball? You pick it up. A decision is unclear? You make the call. A team member is struggling? You jump in.
Pickin' up all the dropped balls.
Every one of those actions feels like leadership. In the short term, it is. Things get done. Fires get put out.
Something troubling emerges when this is done over time. People stop bringing their A-game because they’ve learned, implicitly, that you’ll cover for them. Decisions slow down when you’re not in the room. Your team becomes dependent on your energy instead of generating their own.
You’re the bottleneck, and the business can’t move or grow any faster than you.
The Diagnostic
How do you know if your strength in responsibility has become a liability? There are three signals worth paying attention to.
Signal 1: Problems travel up the org. In a healthy system, each person is put to their highest best use. You solve only the problems you need to solve. Your leaders solve theirs, and so on. In an unhealthy system, a large percentage of the problems travel up to you. Your team could solve them, and they probably want to, but you’ve created a system where that doesn’t happen.
If your team regularly asks, “What should we do?” - and you answer! - you’ve trained them to outsource their thinking to you. You’re doing their cognitive work for them.
Signal 2: Your absence is disproportionately disruptive. Every leader matters to their team. But if things genuinely stall when you’re out, that’s not a sign of your importance. It’s a sign of a dependency you’ve built. In that setup your team only moves as fast as you do, when they’re supposed to be adding to your velocity.
Signal 3: You’re frustrated by people who don’t have your urgency, but you’re also the one they wait for. This one’s uncomfortable, but worth sitting with. If you find yourself frustrated that others won’t own things, and yet those same people have learned that you’ll step in when things get hard - you may have created the very dynamic you’re complaining about.
Answer that question as a systems architect, and investigate your own mindset. How am I preventing people from taking ownership? What are the incentives and goals? How are people measured and rewarded? What is punished? That’s the system you built, and you can fix it.
Why This Happens to High-Responsibility Leaders
When you have a strong value for responsibility, taking ownership feels right. It’s part of your identity. Letting something slide can feel like you’re abandoning your values.
But there’s a difference between owning outcomes and owning every decision along the way.
You can be deeply accountable for results while deliberately not making every call. In fact, that might be the better definition of leadership at scale. Your job isn’t to have all the answers. Your job is to design a system where the right answers are created, by the right people, without you in the room.
L. David Marquet (via Simon Sinek's “Leaders Eat Last”) put it this way: “The goal of a leader is to give no orders. Leaders are to provide direction and intent and allow others to figure out what to do and how to get there.”
I love that definition. That’s responsibility, but for the conditions, not the content.
From Owning Tasks to Owning the System
This reframe is the core pivot.
When something goes wrong, the high-responsibility leader’s instinct is: I need to handle this. The systems-oriented leader asks: Why did the system produce this result, and how do I design it differently?
The questions change, too. You start asking: - Do people on this team have the context they need to make decisions without me? - Is the process documented? - How have I set up the decision methodology? Can I move authority to information? - Are the incentives set up so that owning problems feels rewarding, not risky? - Do I come out of meetings with action items I should be giving away?
That last one is worth dwelling on. If you’re a high-responsibility person, you probably love a good action item. You get to put it on your to-do list - and then more importantly, you get to check it off when you’re done. So gratifying!
But someone who expands the capacity of the people around them is intentional about not being the one who leaves meetings carrying the load.
You need to let other people carry the weight. That’s how they get stronger. They’ll learn more by doing, and being accountable for the outcome, than by being around while you do it.
The Golden Mean
This isn’t an argument for becoming hands-off or disengaged. That’s a different failure mode entirely.
The leader who abdicates in the name of “empowerment” isn’t doing anyone any favors. Neither is the one who gives vague direction and expects people to figure it out without sufficient support.
You’ve got to find the golden mean between not giving your team any load and doing it all without you.
Think of it like exercise. If you never let your muscles do any real work, they atrophy. But if you drop a 400-pound bar on someone who isn’t ready for it, you’ve crushed them, not helped them.
I don't think they're ready.
The art is in progressive load; giving people real ownership and letting them discover what they’re capable of, but doing so with support so they don't break along the way.
That’s how you increase capability in the team over time, because you’re investing in building it instead of substituting for its absence.
Speed and the Cost of Failure
There are times when you should NOT give the load to your team.
If the deadline for something is immediate and your team doesn’t have the inherent ability, don’t set them up for failure by having them complete the task. That’s unfair to them, and unfair to whoever is depending on you downstream of this work.
Relatedly, when the cost of failure is really high, and the team hasn’t shown they’re ready, don’t have them take the load. That’s why you don’t put the new guy in charge of safety on a manned space flight.
The intern isn't ready for this kind of responsibility.
But be careful on both of these. Knowing there are times when you should do the work means that you may convince yourself these two situation are present more often than not. You’ll say “We don’t have time” or “the cost of failure is too high.” The times when those conditions are true are rare, so if you find yourself making these excuses, pause and reflect.
Bringing It Together
Taking ownership is seductive because it looks like leadership. Things get done. You follow through. You’re reliable.
But if you’re the one making all the calls, picking up all the dropped balls, and being the answer to every question, then you’re not leading, you’re substituting. And the team you leave behind when you move on, or move up, won’t be ready to function without you.
This isn’t about caring less, it’s about redirecting your ownership instincts.
Instead of owning tasks, owning decisions, and being the answer - own the system, own the clarity that makes decisions easier for others, and be the person who develops people’s ability to find the answer.
Sheryl Sandberg (via “The 4 Disciplines of Execution”) said it well: “Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.”
You want your team to be fine while you’re on vacation. You want them to be successful and step up when you get the promotion.
Call to Action
Pick one recurring situation where you’re the default solver this week. Maybe it’s a recurring question your team brings to you. Maybe it’s a type of decision that always lands on your desk.
When it comes up, don’t solve it. Instead, ask your team to solve it: “What do you think we should do?” And then hold the discomfort of letting your team own the answer, even if their answer isn’t exactly the one you’d give.
The more you practice supporting the team's ability to execute, the better you’ll get at building the thing that actually scales: a team that doesn’t need you to carry all the load.
Kevin
PS - This is a topic near and dear to my heart. If you've struggled with taking on too much responsibility, let me know about it. Email me at heykev@kevinnoble.xyz.
