Why You’re Getting Overloaded

Just as with the CT-No situation, when you always provide the same answer—be it a positive or a negative one—no one really needs to ask, right? The reason we need leaders is judgment. If your answer is always yes or always no, you’ve removed judgment from the job. When you see the team is constantly bombarded with requests, at least part of the blame lies with you.

Tech leaders in these situations often describe feeling continuously overwhelmed by requests. The CEO or whoever else keeps asking for more and more, no matter how much they’ve already agreed to take on. When viewed simplistically, CTOs often take this behavior to mean they’re not seen, unappreciated, or taken for granted. From there, the road to burnout is very short.

But we have to consider others’ points of view. In many chaotic startup environments, it’s only the squeaky wheels that get noticed. If you never set boundaries, people aren’t likely to stop asking for more spontaneously. In an industry where many are struggling, if your organization is having a hard time but hasn’t reached the breaking point yet, the challenge is usually not visible from the outside.

Would you stop asking for more of a good thing if you’re never presented with the price or consequences?

Effectively Drawing the Line

The solution is not to become more negative. It is to make the cost of every “yes” visible. It might be easier in some contexts and less so in others. For example, often people I work with find it easier to start by setting better boundaries internally in their organization before pushing back on external requests. Regardless of where you start, there are a few key things to keep in mind.

First of all, don’t explode out of nowhere. I mean, surely from where you’re sitting, it isn’t “out of nowhere,” but it’s probably going to look like that to the others. After all, you’ve allowed the situation to be like this for a while. Helping the organization change course will naturally require some time.

Don’t be afraid to tell the truth. Leaders who are worried about stating a clear goal cannot expect to make much progress. If you cannot say the amount of work requested for the next iteration is surely too much, you’re setting your team up to fail. Sometimes there’s a fear of being seen as whining or a “downer.” But if you focus on observations and less on complaining, you should come across better.

I’ll say that there are those people who will actually frown upon tech leaders who are just trying to set proper and sane boundaries. If that’s the case, trying to “suck it up” will only delay the issue. Either you’ll speak up and be treated as a genuine leader, or you’re wasting your time.

Don’t abuse your powers. The easy path when you feel overwhelmed is to set boundaries harshly, leveraging your position as the tech leader. If the CTO says something is plainly impossible or will require six months at a minimum, it might achieve the short-term goal of reducing the load. However, if that claim was an exaggeration just because it’s possible to do so, trust will be lost.

State clearly your observations and assumptions. Explain your certainty about the situation. Boundaries are a lot easier to get across when the other party understands the gravity of the situation.

Establish your principles. It doesn’t matter if you’re not a founder. You should know your boundaries and what sort of leader you’d like to be. Thus, you can decide that you won’t enable behavior like demanding overtime or working weekends solely to eke out some more work that could’ve waited.

Always try to discuss the range of possibilities. Most of the time, we’re not deciding about something truly binary, where the answer is a clear-cut yes/no. When you’re asked to do something, try to come up with several approaches of varying costs, time, value, etc. That reduces the chances of being seen as a gatekeeper who always says no. It is also the healthy move in general to ensure we maximize impact per engineer: don’t just accept requests without ensuring you understand them and agree about the best way to approach the goal.

Boundaries are not something you announce once and then admire from a distance. They are operational hygiene. Every week, every roadmap discussion, every “quick ask,” every executive escalation either reinforces them or erodes them.

If you never show the price of yes, don’t be surprised when the company keeps buying.

The Trap of Getting Good at Emergencies

Organizations that get really good at firefighting build an identity around it. There are those seniors who always act as fast responders. The leaders who are expected to save the day. Mastery of emergencies is a sophisticated way to avoid the harder question: why do they keep happening?

We’re optimizing the wrong part of the process.

The praise-seeking (or, at the very least, praise-accepting) loop keeps leaders stuck in reactive mode. Getting better at handling crises is not the same as getting better at leading.

DRY for Leadership

