The Most Important Teams in Tech

The most important teams in a B2B software company are engineering and sales. Full stop, no exceptions, no further questions. You’re either building the product or selling the product, and everything else is secondary at most.

The intuition is simple:

• Great engineering (fast, reliable) is irreplaceable. Very-good to great design can be rented or borrowed; great product-market fit can ultimately be accomplished via luck or trial and error.

• Great engineering accelerates PM / design much faster than great PM / design accelerates engineering.

• At an even deeper level – the very best engineers are often great at product or design. The very best sales leaders often have great marketing instincts. But your best PM is worthless without an engineering team (unless they start coding themselves). Your best marketer is useless without a sales team (unless they start selling).

• Great sales is necessary to solidify product-market fit (PMF) by building a brand – sell to better customers, make them happy, build your brand – and brand is one of the most powerful compounding forces in business.

• Sales execution is the engine that makes SaaS scale. In some cases, product-led growth (PLG) can succeed without a real sales motion, but those cases are a rare and distinct minority.

• All other functions, while important, don’t move the needle on your company’s core axis of value delivery.

This truth is so clear that it can be used as a litmus test for whether you have any idea about what the hell you’re doing in SaaS. If you find someone who doesn’t intuitively understand why these two teams make the world go ‘round, then you clearly haven’t been in the business for real.

The prominence of engineering and sales may seem like a trivial observation, but it actually comes with a number of very important operational takeaways.

Know Your Place

A lot of people struggle with this, so I’ll just say it plainly – if you’re not in sales or engineering, you need to know your place. As a product manager myself, I’ll describe this in terms of how I want my teams to (ideally) work with our engineering counterparts:

• We ultimately only deliver value via engineering. Without customer insight, good designs, or PRDs, engineering could eventually muddle through. Without working code we deliver no value.

• As specialized partners to engineering (and to a lesser extent sales), it’s essential that we stay focused on areas that will maximize what those teams deliver – whether that means identifying the most efficient path to customer value for engineering, figuring out how to make sales cycles go faster, or identifying exactly how we can make a big marketing splash with our product. We need to propel those teams to do more.

• We need to move especially fast when working with engineering and there is value in saving their time. For example, if we can test a hypothesis with a week of manual PM time that would take a week to verify with engineering effort, we would probably accept that trade.

• If our team isn’t adding value on a project (for example, a PM simply isn’t working out and we verify that), and engineering doesn’t want them involved, we should find someone else to work with them or just pull PM off of that project. Engineering is the customer.

• Our job is to get the highest value code to our customers, and monetize it. We share a bucket of resources with engineering (the company R\&D budget). We need to carefully scrutinize whether we’re using the right amount, rather than taking whatever we can get away with politically, since there’s a direct tradeoff between our team and engineering.

This doesn’t mean that you should just do whatever engineering (or sales) wants. If sales or engineering are incompetent you need to deal with it.

But you need to assume that all else being equal, their immediate priorities – writing and launching code; closing deals; renewing customers – are at or among the very highest priorities for the business as a whole. For example:

• If the sales team is focused on closing the quarter, it’s not the time to run performance reviews

• If the engineering team is working on a production incident, review of your next Figma mock is delayed until the incident is resolved

• If we’re down to our last $200k, our default is to spend it on the next engineer unless we desperately need a PM

Sales & Engineering Execution

If you’re actually leading a sales or engineering function, there’s a lot of pressure on you to perform.

As a company matures and grows your job will evolve, becoming more complex, with higher standards. You need to constantly improve at your job as well. This might be an academic exercise if you are, say, an HR team. But if you’re one of the two most important teams at a company you can literally be solely responsible for killing an otherwise thriving business if you don’t evolve fast enough.

The criticality of sales and engineering leads to a paradoxical situation:

• In the short run, these teams often have very high job security. Nobody wants to rock the boat even if it has a few holes in it.

• In the long run, these teams have very poor job security if you aren’t excelling. The CEO, board, and investors are constantly assessing the strength of sales and engineering and overhauling these teams can be the answer if things really get off track.

Since sales and engineering are the pace-setters of an organization, there is no such thing as “good enough.” You will always be compared to the best team that the company believes it could theoretically build. Nobody wakes up in a cold sweat wondering how they could have a 1.5x better HR team; every CEO in the world would move heaven and earth for a 1.5x better sales or engineering organization.

As a result, it’s on you to constantly self-improve, because nobody is generally going to mess with their money-making teams… at least until they decide that you’re not cutting it, at which point you’ll be replaced.

Building Sales & Engineering Expertise

If you are in an adjacent field to sales or engineering, you should strongly consider how you can build more experience in these critical fields.

In many situations, the priorities of your sales and engineering teams are going to take precedence over your own. The biggest deal of the quarter is more important than your marketing deck review; launching the rebuild of the product is more important than your PRD. This is fine and actually often the sign of a healthy business. As a result, learning about what makes both sales and engineering tick and why will help you do your job better. You cannot swim against this tide, so you need to learn how to swim with it.

The main way that I see leaders getting into bad situations is by assuming that sales and engineering are simpler than they really are. It’s fine for me to be a non-technical PM, I know the customers. It’s fine for me to do marketing without being a sales expert, I know how to build an audience. No. You need to understand sales and engineering as well as you possibly can – otherwise, you’re going to be like a quarterback who’s watched hours of Sportscenter but has never thrown a football.

Sales & Engineering Risks

The fact that sales and engineering are the most important teams means that sales and engineering failures are the largest risks to your business. If you’re at a company where these teams are weak, you should strongly consider leaving. You are highly unlikely to save the ship.

Once you see this truth, many other fact patterns start to make more sense.

• Tech CEOs are disproportionately drawn from the ranks of sales leaders and PMs who used to be engineers. There is enormous value in literally knowing how to build a product.

• PLG companies targeting smaller customers often do well despite poor economics relative to enterprise customers, because they take one of the biggest risks (incompetent sales team) off the table. Additionally, not needing to field a large sales team allows companies to overinvest in engineering, which often brings massive advantages – many of the most successful SaaS companies have a PLG motion. Unfortunately, PLG business models only work for certain industries.

• Y Combinator, probably the greatest early stage investors of all time, have an extremely strong preference for funding companies that have engineering expertise on their founding team. De-risking engineering is that important.

Share to Twitter , Hacker News , LinkedIn