44 comments

[ 3.2 ms ] story [ 107 ms ] thread
This is hilarious because about a year ago I was scribbling on a plane about our idealized organization and I came up with this:

http://imgur.com/a/feJoK

CEO - Focused on managing team (Traditional definition BTW)

Product Manager - Focused on UX

Customer Manager - Focused on Onboarding and Client Management

Customer Acquirer - Focused on Acquiring Customers

Financial Manager - Focused on Managing Capital Flows

You could (or possibly should) combine The Customer roles into one and the financial one with CEO and you'd have the same setup that Feld describes.

I kinda like the idea of separating the "Company Machine" from "Customer Machine" and "Product Machine", but Customer and Product are deeply intertwined.
They're two sides of one coin, right? Here's what we want vs. here's what we can build. Opposing forces that should always be in contact.

Either that or it's late and I'm getting philosophical.

Another reason I don't like the customer/product split is because it pits the Customer team against the Product team. Who is the most valuable? Gee, clearly the Customer people because they bring in the money... Product is then treated as a cost center
Or you could argue this reminds people they are on equal footing with the other.
I have never found an organization where that is the case.
Yes, I think Company machine ~ HR; it is often separate from other two in the real world. And IMO the risks of putting management walls between Product and Customer, even in a small company (7 people example) are high. If product is not tightly plugged into customers one risks making something fun to build and useless / unsellable.
Company isn't just HR. It's "culture" (a vague but important word), financing and fundraising, etc.
Love this idea. I needed the company machine years ago.
This is pretty deep, and pretty smart, since it deals with the things a firm is about: its customers, what it gives those customers, and itself.

One could do worse than to consider those three areas in any decision.

How is this deep or smart? It reads like the common armchair "this is how to run a company" without so much as an anecdote. In fact, the foundation is his unnerving preoccupation with the number 3, not with any eye for business.

> there’s a lot of sloppy thinking on my part so far

That's from the blog post. Mistaking amateur ramblings for analysis is bit worse than seeing someone's mediocrity as genious. What are the standards for analysis now, 2 beers and a couple paragraphs about how the world should be?

Brad Feld is a very successful VC. Those aren't amateur ramblings, those are professional ramblings!

More to the point, he's a longstanding and well-respected business advisor, and has an excellent track record. I may or may not agree with him on any given subject, but I'll sure as heck stop and listen, because he knows more about this stuff than I do, by far.

Advocating a ternary structure isn't particularly insightful, and ternary trees aren't particularly efficient as data structures (they're to rebalance, etc).
I like the idea a lot, like the author wrote, he acknowledges there is still a lot of thinking to do but I like the consolidation of Executive positions into three buckets.

I think an executive mastering the customer machine, another the company machine and another the product machine, will allow each of these critical areas to sing. There will be conflicts and fight for resources sometimes but understanding you are all three silos that also come together to work for a greater good is a powerful motivator and I think can allow the company to see its mission more clearly. The idea needs to be fleshed out more but I applaud the direction

So if you're working on technology that enables the company to build products better/faster, is that part of the product machine or the company machine? At what point do those technology projects become internal enough to be considered Company instead of Product?
If I am understanding his point, the Company machine is basically finance/accounting, legal, HR, and office management. It is a common pattern at mid-stage startups to have some or all of these people report to a CFO. If your product is to make software to build products, the product development is still under the Product Machine, even if the company itself is using the product.
I've always gone with:

1) Create Value

2) Monetize Value

But I see how a third team makes sense.

3) Manage Value?

Value is a non-word.
I disagree. Value is the financial impact something has, as opposed to cost, which is what it takes to produce, or price, which is what it sells for.

Most of business is creating something that costs little to produce and can be sold as close to value as possible.

(comment deleted)
Well, if you run a SaaS company managing value is rather important. Only a small part of a customer's LTV occurs at the point of sale.

Especially if you have a more expensive product, Account or Customer Success managers are critical to reaching and extending your LTV.

In certain industries, it's said a company is made up of three types of staff - finders, minders, and grinders.

It's a pretty simple exercise to map this to the three machines.

Can you explain what each of those types are and how they map to the three machines discussed in this post? It's pretty non-obvious to me.

  finders (sales - those that bring in the $$$) = customer machine
  minders (admin, finance, hr, etc) = company machine
  grinders (the grunts who actually do the work - for a tech company this is the engineering dept) = product machine
At a company like mine where the technology isn't the primary product this would become "the four machines"? With one more machine handling the "main" product. Like journalism/carpenting/engineering etc.
As an aside, the actual article is not as long as the 100 pages it may seem from the scroll bar. There are a lot of comments on the page.
Product Development, Sales and Marketing, and General/Administrative
I like the separation of The Company, but highly disagree with keeping The Customer separated from The Product.

