Very typical. I've run into cases where an "idea guy" basically says "you do all the product and tech half, I'll do marketing and strategy." Which is dumb, because sometimes I'm legitimately better at the strategy half too. Generally these people want ridiculous equity splits of that nature.
It's worth anyone technical's time to build skills in strategy, marketing, finance, etc. The technical co-founder always gets screwed and suffers from a general lack of respect. In my opinion, it's usually unwise to take positions where you're strictly the technical co-founder, or where you're marketed as the same.
> Which is dumb, because sometimes I'm legitimately better at the strategy half too
A semi-related thought I've had recently:
I've run into a number of non-technical product people that say that they're primary skill is that they have a great "product sensibility" that engineers lack so they need to step in and provide guidance. It's true that many engineer-designed products are terrible, but I'd argue that most engineers have pretty good product sense.
The problem is that engineers have a conflict of interest that leads to them making sub-optimal product decisions. A non-technical product person gets the "luxury" of only thinking "what is the best product for the user?", so they end up with a good design. But an engineer can't help but also factor in "i'm the one that has to build this, so how much extra work am i giving myself?" so they're design will be a compromise of what's good for the user and what can be built easily.
this can have big consequences for how an org should divide work. If somebody has a broad set of responsibilities, they can't help but make tradeoffs (that they might not even be cognizant of) because they're weighing multiple objective functions.
So, when it comes time for figuring out who should be in charge of strategy, it might not just be an issue of "who's better" but more an issue of "who has the least conflict of interest"
Every feature, design decision, and iota of technical debt are money and time. Either that's raised and spent up front, eating at equity, or it is deferred until a point where revenue pays for it, it is redundant due to a pivot, or becomes so essential that new funding is raised (possibly from a pool that doesn't dilute so much value).
Presenting an accurate and fair cost / benefit analysis of these tradeoffs (at least on the technical side) is the main purpose of a technical lead. Non-technical business people can't get that information on their own. They should have a say in the decision if it materially affects the product's launch, but that's the normal give and take.
>> But an engineer can't help but also factor in "i'm the one that has to build this, so how much extra work am i giving myself?" so they're design will be a compromise of what's good for the user and what can be built easily.
The PM/Strat component is like a fifth or tenth of the tech work, typically. Every product design decision often has a magnitude more of associated implementation work. The only way i'd go with this setup is if the PM/Strat person if one of these things:
- PM/Strat person already has customers lined up
- PM/Strat person has paying partners lined up
- PM/Strat person has had exits with associated aura
- PM/Strat person puts in upfront $ to compensate the tech person
> But an engineer can't help but also factor in "i'm the one that has to build this, so how much extra work am i giving myself?
I wonder how many startups have failed because the tech has been too much of a pain in the ass to maintain and the technical staff burns out and leaves, with more and more expensive developers postponing leaving till as late as possible and doing as little as possible
Start ups that choose things like Azure are a red flag for me. Churn is really problematic. Learning a code base by having to poke and grok takes a lot longer than being able to fire off a few questions.
yeah azure has come a long way since 2016. id say it has devex ~amazon, better than gcp. but to his point the startup picking azure is a bit of a red flag, though it's not the best example of a red flag, imo.
What about "what role needs to be done the most at the time?"
>sometimes I'm legitimately better at the strategy half too
Technical people should be eager for more business responsibilities than ever before starting a business.
If it's an "engineering company" ideally you would have two founders each having outstanding technical abilities, and far exceeding anything a non-technical alternative could bring to the table from a business or sales aspect. To begin with if you want to start a business, you need to be the kind of engineer that wants to build sales in some way or another. On the front lines and/or in the background.
And to be real one of you is going to have to go full-time into sales & marketing to pursue some type of cash flow until things get rolling in some way. At least.
Then you can more sensibly consider having the non-tech MBA type come in under the top engineer who has been successfully selling already. And that's the beginning of a chain-of-command where an "engineer" is never hired or fired by anything other than an "engineer". And there's always an engineer (sharp in business, not lacking anything needed) at the top of any non-tech hierarchy by design.
Non-engineering companies where the non-tech-types dominate the hierarchy, can still have decent opportunities for the engineers they hire to work on projects under them. But there may not be as much room for upward movement or appreciation for outstanding skill up and down the line. Might also be more often found involved with financial irregularity, or more commonly non-fair dealing even with some of their own people sometimes.
The blue-sky utopian version of this for the Business side is a company shaped like a big Inside Sales Funnel, with all Engineering work implemented in off-shored cost-centres paid piecemeal at contract rates.
Steam had a flat-management structure and Engineering driven leadership from its outset. I'm not sure there's many other that can survive the VC landscape where customer focused design is seen as something between over-engineering and altruism.
Conflict of interest is exactly how I term it as well. Tech people with good product sense have to work very hard to override their engineering instincts or they’ll handicap the product.
I’m guilty of it all the time. What helps is remembering that absolutely nobody gives a shit about the code or the architecture. Nobody. It really doesn’t matter. They just want an awesome product.
(Which isn’t to say none of that matters, because it does. We are engineers and know the consequences of shitty technical decisions… it’s just that you have to pull yourself out of that mode when thinking of what needs to be built)
> What helps is remembering that absolutely nobody gives a shit about the code or the architecture. Nobody.
If there is no competition, money is nearly free, and you have all the time in the world, sure. If any of those isn't true, you probably want a reasonably well architected codebase so you're not spending 3X the salaries and 3X the time to build things as you would've with a well designed codebase.
> What helps is remembering that absolutely nobody gives a shit about the code or the architecture. Nobody.
We could easily say the same about anything. Nobody cares about the engine in their car either. Except they do, because it affects things like whether they can get from point A to B, which is what they really care about.
Same with code and architecture. It "doesn't matter" but it does, because it takes you from A to B at a particular speed and cost.
> What helps is remembering that absolutely nobody gives a shit about the code or the architecture
The programmer on call at wee hours in the morning gives a shit. Good news though, that programmer will not be a problem soon enough. You can hire your way out of this problem after they quit.
It’s funny how many people think their ideas are truly brilliant and warrant a massive amount of respect.
Anyone who’s worked as an engineer for awhile knows that ideas are a dime a dozen, they are rarely unique, and are about a millionth of what needs to be done to succeed
EDIT: I say this as an engineer who is putting his notice in tomorrow to found a startup
EDIT EDIT: Thanks guy, this is along the lines I'm thinking. I'll be competing with companies like Asana, Monday.com, and ClickUp. I worked in a consulting environment for two years and these tools could never be adopted despite the org size growing to 1000+ people in my larger team. It was a big pain point and I think I've built a solution that will help big time.
A good biz guy can be worth his weight in gold. It's harder than people think to get it right: to figure out the right markets to address first and how to tweak/target your product to do so, when, how, and from whom to raise capital, at what rate to expand the team, sales and marketing stuff, etc. Doubly so if the technical co-founder isn't as good at these. It's not worth 80% of equity against 20%, but it is worth a reasonably fair share.
For an engineer, sure. But for a business guy, it might be a bit tricky. Though I'd say a good business guy probably has a bunch of engineering contacts.
Demonstrate traction. The idea person should have at least an audience for the problem space. If not, they are Field of Dreams - build it and they will come. That doesn't work.
You didn't ask me, and I don't have a complete answer, but here's a starting point. Consider what's required for a patent: Novelty, usefulness, and reduction to practice. The latter step often changes the first two, for instance by uncovering problems, or even improving the overall quality of the idea.
Of course a lot of things need to right, beyond that point. I use the patent rule as a guide to make sure that the right people get credit where credit is due, when an idea reaches the market successfully.
We don’t need to go that far. I am “just” a developer but I have been in meetings where developers like me had much better ideas and suggestions on product, strategy etc than the suits. I remember being urgently called into a meeting with a big client to explain how a part of our application worked and why it worked that way, when the product owner/designer could not.
People often complain about developer salaries. I wonder how they can justify suits’ salaries
> worth anyone technical's time to build skills in strategy, marketing, finance, etc.
This leads to jack-of-all-trades types. Good non-technical folk exist. They’re just not easy to find for obvious reasons (same as good technical founders who can see the forest for the trees).
A good technical founder dilutes their comparative advantage e.g. negotiating with suppliers and prioritising payments ahead of a close.
It can, to be sure, and it's not ideal. But the perception that technical co-founders typically get gypped hard is very warranted. This is a thing where you can often still get a reasonably good result with a technical co-founder, not as good as were he solely focused on product/tech stuff, but enough that his individual outcome may be higher than letting the biz guys run it.
Obviously good biz guys somewhat mitigate this but finding those is easier said than done.
I don't know that I understand this, typically I structure the shareholder agreement (when I can) to be such that I have clout because I own or control a significant percentage of the shares, not because of my "title".
It's worth anyone technical's time to build skills in strategy, marketing, finance, etc. The technical co-founder always gets screwed and suffers from a general lack of respect. In my opinion, it's usually unwise to take positions where you're strictly the technical co-founder, or where you're marketed as the same.