The pattern we want to break is a simple one: solving the same problem repeatedly, just with incrementally better tools. Don’t keep building fancier extinguishers, but find out who keeps throwing around lit cigarettes!

As engineers, we parroted the importance of DRY (don’t repeat yourself) in the code, but what about demanding that same professionalism when tackling organizational issues? Invest in root-cause thinking and post-mortems that actually change something. Recurring crises are a system failure, not a streak of bad luck. You ought not view it as destiny, but realize you have the ability to make things better.

Move Upstream in the Decision Pipeline

Another type of firefighting isn’t the outage/bug that needs handling, but that you keep getting surprised because you’re downstream of where decisions get made. The fix is twofold: move yourself upstream, and bring your team closer to the shaping process.

As a leader, you ought to get involved earlier in the shaping the roadmap and in forming the strategy. That planning is where every issue discovered requires a tenth of the effort to handle.

With your team, moving upstream is about collaborating on the “shaping” of the work. Don’t wait to be given tasks that are already decided, but work hand-in-hand with Product to help define the scope of the work. Surprises aren’t inevitable; they’re a structural symptom of where you sit in the flow.

Build Margin Into the Regular Week

If the only mode for tackling systemic issues is “pull the andon cord,” you’re doomed to have each issue become a big, hairy mess. Sustainable teams carry enough slack that non-urgent but important work gets done alongside regular delivery. It should not be limited to crisis response.

Margin is a design choice of sustainable leadership, and not something you should view as a luxury. Your mindset should be one of fire prevention as part of the regular week, not a stop-the-presses move to handle raging fires once they’re already out of control.

Closing

Every time you’re proud of how fast you responded, ask whether you’re just making the dysfunction more comfortable to live with. That’s not for self-flagellation. It’s the mindset shift that moves you from reactive operator to actual leader.

Auto-pigeonholing is the tendency to preemptively shrink one’s scope at work, in our case, particularly the senior tech leaders. Done not because anyone told them to, but because they told themselves to. Either way, it’s wrong.

Where It Comes From

There are various reasons leaders convince themselves to pigeonhole. First, there’s the courtesy mistake. That’s when they think that by becoming involved in other areas of the company, they will be stepping on others’ toes. This is misreading respect for others as self-erasure.

Then we have the impostor whisper: “I can’t, I just know tech.” Treating anything that’s outside their org as if it were rocket science, whereas I’m pretty sure someone who can discuss debugging a distributed system can understand the sales funnel enough to ask a question or two.

Another reason is the job description trap. When you take your role or your title too literally and assume you’re not supposed to do anything beyond that. Worse, some believe the CEO will reprimand them for doing so.

The Rebuttals

Tech is now everywhere. It’s no longer solely about developing the product itself. It’s how every function operates. The tech leader who only thinks about the product is like deciding to only use the right side of the chessboard. When you’re becoming aware of what’s happening all over the company, you can help utilize technology better, or come up with approaches and suggestions to help the other departments achieve their goals. It also means you’ll be able to prepare your team better, because you’ll understand what’s happening all around, as opposed to merely following orders.

Moreover, your outsider status is a feature, not a bug. Yeah, you’re not a sales expert. That means that you see things differently. You ask different questions. You’re not limited by the assumptions of that domain. That’s valuable, if you choose to use it. You can suggest things others wouldn’t consider, and your common sense filter is tuned differently. Your fresh perspective is actually an advantage.

Lastly, you can’t organize deck chairs while the ship sinks. If the rest of the company is struggling, your excellent R&D org won’t save you. It’s more than merely your right to engage. It’s your responsibility as an executive. Of course, you cannot fix everything in the company, but when you decide to stick your head in the sand and stop trying, you might as well look for a different job.

You’re not a tech person who sits at the executive table. You’re an executive who happens to have a deep technical background. That background is an asset across the whole company, not a fence that marks your property or where you’re allowed to go.

Tech leaders grow faster when they stop waiting for permission to care about the whole business.

