I know where this article is coming from, but I guess I've just been lucky to work with a lot of great PMs that:
1) Are a firewall between upper management and the development team.
2) Organize the priorities of the team and help the developers to get the most done in the limited amount of time that they have.
3) Follow up on business requirements and the thousands of other details that need to be figured out so that the client doesn't say, "what the hell is this?" on delivery day even though it is precisely what they asked for (but not what they wanted).
4) Praise the team for the great work that they've been doing and make their successes known to management.
I've worked with as many (or more) crap developers as I have PMs, so I'm always wary of articles like this. It's way too easy to talk about how management/sales/PMs/etc don't add any value to the process (which is patently false) while lionizing the work of the developer as if they are all dedicated, hardworking, and never, ever, make mistakes.
This "us vs. them" mentality that exists is ridiculous. We are all trying to accomplish something. Some are better than others at it. But don't shit on someone else's job, complain about how you want to be left alone, and then wonder why your career isn't going anywhere.
Cute. Nice fake list. Nice writing. The "true" list at the end, like a Hollywood ending, was probably not necessary.
Now my list:
1. You don't "work with" software engineers. We don't even "work with" each other. If you don't learn anything else from this, get this: we work alone. Always. Even when we think we don't. Sure, we occasionally get together to plan, analyze, discuss, white board, even "pair program" whatever that means, but sooner or later, we all sit down alone and do what we do. With that in mind...
2. Leave us the fuck alone! If you see a software engineer looking at a screen and typing, that means we're BUSY. Do not interrupt. Do not call. Do not text. Do not IM. Do ask if we're busy (WE are!). Do not tap us on our shoulder. And whatever you do, don't just stand there waiting for us to stop typing (We won't; that's a test of wills you will lose). Just send an email. That's it. When we break, we'll check email and reply. If you don't write well enough to communicate with us, then learn how to.
(If my language seems a little strong, it's because I feel so strongly about this. Nothing is more frustrating to us than having work to do and being kept from doing it when we want to. We often need large blocks of time and room to focus deeply.)
3. Don't try to understand how we work, what makes us tick, what turns us on, or the "secret" to making us more productive. a. All those things are different for every one of us. b. We don't even know what they are ourselves.
4. Don't patronize us. Sure, we all appreciate beer, donuts, chocolate, and foosball, just like everybody else, but don't bother trying to get something from us with a gimmick. It may work once or twice, but then never again. That shit doesn't even work on your dog. Why do you think it would work with us?
5. Provide us with the resources we need. This is pretty binary. Do this and get results. Don't do this and don't get results. For the most part, we're fairly easy. A comfortable chair. A decent machine. Good lighting. Fresh air or HVAC. Peace and quiet. Decent facilities. Specs or requirements > 50% accurate. (Forget about 100% accurate; none of us has ever seen that; we'll live with 50-80%.).
6. When we tell you we need something, believe us!.If we need clarification on something, get it. If we need more time, give it to us. If we need access to someone/something, make it happen.
7. Never lie to us. We are used to our machines always telling the truth. We insist on no less from other humans.
8. Contrary to common belief, we do not hate the following classes of things, we just hate idiotic instances of them: meetings, status reports, timesheets, processes, procedures, policies, mission statements, motivational posters, HR, reviews, interviews, reports, specs, and team-building exercises.
9. The best thing you could possibly do for us: everything you must and not one thing more.
> We don't even "work with" each other. If you don't learn anything else from this, get this: we work alone.
I don't get this. I like working in a team, and like working with people. I can't imagine working alone all the time. I am more productive when I am with the team, and interacting with the team than when I am alone in a room.
I know everyone works differently, but almost no one seemingly is willing to discuss an alternate version of this. I'm tired of the old 'meetings suck, PM's suck' cliches. When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.
We can make lists until the cows come home, but passing them around amongst ourselves is not going to make one bit of difference.
How about actually asking for all of those things?
For instance, only once in 25+ years in this business have I heard an engineer ask for a decent chair. He got it. Period.
On that same theme, let's start giving the same honesty and information we demand from others. The "impossible" example in the article is meant to be humorous, but is actually painfully true. Rarely is something really impossible, just hard, complicated, insanely expensive, inconvenient or downright useless, but rarely "impossible".
But we bitch about wanting truth, honesty, information and not being patronized. Guess how seriously that will be taken as long as we don't reciprocate.
...this attitude is indicative of a lot of engineers that end up being resented by the rest of the team -- expecting to be treated differently than others, secretly believing their skills make them superior.
>The "true" list at the end, like a Hollywood ending, was probably not necessary.
I sometimes think that, being of an inherently analytical bent, engineers tend to underestimate the inability of others to add facts and observations together into a coherent truth.
As I read the original list, although I saw it clearly for what it was, I felt my blood pressure rise. It fairly accurately describes the apparent attitudes of some senior managers I have suffered over the years.
7. Never lie to us. We are used to our machines always telling the truth. We insist on no less from other humans.
I've started to think of this as an impedance mismatch between engineers and managers. Our "subordinates" (computers, compilers) tell us we fucked up at our jobs by giving them nonsensical instructions. "Your brackets don't match and I don't know WTF to do. Line 87, fix your shit or I'm doing nothing." Being nonsentient machines, they don't fear getting fired so they tell the truth.
We get a kind of feedback from "subordinates" that managers never, ever get. We program them to come to us speedily with bad news. Managers, on the other hand, program us (by having temper tantrums and occasionally turning off peoples' incomes) as well as each other to do the opposite.
No need to be that harsh. It is good enough to recall a fact,a software engineer is a producer but a product manager is an overhead.
I think he needs to go back to school. He even doesn't know what the job description of a software engineer is. He says:"Software engineers write code ..."
Moreover, he contradicts himself. He compares himself with Steve Jobs. He says:"Don’t bother with the details." But, Jobs said:"Details matter. It's worth waiting to get it right."
The sad part is that my current boss follows his "do not" list to the letter.
Yes, I'm working on leaving. Eight hours of that crap in the office, then usually 2-3 hours of job hunting in the evening after working in the yard or otherwise getting the house ready to sell.
The even sadder part is that the "do not" way of working is the norm and the "do" is the exception in majority of the workplaces. And what these people in leadership positions don't realise is that it's good management that creates great results which directly affects the bottom line.
This is why the good start-ups do well because they manage better which results in better output.
Start the morning with some coffee and sarcasm. Fun read. Though it might be problematic that some managers might take it serious. Usually the dumb ones.
I think that's why he said (paraphrased) "I troll U" at the end. Most software engineers would get the joke immediately, but many managers wouldn't.
The problem is that executives never read to the end of anything. They still have to call their kids (or interns, same thing really) in to show them how to work a "scrollie bar".
There was a very large company that required every employee to submit a 63-word summary of accomplishments per quarter (do they still do this?) I pointed out, rather publicly, that this was precisely the low-end of adult reading speed (3.5-8.0 words per second being the typical range) times the short-term memory loop (18 seconds). That didn't go over well.
Ah, managers. They sure love sunbathing in the Yucatan, but that bright point just above them isn't the sun...
Is it just me or is this article a bit condescending? This makes it seem like software engineers are exotic creatures that normal people require a guide like this to work with. What if someone made "How to work with PMs" or better yet "How to work with women"? I feel like one of the core problems between PM<->Eng is that both sides stereotype each other, this just perpetuates that.
The rules in the afterward make sense but if you need a guide on the internet to get you to do those things, I'm not sure I want you to become a great PM in the first place. The problems here seem to be more fundamental, like: Don't be a psychopath. I think the rest of the rules should follow naturally.
Has the profession of PM become so bad that we need "don't be a psychopath" posts?
Grrr. I was going to do a presentation on exactly this next week, and have just put a presentation together on management that pretty much says all these things but Kenneth has done a far better job. I guess I'll go in the corner and sulk. Just kidding :)
A good guide, but not an answer to all. Software Engineers are humans, and everyone of them are different. So, if you want to work with Software Engineers well, get to know them first.
This is the point I agree with the most. When I first started working with developers, a person I highly respect said to me that the most important thing you can do when working with anyone in a technical field is to win their respect. You don't have to be an ace at development or engineering yourself. You don't have to know the craft as well as they do, but there are many things you can do to earn your delegate's or colleague's trust and respect.
It wasn't officially recorded, although audience members might have captured some of it. I wish it had been: I can only really give this talk once.
As an aside, if you're not familiar with the Ignite format it's great. You have 20 slides, and each slide auto-advances after 15 sec. So I really had to practice the timing.
I wish this post were written in a less sarcastic tone and more directly. It's an important topic and deserves to be less off putting than it otherwise seems at first.
[+] [-] hvs|13 years ago|reply
1) Are a firewall between upper management and the development team.
2) Organize the priorities of the team and help the developers to get the most done in the limited amount of time that they have.
3) Follow up on business requirements and the thousands of other details that need to be figured out so that the client doesn't say, "what the hell is this?" on delivery day even though it is precisely what they asked for (but not what they wanted).
4) Praise the team for the great work that they've been doing and make their successes known to management.
I've worked with as many (or more) crap developers as I have PMs, so I'm always wary of articles like this. It's way too easy to talk about how management/sales/PMs/etc don't add any value to the process (which is patently false) while lionizing the work of the developer as if they are all dedicated, hardworking, and never, ever, make mistakes.
This "us vs. them" mentality that exists is ridiculous. We are all trying to accomplish something. Some are better than others at it. But don't shit on someone else's job, complain about how you want to be left alone, and then wonder why your career isn't going anywhere.
[+] [-] bmj|13 years ago|reply
Just like engineers do sometimes.
[+] [-] edw519|13 years ago|reply
Now my list:
1. You don't "work with" software engineers. We don't even "work with" each other. If you don't learn anything else from this, get this: we work alone. Always. Even when we think we don't. Sure, we occasionally get together to plan, analyze, discuss, white board, even "pair program" whatever that means, but sooner or later, we all sit down alone and do what we do. With that in mind...
2. Leave us the fuck alone! If you see a software engineer looking at a screen and typing, that means we're BUSY. Do not interrupt. Do not call. Do not text. Do not IM. Do ask if we're busy (WE are!). Do not tap us on our shoulder. And whatever you do, don't just stand there waiting for us to stop typing (We won't; that's a test of wills you will lose). Just send an email. That's it. When we break, we'll check email and reply. If you don't write well enough to communicate with us, then learn how to.
(If my language seems a little strong, it's because I feel so strongly about this. Nothing is more frustrating to us than having work to do and being kept from doing it when we want to. We often need large blocks of time and room to focus deeply.)
3. Don't try to understand how we work, what makes us tick, what turns us on, or the "secret" to making us more productive. a. All those things are different for every one of us. b. We don't even know what they are ourselves.
4. Don't patronize us. Sure, we all appreciate beer, donuts, chocolate, and foosball, just like everybody else, but don't bother trying to get something from us with a gimmick. It may work once or twice, but then never again. That shit doesn't even work on your dog. Why do you think it would work with us?
5. Provide us with the resources we need. This is pretty binary. Do this and get results. Don't do this and don't get results. For the most part, we're fairly easy. A comfortable chair. A decent machine. Good lighting. Fresh air or HVAC. Peace and quiet. Decent facilities. Specs or requirements > 50% accurate. (Forget about 100% accurate; none of us has ever seen that; we'll live with 50-80%.).
6. When we tell you we need something, believe us!.If we need clarification on something, get it. If we need more time, give it to us. If we need access to someone/something, make it happen.
7. Never lie to us. We are used to our machines always telling the truth. We insist on no less from other humans.
8. Contrary to common belief, we do not hate the following classes of things, we just hate idiotic instances of them: meetings, status reports, timesheets, processes, procedures, policies, mission statements, motivational posters, HR, reviews, interviews, reports, specs, and team-building exercises.
9. The best thing you could possibly do for us: everything you must and not one thing more.
10. Top ten lists suck (except this one).
[+] [-] sheri|13 years ago|reply
I don't get this. I like working in a team, and like working with people. I can't imagine working alone all the time. I am more productive when I am with the team, and interacting with the team than when I am alone in a room.
I know everyone works differently, but almost no one seemingly is willing to discuss an alternate version of this. I'm tired of the old 'meetings suck, PM's suck' cliches. When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.
[+] [-] onemorepassword|13 years ago|reply
How about actually asking for all of those things?
For instance, only once in 25+ years in this business have I heard an engineer ask for a decent chair. He got it. Period.
On that same theme, let's start giving the same honesty and information we demand from others. The "impossible" example in the article is meant to be humorous, but is actually painfully true. Rarely is something really impossible, just hard, complicated, insanely expensive, inconvenient or downright useless, but rarely "impossible".
But we bitch about wanting truth, honesty, information and not being patronized. Guess how seriously that will be taken as long as we don't reciprocate.
[+] [-] tsunamifury|13 years ago|reply
...this attitude is indicative of a lot of engineers that end up being resented by the rest of the team -- expecting to be treated differently than others, secretly believing their skills make them superior.
[+] [-] frobozz|13 years ago|reply
I sometimes think that, being of an inherently analytical bent, engineers tend to underestimate the inability of others to add facts and observations together into a coherent truth.
As I read the original list, although I saw it clearly for what it was, I felt my blood pressure rise. It fairly accurately describes the apparent attitudes of some senior managers I have suffered over the years.
[+] [-] michaelochurch|13 years ago|reply
7. Never lie to us. We are used to our machines always telling the truth. We insist on no less from other humans.
I've started to think of this as an impedance mismatch between engineers and managers. Our "subordinates" (computers, compilers) tell us we fucked up at our jobs by giving them nonsensical instructions. "Your brackets don't match and I don't know WTF to do. Line 87, fix your shit or I'm doing nothing." Being nonsentient machines, they don't fear getting fired so they tell the truth.
We get a kind of feedback from "subordinates" that managers never, ever get. We program them to come to us speedily with bad news. Managers, on the other hand, program us (by having temper tantrums and occasionally turning off peoples' incomes) as well as each other to do the opposite.
[+] [-] drd|13 years ago|reply
I think he needs to go back to school. He even doesn't know what the job description of a software engineer is. He says:"Software engineers write code ..."
Moreover, he contradicts himself. He compares himself with Steve Jobs. He says:"Don’t bother with the details." But, Jobs said:"Details matter. It's worth waiting to get it right."
[+] [-] snake_plissken|13 years ago|reply
[+] [-] touristtam|13 years ago|reply
[+] [-] pointyhatuk|13 years ago|reply
[+] [-] fotbr|13 years ago|reply
Yes, I'm working on leaving. Eight hours of that crap in the office, then usually 2-3 hours of job hunting in the evening after working in the yard or otherwise getting the house ready to sell.
[+] [-] krmmalik|13 years ago|reply
This is why the good start-ups do well because they manage better which results in better output.
[+] [-] alekseyk|13 years ago|reply
[+] [-] Kurtz79|13 years ago|reply
It's probably one of the cases where reality exceeds the worst exaggerations one can come up with.
[+] [-] seivan|13 years ago|reply
[+] [-] michaelochurch|13 years ago|reply
The problem is that executives never read to the end of anything. They still have to call their kids (or interns, same thing really) in to show them how to work a "scrollie bar".
There was a very large company that required every employee to submit a 63-word summary of accomplishments per quarter (do they still do this?) I pointed out, rather publicly, that this was precisely the low-end of adult reading speed (3.5-8.0 words per second being the typical range) times the short-term memory loop (18 seconds). That didn't go over well.
Ah, managers. They sure love sunbathing in the Yucatan, but that bright point just above them isn't the sun...
[+] [-] ttrreeww|13 years ago|reply
[+] [-] rian|13 years ago|reply
The rules in the afterward make sense but if you need a guide on the internet to get you to do those things, I'm not sure I want you to become a great PM in the first place. The problems here seem to be more fundamental, like: Don't be a psychopath. I think the rest of the rules should follow naturally.
Has the profession of PM become so bad that we need "don't be a psychopath" posts?
[+] [-] lotyrin|13 years ago|reply
The existence of the list seems as much an example of what not to do as are its contents.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] krmmalik|13 years ago|reply
[+] [-] goyalpulkit|13 years ago|reply
[+] [-] michaelochurch|13 years ago|reply
[+] [-] dsdjung|13 years ago|reply
[+] [-] krmmalik|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] mvkel|13 years ago|reply
The reality is, not all developers want to be "left alone," just like not all developers want to talk to people.
Why not invest in the person and tease out _how_ they want to be interacted with instead of making assumptions one way or the other?
[+] [-] rcavezza|13 years ago|reply
I think he should make the bold NO in the slideshow much more noticeable in the blogpost.
The sad part is that most PMs I know skim too and will have all the wrong takeaways from this post.
[+] [-] ricardobeat|13 years ago|reply
[+] [-] hcarvalhoalves|13 years ago|reply
[+] [-] GhotiFish|13 years ago|reply
because that would be a great video.
[+] [-] kennethn|13 years ago|reply
As an aside, if you're not familiar with the Ignite format it's great. You have 20 slides, and each slide auto-advances after 15 sec. So I really had to practice the timing.
[+] [-] jschuur|13 years ago|reply
[+] [-] ojbyrne|13 years ago|reply
[+] [-] Scottopherson|13 years ago|reply
http://www.nczonline.net/blog/2012/06/12/the-care-and-feedin...
[+] [-] wallunit|13 years ago|reply
[+] [-] _pmf_|13 years ago|reply
[+] [-] grigio|13 years ago|reply
[+] [-] antonwinter|13 years ago|reply
[+] [-] asah|13 years ago|reply
All-- having worked with Ken, he's indeed awesome.