As employee #36 I lived through some of these things first hand and definitely agree with them (I think we were over 200 people when I left).
It was painful going through the enterprise focus transition along with a nonsensical reorg imposed by the aforementioned Big Tech VP. One day we had focused platform-specific teams working on satisfying customers, the next we were moved to cross-functional feature teams and focused on enterprise features that (from our perspective) no one ever asked for.
I also felt the sting from mediocre engineering managers. I remember sitting down with Tracy and Ralph at Uptown Bar and giving them both barrels on what I thought of several managers. To their credit those managers weren't working there very long after that conversation.
IIRC Ralph asked if I wanted to move to being a manager and I declined but in hindsight I think that was a mistake - we needed good management in engineering more than we needed my code.
Another thing that hurt us was hiring a bunch of PMs. Most of them were condescending, ignorant, or both... but suddenly they were telling the engineers who had built everything what to do? IIRC we could have cut that department down to two people with no loss.
The leader of this product team was a manager that just didn't seem to be doing his job, only pushing paperwork and giving scatterbrained presentations. I never did find out why he was kept on so long. I think I very cheekily asked Tracy one time which of his relatives worked at Y2K or Sequoia such that he couldn't be fired because it was clear everyone in engineering was fed up with his nonsense. I'm pretty sure at least several top engineers quit due to that guy specifically.
Either way I don't regret my time at PlanGrid. It was a great team and I'm proud of what the team did and what I did.
As an outsider to the tech industry, it seems to me that the Product Manager/Product Owner role seems to be not only the most BS role, but also the most damaging role? Considering that I saw a post a few weeks back, I saw a similar post (I think on HN itself) where PMs were being fired en masse, I wonder if there is any real utility with the product team, or if it's just a holdover from Google doing its thing back in the days that everyone decided to copy.
The PM role gets described as the "CEO of <product area>" which I think translates to people thinking the role is ultra high status.
The best PMs I know operate like CEOs in the sense that it's someone's job to scrub the toilets, and until you figure out how to afford/hire someone to do that for you ... you're scrubbing the toilets yourself. Someone has too!
The 0% interest free capital environment distorted the PM role though, especially in land grab cultures. Imagine having enough budget to hire a 4-6 person squad of toilet scrubbers (and golden toilet) so why ever clean it yourself?
So sorry for the crappy metaphor, but that's why I believe PMs are on the chopping block right now. Not because there's something intrinsically not-valuable about the role. From the perspective of Tech Lead / Staff Eng in a Big Tech Co, good PMs created clarity and helped my team(s) execute. The worst PMs created ambiguity, and the worst of the worst pushed ambiguity+responsibility down as far as they could.
PMs tend to have a lot of leverage, so a bad one makes a very large negative impact. A good PM is worth their weight in gold though.
I think of them as basically glue. They just help make shit get done. That could be helping co-ordinate between eng and design, doing customer research, managing expectations, etc. Whole range of things that different PMs do.
I wouldn‘t agree with the BS label, as a good PM/PO can really help along.
but with that kind of role, contribution quality is rarely assed correctly, and at the same time, the sandwhich role between contributors, management, and customers, combined with a usually communication-savvy skillset can be extremely dangerous. even worse in impact than a highly visible „bad“ EVP/SVP.
This. I've had micromanager PMs that made my life hell and I've had PMs that advocate for me to others. It's all about hiring the right people and healthy company culture.
You still need to aggregate and contextualize these in terms of overall business and product strategy. Yes, engineers can do that too and some percentage of engineers are good at this as well - and being able to understand and formulate product strategy can be an important part of an engineering leader's skill set - but that's not that common and ultimately you need some level of specialization and you can't run an org expecting everyone to be able to do everything.
I've done both Eng and Product and most engineers don't have sufficient understanding or appreciation for the importance of product strategy. It's also important to be able communicate strategy coherently at some scale, especially if execution isn't expected to be completely top-down. At some point, engineers just have too much else to do and you need coordination.
Edit: I'll also add that engineers aren't the only ones doing work - Product Managers are expected to be able to coordinate across functions and get everyone on the same page, not everything is about just providing input to engineers.
The same reason when every year a new iPad comes out, you have a thread on Hacker News with engineers complaining they can’t run Kubernetes cluster on it even though it has the technical capability to do it.
Engineers don’t understand iPad’s product positioning, that it’s not built for them and they’re not the target market.
Want to get a portable Docker developer machine?
MacBook Air is cheaper and lighter than a 12.9 iPad + keyboard.
However, given the chance they’d be happy to ram the iPad with never ending list of features.
Companies did that before the iPad and failed, because they couldn’t say no to ideas that sound great and focus on what’s really important.
More often than not, engineers lack the people skills and business experience to know what questions to ask and how to dissect the answers they receive.
Open ecosystems foster growth and innovation though. Yes, companies have tried making something hackable and failed but other companies have tried closed eco systems and failed.
There is a reason I have a PineWatch instead of an Apple watch or Fitbit and Wyze cams instead of Nest or Ring.
I want to build an encrypted local mesh network with my iPhone for emergencies, I'll probably just do it on Android and have a few spare phones for family though.
I guess it is a profit incentive vs building the future. Running a Kubernetes cluster on an iPad would be cool, like that poster who leveraged an iPhone for OCR'ing memes. [1]
Side issue but the iPad is a bad example. People first complain when it comes to the iPad especially the top of the range is that it is artificially gimped to protect the MacBook sales contrary to what customers actually want.
I can tell you that easily because I am currently as far from an engineering position as you can be and see people all around me who like the iPad form factor but are annoyed that you can’t properly run Office on it.
The bit about most engineer not being able to talk to customers is spot on however.
I think you’re getting bad answers here. It’s not just about talking to customers and understanding what they want, it’s about taking that and matching it against bigger business goals, budgets, and priorities plus making sure you’re not duplicating or messing up things other teams are planning plus prioritizing within all the features all the customers want. If you have time to do all that then why is the company paying you an engineering salary to write code?
It's not about being able to do all of it -- it's about being able to do it in a sustainable number of hours a week. Otherwise, you just have someone with the programmer title but actually doing PM work, and not doing it as well as someone who is specialized in the role.
The arguments in the thread are that aligning the product as built and architected with the goals of the company is actually engineering work and not PM work.
You could, and probably should. The challenge is with the fad of scale. Every company wants to be the big guy hence bunch of hiring bunch of initiatives. It is common for people to subscribe to the ritual that a proper team should have some combination of PM, UI designer, UX designer, frontend, backend, devops (which is actually ops), QA, scrum master, customer success, support, data engineer, etc. Like graft different sticks together to call it a tree. OR you could grow a tree organically, naturally. Someone in your team is good at empathizing with customer? Good, do more talking with customer. Good with motivating colleagues? Good, do more motivating. It just doesn't quite fit the narrative of scale
Yes, I continually dislike why engineers are so discounted in terms of parsing customer problems... we build the damn things, we also happen to know how to use the mobile apps, web apps, and desktop apps we build. I'm likely heavily biased and bitter at this point, but I've yet to work with a good "product manager" - and I still don't know what a good one would look like or do.
I good PM does great things if they are very busy across teams and don't have time to hassle people about shenanigans and instead talk to users and understand the product deeply. Many places though have too many PMs that never talk to users and pretend like they know what they want.
You are thinking of scrum master, who can make up to 50% more than POs/BAs. Let me summarize:
1. "Hey, I am picking up my kid from preschool, so cover (my only 15 minute meeting of the day)". This is a mandatory future present in 80% of scrum masters.
2. Team, good job, I am so proud of what you have accomplished - I, for one, am always looking for the approval of a random person who has little to do with the team.
3. "Well, what do YOU think we should do"? "Thank you for your input! Let's remove those blockers. Go ahead and reach out to whoever the relevant person is!"
4. Key knowledge required: Daily standup, retro, planning meeting run by dev.
I’ve worked with a few good product managers. I always equate PM to project manager which is totally different and typically useless in software development. The most useless BS role is when companies hire for scrum master.
“Product Manager” is a double category error - the right title is customer analyst. This clarifies the actual function of the role, and eliminates most of the dysfunction
A common theme seems to be founders who want to keep all the cool stuff about being a small business while they scale to the ARR of a corporate. It can't happen. 1000 people don't all care about some new feature shipped by someone over in the payments team so don't subject them to it.
Most of us have been there in the painfull all-hands meeting falling asleep because the more people you have, the less they will care about the business. In a a team of 5, I have a lot of skin in the game and also a lot of influence. In a company with 100K employees, most of us are just a cog and some cogs don't even move anything!
Hiring is like a code base, you have to have the right abstraction at the right time. Starting out, better everything be a concrete implementation, that is everyone is directly responsible for making things work.
Next is what I found most people doing differently from my ideal - abstract and refactor base on your existing implementation, not because of some framework doing it, nor because the previous project did it this way. Do you need a data access layer, a library, a folder, to talk to database where the first implementation was just storing things as a variable? You probably need a database and plain SQL. Do you need site reliability engineer to keep your site online while your traffic all comes from friends? Do you need a QA for testing? Or do you need a product manager where, as a founder, the value proposition has yet to be proven? How often do you see a code base spinning up all the folders/empty files because "we may need it". And how often when you hire someone, they spin up various incarnation people * time like teams, sprints, squad, function, BEFORE understanding the current implementation. This is why you hire the wrong people. And you know it only 1 year down the road. Wrong abstraction. Using framework has its appeal, where a cookie cutter solution mostly work. But it also has its limitation, bloat.
Once a wrong abstraction is in place, the more code/people depends on it, the more effort it takes to refactor
Btw, the most important point from OP's is the last one. Life is fragile, treat people well. That's more important than all the three letter acronyms in the world.
A lot of the enterprise requirements he talked about add no actual value to the product; they're just checkboxes on an RFP that are required.
Theoretically applying all of those requirements to your product might make your product more secure, scalable, or reliable. It'll also make your product harder to maintain, harder to test, and harder to improve.
Many of those requirements are there because vendors put them there. If you're part of the RFP process (and you should be if you're actually selling to that sort of customer) you should be actively pushing back on requirements that you feel are pointless...making them optional instead of required, or at the very least providing a delivery date instead of delivering day 1.
In the enterprise space there's no guarantee you'll get the contract; to an extent the decision more political than technical. You should do a brutal assessment of your actual chances before engaging in any work implementing their requirements before the contract is signed. And since the sales cycle will be at least 6-9 months you'll have plenty of time to figure things out.
Lastly, if your product is highly desired the "requirements" can be bent or delayed. They're guidelines and can be overridden, if you have the right relationships.
The assumption is: "And remember that A players can recruit other A players, …”, not “ "And remember that A players can ONLY recruit other A players, …”.
(Added: My Ph.D. in mathematics is useful for something.)
The point is that B players have a very hard time ever recruiting A players and actually almost always hire people that are worse than themselves (i.e. c players). This is very true and should be something founders watch out for very carefully as they scale.
> B player wants to hire C players so the B player can more effectively beat their rivals in the company
I’m sure this is the case at some companies. But in my experience, it’s because the B player is as bad at hiring as they are at their job. This repels A players, who can smell bullshit, leaving a pool of Bs and Cs and guess of which there are more.
The A player thing is less about how good they are at hiring and more about how strong of a player they are overall. Founders generally need to be A players to be successful founders.
An A player will still make hiring mistakes but they have the skills/ability/aura/whatever to convince other A players to come work with them.
Many A players won't want to work for/with a B or C player because they won't see this as a good opportunity.
Not sure if they actually meant that B players can't hire B players but maybe. This sort of framing is pretty high level though.
Yep, just put people in bins so you can keep them organized. It’s always worked, so why stop now, right?
It’s not as easy as A and B and C people (or any other labels).
I’ve professionally led a team doing physical labor, and currently a team of teams doing intellectual labor (software development) and several between. They have been excellent, productive and profitable as well as respectful, ethical and honorable.
The reasons behind their success are complicated but always start on the same foundation: respect. Genuine, difficult to come by, and more difficult to maintain, respect. For the customer. For the user. For each other. For other departments. For the community. For the competition.
From there builds trust, and from trust comes ambition and the ability to focus on the purpose of the job (yes, it’s a job in most cases, not a mission or vision).
This is what I see some growth CEOs miss. They lack respect for people outside the “right” mold and don’t hire (or keep) them. Then to their surprise, their teams become dysfunctional.
Many tired anecdotes teach us about this (too many chefs, etc.) yet the same mistake is made with relentless repetition.
Not sure if anyone doesn't get this but just in case this isn't clear, the entire point of the quote isn't that people can be neatly separated into A/B/C classes, but that lowering the hiring bar can lead to a slippery slope effect that continuously lowers the bar, hence the short-term benefit of hiring someone good enough has to be measured against the long-term cost of this slippery slope effect.
The author is quoting Steve Jobs who would parrot it to his original Macintosh team. The Macintosh was an overpriced black and white appliance that nearly bankrupted Apple. Wozniak's team on the other hand built up the Apple II to be cheaper, faster, more modular. The Apple II saved the company. Ironically Wozniak is the A person and Jobs is the B person
I'm currently knee-deep in the enterprise world, and trust me, the point about selling into these orgs is very true. My team just spent the last year moving our client off a Salesforce Lightning-based solution onto our custom-built one. No one in the org could tell us why they chose to build it in Lightning, but everyone now says they love our solution.
The lessons you learn building a startup are good and always usable, but you need to be ready to learn what it's like to work in and with an enterprise, to figure out how to adapt and sell your product to them. It's an arduous process, but worthwhile.
This while A/B/C are just code words for the right pedigree. Say, Mr. X worked for a no-name company, got a degree from some state college. Such a person can't recruit candidates whose pedigree is Ivy league credentials, and top tier companies. You can see this often in terms of successful exits for many start ups: people with right pedigree (that is, right network) can bring more multiples for their startups, than others do.
I hate this BS about A managers hire A people, B people hire C etc. This is total MBA thinking (I think it comes form GE, or at least they espoused it) on a forum where people routinely mock MBAs.
I have been lucky to work in a field where teams frequently work in parallel and success or failure is pretty clear cut. And teams are often stratified based on the priority of project. Many times-- not always -- the "B" team crushes the "A" team. Why? Some reasons include: the A team is performative and focused on the things that burnish the careers and reputation of its members. B teams have more of a sense of the wolf being at the door and that if they don't perform their task they will feel the consequence. Being underdogs promotes teamwork.
Obviously people have profound differences in their strengths and weaknesses and some people are completely inappropriate. But calling people stars or A player covers up a lot of lazy thinking that includes a lot of bias. I have worked at smaller startups that say "we only hire A players". Obviously that is delusional but worse it covered up the more profound questions. Why did you hire the wrong person? Why did that person or team fail?
The corollary is: find out where you thrive and go there.
Don't beat yourself up if you get spun out of a FAANG, or a startup or a smallco or a bootstrap or a founding role or a mid-tier enterprise. Don't contort to a role or company that isn't a fit.
> "We took two stunt people who were the same body mass of Kate and Leo and we put sensors all over them and inside them and we put them in ice water and we tested to see whether they could have survived through a variety of methods and the answer was, there was no way they both could have survived. Only one could survive," he said.
Speaking in absolutes is never useful even though I think this advice might apply when looking for a new role, but small companies tend to grow if you help them succeed so it would be difficult to say your fit is at 10 person companies when that means you would have to jump ship every year just to stay in your comfort zone.
I joined my current company when it was 40 people (and around 10 developers). Almost 6 years later we're ~1500 and the engineering org is something like 200-300. I think I was most comfortable around 20 or so developers but that doesn't mean I can't make continue to have meaningful impact now that there's an order of magnitude more people and the org has completely changed.
I've seen folks who were supposedly "A player"s from small start-ups and FAANG join the company at different stages. Some succeed and some fail but I never noticed any correlation between current size of the company they're currently thriving at and our size when they joined.
Fit is never going to be perfect so don't give up on something just because it might be a little uncomfortable. Give up if you've tried to make it work and it's clear you can't find a way to have impact.
I have. Pretty sure I've seen every movie he was in, huge fan.
He's a great actor, but he hasn't shown the range that other A-listers have. Whether that's because of skill, interest, or typecasting, I couldn't say.
Kind of dumb to say an actor that's clearly proven he has immense range when there are so many other obvious choices. Vin Diesel for example is an A-list star who clearly does not have anywhere the range that Carrey or DiCaprio have.
> Many times-- not always -- the "B" team crushes the "A" team. Being underdogs promotes teamwork.
It's clear you don't understand what A and B people are then. If the "B team" is crushing the "A Team", then they aren't the "B team". Also, notice how you switched "player" with "team"? The quote is "A players hire A players", not "team".
The point is that top tier individuals typically hire top tier individuals. The reason this notion isn't so clear cut is because its hard to identify A players before the fact. It's a retrospective truthism.
Yup, this is the one thing that struck me wrong in the essay.
After spending multiple paragraphs about how they found that they had to dig much deeper into the background of every exec, getting 10+ references from reports, peers, and their managers, and developing specific lists of red flags . . .they end the section with: "Takeaway: Always trust your gut on people. "
Yes, for sure, if you 'gut' tells you something is off about someone, seriously consider and trust that also, but what was really effective was not gut-trusting, but gathering more hard data and observations to evaluate.
Just seems like the author didn't really think it through.
This is just garden-variety narcissism (btw, not trying to accuse the author of anything, I think we all feel this way sometimes) telling you that when you made the right decision, you were right and even when you made the wrong decision, you were actually right all along, you just let your true self be overridden. In reality, a lot of difficult decisions involve you being on both sides of the decision at different times, so it's very easy to look back on any wrong decision you made and decide that the real issue was not trusting yourself.
I'm also a bit surprised that she's throwing the "big company executive" under the bus here, given that it's very easy to identify who this is. She doesn't seem to be merely saying that the fit was the issue, given this:
> 1. They frequently use the wrong pronoun “I” followed by “[contribution to the company]”.
I have hired before. A few times. "Trust my gut" is still the best predictor of success for me. Every hire i have talked myself into didn't end up working out. Nowadays for hiring, i live by, "if it's not a strong yes, it's not a yes"
Agree that a 'gut feeling' that something is off is not to be ignored; it's likely just factors unconsciously processed.
That said, how much of your 'Strong Yes' assessments are on your gut and how much on you have enough info to see that this candidate is qualified, enthusiastic, and a good fit? Also, how many times have those failed to work out and how many have 'Weak Yes' candidates actually worked out in the end? Those counter-examples might be worth looking into...
I think it’s trusting your gut when it says „no”, not that you can trust only your gut when it comes to hiring. Wasn’t clear but that’s how I understand it and agree.
But in an article for publication it seems best to say something like "Trust your gut when it says "No", and get lots of data when you don't have strong gut feelings", rather than just that general trope...
In general good people will be able to identify good people (colloquially: game recognizes game). And good people will know they are being interviewed by someone who is not so good, and they won't want to join. A hires A.
Additionally, people who are not so good tend to be threatened by good people. So they will rather hire someone that won't threaten or "find them out". B hires C.
So 3/4 of the main points here are in regards to hiring the right people...
Almost makes me wonder if hr teams/operations shouldn't be measured on just headcount but rather getting the right people in
Hiring speed, hire quality, compensation (including things like work/life balance, healthcare, flexibility). I think you can try for two.
Once you get large enough your ability to really selectively recruit gets a lot harder when natural attrition means you need to replace X amount of people just to continue operating as before.
Of course earlier on, the fewer the people the larger the impact each one will have so just like the article says about transitioning to enterprise, the focus and requirements of the HR team change as well.
Great article and lots of salient advice in this post. It's so interesting to me that a company can get to $50 million ARR, and then feel strained because "there's enterprise competition". So what? I get that the pressure of VC-backed companies is go big or go home, but if the market that got them to 50 mill still loves and enjoys the product (which seems like it did), and churn is manageable, then one can probably truck along as a nice profitable business with some operational adjustments.
Again, I get that the VC-backed status doesn't allow this, but that's such an interesting distinction - this would be a successful $50mill ARR business if not VC-backed, but since it is, the panic button is pressed and that thus leads to decisions and scrambling that upend a lot of what was working.
Guess we all (as usual) need to make decisions about capital sources early and how we want to grow, as well as the real trade-offs between those choices.
I got the impression that the 2022 late stage funding implosion was also the death of ARR as a be-all growth metric. It got Goodhart's Law'd to death after all the companies that went public at huge valuations based on ARR turned out to not be as "recurring" as investors would have liked.
I wonder if you have more context or numbers. What companies are you thinking of. I remember companies like WeWork and Coinbase dropping in valuation but what more traditional Saas companies have run into this sort of hurdle?
I'd argue that ARR is still a good measure just not the growth at all costs, w/e it takes to get toe 100M ARR/Unicorn status anymore. After all, sales is sales and if you don't have repeatable sales you probably don't have much of anything.
There are many shenanigans that startups can play to juice ARR to render it meaningless. The idea isn't terrible, but that's why I invoked Goodhart's Law.
> After all, sales is sales and if you don't have repeatable sales you probably don't have much of anything.
That's right, but you're missing the key that it's a necessary, but not sufficient requirement. When the pool of investments is 90% with ARR are honest and straightforward, then it's good to use ARR as a metric. But when the pool changes to 50% or less who are honest (as Goodhart would predict), the metric loses value.
I can think of a few; 1) make 2 year contracts cost the same as 1 year contracts (so you're lowering the price by 50% but get the number you want for your report today); 2) give incentives equal to the value of the contract (our software costs $30k but we'll give you $30k of AWS credits).
Two companies pay each other absurd amounts of money for their (nearly) zero marginal cost services, netting no money transferred, but loads of recurring revenue for each.
Your #2 hint at this, but paying more than lifetime value of a customer to acquire the customer.
Love this article. Thank you for sharing. Read it and felt seen and less isolated as I reflect on some of my own similar mistakes. My colleagues loved it too!
Thanks so much for sharing these insights! Especially the humanizing points around life still unfolding around you regardless of how much success you achieve.
On the whole, this is a fairly good write-up but this is just not right:
> Being at a startup is hard in a way that is almost indescribable to anyone who hasn’t experienced it.
Being at a startup as an employee isn't necessarily hard. You hear this type of "startup is so hard" because running companies well is hard and successful startups will often grow faster than their founders are able to grow their own ability to run companies, which makes their own job challenging. And a lot of startups are poorly run in ways that are entirely avoidable (often as a result of their CEOs not being able to grow as quickly as their company) which can make life hard for the employees as well. But this isn't a necessary part of the startup experience.
Startup work is much more chaotic than established companies. It is much closer to my creative experiences of directing a feature film and being in a touring band than it is to my time at big software companies. Instead of having clearly set requirements, you have to figure out the requirements as you go, and it's different and unique challenges every day.
One very easy way to disprove this is by looking at the experience of startup employees after acquisition. Now the product is no longer offered by a startup, but by a big company. Do things get easier now that they are at established companies? Do you now have clear requirements?
Of course not - in many cases, things get drastically more difficult. Instead of being able to pursue a clear vision, you often have to deal with tons of inter-organizational politics. You have all these extra stakeholders that are trying to influence you, some with good intent, others not so much. More processes need to be imposed, there's more pressure for standardization/integration both in terms of the product features, implementation, not to mention processes.
And this is about apples to apples it gets.
Another way to think about this is that there's a reason why startups are successful despite the massive advantages incumbents and larger companies enjoy. It's because certain things are harder at bigger companies. Then how could it be that being at a startup is uniformly harder? Startups exist in large part because they are more efficient or make things easier. If you flip that around, it means trying to do some of those same things at a big established company can be objectively harder.
Startup work isn't necessarily more chaotic than established companies. Assuming we're talking about tech companies, working at a big company doesn't mean you have "clearly set requirements" and working at a startup doesn't mean you don't have "clearly set requirements." You can have a well-defined role at a startup or a fluid role at a big company.
She clearly means from an executive point of view given the context. And having been an executive at two start-ups and one middle-sized company, I agree with her 100%.
Given the lack of details, my guess is that your role at those startups is wildly different from your role at the middle-sized company and also that these aren't necessarily comparable companies outside of size and age. 3 is also a stupidly small sample size for what it's worth.
You're moving the goalposts, but keep on digging I guess. I suppose your anecdotal and theoretical stories trump Tracy's lived ones and mine as well. No reason to continue this discussion.
I'm not moving the goalpost, you are. You're not the only one with lived experience and having had a job and founded a couple of companies doesn't allow you to generalize to come to the conclusion that:
> Being at a startup is hard in a way that is almost indescribable to anyone who hasn’t experienced it.
Because this simply isn't true. The point is also not that my experience trumps yours - the point is that this isn't generalizable and you're not comparing apples to apples.
Being at a startup doesn't have to be hard, at any level. And you and Tracy are certainly ascribing difficulties that arise from having responsibilities that are at times beyond your own capabilities and being extremely emotionally invested in the success of the company to being at a startup.
I'm not making a grandiose claim that being at a startup is indescribably hard. There are lots of hard jobs.
I've also had executive roles at startups, personally know tons of founders and tons of people that have worked in executive positions at startups and tons of other people that have worked in big tech companies, management consulting firms and investment banks, big law firms and so on. An executive role at a startup is simply not some type of outlier experience from a difficulty perspective. It all comes down to core competencies.
The issue here isn't that Tracy hired someone who doesn't have startup experience, but more that she hired someone who had been removed from day-to-day technical execution for decades, whose core competency at this point was dealing with bureaucratic complexity at a scale that simply didn't exist at her company and expected him to operate effectively at a level where you need to be significantly more hands-on.
This has nothing to do with startup vs big company. If you put this person as a line manager at a big tech company, it wouldn't go so well either. On the other hand, big tech L6/L7 type managers would be perfectly fine in these roles.
Not quite what I'm saying here but a similar perspective:
Most non-startup jobs tend to be well-defined and come with a pre-existing business strategy and existing resources, such as a project codebase and existing at least semi-working solution to which one can inspect and add to.
Contrast this with startup companies, where it's often required to explore and build completely new things from the thin air of the ether. I'm not saying other jobs don't also have elements of this, as new projects and opportunities do emerge, but being at a startup is definitely an extreme situation and arguably a different game. In the meta lens, it can be viewed as the act of mining the veins of market realities for golden ideas.
It's for the risk takers and adventurers. I've witnessed many a great engineer learn it's too undefined which can be uncomfortable, and is not a good fit for them.
It's nothing personal, along the exact same lines as some folks who can't stand working for a large company.
Different strokes and all that. This form of diversity is one of the beautiful things about the spectrum of humanity. In aggregate, it works!
A lot of startups jobs are well-defined and have a pre-existing business strategy. In fact, in my experience, startups can even be much less fluid in this sense than big companies, because startups are funded for a much narrower mission based on a very specific vision, whereas big company often has a huge scope within which there's tons of ambiguity as to what to pursue.
A lot of these types of statements generally are made by founders whose relative role at the startup (C-level) is much senior than their past or would-be role at larger companies (entry-level or close). Or early employees who got to be much more senior within a startup than they had been at a larger company. This just isn't an accurate statement for the rank & file or when you compare people at similar levels across companies.
It was painful going through the enterprise focus transition along with a nonsensical reorg imposed by the aforementioned Big Tech VP. One day we had focused platform-specific teams working on satisfying customers, the next we were moved to cross-functional feature teams and focused on enterprise features that (from our perspective) no one ever asked for.
I also felt the sting from mediocre engineering managers. I remember sitting down with Tracy and Ralph at Uptown Bar and giving them both barrels on what I thought of several managers. To their credit those managers weren't working there very long after that conversation.
IIRC Ralph asked if I wanted to move to being a manager and I declined but in hindsight I think that was a mistake - we needed good management in engineering more than we needed my code.
Another thing that hurt us was hiring a bunch of PMs. Most of them were condescending, ignorant, or both... but suddenly they were telling the engineers who had built everything what to do? IIRC we could have cut that department down to two people with no loss.
The leader of this product team was a manager that just didn't seem to be doing his job, only pushing paperwork and giving scatterbrained presentations. I never did find out why he was kept on so long. I think I very cheekily asked Tracy one time which of his relatives worked at Y2K or Sequoia such that he couldn't be fired because it was clear everyone in engineering was fed up with his nonsense. I'm pretty sure at least several top engineers quit due to that guy specifically.
Either way I don't regret my time at PlanGrid. It was a great team and I'm proud of what the team did and what I did.