Note: You can find the previous two parts here: Communication and Measuring Engineering.

Inherent Friction

The tension is here to stay. The fact that it exists isn’t a dysfunction. Actually, its absence usually is. The CEO’s job is to chase opportunity. The CTO’s job is to protect the system that delivers on it. The mistake is treating the tension as a problem to eliminate rather than a dynamic to manage well.

While it often gets too extreme and is one of the main causes for problematic relationships between CEOs and CTOs, it can also be a useful tool. In fact, it can become the basis for healthy prioritization, but it requires stopping the failure modes.

The Two Failure Modes

Two lazy CTO responses make this tension worse.

The Wall: “We can’t, the version is locked.” Process as a shield. You might feel like you’re doing the principled thing, but it usually reads as obstruction. A CTO who’s always seen as opposed to what the business wants to do.

The Doormat: “Sure, we’ll figure it out.” Buys peace today, burns trust (and the team) tomorrow. It’s not effective, and doesn’t utilize your leadership abilities. And, often, it just leads the team to utter failure.

Both approaches are often people’s default stances; they follow them almost without thinking—even when they might be telling themselves otherwise. And when that’s the case, when your reactions are so obvious ahead of time that people know they don’t even have to ask you, what are you there for? It doesn’t matter whether you always say “yes” or “no”; if you always say the same thing, you’re redundant. Both are abdications. You can do better.

Understand Their POV

As annoying or stressful as it might be, your CEO isn’t asking for more things just for the heck of it. I’ve yet to come across a founder who was thinking, “let’s see how much work we can stack on their backs before they finally snap.”

They’re doing what they think is the right thing. They want to get more work done because they see the business need, or have their own stressful issues to handle. They often also don’t have enough understanding, and many think that applying more pressure from their end is needed to ensure that the team doesn’t slack off (even without attributing any malice to the team). You’re all in the same boat.

Conversation Tactics

Speak in tradeoffs, not verdicts. Replace yes/no with “if we do X, then Y slips / Z gets cut / quality on W drops.” Make the cost visible instead of making yourself the villain.

Speak in spectrums. Almost nothing is binary. The answer to a request doesn’t have to be a simple yes or no. Can a stripped-down version ship now, and the full thing land next sprint? CEOs often want the signal of progress more than the full feature.

Don’t buffer. Padding estimates “just in case” insults the CEO’s intelligence and erodes your credibility when they find out (they always find out). Give honest numbers and honest ranges. That’s not to say that you cannot gain some wiggle room. But that needs to be done in the open, and not hidden behind estimates. Aim to not allocate 100% of the team’s capacity, knowing full well that something will crop up.

Ask to break work into small chunks. The smaller your units of work, the cheaper it is to change direction. Long monolithic efforts are what make every reprioritization feel like a catastrophe. Agility is a function of batch size. Yes, ideally, you wouldn’t have to change plans in the middle of a two-week sprint. But if you had to, wouldn’t it be better to at least be able to do it without losing what you were already working on?

Go Upstream

Conversation tactics only get you so far. Find where decisions actually get made. If the CEO is committing things to clients in sales calls without you, no amount of clever framing in the meeting room will save you. The fight you’re having is downstream of a process you haven’t fixed.

Make commitment-making a shared act. You don’t want to be the veto, but it would be nice to be present. You want to be in the room when promises are formed, not when they’re delivered to you as fact. That will help you understand where it’s coming from, what exactly is needed by the client, and come up with the best approach to tackle it. It also helps ensure you won’t be surprised by things that were decided but only communicated to your team too late.

Get an Outside Read

The uncomfortable possibility: you might both be wrong, in opposite directions. Sometimes the CEO’s expectations are genuinely unreal. Maybe it’s anchored on competitor PR, outdated past experiences, or pure wishful thinking.

Sometimes the CTO has slowly acclimated to a sluggish rhythm and doesn’t even notice anymore. You’re breathing your own exhaust on velocity.

