Hacker News Reader

Comment by AndrewKemendo | Hacker News Reader

> At the end of the day, selling well means that you are helping the customer actually understand their problem, and the path to evaluate a solution.

Lipstick on a pig in 99% of cases.

I've been a CEO, CDO, a consultant, a middle manager and an IC. Well functioning high output teams (in any sector of business) almost never need a new tool/service to provide value. On the flip side, poorly functioning teams are constantly chasing new tools and processes as fixes to their broken organizations. So the vast majority of sales are convincing broken organizations to buy organizational nudges.

The single place where I am consistently happy to spend money is on things that our organization cannot internally build that we need to scale immediately. In the long run though, I want to eliminate as many outside dependencies as possible, so my goal is to either absorb you or build processes and systems that replace your service.

View on HN

I too have had those roles, starting my career as an IC, then a middle Manager, then a consultant, then a CEO/founder, and now a CTO. What I’ve focused on is how to help my teams and then my company operate as efficiently as possible while spending our resources where it benefits our customers the most.

Some examples of decisions I’ve made:

- IT/engineers won’t spend time building and maintaining email servers, we’ll spend $5/month/employee on G Suite and use their time on things that make our products more valuable

- We won’t outsource support even though that would dollar for dollar be more efficient, because understanding and building empathy for the customer is more important

- no we won’t spend money on email lists, but yes we will spend money on tools that allows our outbound sales team to more quickly determine prospects that fit our ideal customer profile

- bringing finance in-house much sooner than other people recommended because being more efficient at Accounts Receivable, Renewals, and thus cash flow allowed us to grow faster than we otherwise would have

- paying for a third party SSO solution for our products and instead using engineering time to build first class integrations between our products and complementary products, because having an artisanal SSO System doesn’t benefit our customers

> IT/engineers won’t spend time building and maintaining email servers, we’ll spend $5/month/employee on G Suite and use their time on things that make our products more valuable

In-house email servers are not constrained by the time to build them, but rather by reputation/spam considerations. Sorry, but that's a lucky guess ;-)

> paying for a third party SSO solution for our products and instead using engineering time to build first class integrations between our products and complementary products, because having an artisanal SSO System doesn’t benefit our customers

That's one of vendorlockiest vendor lock out there, which is a very YOLO decision.

The idea that buying stuff is more efficient then building it yourself is at the cornerstone of the modern economic theory, but that's only a theory. In the wilds there's much, much more factors to consider then just comparing cost of building versus cost of buying.

Of course there are more factors. We are not blindly outsourcing everything to services and we are equally not blindly building everything in house. Those factors often come down to core competencies and “best and highest use” of time. These will vary by company. Case in point: lots of companies use highcharts and D3 for charting. why? Because building and maintaining a world class graphing system is not their core business and doesn’t meaningfully advance their business. And outside of a small minority of companies building your own charting from Scratch does not provide a meaningful advantage for your customers or over your competitors.

Deciding what is core and should be in house and what is not is hard and it’s only partially a technology decision. It’s primarily a business/market decision and being able to do those is a mark of a good CTO.

I'd venture to guess that for the tools and services that you buy, you weren't sold them, you sought them out and bought them because you recognized a need to buy vs build. I'm not saying don't buy things. I'm saying, if you're being successfully sold to in this fashion then you likely have more fundamental organizational problems.

My Dad told me something when I was little that stuck with me:

"You never see ads for broccoli"

Of course while that's not strictly true (weekly grocery flyer) his point was that, if you actually need something to survive you'll figure out how to get it without having to be sold to.

> if you actually need something to survive you'll figure out how to get it without having to be sold to.

And if you don't know what you need to survive?

If you don't know what you need, what chances do you have to make a right decision, especially talking to people who are interested in selling you stuff?

I don't see how there is any alternative to researching stuff first in order to know what you need, especially if we are talking about "efficiency" and "value" which are not rigorously quantifiable.

That advice only applies to a narrow set of functionality within the organization though. It's usually not cost effective or wise to write custom marketing systems if you can get one off the shelf. Your teams turnover rate, documentation, support, and feature creep all contribute to the maintenance of that system. No way it makes sense in the short or long term for non-core business functions.

I think "vast majority of sales" is too cynical, though there's undoubtedly some merit to your sentiment in certain cases.

I manage a high-output team, and we _love_ Mode. Could we write our own connectors to our BI warehouse to extract tables into pandas and jerry-rig streamlit to make our own Mode? Eh, maybe. We actually did dumber versions of this in the past. But we can stay lean by not having to worry about all the stuff Mode worries about for us, like credentials, auto-updating, pushing to slack, setting up a python environment? Absolutely, as long as it makes financial sense.

Again, maybe we're just disagreeing about software being shitty 99% of the time vs just 80% of the time. But I think my point would be that it doesn't have to be a sophisticated tool to be a pain point.

So no sales high output team needs a CRM ?

no engineering high output team needs a versioning tool ?

no designer high output team needs a design tool ?

High output teams always need several tools

I think we picture "high output team" differently.

The way I see it, a "high output team" usually knows all the tools in their respecive field, and knows 99% of them are trash and this fundamental thing has to change before a better tool becomes possible. Which in turn makes conversations with salesmen mostly pointless.

On the other hand not a "high output team" don't know exactly what they need and just chase hype.

I suppose the one exception (which is hopefully the real niche any saas enterprise should aim for) is when a tool is so novel it hasn't become well known yet, but will become so soon. Of course, if a tool is in that path, any competent member of your team will immediately see it's value with even a cursory look at what they're selling.

I can personally say that when I first started knowing about snowflake it made so much sense it might be the perfect tool for my org, and a few weeks later when my boss said they're considering snowflake I immediately communicated my excitement. Tech like Snowflake fundamentally changed how data engineers work, and it's not a change you can just invent in-house as a SME. Unless you're a large corporation it's probably wise to keep a lookout for tools that could make your work more fun and efficient.

The question is if your team never wants to embrace the new for risk of it not working out or it's always excited to try out things that might make their life easier. That's an acceptable practice too, as long as there's some teams left to do the experiments, any saas worth its salt will become "standard" in your field that you too will embrace.

What exactly made Snowflake the perfect tool for you?

You're thinking in black and white. This is all hypotheticals of course, but the teams you speak of probably already have something, but why should they switch to yours? What do you even know about what they might already be using?

> Well functioning high output teams (in any sector of business) almost never need a new tool/service to provide value

High output teams benefit as much, if not more, from new tools/services than anyone else.

- Accounting is much more effective with an ERP

- Sales is much more effective with a CRM

- Engineering is much more effective with CI/CD

None of these things are necessary, but they make good people even better.

ERP like peoplesoft and SAP? If anything a previous discussion in HN suggested to me that Tesla's decision to build their own ERP probably saved time and money compared to going with an archaic monolith.

> On the flip side, poorly functioning teams are constantly chasing new tools and processes as fixes to their broken organizations.

The data suggests otherwise. Historically the industries which have the most broken and convoluted processes also have the lowest investment in technology.

Could you share what kind of data points you use to describe "broken and convoluted processes"?

Reply on news.ycombinator.com