The Virtue of a Manager
I never managed a group larger than 5 people, luckily for the people in the group (perhaps more so for those remaining
outside). Good managers are hard to find, which is the basis of my self-motivating motto: "This job could have been done worse".
Such is the background for the hereby presented pearls of wisdom assortment. As to "The Virtue of a Manager" title, it's a
ripoff of Paul Krugman's exquisite title "The Conscience of a Liberal". "The Private Part of a Self-Important Self-Description" is
a great template.
***
A prime virtue of a manager is the ability to take pride in someone else's work.
No, seriously. We've recently deployed a debugger internally and an algorithm developer had a look at it. I knew it was good,
but it's used to debug the sort of thing algo devs hate: code with an anal-retentive performance focus. So the last thing I
expected was praise, but praise it the guy did.
Now, I had previously known proud moments from having done things myself, and here I had this proud moment with 90% of the
work done by someone else. And I'm telling you, it was just like the real thing.
***
The defining trait of a manager is the distinctly wide gap between responsibility and understanding.
By far the funniest spot to have a gap at, hence the easiest target for a low blow: try to make jokes about a gap between
one's teeth and you'll soon be exhausted, but this here is gold. This is mean-spirited though. Imagine living with a gap between
your responsibility and your understanding and everybody laughing at you β how would that make you feel? Show
compassion.
***
One can have the title of a manager or nominal reports for any of a number of reasons:
- An HR system with per-title wage ceilings: can't give someone a raise without faking a title.
- A diametrically opposed case: some forms of brain damage cause people to accept lower paychecks given more
impressive titles, larger rooms, etc.
- Someone is
too senior to report to a team leader but doesn't want a team to report to him, either.
- ...
In a roomful of managers, how do you find the real ones among this variety β not "real" as opposed to incompetent or
unimportant, but "real" as opposed to fake?
There are several cues, for example, only real managers can have other managers report to them. But the perfect,
if-and-only-if discriminator is that real managers don't write code. (The precise rule is that they can spend up to 2% of their
time on a favorite piece of code without getting disqualified.)
***
The principal function of a manager is being the responsible adult.
Some managers occasionally point this out in frustration, both mourning their technical skills which dry up during their
current gig where they only get to exercise adulthood, and because being the adult means getting tired of the annoying kids. A
gal who both managed and met literally hundreds of managers during her career in some consulting agency said "Now I
really understand management" when she got to babysit.
This is why I have hard time believing management can be taught β you can't teach adulthood, it can only result from people
growing up by themselves. I'm not sure if this feeling is fully aligned with reality, but quite some very successful managers
never went to a management school (at least one of those is somewhat
critical of MBAs), and some of those who went say it was worthless in terms of useful things learned.
The opposite is also true: childishness is fitting for a programmer. We were two fake code-writing managers in a meeting with
one real one, and at one point the real one said: "Let's not be childish about this". The technically correct reply to her would
have been "I'M NOT CHILDISH ABOUT THIS, HE IS!", but I suppressed it for tactical reasons. Some time later I told her: "You
don't want us to stop being childish about this, not as long as you're interested in our output as programmers. Recall: the
reason you aren't still programming is because of not being childish enough to truly enjoy this sort of game."
And in fact since she started managing 20 programmers, she's been talking about her work all the time, which she didn't when
she was programming. Well, some people like to play and some prefer to babysit. (I'm not sure where this leaves the
quasi-managers who write code; presumably some are the elder and most responsible kid while others are the most restless who
invent games for the gang.)
***
I've recently got a driving license. One thing I learned was that someone pushing his (presumably broken) car along the road
is a "driver" as far as the law is concerned. I find this counter-intuitive, probably because pushing a car is not categorized
in my head as "driving experience", but, at least in Israel, that's the law.
Likewise, doing the work of three people is not what most of us associate with "managerial responsibility". However, if
you're given two reports without a drive of their own to work, that's what your responsibility will be.
***
A manager will have favorite words. For example: acute (critical), priorities, agenda, rationale, integrity (shoot this
manager first), responsibility (ownership), stakeholder.
Keep laughing at them. Once you become a manager, you'll have favorite words whether you want it or not β it is useless to
resist the dynamics inherent to your situation. My favorite word is "dynamics". Its connotations are deep and its applicability
wide β heartily recommended.
***
Managers get to do a lot of knowledge-free decision making, which necessarily drives them insane. Here's how the manager's
bipolar disorder works.
During maniacal periods, the manager is the only one who can do anything around here. This frequently happens when the
manager is under external pressure, and he feels that control is slipping out of his hands. He's trying to compensate for his
lack of knowledge by immense concentration and willpower. (Managers always have ample emergency supplies of both.)
"Concentration" translates to an ability to derive general and far-reaching conclusions from insignificant details, then
"willpower" translates to aggression.
Then depression follows: "Don't bother me with details". This results partly from exhaustion quickly arrived at during the
mania (especially if reports were wise enough to not argue with the manager, letting his efforts defeat their own purpose.) The
manager has delivered his trademark concentration and willpower, so he no longer feels guilty on that front. However, he's
overwhelmed by information and (rightly) feels that he doesn't know what's going on. He decides it is none of his business and
concentrates on the Big Picture (does nothing). Usually, the cycle repeats upon a new wave of external pressure.
Awareness of the management cycle on behalf of the manager himself can help soften the cycle but not eliminate it. It is up
to reports to apply counter-cycle measures by scheduling most work into depression periods when it is least disrupted. Special
attention must be given to long-term projects, frequently characterized by a prolonged depressive apathy period at the beginning
followed by a period of maniacal frenzy lasting until the end.
***
There's a naive brain model in the spirit of "the brain has a
reptilian part, a mammal part and a human part". For example, if a student fails to answer a question in an oral exam with his
human brain, the mammal brain feels bad about it and complains to the reptilian brain. The reptilian brain then cheerfully
replies, "Who's causing the trouble? Oh, that little guy behind the table? Not to worry β I'll kill him". The higher brains then
supposedly suppress this β "What do you think this is, reptile β Jurassic Park?", and the tension is translated into
sweating.
The manager is the team's reptilian brain; he doesn't know enough to do real thinking, but he's good at "taking
responsibility", bargaining, fighting, socializing, etc. A manager doesn't know how to implement the feature, except for
suspecting, based on experience, that it will conflict with a couple other features and it will take a week or three for the
whole thing to stabilize (with him taking the heat when things break during those weeks). Therefore, instead of technical advice
(which he might be otherwise qualified to give), he'll propose something which solves the problem at his favorite social
plane:
- Prioritize the feature away, delaying the implementation until forever
- Negotiate the feature away, by talking to whoever wants it out of it for something in return
- Redefine the feature away, by reducing the scope to the few scenarios which absolutely can't be ignored
- ...
Do not drag management into anything you actually want solved. Presented with a question, the manager will answer it by
killing the little guy behind the table, so only go to him if you really want that. And once awakened, he might take a lot of
sweat to suppress. (If he's really a programmer posing as a quasi-manager, the chances for an actual solution can actually be
worse: he's more likely to feel guilty about his managerial ability and use the opportunity to exercise and develop that
ability, instead of using his technical ability to think about the issue.)
***
There's this quote from The Mythical Man-Month, supposedly by a pessimistic manager:
All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy
god-mothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps
it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection
process works, the result is indisputable: "This time it will surely run," or "I just found the last bug."
This is backwards. In reality, programmers are the more pessimistic people. Perhaps it's because experience teaches
programmers that programs always have bugs while teaching managers that programs always ship. Perhaps it's because the
programmer is the one with the actual knowledge, and the ignorant are always optimists. But however the selection process works,
how many programmers have you seen saying "it will never work" and how many managers?
A programmer might be more optimistic locally, hoping in vain to have fixed this one piece of code where he has the illusion
of complete understanding. However, it is invariably the manager who believes that everything will work out. A
programmer can't really believe that because there are so many things nobody even understands that are yet to be faced.
But the manager is used to knowing little and understanding less, and thus has learned to translate uncertainty to optimism.
In fact a programmer can learn it, too, in the areas which are of little interest to him. I know a programmer who doesn't care
about optimization and who consequently describes others' efforts to fit a program into a given performance budget as doomed to
success: "It runs at the word of command" β a programmer's expression of the managerial worldview worthy of a seasoned
manager.
***
We don't know how to test for programming ability. The best tech companies spend 5 to 10 interviews to solidly confirm that
the candidate knows what is taught during the first 1.5 years of an undergraduate CS curriculum. Other processes measure less
accurately by asking less relevant questions; the inaccuracy is somewhat ameliorated by the lack of precision β the non-uniform
quirks of interviewers and general randomness of the process eliminate biases, causing all kinds of good candidates to sneak
through the gates.
It is well known that we can't find out during the interview what we inevitably find out once someone gets the job, but what
are the corollaries? Here's one I've heard a lot: trust recommendations more than interviews. Here's another I haven't: let
others interview and get the new hires, then steal the best.
(Objection: the first recommendation is good for the company while the other is only good for the manager following it. Well,
"competition between managers over team members isn't a zero-sum game β it improves teamwork across the company", this one we
weasel out of in a snap.)
***
We have a VIP club at work called Bottleneck, its principal activity being the collective purchasing and consumption of
alcoholic beverages. The club operates during work hours (regular meetings held on Thursdays, emergency meetings scheduled upon
arrival of packages from abroad). Our room being the headquarters, I'm naturally a member. By now the club has shifted to
high-end liquors at prices causing the consumption to contract to a sip per cup of coffee, but originally it was affordable to
actually drink.
I noticed that minor alcoholic intoxication has a notable impact on my programming ability. I can still lay my hands on the
right variable, but by the time I do I forget what you do next with these things. There's that handy member somewhere in it, dot
something, but dot what?
However, managerial ability is not affected. Things I can do just fine following a meeting of the Bottleneck club include
progress monitoring, planning, risk assessment, general technical advice, and requirement negotiation. Now that I think of it,
perhaps the managerial functions are affected for the better.
Really liked this one. I wonder how long does it take you to write an
article like this one?
The interesting thing about driver, so I've heard, is when you drive
along with instructor, he is considered driver and you're the
passenger.
A very clever and programmer-way circumvention of the principle that
every driver ought to have driving license.
@Sergey: This particular one spent a lot of time in drafthood, so I
don't know how many hours actual writing took, but almost certainly more
than 4 hours since that's how much stuff written in one sitting and
published immediately takes.
@Ilyak: Well, the instructor does control the higher-priority brakes
and when that's not enough, they're quick to grab the steering wheel, so
I wouldn't call their legal status a gross hack to the code of justice;
perhaps there's even a legal design pattern for shifting responsibility
this way (The Delegation Pattern?)
I'm not a manager but I still have a favourite word, it's
"semantics."
You're on your way to management then.
Yossi are you sure your not suffering from Peter Principle?
So many answers to choose from. "No, I'm enjoying it". "Not nearly as
much as my reports".
This is a public blog, so obviously I won't seriously discuss my
private life, nor will you be able to guess much (correctly) about
it.
That came from left field.
"We donβt know how to test for programming ability."
Anecdote from a friend of my family, whose mother was a COBOL
programmer when COBOL was less than 10 years old:
When she (the COBOL programmer) was a math major in college, one of
her profs approached her to take a test given by a major USA bank
(National City Bank, IIRC). The purpose of the test was to find skills
useful to computer programming. It consisted of five questions, and the
candidates had three hours to complete it.
Scores of 4 or 5 would result in interviews. Scores of 1 and 2
obviously didn't. And scores of 3 usually indicated cheating.
The woman whose daughter told us the story got 4. She went on to work
for that bank until she retired.
One of the other candidates came in hung over from a late party the
night before. He scored a 5.
How I wish I could see that test.
What, absolutely no details about the questions themselves? This is
teasing. It's still interesting how they used few hefty questions
instead of many small ones, the latter being the modern
IQ-tests-inspired wisdom aimed at statistical significance.
I can think of at least one manager β a VP for that matter β who
doesn't fit the bill.
And I want in on the Bottleneck club.
I don't know which bill you mean but I think I know which VP you
mean; superhuman abilities are outside of the scope of this blog.
Bring a bottle of admission fee to room 401 and you're in.
@Yossi:
I know. Like I said, an anecdote. When I pressed the daughter about
the test, she admitted total ignorance about it. She knew only what her
mother had told her on the matter.
Then again, if her mother had any reticence to go into detail about
it, I can understand completely. She took the COBOL listings with her on
seaside vacations, and one time, that was a *good* thing.
In the "early days" of programming (I use the term loosely), it
wasn't well understood how such a vocation based on symbols and abstract
math could disrupt one's life outside the office. Some managers are
still not up to speed on that, so I recommend "The Mythical Man-month"
to them, just to shake them up.
Hmm, I think for management MBA is worthless enough but a finance
degree is probably the best bet. In a way it's better to have complete
ignorance than to have half ignorance of technical items when it comes
to management, so you don't have expectations when you ask people what
is possible and what kind of time and resources it takes and how much
use it is to you. Then you don't get bogged down in technical matters,
which are not your function and you are sure to have a team where all
that can be done for you.
Just put everything into Project and you keep track by what each
person says and use that to determine in the future what the real
expected cost and benefit of anything you do will be. For some people it
might be 2.0 for others more like 4.0. Instead of trying to unravel
things like who is smarter or where things went wrong over time you will
see to a good degree in a quantitative form just how much use people or
departments are to the company. This is usually used for larger projects
and especially when bids for big money projects are involved, but it
works with a group of three to four people just as well. As long as you
can assign valid numbers to the benefit section you can easily determine
whether a project is worth doing or how well an employee is working out
given enough time. Anyway, that has seemed to be the only really
effective way I have seen things done, other than that it should be
largely hands off. And of course, never tell anyone this is how you do
things so they don't try to game the system and don't go into a panic
when they realize you have their worth measured down to the cent.
***
Unlike management, finding a good programmer is still an open
problem. I have only at most suffered through four interviews and can't
even imagine someone with other options sitting through ten interviews,
and after I realized I had completed a whole business model for them
I've decided two is the absolute limit. If someone is willing to put a
random stranger through that kind of hell what will they do with their
employees?
I guess with trivia questions, you at least know they have learning
ability, but there is grave danger here. The semiautistics can go into
some seriously messed up and elaborate coding 'paradigms' and with a
language like C++ where you need to be conservative in the use of its
features to maintain a pretense of stability the problem goes from
irritating to insanely dangerous very quickly.
But people who posture well or are conmen are good at talking the
talk and most techminded people who might interview them are probably
not great at weeding out people who are very good at this because they
can see what the interviewer wants and take control of the
interview.
So there's no perfect system, but I think you could make an arbitrary
but very fast method that's just as accurate as anything used to date.
Just have all the applicants fill out a list, or rather two lists.
Things that suck, and things that rule. With the broad instruction every
item should be three words or less and should somehow convince you to
hire them for the job at hand.
Then have your techie people argue over the list for technical
merits, and have the managers sanity check it just to make sure they are
not an actual serial killer and you are good to go.
Regarding "complete ignorance being better than partial ignorance"
for a manager: contradicted by most empirical evidence I know; even top
managers of many successful tech companies are very technical
(Microsoft, Amazon, Google), not to mention middle management.
Regarding "measuring worth down to the cent" based on numbers without
being able to comprehend the subject matter: a tested recipe for
disaster if you ask me. This is more or less how investments into the US
subprime mortgage derivatives were made. Bogle said something along the
lines of "never invest into things you don't understand"; I think "never
manage things you don't understand" holds just as well. (The manager is
necessarily doomed to very incomplete understanding, but it doesn't mean
he can do with none at all.)
Regarding "semiautistics": pop psychology is the worst thing since
non-sliced bread. I might blog about this sometime.
Regarding "conmen": an incompetent candidate posing as a programmer
wouldn't last 15 minutes with a competent programmer interviewing him.
The open question is how to rank reasonably competent people β those who
know the basics; currently about the only way is to hire and see.
Regarding the list of things which rule and suck β interesting. The
input to the candidates doesn't vary so they could prepare really well,
and it isn't clear what to make of "XML sucks", but still
interesting.
The management above is a bit novel and not used in the same scope.
This is not your decision making manager, but middlemanager. No decision
to make a project or any idea comes from him, hr id just the project
manager, which is where most software projects get wildly mismanaged.
Someone above says what to do, or it's something people are offering
money to do.
The real benefit with the lists would be there would be to avoid
internal strife like ms vs linux warfare. Mostly I just like its
arbitrary nature and would be interested to see what people put on
lists. My list for applying for a C++ programming job would be something
like:
rules:
templates
definable languages
exceptions (not C++)
simplifying problems
sucks:
const
heterognous inheritance
STL
Boost
templates
exceptions (C++)
long interviews
sliding into chaos over time
A "Microsoft fan" and a "Linux fan" should be able to work together
and most do, or so it seems to me. On the other hand, rules/sucks lists
may leave the reader unenlightened when the reasoning is kept out of
them. What if I like const because const globals map to ROM and you hate
const because of issues with const correctness and the C++ type system
and stuff? And I like STL because it's the only way to display
containers in my debugger and you hate it because of build times? Would
it be reasonable to conclude that we shouldn't work together 'cause of
fighting over this all the time, when (1) we should be able to get over
it if we are sane, (2) almost every pair of people will have several
incompatibilities in their rules/sucks lists and (3) some of those
incompatibilities actually come from weighing costs and benefits of
things differently because of differences in experience justifying the
corresponding rules of thumbs of both people β which you don't see from
the short lists?
I suppose you are right. It is a silly idea, though I'd like to
mention I had some items on both lists. It would be interesting to see
what sort of things I came across.
I think a very good programmer, is the one who can find someone elses
vulnerability and tell them about it, thats one. When he codes he has to
worry, well for many reasons am i making this vulnerable,very few will
have that ability. How clean his code is. Back in the day, i remember
when programming challenged me, if i cant be challenged enough, I simply
wont code. Ok they took the math out of it, ill simply say it. Not all
programmer do it for money, thats not there reason for programming, its
the challenge they thrive for. Thats why most of the games, that they
call games today bore me, i dont care about the graphics im worried
about the challenge, the harder the better. If you had a programmer that
thought like that, just imagine how good he would be, but for some
reason companies dont care about that and they should or there product
wouldnt be full of holes. I guess the moral of a story, having someone
that can find vulnerabilitys on other software's is a good thing,and to
be able to code at the same time and then thing about his code, well
thats something unique, i use to have a hobby before i coded,well it was
the reason i learnt to program. was to find vulnerabities ways in, i
wouldnt do it to harm, its just what i like doing, i know of one
operating sytem if you tell them of a vulnerability, theres a good
possibility you'll get arrested "Personal Experiance" here's my
conclusion why this happen. 1 β They found me a threat, yeah i could see
that but that wasnt why i was doing it. 2 β They have noone that can fix
it, The good programmer dont even have to have degree's. heres what i do
in a job interview, before they hire me, the first thing i ask can i try
to penetrate your software "The reason i do this, theres more than one i
test them, if it takes me 2 minutes to penetrate there software, then i
simply find them unworthy to work for and will even walk out of the
interview, because they dont care whats important, but i guess that isnt
what sells there product and ive noticed this. its a operating system,
got more holes than swiss cheese, what sold it it isnt because of the
programming ability, it was the buisnessman and brilliant he is for
that. Has made it a sucess, noone would of ever thought, not because it
was programmed better, if it was it wouldnt be so vulnerable. because of
the buisnessman who sold it, people like easy, my operating sytem of
choice is linux, but im not on linux right now. The way i prove this.
You take someone who uses windows and isnt use to having to work, 99
percent of the chance, he will not like slackware. Ive seen windows
users say linux isnt possible of that, when in fact it is. theres many
who do this and will go to the point of even saying they used linux for
years. alot of people dont know this Linux is the kernel the core, and
what they really have is a distro of it, convincing someone of that its
a endless battle, Linus Torvalds, Awesome Programmer, you should see the
art of his code, he doesnt code everything in the kernel now, he reviews
it if he dont like it, it dont go there, and its been seen over and over
when noone cant accomplish something on the kernel, theres only one who
can. Linus. If you got a programmer and right off the bat he ask how
much you gonna pay me, then you know he's only programming for the
money. Great Programmers do it because they love it and pay isnt a
factor, if he directly tells you that, hire the man, he will do wonders
and even have ideas,because thats what all flows in our heads is
ideas,security and the way its programmed. But programmers like that
well, lets say are hard to find and such programmers have never been to
school for it. Ask him what are his ideas even though you might think
its stupid, let him try and it might make you tons. I like how google
hires and people will argue, why did google come to our university and
not hire just a few people, and microsoft hired several. you can have
the highest grade in class, that doesnt make you good, they look for
something else. Btw ive heard programmers at google are treated very
well they even have a chef for there employs. i mean who could ever
dream of such a job. They have a idea and its in beta right now thats
brilliant real time email, called googlewave its now able to recieve
email right now outside googlewave but again its beta. It's impressed me
i might actually get rid of my instant messenger, im waiting on my
friend to get on and invite him to it and i will. so when i dont have
wave up ill get his message and i can answer it, and he will still have
the email and know what he asked, or if we both have it open we can chat
interactive, i can add more contacts to the conversation and decide when
they dont see the conversation, i can talk to 3 people, when theres 20
in the conversation and the others wont see but them and it be email at
the same time,thats brilliant that isnt all thats brilliant about it and
new things are added all the time, when it gets finished its gonna be
awesome. I actually dont know when this will be completed, but there
gonna change the way your used to email, that you would of never thought
possible. Well i think all things are possible, if i cant do it maybe
someone else will, ive even went to the extent of telling a employ at
the time of interview, I want you to enterview alot of people and then
if you find me a access to your company, then you hire me and you must
tell me why, it has to be something im wanting to hear, if they get it
right then ill get a job or its something i havnt noticed and they
explain it to me then and i understand it and only then i will take the
job. because i like working for a company that knows how important i am
to them and will respect me for it, it does wonders at the workplace and
yes the company makes money because of it. First question you should ask
a programmer, why do you program and he answers this, for the money, you
better send him walking because thats what he cares about nothing more,
now if you get this because i enjoy it and i like it. then continue and
ask him as a programmer what are some ideas youve had, just listen
because you think its dumb at the time, doesnt mean its a bad idea, a
programmer thats doing it for the fun of itand he likes it, chances are
he will do more for your company and if he is full of ideas all
programmers like that are. Having a programmer like that is good for
you. Just look what google is worth it will shock you they are catching
up with microsoft. and they were the most of the time a search provider.
google has projects going everywhere, there programmers even while not
beeing paid, as something to do made there own programming language, i
havnt tryed it but i will id like to see what can be done with it. thats
my main goal. bit to have programmers do that when they dont even get
paid is something in itself, Probably because they dont program for the
money, i hope that isnt the reason you do it.
bob wall of text is scary, paragraphs are your friend.
When you write, you don't write for yourself, you write to help the
reader read what you're saying.
If I edit bob's illiterate screed into something comprehensible, will
you post it?
I don't quite see why you'd want to pick it as a starting point, nor
what do you want to pick it as a starting point for. If you find this
interesting though, we could discuss it via email.
I have no idea what it says. I just thought that if I had to do the
effort of picking it apart to see if there's anything good inside, it
wouldn't be worth it unless other people benefited too. Kind of like how
cooking for one person can't justify much more than a sandwich.
I actually gladly spend half an hour or more to make a meal just for
myself, however, um, not unless the ingredients appear appetizing...
I'm not a manager but I often catch myself minding word
"implementation".
That's how you/he/she want the things to be done and how you/he/she
actually implement them.
This is very insightful and funny at the same time. It is also very
educating to me, thank you :)
It also got me worried: I find myself playing less of computer games
recently and replacing it with working on a personal project. Is it
because I just find programming more challenging (so I'm reinforcing the
child in me) or because I'm finding gaming to be a time waste (thus
becoming more adult and manager-like)?
I wouldn't like the latter, I'm afraid :)
Well, I'm the last person to judge β neither because having never
played that much computer games nor because having never invested that
much in personal programming projects, but because in anything
psychological, I find that I fit not as an expert but as a data
point.
Post a comment