I bet you Bob was great at launching new concepts but that taking oncall responsibility for crusty old code that he didn't personally write wasn't for him...
I agree, Bob is great. I think scaling a concept is also really really important. We need features but we need scalable frameworks and platforms to support these features. Bob's not going to write the distributed db system that makes his feature look good, but that also needs engineering. That too needs to be good enough to ship and no more btw, but it's more often the work of a team that has to slow down and think carefully about what it's doing, especially when evolving long-running platforms
Yes. I wished we recognized more often that hyperproductivity exists for these engineers with different strengths too. It just looks very different than Bob's twenty feature launches per quarter
Depends on what you compete on. If you compete on features and oncall is just some contractual obligation, then probably not, if you compete on customer service then perhaps yes
This is something of a circular argument. Bob doesn't waste energy on on-call duties, so he implements more features, so he's a prolific engineer, so he doesn't have to waste energy on on-call duties.
Yes exactly. I'm not sure whether Bob is a hyper productive engineer, but in any case, Bob is an engineer hyper focused at shipping new stuff out the door quickly. Which is great! We need Bobs. But we also need the company to run and scale, and Bob might not just be the right guy for that.