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.
Just like engineers do sometimes.
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).
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.
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.
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.
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.
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.
The fact that some meetings add value doesn't mean all or even most meetings add value.
My analogy holds; page fault handlers add value. They also incur a heavy cost and you want to avoid faulting if it at all possible.
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.
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.
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.
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 - build something that does, maybe a remote controlled rocket
3 - we can start and work on that direction
4 - there are software that generates stories already
5 - same kind of software can be adapted to generate music, you could use machine learning to follow the same logic from the part we have to finish it
6 - you can start and do incremental updates each day
7 - Thats actually a nice idea to use computer vision to tts, someone could actually make this as an app to google glass
8 - not long ago circulated a story about the army developing something like this
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.
At least I am pretty sure...
Impossible becomes a crutch very easily.
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".
Nope. But we might be able to do NYC to LA in minus 3 hours on a fast drone.
...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.
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.
It's not an attitude. It's just the harsh reality of being in an environment where you work most efficiently when you're not being interrupted.
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.
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."
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.
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.
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.
This is why the good start-ups do well because they manage better which results in better output.
I've been part of the not-so-good start-ups myself and have experienced "career managers" first-hand.
I totally don't understand how they got their in the first place though. I just don't get it?
It's probably one of the cases where reality exceeds the worst exaggerations one can come up with.
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...
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?
The existence of the list seems as much an example of what not to do as are its contents.
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?
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.
because that would be a great video.
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.
All-- having worked with Ken, he's indeed awesome.
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.
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.
"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.