dworin

It's very hard to find people with both deep domain knowledge and deep math/statistics knowledge, in the same way that it's often hard to find people with deep programming knowledge and deep business knowledge.

We solve the latter problem by having business analysts or product managers that "get" the technology enough to provide direction, even if they wouldn't be effective implementing it themselves. I think there's a next phase where, as we try to do data-science at scale, we look for a similar role that deeply understands the business and knows enough about the analytical techniques to define the problem and work with a team of specialists to figure out the best analytical approach.

People talk about data science teams being multifunctional - with programmers, data engineers, data scientists, and designers - but we always leave out the role for someone with deep business expertise and shallow but meaningful data science expertise.

The best business practices to emulate come from successful in boring and fiercely competitive industries, where you can see if those practices are really making a difference. When a company has a single massively profitable product that's mostly protected from competition, it's hard to know if anything they're doing makes sense at all. But boring companies don't make exciting Fast Company headlines.

I think this is a fairly common pervasive, semi-conscious but unspoken feeling throughout many marketing and communications measurement organizations.

>>> the change is mostly about moving this risk (and potential reward related to it).

This is exactly right! And the theory behind it is actually one of the papers behind this year's economics Nobel Prize.

Different billing models aren't about paying for outcomes - they're about how to both incentivize and compensate when 1) there is uncertainty about the effort and ability required and 2) there is uncertainty about the degree to which effort and ability will lead to outcomes and 3) outcomes are costly or difficult to measure.

Different ways of billing are really about who takes on the risk (and gets both the upside or the downside), as well as how to align incentives between the service provider and the recipient. Oftentimes risk-sharing and incentive-alignment are in conflict with each other, which is why this isn't an easy topic.

This echoes some of my recent frustrations with customer success organizations to a T. I'll also add in that many customer success organizations feel like the Post-Sell Upsell Sales Team rather than the Make My Customer Successful Team (upsells might be a goal, but it shouldn't feel that way to customers).

At most SaaS companies, customer success is designed as a slightly-better support function, rather than a value-added consultative function. This is actually an evolution from the old model, where you'd have a more expensive professional services function that accompanied enterprise software purchases, usually because the implementation itself required a great deal of technical sophistication that the cloud has made obsolete.

Customer success managers tend to be lower paid than consultants who have domain expertise and strategic thinking skills. They also typically handle a much larger client load, which makes it hard to invest time in relationships, and have automated their work to the point of annoyance, which makes it hard for them to individualize.

On the other hand, it's not always such a great idea for a company, especially a SaaS company looking to make an exit, to have their own professional services function, let alone a paid services function. Consultants are expensive and have much lower margins than software. They also add headcount and bring down valuations when it's time to sell the business. That's why most software companies a partner ecosystem around their software, rather than trying to do it in house.

Based on my experience, there are a handful of customer success organizations that get this right. But as a discipline, customer success is still meandering around trying to figure out what it really is. At most companies, the legacy is in a customer support function, not a professional services, consultative sales, or account management function. So that's the level of service you get. I'll be interested to see if they'll respond to feedback like the posters and evolve towards a more consultative model.

In my experience "expertise in making sense of data" is only one piece of the puzzle, and often not even the most important one.

Domain expertise is hugely important at making sense of data. Self-service allows domain experts to quickly look at data themselves. They may have to learn skills in data-sensemaking, but the expert in data will have to learn about the specific domain (often much harder).

I'm noticing that more and more people in a variety of fields have at least a passable understanding of how to make sense of data. For quick questions, self-service access to data makes the process much faster with little risk.

I've been in organizations that tried to put data behind gatekeepers who would protect users from making mistakes. In those cases, we made a lot more mistakes because not enough analysis was done, or people didn't have access to data.

I've been in other organizations where we let everyone look at the data. Sure, some people made mistakes, but we used that as an opportunity to teach.

If I had to bet on which type of firm would win, I'd bet on the latter. I'm deeply skeptical of the promises made by BI vendors, but self-service analytics isn't one of them.

As a user more than an engineer, most of the apps I use have 'one feature,' but the one feature that's important to me is different than the one feature that's important to other people. My 'one feature' may also be a unique combination of smaller features that, when brought together, solve one very important problem for me, and some different combination of smaller features in the same tool will solve a different problem for someone else.

There's actually a lot of research about confidence (and an entire pop-psychology book on the subject).

The basic finding is similar to what the article says: too much confidence is bad because it makes you miss things, but so is too little confidence if it makes it hard for you to do anything. The trick is calibrating confidence and how you react to under/over-confidence.

In a situation of low confidence, you want to take action to grow your confidence by getting feedback, learning new skills, or collaborating to get new ideas. When you have too much confidence, you need to figure out what you're missing or get a more realistic perspective on where you are.

For better or worse, there's also social value in projecting confidence (not arrogance, but confidence) in certain situations.

"2. Internal employees - Stack Overflow said this has been available internally for a bit, but when employees find out what others are making they are inclined to compare their own efforts/abilities vs others. It can lead to people either asking for raises to match their co-workers, or perhaps feeling slighted and seeking other employers."

One nice thing about being transparent and consistent with salaries is that you can have an objective conversation with someone about the reasons that they're making less, versus having to rely on vague, irrelevant, or harmful explanations like "he was making more at another company," or "he negotiated harder." If someone thinks they should be making what another developer is being paid, they need to make the case based on clearly laid out criteria.

There's no compensation system that makes everyone happy, and there shouldn't be. You want a system that leaves people knowing where they stand, what it takes for them to make more, and management that encourages them to grow into that amount.

>> Good HR means three things: a clear management structure, a way for people to talk about workplace issues and concerns, and pathways for people to evolve in their careers.

I've seen a number of startups who think the only part of HR where they need to invest resources is recruiting, right up to the point where the wheels start coming off. Once you're feeling the pain points - disgruntled employees, people leaving, communication problems, etc... - it takes a lot more time to get things working again.

It's hard because these issues aren't the things recruiters are good at solving, so they need more specialized knowledge, but at 20-50 people don't have the capacity to bring on the right expertise.

I've said the same thing to leaders at multiple startups (some well known) and they all gave me a look like I was a neophyte who didn't understand the motivating power of ping pong tables.

The missing part of the advice is that you need to hire the best _for your company_. But there isn't an objective definition of 'best.' People can be great at one job and not right for another, great in one company and not right for another. Hiring and job hunting is about fit.

I've worked with people who were A players, hired into a new firm, and quickly spun out. Other people were C players, found a new job, and quickly became A players.

If you're a company who's great at training people, you can hire for energy and eagerness to learn. If you expect people to know everything on day one, hire for experience. The same people who succeed in one of those companies will fail in the other. A big part of hiring is knowing yourself and knowing what makes people successful.