An outside perspective (a peer CTO, a coach, a board member who’s seen other engineering orgs) is often the best way to realize whether there’s a bias one way or the other.

The Work

In closing, the friction isn’t a sign that something is wrong. If you feel that it’s a fight, then that’s a problem and means the relationship might be breaking.

Bring it back to the therapy frame from the series.

You should be disagreeing, or pushing back, thoughtfully: with shared language, shared visibility, and the humility to check whether your own calibration has drifted.

No wonder. How can they be creative? Creativity requires two things that are often lacking in modern teams: safety and inspiration.

Creativity is critical, especially nowadays, when the lines of code are surely no longer the bottleneck; it’s about the ingenuity your team brings to the table. That’s what’s going to create moats and make all the difference. What do safety and inspiration mean in this context, and how can you provide your team with them?

Safety

In general, when people don’t feel like they can risk it, they aren’t likely to try anything innovative. After all, they want to succeed in their work, and thus, if they’re worried about something not working out, they’re more likely to stick with the regular way of doing things. Will you take a different route to work, that might be faster or just more interesting, if you’re afraid of getting there late? No, you’ll let your autopilot kick in and take the same one you always do.

If you want more creativity, you need to deliberately create the safety it entails. To start, be clear with your team about your expectations. They should know some experimentation is expected and that you understand it could mean things taking longer (or not working at all). Regularly add enough wiggle room from time to time in the things you’re working on so that people can have the ability to play around.

For example, you can have intermissions (the subject of the free sample chapter of my book that you can find here), or just regular experimentation baked into the work from time to time. When someone has an idea for an experiment, you discuss it and decide whether to add the extra time for the task or not, which can also be time blocked to ensure it doesn’t get too deep.

Inspiration

The other half is about the team actually having ideas for experiments. If you have ever looked into the history of the Renaissance, you have seen how a lot of the inspiration they got was from acute observation of the world. Studying ancient works. Experimenting. All that supplied artists with inspiration and helped them come up with all those works of art.

You need to ensure your team is not breathing its own exhaust. They need to regularly learn new things and get exposure to new concepts and different ways of doing things. If you value creativity, you should prioritize it, like ensuring that you don’t hire solely people from the same “pools” and have diversity. I’ve seen teams that were too homogenous when it came to people’s backgrounds, and thus were all alumni of the same company or university, and were all thinking similarly. Rather than having many minds with different ideas, they created echo chambers.

Have budgets for conferences. Encourage people to participate in meetups and communities. Schedule internal tech talks every couple of weeks and give people time to prepare interesting stuff.

Creativity doesn’t happen in a vacuum. We need to be exposed to things that inspire us and then have the time to tinker and play around.

It Doesn’t Have to Be Like That

Often, leaders tell me they feel they just don’t have the time to take action on all these fronts, and in the meanwhile things keep moving forward (or downward). That’s an excuse. Virtually every team I’ve worked with could find wiggle room through creative thinking, tech capital, or honest conversations with product.

It’s crucial that you snap out of it and start taking action. If not, you’re making things worse, because while you’re paralyzed planning, you’re still digging the hole deeper. Eventually, no ladder will be enough.

Phase 1: Stop Digging

Before you can cover your debt, of any kind, make sure it’s not getting worse. Look at what currently sucks and ask: how do we at least stop making this worse? For example, I talked to a VPE who kept equivocating about how to tackle their mountain of untested code. That’s indeed a big issue to solve, but in the meantime, how about deciding that no new code will be committed without tests? He was waiting for the “perfect solution”, de facto letting things deteriorate.

Another example could be a team suffering from knowledge centralized in a handful of seniors. Yeah, ultimately, you want to spread out their knowledge across the team, but ensure it doesn’t continue like that! Every new initiative involves others from day one, ideally as owners. This is about changing the trajectory from declining to holding steady.

Phase 2: Flipping Momentum

Now, hopefully, things are stable. You’re at “break even.” You can decide to tackle things incrementally. Whereas sometimes you might have an issue that you can allocate a couple of days to tackle and get rid of, most things are not that simple.

