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.
I can. I like working that way because it lets me focus and write really good code.
being around people, is more social, but I'm not writing code while I'm doing it. Which doesn't mean that it doesn't have its place, because it does (meetings are necessary to get a shared clear plan of how to work together on something, getting help on a problem or helping out with a problem builds trust/camraderie among team members)
> I'm tired of the old 'meetings suck, PM's suck' cliches
Just as I'm sure tons of programmers are irritated hearing you seem to suggest that working on their own is somehow bad or wrong.
> 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.
How did you get work done in meetings? By definition, meetings are stopping work to communicate; the most work-efficient approach is to optimize away the need for meetings as much as possible.
> By definition, meetings are stopping work to communicate
You have implicitly and uselessly defined "work" as "everything you do that's not communicating".
I can write code and solve problems all day long by myself. So can my coworkers and housemates. When we have meetings at work, we figure out which problems to solve and why. Why is it that the coding part is considered "work" and the meetings is considered "not-work"? I would just be a lone programmer working on subsets of the wrong problem without the meetings. Lately, I feel like the "work" gets done in the meetings, and I just tidy up afterwards (for a few days) by myself. That's because the answers are easy, but the right questions are hard.
Let's try this: meetings are stopping implementing to communicate. Or, from another perspective, coding is postponing meetings until new issues/questions have been solved.
> Why is it that the coding part is considered "work" and the meetings is considered "not-work"?
In kernel terms, meetings and PMs are the scheduler, and you are the threads/processes being scheduled.
Is the scheduler doing work? Yes. Is that work simply overhead required to keep the pipeline full and fair scheduling of work occuring? Yes.
> Let's try this: meetings are stopping implementing to communicate or from another perspective coding is postponing meetings until new issues/questions have been solved
Or to put this another way, meetings are a page fault interrupt that is taken because the necessary backing store (the solution to issues/questions) is not available.
They're almost pure cost. Spending any more time there than you absolutely need to is a waste.
> Spending any more time there than you absolutely need to is a waste.
This is a tautology. Spending any more time anywhere on anything is a waste. The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.
I agree. You asked "How do you get work done in meetings" and implied it was impossible. I argue that just because there is no work accomplished in your meetings or most meetings doesn't mean that no work can be done in meetings. No one anywhere is suggesting that valuable work is accomplished in all meetings. But when you suggest that no work is accomplished in any meeting, you're wrong.
I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist. My workplace is different. Since my most valuable work is accomplished in meetings, I wish I could be in meetings all of the time. The only reason I can't is because we frequently need long breaks to implement the work we did in the meetings. In fact, coding is a much heavier cost than meetings; unnecessary coding is much worse than unnecessary meetings and you want to avoid unnecessary coding at all costs (even though it's usually still quite fun). Just because you develop software doesn't mean you should spend as much time as possible writing code. Just because you produce code at work doesn't mean you're only working when you're coding.
> But when you suggest that no work is accomplished in any meeting, you're wrong.
This is where we disagree. Talking about work isn't tangible work. Talking unblocks work, to a point.
> I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist.
Given that my experience spans roughly 15 years, major corporations, small and large startups, in both management (director, VP, and C-level roles) and engineering (software, systems) I'm inclined to trust my experience that meetings are generally a work-substitution mechanism and a means of furthering political/social career advancement, and bad PMs (which is, sadly, most of them) are the worst offenders of them all.
Man, no offense, but you seem extremely short-sighted here. So when you and a couple coworkers are architecting a system, deciding what the pipeline of information flow is going to be, where the security holes may be, stopping any latency or unnecessary operations, and making sure the user knows how to use the damn thing on top of that - and you aren't writing code, but instead communicating with your coworkers - you don't think that's work? How could it not be?
What is work? Is it the typing of the code, the architecture of the software, or the decisions about what the software should do for the user? The latter 2 can be at least improved in meetings, where the clash of different opinions can produce a better outcome than just one person implementing their whims.
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.
We don't ask, because we've learned from both direct & indirect experience that we won't get it (and may be punished for asking). We're good at making something from nothing, we just do it and others expect us to; thus making most needs seem a matter of wants, and wants being looked down on as waste, we learn there is little point in asking for more.
You are a good manager, sensitive to how a little money spent on a good chair can make a great difference. Alas, you are not the only one subordinates are exposed to, and takes little for others to undo the good you did.
Can we get a snapshot of the internet at 6 AM each morning?
Can you send a physical package from Los Angeles to New York City in 14 minutes?
Can you write software that will province 100% accuracy of handwritings for all human beings on the planet? (That's arguably more possible than the Los Angeles example above, but only in theory)
Can you write software that will write the sequel to the Lord of the Rings?
Can you write software that will complete Mozart's unfinished Requiem Mass in d minor?
Can you get a complete list of valid email addresses of actual people on the entire internet, in all countries?
Can you write software that will convert what it sees through a camera as speech, thus allowing a blind person to walk around a city and have the software describe, in details, what the device with the camera is pointing at?
Can you create software that can replicate the artificial intelligence of a common fly, and be placed in a device the size of a hand-powered drone, with the ability to actually fly and avoid being hit?
2: Distance from Los Angeles to NYC: 2790 miles. Distance in kilometers: 4469.58. Kilometers per hours: 19,155, for arrival in 14 minutes. NASA's X-43A has a top speed of 10,000 km/hr (by comparison, the SR-71 has a top speed of 3,529 km/h). So NASA's fastest plane, the X-43A, could not make it in time to satisfy the requirements.
It is possible to say that sometimes in the future, perhaps distant future, all things are ultimately possible, but that's not what we're talking about, is it. We're not worried whether sometime in the future we will be able to zoom around the galaxy and perhaps Andromeda on wormhole ships, in fancy flights of the imagination that would even surpass the bounds of science fiction and enter the realm of fantasy. No, rather we get silly requirements from managers who wants these things delivered in the next twelve to eighteen months.
Also note that a data center that crawled the entire internet daily would probably have to re-implement Google, and even Google most probably doesn't crawl the entire net daily.
Software that generate stories already... Please. Name one bestseller in the past, well, ever, that was automatically generated.
We can put an ICBM on someone's doorstep ~8000km away in just over half of an hour. Putting a package ~4500km away in 15 may be doable. You just better be ready to catch it at a couple miles per second.
Oh, and Google glass is a freaking disaster. If someone has one at a party at my house, I will kindly ask them to take them off and put them in their car. If they refuse, I will kindly ask them to leave. If they refuse I will kindly remind them that the Los Angeles Police Department will help remind them that in my house, I get to say who gets to stay.
Many times management does not know enough to understand the explanations.
Given proper audience, many computer people are able to base their reasoning for rejection on actual physical laws and theories, but since management many times is unaware of these laws and theories of physics, management dismisses the claims of impossibility as "primadonna behavior".
...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.
Our skill is intense concentration. Imagine a soloist violinist mentally rehearsing his performance for later that evening. On the outside he looks sullen, near sleep. Inside, however, there's a 120 piece orchestra with the crazy Russian conductor, and the German harpist is plucking strings, and the soloist is counting in his head, watching the conductor, trying to perfectly time the moment when he begins moving the bow's horse hairs across the fourth string, vibrating his wrist, ring finger on the high e, indicating the moment of the hero's death and ascension to heaven, in the emotional denouement of the 45 minute piece.
Just as there are many people who neither appreciate classical music nor the skill, talent, and concentration required to play it well, so there are many people who neither appreciate computer programming nor the skill, talent, and concentration required to do it well.
As an aside, if you want to hear some fantastically good classical music, head over to youtube and search for the Vienna Philharmonic's rendition of Rimsky-Korsakov's Scheherazade conducted by Valery Gergiev at the Salsburg Festival in 2005.
>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.
Indeed. I had originally left off the ending, but a few people who previewed the essay told me they showed it to others (who don't know me), and they said they weren't sure if I was joking or serious.
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."
I'm assuming you never got to the "Afterword" (perhaps due to anger or frustration?), as it is at that point that the author reveals that the entire article up to that point is the exact opposite of what he supports.
This does of course make for the argument that perhaps this style of writing is not suitable for skimming, though I'd agree with another comment on this post that after reading the part about 95% of 3,875,000 equating to approximately 1,000,000, I was definitely more perceptive that something silly was going on.
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.
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.
have in mind that this will only work if you have great workers, that are able and willing to help theirselves. This attitude will be destroyed by continous bad leadership and will not come back very fast.
Tell me about it. Been there, done that.
But to be fair, if you have good management, they'll do a good job of hiring in the right type of people as well. So it works both ways.
Lost cause. He's dead set in his ways, and if you don't think he's the equivalent of management Jesus, you don't deserve a job. I've watched coworkers try to talk to him about his management style and get escorted out by security before the conversation is over.
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...
I can't tell if this is parody, or a parody of a parody, or a parody of a parody of a parody. The tone is very much like the original article, but as if written by a hypothetical Scumbag Steve software engineer rather than an imaginary Scumbag Steve management type.
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?
Sorry, I knew it was intentional but I mean, despite the sarcasm, it still feels condescending. Just the pure existence of an article with the title "How to work with women," no matter how accurate, would still be condescending and bigoted. It's because all women are different, just as all software engineers are different.
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 :)
I hated it for the same reason. I find this kind of sarcasm manipulative. The piece had me pissed off by the end until the reveal, which made me even more angry. Maybe as a talk it might be slightly more tolerable since you can presumably hear the sarcasm in the speaker's voice.
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.
However, I don't think it's only PMs who indulge in that behavior. I've seen managers and engineers (yes, indeed) do the same shit. Internal competition within companies is pure corrosion and it's always detrimental. I'm convinced that there are no exceptions to that.
The rare good manager is K-selective insofar as she intends to reproduce (scale) processes with quality and moral decency. If she runs a company, she won't hire before she trusts, and she'll make sure everyone gets credit and autonomy. Most managers are r-selectors, though; they over-hire, don't trust, and throw shit at the wall until something sticks.
The egoistic bad-guy PMs being described here are the ones who thrive in the typical r-strategist corporation.
It's what I'm focusing on as I study organizational decline. It turns out that the metaphor (reproduction of processes, skill sets, and values) applies to corporate life. The reason most jobs suck balls is that most companies are r-strategists.
The r-selective alpha male was the harem owner who treated his "wives" like chattel and invested nothing in his (hundreds of) children, most of whom would fail. It was "spray and pray". The K-strategist was the monogamist who treated his one wife well (often, as an equal) and invested heavily in the health of mother and children.
The r-strategist boss doesn't mentor employees, creates a sink-or-swim environment, and over-hires, generating internal competition, which is always toxic. The K-strategist hires more slowly but invests trust and interest in the people brought in. Of course, r-strategist companies grow a lot faster and, in many spaces, are much more "fit", but I believe that's going to change amid the convexity of post-technological work.
Essentially, I mean that technology is taking the boring, commodity work away from humans and the stuff that remains can't really be managed into existence.
"Post-technological" was terrible word choice on my part. I meant "post-technological transition" but there is no way anyone could have known that based on what I actually said.
The last transitions were 10000 BC (into agrarian) and about 1750 (into the industrial era). The technological transition is underway. We're probably 10-20% technological at this point.
I've seen people do this at my last startup, needless to say, they are now tanking. Close to a 100 million VC dollar going down the toilet... Those people got promoted really high too...
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.