How to Become Linus Torvalds (The H)

Sometimes Linus is wrong, sometimes he's right, but the fact is that he probably knows in more detail about almost anything he bothers to question, and does so from a position of intelligence and experience. When he's wrong, and proven so, he apologises and moves on. When he doesn't know, he defers to someone who does.

When it comes to subsystems he doesn't care about, or understand as deeply, he cedes control to other maintainers who *do*. It's a knowledge-economy. Those who know, do. Those who don't... well... don't. Thus the people that know best float to the top of the economy and come out as maintainers, massive code contributors, release managers, etc.

Who here hasn't complained about having a boss/manager/supervisor that is incapable of doing the job of their underlings, doesn't understand how things work, has to have every little technical detail explained to them, etc? They might be great socialisers, maybe even good businessmen, but at the end of the day if they want to stick their noses into how things are run, they either have to know how things work (and prove it, with actual results, when they take control) or concede to those that do. There is no shame in saying "I don't understand this, but I know one of you guys will probably have a better understanding and you can explain it to me / do it for me / explain to the others why we do such a thing".

It's only when we get "middle-management" and business-managers, who have *NO* clue how their underlings do any of this stuff (e.g. "if I put twice as many programmers on this problem, it'll get done in half the time!"), sitting at the top of the scale that things go wrong from the point of view of people underneath them - the business might make more money, the customers might be happier, but the people underneath *know* whether something is wrong or right and when/if it's going to bite back.

The management style is a knowledge-skill-hierarchy. If you know better, can prove it, and convince everyone else that it is better with facts, you end up at the top of the heap - people will wait for your approval, approve your oversight, not question your authority. If you're just a code-monkey that wants to just get a quick bodge into the code, you'll be listened to, but generally overruled - by people who *do* know the code better and could rewrite your code in an hour if they really saw the need for it.

That's how things *should* work in business too, but unfortunately they don't in the majority of businesses.

Never work directly under someone who couldn't do your job, if pushed. Never work under anyone who *can't* recognise that you know better than them when it comes to your specialist areas (e.g. CEO's telling you how to program, rather than what the want in the end-product, and then not listening to your objections / comments).

Listen to the people that know better than you. Nobody can ever know everything about every part of their business and if you fail to listen to those that know better, or fail to admit your own weaknesses, you will lose good talent and/or fail at managing that talent.

Say "I don't know, but Bob will...". It's part of the rules of workplace happiness. Bob is happy that he gets recognised for his talent and things that affect him come under his control, the person asking gets the right person for the job, and you don't look a prat by claiming to know *EVERYTHING* about every single interaction your company has.

You don't ask lawyers to sweep the floor, and you don't ask cleaners to write contracts. Linus knows this, but has a vast range of expertise himself and is able to demonstrably show when he's right. That means he gets listened to and unofficially becomes a "leader". Management style? It's called doing his "job" and doing what he thinks is right.