111–120 of 287 posts
I particularly don't understand why an organization would hire a PM for an internal infra team. It's like hiring a PM for Go to design the features of Go. Funny enough, executives from Google love to do this kind of things. I'd thought Google's infra engineers would be perfectly capable of driving the features of their infra services.
I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof): 1. Too-technical leaders: As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup…
1. Writing-intensive hiring process
This is controversial for some, but I have the personal advantage of having previously made The Worst Hire of All Time -- one that forced me to accept that using resume + interviews as the sole (or even primary) criteria left me extraordinarily vulnerable to Problem Engineers. We ask candidates not just for a portfolio of their work (and analysis samples and so on), but also ask them values-based questions[0] -- the answers to which are astonishingly revealing. Our review of candidate materials constitutes the bulk of our hiring process.
2. Transparent compensation
Another one that is surely controversial, but in my professional experience, an amazing number of anti-patterns arise from the scramble compensation -- and usually not for itself per se (that is, not for the marginal dollars), but rather for what it represents in terms of validation, power and so on. Making compensation transparent forces some measure of organizational health -- to say nothing for the bright light it shines on any institutionalized inequities.
3. Uniform compensation
One that even more people will find controversial. ;) When we wrote our blog piece on this 2+ years ago[1], we assumed that it wouldn't last as long as it has -- but it honestly is more important to us now than ever before. Especially as we go to expand the team with roles that are often less well compensated (e.g., customer-facing roles), the fact that we explicitly compensate them as well as everyone else allows us to attract extraordinary folks to the company. We still don't know if this is going to last forever, but we have seen so many incredibly benefits from it that we have stopped burdening it with asterisks.
4. Very, very careful hiring
We are deliberately lean. We add people to the company very carefully, and we have no one inside the company who is incentivized by the size of their team (see #3, above!). When we add people, we keep a sharp eye on versatility and intrinsic motivation. This allows us to do more with relatively fewer people -- helping us avoid the foot-guns you've outlined. That said, it is also not without side-effects: a consequence of this is that we are extraordinarily selective, which means we have many more people that want to work at Oxide than we can reasonably accommodate -- and it can be really, really hard to turn down someone who you think will likely be successful!
[0] https://docs.google.com/document/d/1Xtofg-fMQfZoq8Y3oSAKjEgD...
[1] https://oxide.computer/blog/compensation-as-a-reflection-of-...
1. Go from "more to gain" to "more to loose" thinking.
2. Growth slows and either ethics or vision are sacrificed.
Both of these are natural, and the people will have to change. In most companies, eventually growth stops (at least growth driven by the original vision). Eventually you really do have more to lose than gain. The signal these transitions are happening can be spotted by proliferation of guardrails and process controls, and a cultural change towards risk aversion. The drive is to make everything predictable, controlled and safe. The focus is no longer on acceleration, and is on momentum.
Earlier quoted context omitted.
Maybe by avoiding fast scaling, which implies avoiding VC money.
The first startup I worked for was a slow-growth company that had slowly expanded over 7 years to only about 50 people. A dinosaur in startup terms. It still had the same problems as above. Expanding slowly doesn’t automatically protect you from these things.
Earlier quoted context omitted.
As a corollary of these people problems, I would add: 1. Not correcting problem hires fast enough. First time founders are often too hesitant to give negative feedback, demote a too-technical manager who should have stayed an IC, or remove a problem employee who isn’t working out. The anecdote that comes to mind is a local startup that hired a C-level executive’s UI designer friend into their VP of Product role. He w…
Ray Dalio talks about this in his book "Principles." The specific advice he offers is "hire slowly, fire quickly."
I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof): 1. Too-technical leaders: As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup…
Early on, you joined the company knowing exactly who you get to work with. You were probably involved in hiring for a while too.
But at some point 100+, you’re put on a team with people you’d never met, never hired, and might not vibe with.
A direct, “let’s hit the ground running” attitude runs up against a ex-FAANG person with softer personality, prefers a “compliment sandwich”, and wants to write a 50 page technical specification before getting started.
It almost feels like the "efficiencies of scale" you get from large organisations (e.g. specialised people for recruitment, people matters, quality assurance, user research etc.) are not really efficiencies. Perhaps it's better to grow the organisation by repeatedly cloning the smallest effective team you ever had, rather than creating a more "efficient" organisational structure. How those "mini-companies" communicat…
I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof): 1. Too-technical leaders: As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup…
Im a bit anxious and introverted and thus like to get my part done and focus on other things.
This always results in rest of the team losing will to go far and beyond.
I dont know what to do about it, beside aknowledging it exists.
Do you say that ppl like me should simply quit and go working at sewege?
I dont think I like that idea. So what can I do if thats just how I am ? I cant seem to change how others see ppl like me.
I'll raise your spark for complete destruction. Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof): 1. Too-technical leaders: As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup…
Then they start looking at the app and questioning every decision calling everything they don't have context on "technical debt"
I've seen it a few times. I told a new VP of Eng he was being asinine because he wasn't there for the original problem, decision, or timeline and saying we made a bad call is just showing ignorance.
Thankfully, He pulled me aside later to thank me and asked for more background on it. After hearing the whole story he agreed. We did the right thing.
Now, that could have gone the other way. And I've seen it happen. When it does, it sucks.