Start enabling small upgrades and leaps forward to address those long-standing issues. Lots of untested code? The previous phase was about ensuring new code is tested; now you can make it a habit to add a few basic tests whenever someone touches an old file. Hero senior engineers? Start enforcing pairing on their work and teaching them to explain what’s to be done rather than doing it themselves.

Again, don’t get stuck in analysis paralysis here. Create an inventory of the things on your plate and backlog it. Map the different constraints and current costs, and just choose something. Don’t agonize over the perfect path; it’s better to start gaining momentum. Even saving whoever is doing on-call five minutes every morning because AI will skim the night logs for them counts.

Not Sexy

Most of these aren’t sexy or shiny. They’re not the tasks teams are excited about. Yet they’re necessary, and don’t require too much work. Assuming you cannot take concentrated weeks to address it, this is the path forward. In addition, it will also help your team regain ownership, agency, and feel proud in its craft again. This is especially important for cases where the team feels somewhat disassociated with the existing codebase or past decisions.

Also, this is about cultural change. Whatever hole you found yourself in is one your team has been digging for a while. To make a lasting change in how the team acts, it’s sometimes beneficial to spread the work so that everyone gets exposed to the wanted behavior over time and has enough opportunity to digest it.

An impossible situation can look 180° different within 6 months. Do you want to spend the next year lamenting that it’ll take you months, or do you want to get to it?

Why Leaders Resist

Having worked with leaders on dramatically improving their teams, I’ve seen how often you might be doing all the work yet not getting it noticed. That’s because it’s challenging work to change people’s existing opinions and views of your organization. When I say they need to do some PR, they have an ego barrier.

Politics feels wrong or dirty. As if it’s something that only sleazy people do. But this isn’t self-promotion or ego stroking. It’s expanding your organization’s ceiling of influence. A reputation ceiling limits what your team can actually do. People won’t trust you with projects beyond that perception. You’re literally capped. This “political” effort is for the company’s benefit, not your personal gains. Not doing it for whatever reasons you make up in your mind is almost negligent.

I know this mindset shift isn’t something that can always be “cured” in two paragraphs, but what we covered here is essentially the same conversation I have with clients when this happens, condensed from an hour to a few sentences. If you need the longer version, reach out!

Assuming that’s settled, let’s go over the tactics that have worked with my clients for effective reputation makeovers.

Pull People In

You might be thinking that if you’re doing the job well enough, you’ll be recognized for it. Maybe, but that takes forever. Don’t wait for them to notice on their own. Invite them into the change. Make them stakeholders.

You want to be vulnerable and plainly address the elephant in the room. Say that you know you’ve had issues and are actively fixing them. Invite them into this process by telling them you’re doing it and asking them to provide you with feedback from the outside.

This does two things at once. They give you real-time feedback to help you improve faster, and they notice the changes immediately because you’ve made them aware. The first bit is trivial, yet the latter might be a surprise. The truth is that by openly talking about it, you’re priming them to be attentive to improvements, much more than they were naturally inclined before. Thus, they will take note of your efforts much earlier, making the reputation improvement require less time.

Close the Loop

When they give feedback, act on it and tell them. A surefire way to make matters worse is to ask them for this feedback and then let it accumulate dust somewhere. Show respect for what they’re telling you. People become deeply invested in things they helped improve. They’ll naturally want to see how their input helped.

By creating an ongoing relationship where they see the seriousness you give to their feedback and how you execute on it, you will see them essentially rooting for you. Not that I’m insinuating they were hoping you fail before, but that there’s still a difference between indifference or frustration and actively cheering you on.

Peer-to-Peer Flywheel

Don’t limit this work to the higher echelons of the company. Have your people talk directly to peers outside the org. This effort shouldn’t require everything flowing up and down through you. Horizontal feedback spreads faster and shows the gospel more widely.

