2024-12-17 20:59:22
Figuring out what to do is a big part of senior tech roles. Senior Engineers and Engineering Managers often struggle to define technical roadmaps. Reasons include:
Oftentimes, good technical vision can feel like it has to be some gift from the heavens or a skill you’re born with. In reality, good technical vision is often a very simple and boring review of small amounts of data.
An easy playbook for technical roadmap development is Problem Driven Development. In short, it means you develop your technical roadmap based on fixing things that are going wrong. It sounds simple, but it can be very empowering.
The classic first-attempt by EMs/Senior Engineers at roadmap development is to ask people what they think the team should do. This usually ends in sadness, because:
You get a list like:
The implicit “we should do this because it solves X problem” gets lost. Three sprints later people start debating the solution in abstract without ever remembering why they were doing it in the first place.
The main fault with this approach is that it does not capture and solve the biggest problems.
When you prioritize solutions, your job is done once everyone agrees to do your idea. You can prioritize solutions for years and execute effectively without fixing your problems.
When you prioritize problems, you prioritize fixing the issues you actually have. You cannot prioritize problems for years and execute effectively and not solve your problems.
The a-ha moment is this: everything you’re doing should be solving a problem. Align your team on the biggest problems you have. Derive your technical roadmap based on solving those problems. Periodically revisit your problems list to make sure it is still accurate.
OK, if you’re going to solve problems, you must figure out where they live. Most software teams have problems that live in the following places:
These failure repositories are auditable and you can directly build prioritized list of problems based off of them. When building a technical roadmap, you might end up with something like:
From here, you can figure out solutions you think solve these problems. It sounds very simple, but it’s a powerful way of figuring out what to do.
Tech debt prioritization is notoriously fraught and challenging in industry. One major contributor to this is that engineers are pretty bad at saying why tech debt is important. Another contributor is that PMs often require PM-level prioritization research to prioritize against product work, which is unfair. Teams then get in fights and land on %-based tech debt allotments to not have to deal with each other.
In any case, engineers ought to be better at doing reasonable due diligence on tech debt reasoning, e.g.:
Pretty quickly you can get to tech debt principles about wasted time, fail rates, and change frequency of issues if you frame things as solving problems and believe it can be done.
Regular-sized tech debt should just be addressed as people code other work in that area of the codebase. But if you’re asking a team to take the time to scope and prioritize work, you should have at least a miniscule amount of data to back up your claim. I’ve often found myself high conviction on a piece of tech debt until I actually researched the value in this way.
Problem Driven Development is a theory so simple it sounds obvious. But I’ve seen many Engineers and Engineering Managers struggle to figure out what to do. And I’ve seen even more not have a framework to say no to a Senior Engineer who loves a solution that doesn’t solve a problem.
Some next steps:
Problem Driven Development is basically just ersatz product management. One irony, however, is that PMs can do Problem Driven Development to a fault. Customer’s problems are often much harder to get information about and take a very long time to gather. At the same time, your competitors might all have one feature that is clearly valuable that you don’t have. In that case, you shouldn’t be spending a bunch of time researching the problem just to get to the solution your competitors all have. More on this in a future post. Stay SaaSy everyone!
2024-12-11 20:59:22
These are the heuristics that I use for professional networking. I think I’m a pretty good networker, but not any sort of natural networking savant – I’ve just been able to find good results by following a few easy habits.
Networking is kind of like working out: It’s easy to get started and a relatively small amount of effort gives you significant benefits. If you follow some incredibly basic rules and aren’t lazy, you can build a great network with ease.
Networking is probabilistic. Most of the people that you meet are not going to wind up being long-term connections that matter in your life. This is fine and normal, and as a result:
By far – by far – the most important way to build your network is to positively interact with your coworkers. People that you work with are the most accessible and high-quality network that you can build. They are right there. You have a shared experience, a similar industry focus, and are often of a similar age and life situation. The #1 missed opportunity in networking is failing to take the achingly simple steps to build a network from people you work with every day.
How do you do this? At a bare minimum: Literally just be competent, be a good teammate, and don’t be actively antisocial. Say hi to people in person. Be friendly in meetings; have a brief Slack conversation if it makes sense in context (don’t be annoying, of course). Remember names. Eat lunch with other people. You barely even need to talk at lunch – just be pleasant. If you do these things and are a good, reliable teammate, it is almost impossible to not build a network.
When you talk with your coworkers, be positive. Many people find it tempting to use shared grievances to build relationships, which can work well in the short run but sets you on the wrong course. If you try to manufacture rapport by complaining about your boss or the sales team or your CEO, all that you’ll construct is a network of complainers. Winners are inspired by ambition and shared victories, and complaining is pretty much the polar opposite.
For the more advanced level of building a workplace network, actively identify people whom you’d want to work with in the future. The reason that coworker networks are so valuable is that judging compatibility is incredibly difficult outside of work and incredibly easy at work. Whether as a peer, boss, cofounder, or subordinate – doesn’t matter. Do not waste this information asymmetry.
It’s also valuable to expand strong relationships outside of work, even if it’s very simple (we’re coffee buddies, or we get a beer every few months). You want to broaden the context of your relationship beyond your job, because your network will ideally outlast the context of your current team.
Beyond your coworkers, the next rule is simply to get out there and meet people occasionally, in ways that work for you. For myself: I like nice dinners, I like expensive cocktails, I like talking to people, and I don’t like approaching people speed-dating-style. That means that I prioritize dinners for senior Product leaders – and I will not go to a meetup, conference, hosted talk, or virtual event unless I’m forced or paid to attend. I also like chilling with my family, and won’t travel to an offsite unless I really like the group.
When you’re at these events, just be yourself and never brag. You’re going to get asked where you work; my quick tip is to have a very brief description of your background that hits the highlights concisely. Mine is about 12 words, and I’ll only elaborate if prompted. Keeping it brief is essential because nobody likes a person who only wants to talk about themselves.
This is a well documented “trick,” but whenever someone comes to mind, you should reach out and say hi. It can be for anything:
People do love being thought of… but more importantly, life is made up of all of the tiny events that happen in between the big ones. Take advantage – bring people along for the ride of the micro-moments that are happening in your life, and it will help to keep your relationships alive.
Staying connected in these tiny moments is great, but if you want to maintain a deeper relationship with someone, you must meet in person at least semi-regularly:
Past 3 years of your last in-person meeting, assume that your friendship is going to erode.
We are social primates, and in my experience humans do not fully trust people they haven’t seen and ideally physically contacted. Vista Equity Partners, one of the most successful PE firms in tech, literally enshrines this with their culture of giving hugs. Vista are not preschool teachers; they are not sensitive artists; they are not running a sentimental business. They are apex predators of the capitalist wilderness. But even they realize that in order to build trust people rely upon close contact, and giving someone a hug is a good way to get there.
You need to meet in person to build a network. For a tiny example of this: my Stay SaaSy co-author and I don’t actually find ourselves in the same office very often anymore, but I always prioritize speaking with them for at least a few minutes face-to-face when I can.
Swapping some amount of personal information is an important part of building a connection. There are a few reasons that this works.
The first is that it just feels nice if someone remembers a few personal details about you. This is true even if you suspect that someone is only remembering personal details for relationship-building purposes, because 99% of the time people will treat you like an NPC even if it’s not in their best interests. I suspect that the guy who makes my bagel only remembers my name so that I keep giving him money; he’s a smart guy and probably likes recurring revenue. But at every other shop I go to weekly they act like I’m a goddamn stranger, so I still like Javier more.
The second reason this works is that people like you more if they know personal details about you. It’s just natural: You know the most about your close friends and family. You also (largely) like your close friends and family the most. People perceive a strong association with knowing others’ personal details and liking them.
If you stand far away and squint, networking is kind of like dating: Two people talk and decide if they want to spend more time together. As a result, networking and dating share the same patterns for when they get weird. Don’t fall into these patterns:
It is shocking to me how often people violate these basic rules and inadvertently act like creeps.
Many jobs kind of suck – that’s why they pay you to be there. They suck because they don’t pay enough; they suck because they don’t provide enough opportunity; they suck because you don’t like your coworkers. Networking is a solution to all of these problems: If you network effectively, you’ll work with people you like, at more successful companies, which can pay you more.
There’s not a whole lot more to ask for than that. Over a third of your waking life is spent at work – that’s too much to spend with people you don’t like or respect. So get out there, and follow these incredibly basic steps to build a better network.
2024-11-19 20:59:22
This is a follow-up to one of our most popular posts, which contained practical advice on executive presence. As a refresher, I define executive presence as a set of behaviors that will influence others to fully listen to what you say – because they respect you, view you as reliable, and otherwise think that listening to you is important for the company’s success.
It can be somewhat circular, but one of the best ways to build executive presence is for other executives to obviously care about what you have to say. This time, we’re going to dive into the behaviors that earn respect from other executives – the traits that help make them allies, and that prevent them from resenting you or taking you for granted.
People respect strength. At the end of the day we’re all just mammals trying to map every organization we’re a part of onto a primate dominance hierarchy. And since it’s generally not acceptable to club your coworkers over the head or bare your canines at them, the measure of strength that most teams revert to is expertise.
To have strong executive presence, you need to have skills, knowledge, or capabilities that are beyond everyone else along at least one dimension. What is the one thing that you know how to do, or that you know everything about, where nobody else is remotely close to your level? It doesn’t have to be something huge, but it has to matter. There must be a domain where you are the king or queen.
Some signs that you have the right level of expertise:
Executives who are losing their grip consistently demonstrate what I call uncontrolled lateness – tardiness or lack of follow-through due to a systemic breakdown of control. Uncontrolled lateness manifests in two main ways.
The first is being significantly late to appointments without notifying others: No email or Slack message saying “hey I’m running late,” or worse, no response when others ask where you are. This is often accompanied by showing up to meetings looking disheveled or frazzled, or being unable to rapidly shift gears into the next conversation. (Note: significantly late means more than 2-3 minutes – longer than a generous margin of error on a mechanical watch)
The other is missing deadlines for the most important one-third of your TODO list. Most executives literally have more demands on their time than there are hours in the day, so for better or worse they’re going to drop stuff – I’m not talking about being late to approve an expense report. But the top ⅓ of items on an exec’s plate are usually really important, and things that only they can do. It’s a red flag when these items start to meaningfully slip.
The typical executive schedule is absolute fucking chaos. In my experience this is not widely known, and is the source of much resentment from people who are less busy (“Why doesn’t our CEO remember that important detail we told him on Monday?” “Well, it’s been 3 days and he’s had 32 meetings in between that conversation and now…”). Most humans are not adapted to the sort of schedule that the modern hyper-connected workplace imposes on them, but effective executives find ways to keep all of the important balls in the air.
Uncontrolled lateness erodes executive presence. It makes you less reliable in the moment, and more importantly it’s usually an early symptom of other latent issues which indicate operational dysfunction:
If you’re late in an uncontrolled way, I may not know exactly what you messed up, but I know you messed up something.
Being an executive can be great. Your manager is the CEO or some other leader with a very distributed focus – they probably don’t (and can’t) follow your day-to-day very closely. You have the power to promote and fire; even the boldest people on your team are wary. Outside of your team, people generally don’t want to get on your bad side. You can get away with a lot.
As a result, many executives are able to set up a life of leisure. They start the day late. They delegate a lot, so their day mainly consists of commenting and approving. They never handle follow-ups – they have people for that. They simply preside over meetings and chime in with a few specific wishes that others scramble to heed. Most critically, they can remove themselves from taking any initiative; their role is to hire and judge, but not to actually instigate anything. Typically this sort of person only responds fast to their own manager or someone more senior than them.
You might think people don’t notice. They do. If your title starts with VP or anything more senior, you should assume that people are observing you regularly. The hardest working people on your team will notice, and will begin to resent – over time they may quit and your team quality will erode.
Worse still – competent leaders know to lead by example, and know that poor work ethic is contagious. As a result, other executives won’t trust you, even if your laziness has no effect on them. They literally won’t want their teams to be around you, because they’re worried that your bad attitude will infect them. They will find every way to block your career to quarantine the bad precedent that you’re setting.
The solution? Hit the following minimal standard for how hard you should work: You should be above the 75th percentile of your team in terms of hours worked, or work at least ~45 hours per week (whichever is higher). You should also be reasonably available outside of working hours – roughly defined as being reachable for anything very important within 12 hours regardless of weekends or vacation (this roughly just means that you don’t ignore texts and phone calls). Your team will notice, and it will help. And honestly – you owe it to them.
There is something fundamental about taking things too literally that makes you a poor executive.
Over the years, I’ve observed that junior team members are significantly more likely to take things too literally, especially when compared to senior leaders:
Taking things too literally erodes your executive presence for several reasons:
As an executive you are being paid to question the orders you were given, and you’re being paid to consider a wide range of possible explanations for anything you observe. Executives don’t take things too literally, and if you take things too literally you look like you’re not a leader.
To be fully respected, you can’t let people take you for granted. And a fast way to get taken for granted is to make it seem like you have absolutely no life outside of work.
Being taken for granted gives people around you license to very subtly throw you under the bus: We don’t need to promote them this cycle, they’re really loyal. We don’t need to get their opinion on this org change, even if they dislike it they’ll never quit. What else are they going to do? All (competent) execs technically have career options elsewhere, but if it seems like the company is your whole life, you’re opening the door to being taken for granted.
Don’t let this happen to you. Let people know that you have other options emotionally. You’ve got kids; you love vintage motorcycles; you’re traveling the world spearfishing. It’s a terrible thing, but people discount the value of those who give them unconditional love. Your greatest power is your ability to care about something else.
2024-11-10 20:59:22
Sometimes when people give notice that they are quitting they start acting differently:
In any case, changing behavior once you’ve given notice always makes you look bad. Even if you are being nicer, or happier, or trying to be helpful - large changes in behavior make everyone think you were lying to them throughout your time, that you were not being authentic.
Inauthentic behavior is one of the most off-putting things you can do for your reputation. People can forgive mistakes and character flaws, but if they feel like they don’t know who you really are, they will resent you. Something in our pre-modern-era DNA is hardwired to despise sneakiness and false pretenses more than unapologetically bad behavior.
Once you give notice, just be normal. Do your job. Have a final happy hour. Move on with your life. The industry is small, and people remember their last impression of you even more powerfully than their first. You want to make sure that the last impression you leave is something like “they were a great teammate for years, they were still a great teammate at the moment the door closed behind them, and maybe we’ll be teammates again in the future.”
2024-11-03 20:59:22
Setting strategy at a SaaS company has many pitfalls. As a software product, there are innumerable directions that you can steer your roadmap or your go-to-market (GTM). With the whole world arrayed in front of them, I often see companies make terrible strategic decisions because they don’t ask basic questions to orient themselves before moving forward:
To set an effective strategy, you need to orient yourself in regards to your company’s strategic landscape – where the opportunities lie, where there are gotchas in your market, how the dynamics are likely to evolve. Here are the questions that I try to make sure I’m always able to answer before setting SaaS product or business strategy.
Are your customers under budget pressure, or are they able to spend aggressively (like sales, engineering, and marketing teams during boom times)? Are you selling your customers their second Ferrari, or their first 2004 Honda Civic?
Rich and poor customers couldn’t be more different. Rich customers are usually experienced at buying software, know exactly what they can pay, and care about lofty goals like future-proofing their business, having a high degree of customizability, and gaining an edge on their competition. Poor customers are in survival mode, and typically favor speed to deliver modest value. They’re often under pressure to consolidate products to reduce total spend.
More importantly, if your buyer is a big spender, you’ll often face significant competition. But it’s often worse if your buyer is broke – you’ll either need to dominate your market entirely or find greener pastures, which usually requires a risky leap to re-establish a broader product-market fit. Many startups break themselves on the rocks of a market with destitute buyers.
Customers periodically go through different evolutions – engineering, sales, and legal are currently being disrupted by AI; marketers were heavily disrupted by the web and mobile. Changing customer dynamics are an opportunity to sell as a challenger vendor and a risk for disruption as an incumbent. Companies lose product-market fit when their buyers change, so you need to constantly stay on top of whether your ideal customer is in motion. One of the most common ways to fumble the bag on a great business is by assuming that your buyer will never change.
This is a subtle but important point. Many buyers want to consolidate their SaaS applications into a single vendor where possible – are you at risk of being consolidated out? And on the positive side, is there an opportunity for you to expand your Total Addressable Market (TAM) or beat competitors by consolidating their functionality into yourself?
Many teams like to focus on why their competitors suck – to pump up their sales teams, to gloat, or to quiet the anxious voices in their own heads. I like to think about what my competitors are awesome at. Observing your competitors’ strengths is a great way to understand strategies that resonate with your buyers, since they’ll run a different set of plays that you can observe. It’s also an important way to avoid getting flanked in the market and to track the state of the art for your industry, which will typically be defined by the top 2-5 players.
Many competitors have fundamental weaknesses that can be exploited. Examples include:
Are your competitors going to need funding soon, or are they flush with cash? What was their last valuation – could they hit that valuation today? Have they had layoffs or are they hiring?
Companies that are dying tend to get desperate: They drop prices, they throw in free services, they lie about their competitors (you). Cornered animals are dangerous, but you can take advantage of their weakness. Beat a weakening competitor for 2-3 more quarters and their team might quit, allowing you to remove them from the picture and reclaim focus.
It’s also worth mentioning that a strong company with a valuation that is way too high can be just as weak as a middling company whose valuation is right-sized. That company that raised at a $1.5b valuation with $10m of revenue is very unlikely to attract strong talent if growth slows, which means that if you can further slow their growth you can throw them into a tailspin.
Understanding the state of your competition helps you understand how your market will unfold. Don’t step off the neck of a weakening competitor until they’re no longer a threat, and beware of competitors whose fortunes are rising.
In the long run, companies who are partners often evolve to become frenemies. The best partner usually has a directly adjacent related capability to yours, and these adjacencies (i.e., your business) are the most tempting directions to expand their own product offerings. Be careful about how you position yourself versus your partners; assume that they truly are agnostic whether you win or lose and are eyeing your market share. And if you find a partner who doesn’t want to compete with you (and whom you don’t want to compete with), make them your ally forever.
Investing in a weak partner is incredibly wasteful – you put in real time and effort, and then your partner is acquired or weakens and can’t support their side of the deal. You need to hitch your wagon to strong companions. Some partners, particularly successful systems of record with large revenue bases, will tend to become the central nexus points through which influence and power will flow.
A challenge: Weak companies have a strong incentive to seem like they’re very strong to prospective partners, because suckering in a better company into a business relationship is a reasonable last-ditch effort to succeed. You need to look at the team, market, and product to try to assess how strong a partner really is. Put on your best growth VC hat when you’re analyzing where to place your partnership chips.
Are you great at engineering? Is your system architecture highly differentiated in some way? The better and faster that you can build, the more ambitious you can be with your product strategy. Out-executing the competition in a straight-line development race is a great way to win, if you can do it, and it can overcome go-to-market (GTM) weakness.
Are you great at sales? Great at marketing? Is your CEO an incredible public speaker, or are they famous or notable in some way (this could be something as subtle as having a compelling life story or being extremely good looking)? The stronger your ability to execute at GTM, the more you can win with a reliable-but-not-necessarily-differentiated product.
What do you rely on to actually deliver value? What type of people are essential to your business, and at what level – do you have ready access to the talent level that you need? Are you entirely dependent upon another platform as a vendor or partner? Is your vendor landscape changing – are your costs going to plummet in the coming years, or conversely, are they going to skyrocket?
For a SaaS business, your supply chain starts with your people – mainly engineering and sales as the most important teams in a SaaS business. It also includes key factors like cloud services and SaaS vendors. You should always lean into unique supply chain advantages – for example, if you have the world’s best AI talent, or a sweetheart deal for cheap infrastructure, you should leverage them to the maximum possible extent.
It’s vital to know how your team actually operates, and how things get done at your company. Do you mainly do things that the CEO wants? Does the CEO have little control, with a decentralized command-and-control structure? What will it actually take to get something done? Do you have a culture of perfectionists or do you like to blast out MVPs? Do you identify and give up on failing ideas quickly, or are you doggedly persistent? Knowing how your company actually operates is essential for any broad strategic calls. And keep in mind that your company will tend to become a more extreme version of itself in high-pressure times or when under duress.
This final question is essential, as there are often strategies that just won’t work because you don’t have the cultural DNA to execute on them. You can’t run a strategy that requires tons of exploration with a highly centralized culture. If your plan is to build a perfect UI, you’re unlikely to achieve usability nirvana if this is the first time you’ve ever attempted perfectionism. Knowing the type of strategy that you can actually execute on is the final filter for knowing what sort of plans to put into practice.
One final thought. In my experience, something like 75% of strategy is just sticking to a simple plan: Keeping the team reasonably focused, pushing the plan monotonically forward, and not operating like some kind of foraging rodent that’s distracted by shiny objects. If you can set an impactful plan and hold to it for a few years (e.g. “win this market that we already play in”), from what I’ve seen you are way ahead of the game.
2024-09-15 20:59:22
AI is awesome - it can help people build things faster than ever before.
On the other hand, it’s also convincing some CTOs that they can build versions of their SaaS tools internally, saving money and avoiding the pesky problems that come with having to deal with anything outside of their fiefdom.
This is crazy.
Whether this approach is a power grab, hubris, or something else, it’s almost never a good idea. As a rule, you should only be replacing your SaaS products with internal tools if you’re FAANG-sized or if you can replace the tools with a spreadsheet.
Let’s talk about why.
Meet CTO Bob. Bob is an AI believer. He saw someone use Replit to launch a full website in 4 hours.
He also has a terrible case of Not-Built-Here Syndrome.
He also doesn’t invest the time to properly integrate or use his SaaS tools and then regularly complains about them not working.
Nice to meet you Bob.
Well, Bob asked his team to cut costs and his engineers said it would take 18 months to implement something that might reduce their storage footprint.
Bob doesn’t want to wait 18 months. Bob wants to save money now. Bob wants to replace all of his SaaS tools with internal tools. Bob talked to his C level peers, and they said what they do with these tools, and he can totally find someone to replicate that with AI super fast.
How hard can it be? Half these SaaS tools are just glorified fucking forms!
So Bob gets permission to rebuild a tool internally. He gets 2 engineers and a mountain of AI tools to start the project.
Right off the bat, Bob is dedicating about $400,000 of headcount to replace $200,000 of SaaS tooling. But let’s not confuse Bob with these details. The headcount is already budgeted for and he doesn’t think of it that way. It’ll pay off in the long run.
OK so we’re gonna get some engineers who are interested in focusing on greenfield development. But we can’t have our best engineers do this, because these are just lame tools. So Bob gets 2 mid engineers to build this project.
Alright well we need a database, we need hosting, we need authentication, we need some business logic. The AI tools probably help with all of that right?
Maybe, Bob, maybe.
Say you get through that, now you have to rebuild a mature piece of software from scratch.
Well, your team only does a few things with these tools, and only uses a few features, so let’s just build them.
OK, well we’ve built a shitty version of a CRM, done and dusted. And it only took about 6 months!
Uh oh Bob, it turns out there’s some bugs and some missing features. Just asking your internal partners to kind of vibe-check what they do wasn’t really great product management. More to be done!
Alright, 9 months in, v2 is done! Here you go suckers, money saved!
Dammit Bob, the thing just broke at 2am and our EU team relies on it! You need a 24/7 on-call for this tool. Well, this is awkward because we only have two people. Are they on 24/7 work every other week? Or do we ask another team to support the on-call. Ehh just get these 2 people to go on-call and we’ll figure it out later!
OK we have 24/7 on-call of two very nervous engineers who wonder when they’ll get more help, but we’re ready!
Bob, it broke again in the middle of the night and it turns out your 2 mid engineers couldn’t fix the Postgres issue that was happening. These AI tools helped us build something but they’re not expert debuggers! Gah!
OK, we have now declared that any long running incident on these tools has to bring in people from other teams. That won’t be a morale issue at all!
Ok we’re 12 months in but feeling good about this.
Fuck. Bob, one of the engineers just quit. They don’t like being on a non-core product team. This last performance round you told them that their problem space wasn’t complex enough to ever get to staff engineer because it was just a dumb SaaS tool that AI mostly built.
Hurry Bob, replace them with some other sucker!
OK, we’re 15 months in and hired a new person on our mini SaaS product team. The old SaaS product just released a great new feature and your internal users want it plus 5 other things that their product already has.
You told them it’s going to take 6 months. Fuck Bob! If we had the old tool we’d have it now. You said you’d have parity!
But wait, there’s more! The 200 engineers at the SaaS company also have AI tools. Turns out you don’t have a monopoly on talent and technology. They’re building super fast now! Bob! What! The! Fuck!
But wait, there’s more! That SaaS company is finding more efficiencies. They just cut their unit pricing. Our 2-person team has no idea how to leverage the new AWS server types to get these savings. Buying off the shelf would now be cheaper!
It turns out, underneath it all, spending $400k to replace a $200k tool didn’t make a lot of sense for the business. This was just a long line of problems that Bob had. Bob just got a new CTO job and his LinkedIn says he successfully replaced a bunch of SaaS products with internal tools.
What happens next is slow death.
Your internal product can’t keep up with the SaaS product.
Every new feature request takes months (when those tools already have them)
You continue to struggle to staff a B team. These are teams to nowhere. They’ll never justify a major investment and lots of promotions, but now they’re a critical part of your stack.
You continue to have major outages and annoy other teams that have to support that team.
You sow friction with other departments because you’re providing a bad product and it’s causing issues. Ouch!
It turns out that writing greenfield demos of simple business logic (something AI is good at) and doing full scale product development are two very different things.
It turns out that engineers and PMs cost a lot of money, even more than SaaS products.
It turns out that developing deep expertise in an area lets SaaS products build effectively and thoughtfully.
It turns out that having lots of customers lets SaaS products build for what you need and what you might need eventually - a product for multiple stages of maturity.
So listen, CTOs, if AI is so fucking great, use it to make your product so good that you have enough money to buy the best SaaS products out there. You wouldn’t try to replace your laptop with an in-house laptop built by AI tools. You wouldn’t rebuild your own IDE in house.
Stop trying to rebuild your SaaS products.
A related thing that’s happening right now is people trying to save 40% on their SaaS bills by moving to cheaper, worse alternatives.
This is also pretty dumb.
Your CEO says every department has to save $100,000. So instead of reworking the usage of best-in-class tools to avoid overages, or firing Tim who is a long-standing low performer, you start a 12 month procurement cycle to get a cheaper version of a SaaS tool. After spending 1000 hours evaluating, testing, migrating, and onboarding to a new tool, you now are stuck with a crappy tool.
But hey, you can tell your CEO you saved money right, so it’s not your head on the chopping block? Nevermind that you spent more than $100,000 in salary-hours doing the migration. Nevermind that while you were busy replacing great with shit your competitors were building new functionality.
This would be like if a CTO decided to move their entire department to worse computers, because they found out most people almost never use all of their CPU. If you find yourself saying “but wait, maybe that’s actually a good idea”, please remind me not to invest in your company.
Tech teams shitting on SaaS products is not new. Since the beginning of time, it’s been major recreation for some tech teams to dunk on every SaaS tool out there, lamenting how such garbage products have such successful businesses. Then they try to in-house stuff to empire build. Then things fall apart and they blame everything but themselves.
People making short-sighted tooling decisions is also not new.
Neither of these are new, AI and high interest rates are the just great catalysts for giving in to our worst instincts. And we know that’s happening in other areas as well.
