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).<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>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, <i>BEFORE</i> 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.<p>Once a wrong abstraction is in place, the more code/people depends on it, the more effort it takes to refactor
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.<p>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.<p>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.<p>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.<p>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.
"And remember that A players can recruit other A players, but B players can only recruit C players"<p>In point one they list this. In point 3 he mentions his biggest mistake was hiring someone with starpower from a public company who didn't work.<p>Unless the founder is an A player in terms of recruiting everyone hired would be a C player or less. And in point 3 we learn he is not an A player.<p>How do B players ever get hired?
Love seeing you back in the game Tracy.<p>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.<p>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.<p>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.<p>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?
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
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.<p>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.<p>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.
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.
Parroting the A player, B player cliche means that anybody you've hired has a choice of thinking either YOU are an A player, or they are a C player.
On the whole, this is a fairly good write-up but this is just not right:<p>> Being at a startup is hard in a way that is almost indescribable to anyone who hasn’t experienced it.<p>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.
Ha! one of the slam-your-own-dick-in-the-door moves that startups seem destined to repeat<p>Seen it SO many times when startups decide they need "grownups" in big positions to be credible externally