So, for example, consider talking with the team leaders of the most problematic teams about how they can perform the same tactics with their peers in Product or Marketing. Doing so will provide them with more autonomy and ownership of these changes, as well as increase the “surface area,” making many people more aware of the effort.

They’re On Your Side

These steps assume a healthy, supportive relationship across the organization. Even if people have a history of being frustrated with your team’s performance, that doesn’t mean that they’re your enemies. I highly recommend starting with the assumption that everyone’s a potential collaborator. Moreover, these tactics can be used with your boss (e.g., the CEO) as well as with your peers in the executive team.

The payoff? Faster reputation shift plus actually better performance because you’ve got a real-time signal from people who matter.​​​​​​​​​​​​​​​​ Good luck!

How We Get Here

Many tech leaders deprioritize their own well-being, sometimes without even realizing it. Often, consciously or not, we misunderstand the leader’s role as the person who “soaks up” everything unpleasant to “protect” the team. Or the belief that work is supposed to be work. It’s fine that it sucks.

I have a regular opening question with new clients: “Are you having fun?” Routinely, it’s met with laughter, as if fun is an absurd concept for someone in these positions. This becomes your default operating mode. You inculcate yourself to think general suck-iness is just the way things are.

Why That’s Wrong

First, as part of the shift I want to propose in your thinking, let’s start with the egoistic argument: Life’s short. You’re in one of the most privileged roles on earth. Most tech leaders have significant control over their situation. Taking better care of yourself isn’t a fantasy, but a viable and accessible option.

Then, there’s also the performance angle. Leaders who spend months or years with a suffering mindset carry too much cognitive load. Every day is already a struggle, which makes it incredibly hard to come up with strategically ambitious ideas. You can’t think big when you’re barely keeping your head above water.

This naturally leads to more burnout. Martyr leaders burn out faster, meaning that this approach not only doesn’t help them (“I’ll suck it up and enjoy the results later”) but actually leads to their failure because the approach cannot sustain them long enough to reach the goal. They make this big sacrifice for nothing.

And let’s be honest, in most cases, nobody is even acknowledging or rewarding you for this suffering. No one’s giving you credit for being miserable. Its’ a lot of wasted effort for nothing.

What to change

To dig yourself out of this hole and start correcting course, start by giving yourself permission to matter. Acknowledge that your well-being should be a factor in decisions, not tossed aside as an afterthought. Yes, there are other priorities, but you’re allowed to be one of the factors taken into consideration.

You should also tackle systemic pessimism if that’s your default lens on the world (or at least work). You have to grow your executive mindset. Pathological pessimism caps your innovation and energy. Sometimes, to make a change here, the best route is getting some coaching or even therapy. There’s no shame in that, and it can really take a load off your back.

Then, you should make a point of tacking martyrdom rather than automatically accepting it. Look at what’s actually draining your energy and consider what changes are possible. A common example is when leaders exhaust themselves “protecting” their team, not realizing they could reduce those issues from arising so frequently in the first place.

Or that their direct reports would actually grow from being exposed to the real world. The opportunity to tackle things themselves without your constant shielding is actually a personal growth accelerator. That’s how people become more senior, not by having their manager constantly hover around them.

That CTO we started the article with spent 10% of his adulthood so far or so, doing daily work that drained him. He’ll never get that time back, nor know what he could’ve achieved had he not been so engrossed in the daily struggle. Don’t make the same mistake.

Stop Trusting Those Who “Know”

Anyone giving you a list of “what leadership means now” is deluding themselves (or selling something). I’ve spoken to dozens of leaders recently, and one thing’s clear: there’s no single approach that’s winning. Many have already gone through multiple iterations. The people who sound most confident are often just the loudest.

This doesn’t mean that you need to throw everything out of the window. Some of the principles at the core of leadership remain as relevant today as ever. However, you cannot try to drink from the firehose and try every new idea on LinkedIn, nor can you stick your head in the sand. It’s time to restart.

You’re A Noob, Embrace It

