Hacker News Reader

> What's the oppposite of active sabotage?

Isn't this exactly what an article like this is attempting to ask in the first place, albeit through irony and story-telling? I agree it's hardly ground-breaking, I guess it's just trying to make readers feel clever because (clearly) we'd never be stupid enough to do something like that. (Although it's worth far more to me, at least, when you get those articles saying "I did something stupid when I thought I was being clever," because if we're honest we all do things like that.) But I think OA is trying to discuss "how to run companies right."

> HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?

I interpreted this as being one of them.

How? He provides no tips or guidelines for what to do, only some snark about what not to do.

"Do Not Enter" street signs are useful.

It's the principle of "first, do no harm". Almost nobody follows it, but there are good reasons it is the first and in many circumstances the only real piece of advice that can be given. Look up 'via negativa' as well and daoist wu wei philosophy if inclined.

The point is to highlight common practices in this industry today that result in effective sabotage.

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 [2]: I wrote a few sentences here: http://seneca.systems/values

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

> the people most likely to understand your company's particular problems and history are those who have been around for quite awhile.

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.