I would like to see more of what can be done as we focus more on combining these, not segregating them.

As a developer the very rare chances I have had to go on a sales visit were eye opening in an astounding way. Sure, maybe don't have developers cold calling, but making product developers a part of the sales process can only help with the feedback loop.

The branches should never be separate, in the end every branch cares about final product, that it sells.

What is missing in the model is strategy - there should be people responsible for an overall strategy. That part requires communication with all branches while having a general vision. In a small company, that function always belongs to CEO.

Next, someone who cares about internal company health. In some companies, this would be called "operations". Those people would handle adherence to rules, mood and day to day infrastructure. (maybe part of hiring process) Think of them as legal branch of a government.

This makes it four.

Tossing these two as one (company machine) is problematic. Strategy needs to "be plugged into" all of the processes quite directly, as well as being aware of external conditions.

Some segregation is inevitable. It's a result of complexity. At a certain point, the company becomes too big and complex for everyone to be doing everything, and you need to specialize, not just distribute the work.

The Product/Customer divide makes sense to me, because what you do about them is different. Sure, customer steers product and vice versa, but the "Customer" machine is about sales funnels, marketing language, customer service, etc. The "Product" machine is about specs, coding, release schedules, etc. Implementing a new feature and selling a new feature are different tasks, requiring different skillsets.

I think your hangup may be more about the words Brad used to describe the 3 machines than their actual functions (which I totally understand. I had the same initial reaction to Brad's post. Across the board, every part of the org should be customer-focused.)

Another way of naming these 3 distinct operating groups:

Build | Acquire | Operate

Or in our company's case,

GTM - Go To Market | EPD - Engineering, Product & Design | G&A - General & Administrative

I don't think Brad meant to imply that only one branch was focused on customers. I think it was just a simplification to make the names more accountability-focused & less function-focused, as Brad worked through it.

(NOTE: I'm an employee of the company that sparked this post.)

As I'm making my first hires this month, I've been thinking very heavily about future org structure - and oddly enough I've called it the "machine" too.

My machine has custom components that perform different functions but connect together (which parallels your machines pretty well). Each of those machines can be subdivided to an extent.

I think it's an interesting approach in that I could practically design draw a schematic to describe how it all comes together. Every company would probably need a custom-built machine - there's no general one-size-fits-all approach in this way of thinking about it.

We'll see how it goes

> I'm making my first hires this month

Early-stage business advice is cheap and sometime barely worth the bytes it's stored in, but...

Speaking as someone who has done a few startups. Until you get to 50+ employees you probably don't want to spend a lot of time thinking about the org structure. Keep it relatively flat (CXOs -> VPs -> Everyone Else)

It is less cognitive load on you and empowers individuals to help form the company culture and workflow.

Edit: I don't really agree with the premise of this article. I think it is critically important at early stages that everyone (engineering, marketing, sales, customer service, etc) are exposed to every part of the business. If a customer sends customer service a great review, engineering should see it. If a customer has an issue, engineering should be involved in making the customer happy. And the other way around, customer service should have a say in how the product is built... heck, the administrative assistant that answers the phone should even have an avenue for their feedback to be heard. Of course someone needs to ultimately make the decision but everyone should have a voice and feel vested in the company success.

> If a customer sends customer service a great review, engineering should see it. If a customer has an issue, engineering should be involved in making the customer happy. And the other way around...

100% agree with this sentiment. I have tended to work at small (<30 headcount) companies and the better ones fully adopted this mindset. The less good ones tried to insist on closed doors and "you only need to know X" - which ultimately led to complete apathy to other departments problems or successes.

My read was the article was about focus, not building information silos. When everyone reports to the CEO, the org suffers.
Depends on the size of the company... if the company is three people that seems perfectly reasonable.
I like this clarity. But I think to make it work you need the best people at the boundaries of the divisions. Between customer support and product development must sit someone, or a team, with experience of both. Between the internal company function and the engineers must be a former engineer who is now a manager or at least a person who both understands the business and also understands that programmers need quiet offices and decent equipment.
This is really great...
As the founder of an early stage startup, everything that is not related to product development seems that I am not actually working. I know that I should devote myself to hone my Customer and Company machines, but I hate the feeling of wasting time.

I am trying to transform Customer and Company as products, so I trick my mind to evolve them appropriately.

(comment deleted)
Thinking through Company can usually wait, but ignoring Customer is risky.
Indeed, but sales are difficult for a technical founder, and as a solo founder, I need to adapt or bring someone on board, which is risky as well.
Very true. The hard part seems to be finding the hierarchy. Can the head of Sales ever not be the head of Customer? (Can the head of customer success have the VP of Sales report to them?) Having product management subservient to engineering or vice versa seems tricky too.
I really like this concept. I hope to see more on the subject!