| See, conversely I can think of semi-legitimate arguments arguing the opposite - which may explain why these patterns are so entrenched in the modern workplace. > Do not promote based on tenure Maybe not solely on tenure ala the government, but the people most likely to understand your company's particular problems and history are those who have been around for quite awhile. Having someone who can say "We tried A last time and it didn't work because of reasons B,C, and D so what's changed?" in a position of (relative) power is invaluable to avoid repeating mistakes. > Do not promote into people management roles based on individual contribution Agreed that someone who doesn't want to be a manager shouldn't be one, but experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team. Sure, just because you're hung doesn't mean you have to do porn, but it's easy to see why companies would be eager and even pressure experienced ICs to become managers. > Choose values that are specific to your company... Stick to them Why? Shouldn't we re-evaluate our values as time goes on and we gain new information? It's hard to imagine a contentious set of values (i.e. if your company values are "Don't be evil," then fine) that shouldn't be constantly re-evaluated as time goes on. > If someone does not add something that no one else in the meeting does, remove them. Ouch, this sounds like an insidious one that you could abuse heavily to do the committee thing that the OP rails against. If you want something to go through: Invite only people who agree. If someone calls you on it and asks why you didn't invite more opposition voices, reply "I didn't think Alice had anything to add that Marie didn't, so I didn't invite her." or even just feign ignorance in the name of small meetings. If you want something to get stuck in committee hell: Invite lots of people with different opinions that will never reach anything close to consensus. Don't invite any two people who agree, because "the other person isn't adding anything." > Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting That's suuuuper hard to do with anything that's even remotely considered a moonshot. It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success". > Have one clear decision maker Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker. > Effort can correlate with success It often does. > but certainly does not predict it It often does. > Writing code at 2am is not a priori more valuable than at 2pm This kinda sounds like you're shaming people who have different circadian rhythms. I know plenty of night owls who do their best work at 2am and take it easy after lunch. > Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it. It also might mean that they: * Know how to manage their time effectively * Are fairly mature and forward-thinking * Are good with delayed gratification * Are generally intelligent and capable of picking things up quickly because certainly people who meet those criteria often find themselves at places like Stanford (with luck thrown in, certainly). |
That works, if what you need is someone with substantial institutional knowledge. This isn't often the case, or the domain knowledge is not the most difficult part.
Would I rather have an incredible engineer with no local government knowledge, an engineer that knows government inside and out but has never worked for a tech company, or someone who has worked with me for years?
Depends on the role, needs of the team, etc. My point is that, too often, tenure is used because that's what's always been used. This is especially tough in startups, when someone has dedicated significant time and energy in the early days but just hasn't grown at the rate of the startup. It's a very emotional human decision that fights against our nature.
> experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.
I agree that they would be great at the technical aspects. That's oftentimes the least difficult part of running a team. People are hard.
> Shouldn't we re-evaluate our values
Yes! But either live up to the values you have or change your values. My comment was against having a set of values and ignoring them when they are inconvenient.
> It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".
You've proven my point. Upgrading Ruby is not an end in itself, it should solve some actual goal. There are many (performance, security, library compatibility, tech debt, etc.) but you should be able to list why we are prioritizing that versus other things.
>> Have one clear decision maker > Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.
This does not mean one person who does whatever they want. It means one person who, at the end of the day, owns the decision. By that definition the CEO is absolutely the one clear decision maker.
As CEO, if our company fucks up it is my fault. If I didn't know about it, it is my fault for not knowing about it. If it was some hire 4 levels down, it is my fault for creating a culture where a) that person could be hired and b) there weren't adequate checks in place.
To be clear, we will absolutely make mistakes. I'm not saying, "someone shipped a bug so that is my fault."
>> Effort can correlate with success > It often does. >> but certainly does not predict it > It often does.
We may just agree to disagree. I believe that effort is necessary but not sufficient for success. I have meant plenty of nice, smart, well-meaning, and hardworking people who were vastly unqualified for their roles.
I love them as human beings, but, especially in strategy or people management/leadership, results flat out matter. You can get better, but you won't train a 2 into a 10. It's about recognizing your strengths and weaknesses, then working in a role which emphasizes your strengths.
> This kinda sounds like you're shaming people who have different circadian rhythms.
My comment came off wrong. As a night owl, I'm definitely not shaming people for when they work. I'm shaming people who purposefully try to look hardworking by making it known they are working at irregular times.