The reason why I haven’t been writing too much is that I work at a startup. No one tells you how much work it is. When things are going well, you are working. When things are not going well, you are working. For the last four years, I have maybe spent most of my time working to build an enduring institution that hopefully will stand the test of time. I do it for the sake of our customers and the future of computing. (I work at Railway btw.)
I don’t want to jinx it- but things are working. Growth is great, the team is great, and the product, mostly great. (Everyone notices the shortcomings of their own child.)
My last job, I worked on getting a universally reviled product to be less so. It’s nice to open up X or LinkedIn or our Emails and see kind comments pour in about what we are doing. It makes the long days worth it. However, there are times when it appears that your fortunes shift.
An outage. A bad feature. Employee trouble. You name it.
Some days just leave you feeling that no matter what you did, none of your pitches landed. All code that leaves your fingertips fail. Maybe it feels like the team hates you.
It happens.
For seed stage companies, that’s fine. Usually the stakes are low. It’s meaningful to serve 100 customers- but it’s different when you have tens of thousands of them. At some company juncture, the founder and/or the early team CAN’T put anymore hours than humanly possible into the business. This was a lesson I learned the hard way.
So you hire.
One of things that eluded me during this four year journey was really figuring out a hiring model that stuck. Rabois has barrels and ammunition. You may have heard an average Whartonite grad talk about A players and B players. …But each of those analogies fail to consider what really allows a company to grow beyond a gaggle of people.
In the past, we would hire for a function. The function wouldn’t grow beyond the original person. …Then the responsibility would boomerang back to the original person. Therefore incurring a scaling penalty and lack of capacity to “do things” in an org. As companies scale, it’s imperative that they walk and chew gum. You will need to be able to juggle more balls, faster, and better over time.
For good government: you shouldn’t have to think about if you have good policing, revenue collection, utilities, and more. They are all disparate functions, and they *should* just work.
For good companies, revenue collection shouldn’t be at the forefront. Same goes for planning processes… engineering standards… you name it. There are a bunch of functions that should *should* just work so that your company can focus on litigating and then solving customer problems.
Successful companies have state capacity.
When I think of über successful hires at Railway and at other startups, usually people have come in, taken responsibility for work, and then built on those streams of work with processes or infrastructure that make it sing in their absence. Usually the trait that I see on the business side of the house is this core desire to build an institution. (In contrast of building a fiefdom, where they expect to rule in perpetuity.)
However, in my conversations with these successful hires (and ones that I have pitched in to help advise on) the common thread with those people are those who really think about their role as a systems game, where they seek to get themselves out of the system and constantly observe, monitor, and test what they make. It’s like they themselves are founders, and they view what they are doing as part of their own founding story.
In their wake, they leave institutions with the operating manual behind.
It’s like you can put that same person to run a government agency and they would wrap their head around it.
To witness this? Divine. To work with them? Even better.
In that vein, it makes sense why Sheryl Sandberg had the success she did, and it’s a bit confusing why other policy people tend not to do well in startups. Curious to see if other people have other examples where gov and business knowledge played out in their favor.