4 ms·

Read my comment above[1] and do the opposite. If you are not in management, manage your expectations to do what is best for the whole. For example, if you are

by tyre 10y ago

Read my comment above[1] and do the opposite. If you are not in management, manage your expectations to do what is best for the whole. For example, if you are the first employee, do not expect to lead your team just because you were there first. Here is the positive advice version: 1) Do not promote based on tenure. Talent is not 100% correlated with age or (especially) time at the company. Oftentimes the employees who thrive at early companies are generalists or love diverse responsibilities. These may not be the problems you're trying to solve later. 2) Do not promote into people management roles based on individual contribution. To be sure, knowing the problem domain is important, but, especially in engineering, people management skills are orthogonal to programming ability. If your HR structure caps salaries for individual contributors to the point where ICs are forced to move into management, either change that or (if you determine there is a maximum value of an IC) stick to it. 3) Choose values that are specific to your company and can be reasonably disagreed with.[2] Stick to them, especially when it is hard. Values don't matter when it is the easy choice; they are defined by what you do when shit gets hard. 4) Narrow meetings to only those who provide knowledge which is Mutually Exclusive and Collectively Exhaustive. If someone does not add something that no one else in the meeting does, remove them. If others need to be updated, send them a summary. Having an opinion does not qualify it as useful. This is also the first rule of being a CEO and the first rule of hiring product managers out of MBA programs. 5) 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. If you are changing metrics to optimize results, your metrics for success are too in the weeds. Success is defined by what gets done, not how it gets done. 6) Have one clear decision maker. Do not appoint decision makers who are unwilling to make the right decision if it upsets everyone. Of course, they should be able to explain their reasoning enough that it shouldn't upset everyone, but the first objective is not that everyone feels like they got everything they wanted. Different people have different goals at cross purposes. 7) Effort can correlate with success, but certainly does not predict it. Writing code at 2am is not a priori more valuable than at 2pm (in fact, the opposite is likely true.) People who pride themselves as being busy will naturally resist automation. As with most things, quantity is not the same as quality. 8) Know what pedigree tells you. Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it. Similarly, thriving at a large organization does not predict the same skill set as thriving in a start-up. Because someone works at Google doesn't mean they have any idea how to build Google; because someone is at a startup does not mean they can turn your company into a startup. Hope this helps. [1]: https://news.ycombinator.com/item?id=11702549 https://news.ycombinator.com/item?id=11702549 [2]: I wrote a few sentences here: http://seneca.systems/values http://seneca.systems/values

GlideCleanser 10y ago
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).

by tyre 10y ago

GlideCleanser 10y ago

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).