To an extent, many experienced leaders are genuinely beginners again. It’s uncomfortable, but also rare and valuable. Curiosity is always a competitive advantage, but now even more so.

The leaders who I see struggling the most are clinging to their experience too hard. They think, “I already know how to do this.” The ones thriving are those who put aside their egos and started asking questions again.

Personally, I find this liberating. When nobody knows the answer, experimentation becomes obviously critical. You don’t need to justify wanting to try new things. Your new default should be to experiment.

Be Deliberate, Not Paralyzed

Many are really overwhelmed right now, and I understand it. When everything could change, it’s easy to freeze and do nothing. Don’t try to reset the universe. You don’t have to throw everything out the window right now.

Instead, start by picking one specific thing. Define the hypothesis explicitly. What do you expect to happen? For example, some are betting on fitting more engineers into each team, while others are changing their tech stack to match what agents seem to do best.

Being explicit about experimentation also gives you and your team psychological safety. If it’s framed as an experiment, “failure” is just data. If it’s framed as “the new strategy,” failure is a crisis. Aim for discovery, insights, and rapid learning. Don’t assume you’ll find the ultimate answer that will then hold for years.

Don’t Rock the Boat Too Much

This isn’t a license to blow everything up. Small, contained experiments with clear boundaries are going to get you to improve much faster. Think of it like a portfolio. Keep most things stable, yet run a few deliberate experiments. You cannot A/B test the entire org.

Iteration is key here. You won’t find “it” and be done. Again, many leaders have iterated and tweaked things. That’s the pattern we’re aiming for here. Leadership requires getting good at iterating fast and not getting too attached to any specific way of doing things.

If you haven’t changed anything meaningful in how you lead in the last 6 months, you’re late to the party. We’re having fun over here.

What It Means

Whereas tech debt can only reduce a fixed number of issues and thus is limited in what benefit it can bring, tech capital is about software solutions that accelerate different parts of the business, not necessarily within the tech organization. We’re not talking about features, but about capabilities that make the team itself faster.

You might not consider it that, but as an example, think about paying for a good CRM for the Sales team—that’s tech capital, but the type you purchase. Internally, we often have tech capital in the form of engineering velocity efforts. We create tooling and systems that make our work as engineers more efficient (like a reliable CI/CD system, which means we can ship code faster and with less stress). That’s tech capital, even if it’s the type you take for granted.

Taking it a level further, teams that doubled down on tech capital have amassed tooling and solutions that aid everyone in the team. It’s about automations to tackle common problems and reduce the load from customer success, wizards and sandboxes to onboard users to your platform without having to do handholding, tools for better marketing experiments, etc.

What’s Changing

Many are now realizing the potential of tech capital without being aware of it. How many PMs, marketers, and salespeople have posted what they created for themselves with a vibe coding tool or got OpenClaw to do for them? That’s tech capital, friends. It’s only that now it means you don’t have to wait for the engineers to make some time for them.

This change has also made many people realize what code can mean to them without needing to be too code-literate. Whereas in the past, many couldn’t even imagine what was possible and were oblivious to the many imperfections in their day-to-day work, now eyes have opened. When your mom looks at a tedious thing she’s been doing mindlessly for years and finally wonders if the “computers” can’t take care of it, you know we’ve turned a corner.

Join It

What does this mean for you and your team? As with everything AI-related, you shouldn’t try to find the one-true-solution yet. Things are just changing too fast. Instead, aim to be an active participant in this wherever possible.

For example, if others in the company are already vibe coding internal tools, double down on it. Share the successes, teach them about the needed guardrails, and actually turn this into an internal backlog. Things are vibecoded, and if they demonstrate enough value, they might be handed off officially to engineering to redo it properly and take ownership of it. This means that many experiments will only take up engineering time once they’re almost guaranteed to pay off.

Second, ensure that your team realizes the concept of tech capital and starts noticing it in the wild. This is one of those areas where merely teaching about it can have a noticeable effect. Once you see it, you cannot unsee it. Don’t leave tech capital on the table.