DevRel at HuggingFace

This is such a great piece.

Phase 1 - Launch product which loses money

Phase 2 - ???

Phase 3 - Profit!

Few have progressed past the first phase yet.

I remember seeing a post last week-ish from Julien Chaumond that they are profitable.

They are selling related services. Looks like data and inference offerings with per seat pricing. https://huggingface.co/pricing

My business model was that people with great models trained on proprietary data sets would buy & sell trained weights and fine tuned models for private use.

Here is an example.

No e-commerce business is going to easily publish their sales data for everyone to train so they can build a great model for optimizing recommendations of products.

Hiring an internal AI team may have 2 problems.

- It may cost too much - May not work as well - You may not have the appropriate data set or data size (DL is very data intensive).

For a small fraction of what it may cost to hire your own team. You may buy a fine tuned models or readily trained weights that you just "plug & play".

That sounds like reasonable model.

The client (e-commerce) saves money, time, is guaranteed success, and gets the bonus productivity output from AI integration.

What do you guys think? Tarpit idea?

If I owned hugging face, I would follow such a strategy.

Simply put: they use the information they gain to justify the utility of individual team members to the overall effort and thus the proportionate compensation.

And they will misunderstand you, turn around and butcher the explanation to some higher up, indirectly claiming credit for your work as the messenger of its result. If something goes wrong with the project, they'll definitely make sure to emphasize your involvement in the failed initiative, strategically distancing themselves.

Where the problem exists is when the systems and processes business use start to become calcified into the organisation's way of working, and compliance is used to control the work people do.

RACI, RASCI, DACI as an example are all fine mental models for thinking about how people or teams should work on a project. But if I'm planning a project and propose a DACI, and then my project ends up getting derailed because some other manager thinks we should use a RACI instead it's probably game over.

Having a team of thoughtful and professional self-directed learners and creators sounds amazing if you can get a space for a team to come together around it.

Companies that have to, or choose to compromise on their labour force, either from a competency or salary perspective often have to put more supports in place to keep people longer.

Doesn't mean OKRs, etc are the correct solution.

I'm an Engineering Manager these days and I suspect this is true to an extent for my role. All I seem to do is relay information from one group to another, translate from one jargon to a different jargon, figure out who to talk to in order to get someone to be able to push a button, and, more often than I'd like, sit in meetings and remember things when someone else has forgotten. If my teams and the teams they work with wrote things down in discoverable and organized ways I would be out of a job.

However, due to the fact my teams are made up of fallible, disorganized, and very human people, my job seems pretty safe, and I get a great deal of satisfaction from knowing I help a lot of people get a lot more done than if I wasn't around.

When I became an engineering manager I invested a ton of effort into providing solid documentation where people expect it: Swagger docs with real examples for our RESTful services for devs, confluence documentation for wider audiences, various guides and FAQs, and even in-repo ADRs. It probably saves us about 15 labor hours of meetings a week and maximizes my team's hands-on-keyboard time and minimizes interruptions.

The weird part to me is I’ve worked with PhD folk, DARPA hackers, FAANG folk and they were so kind to me even when I said dumb things the person on the other hand was just idk how to describe it made coding just painful idk why though to this day

For anyone else that got tripped up... 1x to 3x is 200% growth because you don't get to count the original 1x

IMO I prefer the former ("growth factor") calculation to the "growth by" calculation as it's simpler, it's just [the_percentage]/100 * current_value

in the other case it is (the_percentage + 100)/100 * current_value which takes an extra CPU cycle of my brain

An example: an objective might be "improve application performance". The key results for that objective might be "reduce average page load time from 3s to 1.5s" and "reduce API response times by 60%".

Youre currently only supporting jpeg and png.

Your objective for a quarter could be to broaden support.

So you'd plan to add 10 additional formats. If you add 8, you've achieved your goal. Makes sense, right?

Honestly, the snide comments are spot on. It was even dumber then SMART SCRUM, aka development via waterfall, which is totally agile xoxo

So for example, if you worked in online retail like I did, maybe you'd get an objective like that and then hypothesize a few things along the lines of "if we increase product image interactions by X% then sales should go up by Y%." as key results that you then report back out to management to show progress towards your objective.

Not trash talking them, just agreeing that there are other factors.

> Why is it X and not, y'know, X?

Is there something central to what a business is besides the way communication happens within it?

Not to say this way of working isn't good, but HuggingFace's success is not a great data point to validate the hypothesis.

Step 2: Cash it in and make a lot of money.