Fog Creek Software
Discussion Board

Non-Technical Program Managers

This isn't so much a question as a suggestion for a Joel On Software essay.  Maybe you agree with me, maybe not.  No doubt your opinion will be more tempered than mine, given my biases... but I digress:

My organization has in recent years been overrun with program managers who seem better-equipped to make decisions about polo shirts and khaki pants than about technical matters.

They foment confusion by misusing distinct technical terms as if they were interchangable.  They're oblivious to technical nuance.  Worst of all, they have no natural defenses against the influence of weak engineers.  (Hmmm, maybe the weak engineers are the real problem here... Maybe software companies don't need technical PM's.)

Obviously, I'm a bitter curmudgeon whose judgement is a bit skewed by personal frustrations and nostalgia for the days when a little flame mail went a long way to nip a bad idea in the bud.  But what's the more tempered perspective?  How technical do PM's really need to be, relative to the technical depth of their environment?  Am I way off-base here?

Thursday, February 26, 2004

Ah, polo shirts and khaki pants. I miss Redmond. Where else can you go to the Gap on Sunday, come back to work the next day, and find twelve other program managers wearing the exact same thing you just bought?

I used to say that Program Managers who do not have the respect of developers are not going to be effective because they won't get anything done. In my day on the Excel team the developers ate untechnical program managers for breakfast. It sounds from your anecdotes that you've seen some teams with the worst of both worlds: weak program managers and weak developers.

The truth is that the Program Management gene and the Software Development gene are mutually exclusive. The perfect program manager is a software developer with user empathy, organizational skills, and the people skills of a sorority leader -- and there just aren't enough of those to keep 45 buildings under control. At some point someone decided that coding was an expendable skill for this job, and, guess what? Who interviews potential program managers at Microsoft? Other program managers. Remember A's hires A's but B's hires C's?

The only reason I had any success at all as a Program Manager was because I have two -- that's right, two -- complete sets of DNA. It's called the quadruple helix and only I have it. And I avoided the Gap entirely: after one terrifying oh-my-god-did-I-just-pass-MYSELF-in-the-hall? incident too many involving a boldly colored striped sweater, I resolved to chose my polo shirts and khaki pants from the other 27 perfectly good polo shirt stores at Bellevue Square Mall.

Talk to Microsoft program managers about their roles. They'll always tell you things like "our job is not just to run with the ball, but to find the ball in the first place!" or something grandiose like that. OK. So the programmers think they're deciding everything and the program managers think they're deciding everything. How can they both be deciding everything? They can't. Who is really deciding, then? Let me give you a hint. Of the program managers and developers you know, on the whole, who has better people skills? eh? speak up boy, I can't hear you. Duh! Of course it's the program managers. You knew that. Developers couldn't people-skill their way out of a summer intern party at BillG's lakeside mansion. Developers have such weak people skills they can't even imagine what people skills could be used for, other than the purely theoretical concept of getting a theoretical date ("I ... like ... big BUTTS and I can not LIE..."), so it's no wonder they're not even aware of the secret that I can finally reveal today.

You know how the really good Program Managers make you feel like you're doing all the important design work, and they're just a gopher, taking care of dumb bureaucracy like "dealing with users" and "dealing with marketing shit" and "writing lame-ass specs?"

Guess what. Number one required skill in a program manager is learning to make software developers do what you want by making them think *it was their own idea.* Yes, it requires a polo shirt to pull this off, but an average program manager does it three, four times a day and for the most part pulls it off. I've read entire self-published "books" by ex-Microsoft developers who detailed their sophomoric Microsoft careers in insanely boring detail, including an entire chapter about how stupid and irrelevant program managers are, and yet they never once realized they were being manipulated the whole time -- the sign of a brilliant program manager. A brilliant program manager makes it all look effortless! Which is not hard when you're dealing with a person whose favorite comeback is, "I didn't give you the wrong answer, you asked the wrong question!"

Can you imagine the phat skilz it takes to manipulate a developer into doing what you want, while simultaneously appearing to be just a airhead Club Med Gentile Organizateur? Not only do you have to erase your ego ("oh, what a smart idea you just had, Mr developer!") but you have to do so *while appearing to be a self-centered preppy*. Sean Penn couldn't pull off a role like this as well as a merely average Microsoft program manager.

Joel Spolsky
Fog Creek Software
Friday, February 27, 2004

Oh, beautiful.  Beautiful.

Edward Becker
Friday, February 27, 2004


Friday, February 27, 2004

Have you considered taking a step or two outside yourself and considering the possibility that you are fundementally wrong on this point?  I don't mean about the premise that an ideal program manager needs to manipulate the developers by making them think that his ideas are theirs.  I just mean that you might be misjudging how good you were at this and/or you might be projecting a bit onto other program managers.

Of course I have to admit that I have never had the pleasure of working with a good program manager.  My experience is that good (let alone great) managers of any kind are in short supply.  I suspect it's because so many people are promoted into it and don't really buy in to the idea that it is a separate talent/skill set.

name withheld out of cowardice
Friday, February 27, 2004

That's a completely bizarre idea -- stepping out of myself? What would that look like? Would my skin and flesh sort of crumple to the floor while my self walked around? Or would it be like walking around the hallways of Building 16 and seeing 10 other people wearing the same khakis? :)

One correction though -- at Microsoft nobody is promoted into Program Management -- they're hired directly out of school for the career. The one mistake Microsoft does NOT make is promoting perfectly good software developers into management just because they were good coders.

Joel Spolsky
Fog Creek Software
Friday, February 27, 2004

Well (yes I get you were joking) in the metaphor I picture myself as either incorporeal and observing myself and others as a sort of 3-d movie or I put myself in the place of a specific other person (usually someone who seems angry at me or clueless on something I consider obvious).  In the first case I try to see how I come off looking to others.  Often I seem like a dick.  Then I try to decide if I should make an effort to seem less so.  The answer tends to be yes but over time I lose concentration and revert to seeming like a dick (fine, I admit it, being a dick).

In the rare cases in which I see myself stepping out of my skin leaving my underlying muscles exposed to the atmosphere I also imagine myself in extreme pain and dying of an infection.

BTW- your correction isn't so much a correction.  I didn't mean to imply that Microsoft does this.  Much as I dislike Microsoft, I do see that they knew what they were doing in terms of creating software for consumers.

name withheld out of cowardice
Friday, February 27, 2004

I've often fantasized about developing multiple personalities in order to live vicariously through myself.

Friday, February 27, 2004

>Developers couldn't people-skill their way out of a summer
>intern party at BillG's lakeside mansion.

I've attended one of these.  However, it was just at Bill's Summer House on Lake Washington -- the mansion was still under construction. 

When Bill arrived, the geeks swarmed him and attempted to demonstrate their intellect via thinly veiled "questions."  I was told that one asked Bill, "Do you think it was Windows 3.1's great performance or incredibly robust feature set that lead to its dominance?"  The geek's self esteem was instantly revoked when God Himself said "That's the stupidist question I have ever heard."

I remember that the difference between PMs and developers was often summed up with the insulting expression "You're such a dev!"  Usually the developer had just said something like "Well, it's not really a bug because...."

Friday, February 27, 2004

Joel you jest??

The part about managers & developers being genetically different may well be true . Have you ever heard of the "Reciprocality" ideas of Alan Carter. Quite a few people have sussed that a mind-type that can create great software is not the same as that to prepare a 6 hour Powerpoint Presentation on how to make the business customer focussed whilst synergising our strategic leverage.

Anyway...the part about Prog Mans having best people skills. They may *think* they have, but... has anyone else ever suffered a project lunch with a manager who thinks they're one of the lads...but isn't? The deafening, awkward silence. As soon as manager leaves, though, everyone starts chatting (about Star Trek, Nano Tek, whatever) and before you know it, we're all planning a night out clubbing together or something. The social awkwardness is actually  created by the manager!

Viewers of the UK comedy "The Office" will know what I mean and I guess many others will, too. Social conduct witnessed by a teams manager is non-genuine. He/She can never know what the team is really like until they cease to have the power over them.

Point being that these managers think, subjectively, that they have better people skills, but this is not the objective truth. They hear the geeks discussing chaos theory and believe that no real social interchange is happening. Wrong. There's more to social skills than wittering on about the best club to use at the 16th hole at Bigshots golf course. More than forever stating "I'd never drive a car more than 1 year old".

Too many managers I've encountered have faulty logic that goes like this:

1) There's loads of easy money in IT
2) I want easy money
3) Therefore I'll work in IT
4) But I don't have an iota of technical skill
5) Therefore I will manage

Can you see the flaw? As Joel says, good technical does not equal good manager.
Equally important: bad technical does not equal good manager. Yet this assumption is even more common!

Friday, February 27, 2004

I believe Sun Tzu wrote something similar in The Art of War. I'm not one of those freaks who can quote chapter and verse, so this is loosely paraphrased -- eh, it's a translation anyway -- but it went something like this:

"The best general, when the battle is over, is one whose soldiers say 'We didn't need him. We could have done it ourselves.'"

Ancient wisdom, still true today (though I hesitate to take the PM-as-general analogy with any degree of literalness).

John C.
Friday, February 27, 2004

pms are more like the arrogent lietenants in vietnam who get fragged at the first opportunity

the artist formerly known as prince
Friday, February 27, 2004

Some of the comments in this thread reflect a slight misunderstanding of the role of Program Managers at Microsoft.  The role tends not to exist at many Silicon Valley companies -- if it does, it's called 'Product Management' and tends to report into the marketing vp.

Program Managers at MSFT are part of the Engineering organization.  There are typically a handful of them in a group.  It's important to note that dev and test do not report to the PMs at all -- our job is to make sure there's good coordination and communication between all the folks on the team.  There are lots of "flavors" of PMs -- some are great at organization and only so-so technically.  There are others (like me) who were devs in the past, and who still think in code -- my best strengths are in helping to design and architect features of our product.  I too have the quadruple helix :)

Anonymous Microsoftie
Friday, February 27, 2004

I wanna be a PM!  ;)

Friday, February 27, 2004

prince, take your hand away from that grenade.

Exception guy
Friday, February 27, 2004

My friend worked as an intern Program Manager at Microsoft. I was impressed and asked her what she did. She said "oh, I walked around and asked each developer what he thought he should do next. He would tell me, and I would say 'ok, do that'." I wasn't so impressed then.

So, perhaps a small minority of PMs are these brilliant visionary manipulators, but my guess is most are not.

Friday, February 27, 2004

The entire PM dynamic is summed up in eight words:  "All of the responsibility; None of the authority."

Which amazingly enough boils down to three words:  "Spec and ship."

Unlike most PMs at MS, I have actually had a career in IT outside of MS, rising through ranks from dev to management to executive management.  I have never seen a role, including my stints as a consultant and business owner, which so closely resembles herding cats as the PM role does.  Of course it involves letting others think the idea was theirs, swallowing your own ego at appropriate times all the time knowing nobody else will, and negotiation, negotiation, negotiation.  What is hard is negotiating when you have no bargaining position, a position in which most PMs find themselves far more often than anyone else realizes.

Perfectly Normal Beast
Friday, February 27, 2004

Anonymous - it sounds like your friend had learned the first order every competent Rupert learns whatever the field - i.e. "carry on serjeant / nurse / lads..." etc.  After a while learning from the people they're in charge of, they're allowed to give real instructions.  It's the one's who think they know what they're doing that you have to watch.

a cynic writes...
Friday, February 27, 2004

The best managers can fake at least a little expertise...even if they have none. At least they might get "dinosaur respect" (like Sid in UserFriendly)

John G
Friday, February 27, 2004

I think geeks need organizational leadership courses so they get the concepts of responsibility, authority (line, staff, functional) and accountability.  The manager's prime directive "get things done"...if that means whipping some and bribing others to get it done, then they have basically performed management.

My manager however lacks morale building, flexibility, rushes schedules to eliminate requirements and has developers do own testing. They violate the "sloppy test" horribly. Basically, we are often handed forms with labels and blanks and we sometimes have no clue what kind of rules or validation there will be. It's basically expecting the developer to perform as a guerilla architect while being treated like a glorified secretary. Basically, I'm looking (and will be out soon) was a real bait n switch.

John G
Friday, February 27, 2004

What Joel apparently fails to realize is that the good software engineers *know* the PMs try to make us do what they want, while they think that we think it was our own idea. It's the old "I know, and you know I know, and I know you know I know" routine.

Keith Moore [exmsft]
Friday, February 27, 2004

"Ah, polo shirts and khaki pants"

Hm.  I wear polos and khakis, and I am mostly a developer.  What does that make me?

(small company employee, that's what)

Joel, I really like the style and bravado of your essay.  But I find it hard to believe that program/product Management is just a glorified sales job.  I understand the role more as "getting shit out of the way" (and I believe that's how Peopleware understands it as well) than continual soft-selling.

That may very well be a practical approach to the job.  If you, as a product manager, are to assume responsibility for every feature and its implementation, as opposed to delegating that to developers and generally trusting them outright.

But if you're just soft-selling people into doing what you want, that's really no different--except in style--from the hardline management you experienced at Juno.  I think what you percieve as ego in developers, is partly the necessary independence that makes creative people productive.

What's advocated by Peopleware--and certainly by me--is that the role of management is to provide occasional direction, but more generally to clear away obstacles to success.  Not to sell people on doing their jobs well; be it soft sales ("oh, you're so brilliant...") or hard sales ("do it now!").

From my personal experience, I think the role of product manager--especially in a small company where there's little barrier between developer and the executive management--is to distill the technical side's information and communicate it to management, and vice versa; all while clearing away hurdles to "getting shit done."

But playing people skills against ego?  Again, I don't know the specific culture of Microsoft that well, or your circumstances, but that seems far from ideal, especially for an "enlightened" company.

Friday, February 27, 2004

Ok it is official.  You are an arrogant SOB.

Saturday, February 28, 2004

Read through Chris Pratley's very informative blog to get an insight on Program Managers at Microsoft. I sat through a session he was conducting sometime and was impressed at his rapport with the audience and how well he promoted his product. A future Joel in the making.

Saturday, February 28, 2004

I've contracted off and on at Microsoft for the better part of 10 years. Most PMs are hard-working, dedicated, honest, and damned technical. I've met a few that had egos the size of a small battleship, but most keep it in check. The very best realized they would lose a tech pissing contest with the devs, so they find another route.

I hate the "managing cats" analogy. Developers are not fickle, we just prefer reason over chaos. If you don't have the technical chops to understand the difference between a pass by value and pass by reference, we'll snow your ass.

And don't think we don't appreciate a good PM. Who the hell wants to talk to users about stuff some damned saleman promised them last release? Hell, we're Microsoft, we move forward! Onward!


Saturday, February 28, 2004

At a pet store:
Client: How much cost that monkey?
Salesman: 5000$ ?
C: That much?
S: Yes, he knows VB, ASP, scripting.
C: Hmmm,.. but that one?
S: 10.000$, he knows Linux, Unix, C++, Java.
C: Waw! I think I take this one...but I see another one there, in the corner, how much is that?
S: 20.000$.
C: But what he knows!?
S: Nothing, but the other two monkeys call him program manager.

Saturday, February 28, 2004

"at Microsoft nobody is promoted into Program Management -- they're hired directly out of school for the career."

Well, that explains a lot about Microsoft products. God forbid that people with some experience should do things. That could lead to - gasp - excellent design and no reason for future upgrades.

The best products I ever worked on had no product managers, but did have a good mix of experience in the developers ... and at least one world-class person ... and managers who spent their time clearing roadblocks, not in bothering highly productive people.

Earth to Joel/Microsoft: world-class does not mean the ability to figure out why a manhole cover is round. If you hire people who know what they're doing, you don't need Program Managers to cajole them into doing something resembling the Right Thing.

Of curiosity: how does Microsoft Program Managers pay compare with that of software engineers?

Saturday, February 28, 2004

Anyone development manager saying "Developers have such weak people skills they can't even imagine what people skills could be used for" is suffering from just as much cognitive dissonance as a developer saying mangers are just "gophers, taking care of dumb bureaucracy". Thinking only managers can play personal politics is ridiculously naive, and is probably an indication that you have been manipulated (1) as often as you think you have manipulated others.

The fact is that the people who have the power in any system are the one who know how to manipulate the system to get what they want. If a developer is willing to accept that to get what they want they need to consciously manipulate management, and they have the skills to do so, then they will have just as much power as any program manager, no matter how “brilliant”.

I agree that there are genetic differences between most developers and most managers, but I think the difference is generally the word "enjoy" rather than the word "able". Managers enjoy human interaction - they enjoy getting things done by consensus building (ie they build consensus and then other people actually do the thing). Developers don't – problems caused by people interacting are far more messy than nice clean technical problems, and so they would much rather spend their time on the latter. But good (and I certainly agree not all) developers will deal with the former if it is preventing them from doing the latter.

At a previous job as a developer part of what I had to do "three or four times a day" was to get a "Program Manager" (which they called a product development manager) to make a decision the way I wanted by making them think that it was *what they wanted*. I did this because I thought it is what needed to be done for the product to be successful. I eventually left because having to do it every damn day was impairing my enjoyment of the job. Yes this was a sign of an inept Program Manager.

But let’s assume the program manager was “brilliant” and was trying to subtly manipulate me to implement things his way as the same time I was subtly manipulating him to do them mine. I imagine it could go two ways. It could devolve into us dancing circles around each other playing power games, with the real issues never being dealt with. Or we could throw away the games and each say “this is what I think, this is why it is right”. And one of us would either have to swallow our ego or make a genuine appeal to authority. 

The hardest thing for any professional to do is swallow their ego – it basically means that their skills and opinions are not being accepted as part of forming a decision. I think what a good Program Manager does is two things: -
1) He has the technical judgement to know which opinions being put to him are really the best
2) He massages a situation and massages peoples opinions so that people feel that their opinions have been part of forming a final decision – even if in fact they have not.

This is not much different to what Joel suggests, but is hopefully phrased in a way that is not so insulting to all developers.

(1) I realise there are negative connotations to the word manipulated, but to me it is calling a spade or spade. If you consciously manage a relationship with someone to get them to do what you want, then you are manipulating them. You can ease your conscience somewhat by saying this manipulation is for the good of the project/ product rather than the good of yourself, but in the end your own happiness is probably tied to the good of the project/ product, so you are in a roundabout way manipulating someone for your own benefit, and so using a word with negative connotations is justified.

Hank Jones
Saturday, February 28, 2004

As a member of PMI (Project Management Institute), with 10 years experience at the PM level, I am confused about the varying perceptions here of Project and Program management.

I agree that people skills are important, as well as "removing barriers" for the developers and some understanding of the knowledge domain but, what I believe is more important is the PM's ability to maintain a consistent drive to:

            * establish/maintain a scope statement
            * establish/adhere to a deliverable schedule
            * enforce quality standards
            * manage "resources" (budget, people, space)
            * manage changes to the scope

Based on what I've read here, I am not surprised at the number of programs (or projects) in software development that finish over budget, behind schedule, of lower quality than expected and misses the user requirement.

I guess if you have a lot of budget and free reins for resources, then the PMI approach to project and program management is not necessary.  But, this philosophy has been successfully used in many industries to produce better products, quicker to market, of higher quality than previously envisioned and that blow away previously thought budget requirements to accomplish that goal.

The whole purpose of a project is change, bringing to reality something that didn't exist before, that solves a problem or enhances a customer's process (value added).  Go ahead, flame me, but I see now why I have been unable to make headway in a career change into IT/software development.  Accepted standards of project/program management do not resemble the perceptions I see stated here.

Mark Grosskopf
Sunday, February 29, 2004

Mark Grosskopf wrote, "Accepted standards of project/program management do not resemble the perceptions I see stated here."

Most industries have standards that must be followed. Sometimes those standards are government mandated and regulated and sometimes the standards are imposed by a governing body (i.e. bar association, AMA, etc.).

You are correct there are no "accepted standards" when it comes to IT project/program management. The fact is, each employer/company has the freedom to make up whatever rules they want when it comes to developing and maintaining software. This fact is one reason why software development is unique and different from all the various professional service and construction/manufacturing industries.

One Programmer's Opinion
Sunday, February 29, 2004

I always figured any manager's job was:

1. Try to divine from the company's "mission statement" what it really wants to get done (granted, sometimes these can be mutually exclusive).

2. Find the best people to do the job, and, often more importantly, quickly get rid of those who can't/won't perform before they contanimante the work environment.

3. Fight to give them the tools and resources (everything from good workstations to time off to deal with sick kids, etc.) to get their work done.

4. Try to absorb as much of the bureaucratic B.S. that comes down from on high so it doesn't interfere with their work.

5. Help "negotiate" conflicts between them.

6. Be a "sounding board" for them to bounce problems off (90% of the time they come up with the solution by just making the effort to explain it to someone else).

7. And the rest of time ? Stay the f**k out of their way.

Neil Johnson
Sunday, February 29, 2004

Am I the only one who finds it completey and utterly bizarre that someone having the ability to lie to and manipulate people is considered to have "goog people skills"?

Surely they're good at something, but what we'd probably call it here in Australia is good at being a "bullshit artist".

Someone with truly good people skills treats others with dignity and respect, not as though they are tools to be manipulated to their own ends. I think it's a pretty sad indictment on Western society when we get what equates to "good" and "poor" people skills completely arse backwards.

Sum Dum Gai
Monday, March 01, 2004

In response to Mark Grosskopf's comments (without trying to "flame" him), I think that while there is some value in your call to arms for tighter project management practices on software development projects, I think it is a slight oversimplification.

The problem isn't the goals you detail that should be driven towards, the problem is how the average PM without any sort of technical skillset goes about meeting these goals.  Here are some mock examples:
*Establish/Maintain a scope statement:
In reviewing code for a newly developed feature, Developer X finds a design flaw with developer Ys code that will have serious performance and scalability implications.  When it is brought to Project Manager X's attention, the PM indicates that the necessary rewrite to correct these issues sounds an awful lot like scope creep, and the rewrite is scrapped, causing major issues with the deliverable.

*Establish/Maintain a Deliverable Schedule
Project Manager X prompts Developer X for an immediate estimate on how long the data query web service outlined in just about that detail in the Scope Statement will take.  Problem is how valid is the estimate without providing the developer with the time to gather specific requirements for the task and develop a design document?  Development is not like building a house, where if you give a builder a few pieces of information, he can pretty much tell you how long it will take to get up the drywall.  It seems like common sense, but I've seen non-technical project managers make it over and over again.  In defense of the PM, developers need to be stronger about not providing shot in the dark estimates and pushing back when asked for estimates at inappropriate times.

*Enforce quality standards
How can a PM enforce quality standards if he doesn't understand what terms like code coverage, code inspections, and code reviews mean in terms of enforcing quality on a software project?

*Manage "resources" (budget, people, space)
A PM who doesn't understand the nature of software development would line up tightly spaced cubicles for developers in a 1000 square foot office space without any knowledge that spending the money up front for 3 times the space and private offices for the developers may actually reduce the budget in the long run due to the overall productivity gains.  All the non-technical PM sees is the costs for the space...

*Manage changes to scope
See first example...

To summarize, I think these are all great principles that should be applied to software development projects, but the principle are only as good as how they are applied, and without any sort of technical background, a PMs application of these principles is bound to be poor.

Monday, March 01, 2004

"Am I the only one who finds it completey and utterly bizarre that someone having the ability to lie to and manipulate people is considered to have "good people skills"?

"people skills" means "The ability to manipulate people."

Monday, March 01, 2004

I'm surprised that a couple things haven't come up. In my years as a not very technical program manager (never at Microsoft), a lot of what I did was:

TRANSLATING. Explaining to marketing why the feature they thought of yesterday can't be in the next version, unless they are willing to take a schedule hit.  Explaining to developers why the new feature they just thought of and implemented last night has to be taken back out, because users/the customer will be more confused than pleased with it, and because documenting/testing/supporting/maintaining the feature just isn't worth it from a business perspective. A good PM has to be able to speak marketing/sales/business speak and engineer speak, and translate between them, even though she is not either of them. I regard that as one of the critical skills of a good pm

FORCING DECISIONS - On every project, there are dark holes no one wants to look into, decisions that are very painful for the group to make (e.g. Putting customer #1 favorite feature in will screw customer #2, and it is a terrible hack). A program manager doesn't have to be the one who makes the decision, but he is the one who makes sure that the decision gets made at the appropriate point in the process.

PROCESS - Instilling just the right amount of process. Too much and you bog down the developers and the rest of the team in doing tasks other than creating the product, too little and you have no idea where you really are in the development process, and your CEO thinks the product is almost done (and tells customers so) when you have a months (or years) to go.

COMMUNICATING - Doing the boring stuff that developers don't want to do and often aren't good at doing - writing reports, holding meetings, dealing with the other stakeholders.

TROUBLESHOOTING. Finding and fixing problems before they happen.

All of these can be done well (or poorly) by a non-technical PM. I've seen projects with and without PM's, and I have no trouble knowing which kind I'd rather work on. Most developers who have had both experiences have a pretty clear opion which they would want to work on too.

Monday, March 01, 2004

Mark Grosskopf and M-Dub,

Non-technical PM's are capable of making rational trade-offs (even if they don't always do so). They can read Peopleware and Debugging the Development Process as well as any developer. Of course they have to be able to understand the development process at some reasonable level, but they also have other skills that developers don't that contribute to the project. Maybe Joel is right, and the best ones have two sets of DNA.

What some of the PMI formalism doesn't take into account is that what is being managed is a creative process, at least in the small start-ups I have worked it. It isn't like herding cats, it is like stage managing a play that is being written right up until the moment the curtain goes up. When you are in a startup, building a brand-new product, you don't have a fixed scope and fixed specs -- they change as you learn by doing. I would never advocate no specs (I've seen what that does), but the manager of the project needs to understand the creative nature of the process, and not try to clamp down on all the creativity.

I'm sure that is different when you have a very well understood spec and scope and customers at the beginning of the project -- perhaps there the PMI formalism is more useful. 

Monday, March 01, 2004


Your points are well taken; a non-technical PM can indeed read Peopleware and any other of a myriad of books they need to to get the context they need to make rational decisions on software development projects.  Furthermore, I've seen PMs who are effective without even this, because they have an understanding of what their limitations are, and defer to experts when appropriate.

I've also seen PMs however (and this is the type I was describing in my post) who don't think they need any context to make decisions, but rather they can simply apply the teachings of PMI or whatever methodology they subscribe to in the exact same generic way they can apply it to any other type of project.  And that's when chaos ensues...

Tuesday, March 02, 2004

M-Dub & Geodog,

I hope I didn't lead you to believe that PMI promotes the "technocrat" type of program/project management, where decisions are simply logical choices and trade-offs.

What PMI stresses (and there are a LOT of IT types on the local chapter...) is a framework for meeting the multiple objectives, somewhat contrary at times, that any project must meet.

And people skills are NOT manipulation, but a measure of team leadership and cooperation.  I don't think you succeed by "getting people to do what you want", but getting people aligned on what needs to be done, while still enabling creativity and problem solving.

I guess some of my frustration with trying to find a path in software development bled into my words.


Mark Grosskopf
Tuesday, March 02, 2004

Microsoft has yet another problem. The goals of the corporation are not always consonant with the goals of the technician. If you've seen (or read) The Bridge on the River Kwai, you'll see this fundamental conflict played out.

The corporation, in this case the Allies during WWII does not want the bridge in the title built.

The program manager, Colonel Saito, played by Sessue Hayakawa also wants the bridge built and manipulates Nicholson into building it.

The technician, Colonel Nicholson, played by Alec Guiness, wants the bridge built, and built as well as possible.

I won't give too much away by saying that the bridge is indeed built, but it is also unbuilt in a manner of speaking.

You often see similar conflicts at Microsoft.

Microsoft often designates certain technologies or functions as "monopoly critical". This means that they must be inextricably intertwined with the operating system, lest they be forced to unbundle them. By definition, this means that modularity must be sacrificed, otherwise someone might be able to remove the critical component and replace it with a competitor's. This lack of modularity makes it harder to guarantee system security and reliability, but only the users care about that kind of stuff, and they aren't players in this tale.

The stage is set. The program managers, the programmers and the software are all in fundamental conflict. This makes for excellent drama, but not particularly excellent software. Let the manipulation begin.

Seth Steinberg
Thursday, March 04, 2004

Hank Jones had stated "The hardest thing for any professional to do is swallow their ego". I've only worked with a few Program Managers and a few developers who were willing to do that. If you can step outside your big ego (I think Joel let his get away with him on a rant there) and put the project first, then you get both a better solution and a better work environment.

I'm guessing that Joel never had the contempt for developers that drips from his initial comment. Having read about how he hires only the best (no, I am neither brilliant nor interested in living in New York, though I am available....) I am certain that he doesn't.

Honestly, I would love to work for someone who could convince me that doing it their way was my idea all along. Being manipulated into thinking I'm brilliant might make me a happier man....

Dave Navarre
Thursday, March 04, 2004

Of course Program Managers are not just hired out of school. Most of the best ones I know (like myself) started internally in product support, developer relations or consulting.

Saturday, March 06, 2004

Mark Grosskopf, I think you actually demonstrate the problems with a lot of project management in software.

First, you quote your membership of PMI as a credential, presumably expecting this entitles you to automatic respect.

Second, you list a series of bland bullet points with an implication of a correspondingly bland application to a project.

Third, you invoke popular but generally poorly based criticisms of the software process as justification for your claimed higher standing.

You're a good example of what's wrong with project management in a lot of software projects. Microsoft and other successful developers understand the skills and expertise that project managers really need in software. It starts with understanding software.

Must be a Manager
Tuesday, March 09, 2004

To all those there,

I am in a quandry. 

Having applied for a senior tech role in a consulting org, I was told that I should accept the role of a PM since the client is expecting someone there! Also - that this role would grow to much bigger proportions across all deptartments in the org. The compensation and perks are quite huge

All the venom in this blog is giving me creeps - especially since I pride myself on being a great techie!

Joel - do you really think the head of a PMO is a respectable job ?!!!

Thursday, March 11, 2004

Don't let the added perks and money blind you. If you are a good, happy techie, then there is no guarantee that you'll get a "better" job (even if it does pay more) by going into project management.

In fact, there's good reason to think you would be *unhappy* as PM.  Management and Development require two totally different skill sets, and not many people have both, so odds are if you're happy doing one job, you probably won't enjoy doing the other. 

As has been pointed out, it's a mistake to promote someone into management just because they are a good developer.  You just end up (definitely) losing a good developer, and (maybe) gaining a mediocre manager.

Thursday, March 11, 2004

I’ve been a salesperson, product manager, project manager and developer. Wearing my salesperson’s hat, I can tell you that the surest way to lose the cooperation of a client is to ever give them the impression that you’re “manipulating” them. Double that if they’re analytical or professional, by which I mean doctors, lawyers, scientists and most programmers (the better ones).

What’s more, it is the most analytical people who will see right through any attempts at manipulation. The best you can do with these people is be completely straight. If you have a goood reason for suggesting a certain course of action, then explain the reasoning and invite a reaction. Then listen to it.

In my experience, it is not true that the people who lack warm fuzzies are those who can most be easily be led by the nose. In fact, it’s the exact opposite. But no analytical type will ever let you know that they think you are a complete doofus. They just give you that cold stare.

Tuesday, March 16, 2004

I am surprised by many of the comments here. The rationale and role of the PM is primarily as corporate spy in the dungeons and dragons world of development.

MS has an awkward goal of having UI drive development. This breaks the top down design strategy of a priori defining key interface, states, algorithms, then process; adding a parallel track of UI design that *changes* fairly late in the development cycle in a bottom up way - creating a design thunk.

The stakeholders in an engineering enterprise emotionally (and in MS compensated for it as well) are pulled into going for the big win. In a marketing enterprise, it tends to be competitive position. In a sales organization, it's product flow - a single salable feature in the product.

This conflict is resolved in normal circumstance through negotiation, dictum, partial information, or even outright lying. Developers often cherry pick features to offer to others to give input on, and so on.

Very tech management is inherently conflicted. Needing to fulfill personal needs and needing the support and trust of their developers - their bias is obvious. Product managers are likewise biased to marketing goals, and not trusted by developers.

Bell labs in the 1970's saw the same problem of runaway developers, and the PM model originated in their "position practice".

The PM is a management flunky who lives with the developers, but talks to the outside. While not a single point of contact, the PM legitimizes external requirements - since they are more answerable to them. They take much heat off the tech management: "I can't give you all that leeway since I'll get in trouble with the PM...".

They are legitimately not held to the fire by executives for things out of their control. They are totally accountable for any missed *issues*. Because they exist, management gets early warning about bad team dynamics, fudged deadlines, and other runaway development issues. They are responsible for skulking around, collecting gossip and rumors, and smelling when things are not kosher.

It's a miserable role, and one with much turnover, much mistaken understanding of authority. It also pays well, doesn't hardly ever require a suit, and is a useful springboard because of the number of contacts made.

(also - don't confuse this with a bank style PM office, which is responsible for insourcing projects, with substantial tech ownership.)

Tuesday, March 16, 2004

I think the main theme is not about PM, but about the people skills of PM – ego is the main subject here.
From the ego point of view, there are people:
-    with strong ego : those who sell something are here ; you can not sell if you don’t have it . Here are the marketing people, but also the developers – developers sells themselves as human resource
-    with weak ego : "veritas" leaders
Two strong egos can never collaborate – that's why developers and marketing are always fighting. So to be able to collaborate with strong ego – you need weak ego.

PM work with client - here they need ego, and work with developer – here they need to not have ego. So to be a great PM, you need to be a timing combination of strong and weak egos.

Tuesday, March 23, 2004

The "two different kinds of DNA" statement is right on the mark. What is euphemistically called "people skills" is the ability to lie effectively, and is a relatively common evolutionary adaptation that some credit as the engine driving the very growth of human intelligence, honed through millenia of seduction, persuation, and getting away with it. The major enabling mental mechanism is the ability to keep contradictory statements in play at the same time: what you believe versus what you want the other to believe. This ability, coupled with technical knowledge, is what makes a good PM. However, there is usually some leakage between the contradictions in their head, or the machinery needed to keep nontruths in play limits their thought-depth and that makes them unable to achieve the ultimate metal clarity needed for heavy programming.

I think good developers are people that are missing this ability and in that sense are somewhat mentally defective. For a good developer, the ability to program is immensely enhanced by his inability to keep anything but a single version of the Truth in his head. Only with this firm foundation can he build the most intricate mental edifices imaginable. Top scientists also share this trait. Unfortunately, the associated poor social skills dooms them to standing in the corner in parties.

Joel is perhaps one of those rare people who can keep the contradiction leakage from affecting his programming.

Carlos Ibarra
Friday, March 26, 2004

> The only reason I had any success at all as a Program Manager was because I have two -- that's right, two -- complete sets of DNA. It's called the quadruple helix and only I have it.

Quadruple DNA helices haven't been observed (unlike triple helices), but genome duplication does occur in different organisms relatively frequenly. The human somatic cells are diploid to begin with, i.e. they have two copies of each chromosome except for X and Y. A duplication of the human genome to a tetraploid state would not result in a viable embryo, but this does occur in e.g. several plants and is exploited in breeding of crops.

Random Biochemist
Thursday, April 08, 2004

As a PM I always believed that it was my job to make suggestions and then get out of the way for the much better suggestions to come along. The developers should know how to doing something much better then I, after all it's their [primay] job. The skill that a PM needs to bring is to make a decision on the best way to do things (considering several other facters that devs don't need/want to consider) to upper management. They must not demand (or manipulate) a developer into doing something but show them that it is the best way. After all when the developer goes back to their desk unless they really believe in the goal then they will be forever 'churning' their head with alternatives.

Stewart Whaley
Monday, April 12, 2004

All those Microsoft techies probably look
much dumber once you have gotten
very far away from them...  And you
can safely imagine you were 'mainpulating'
them all those times you had to say
"oops!  I didn't think of that!"

No name
Tuesday, April 13, 2004


As a technical PM at MS who many times considered moving back to devs (who I was fo 20 years before), I am have much more serious questions than bashing PMs or Devs or whoever. And I believe you should have them too.

We all see what's going in IT industry. IT passion may be a good thing, but when you have kids who plan to go to college and mortgage to pay, you start to wonder which of the three IT professions - Dev, Test, or PM is going to survive longer providing a reasonable inclome. I still don't know. I miss coding, but I suspect that coding will leave US earlier than PM job, and if it will leave to India, I am likely to get back a real power of technical design, which would be a little consolation. So, you see, the question is different.

For Silicon Valley guys and gals reference, "program managers" has really nothing to do with "managers", don't get switched off by this inappropriately put word. PM is a vaguely defined flexible mix of architect, analyst, project manager, and a village idiot. By the way, they are not necessary hired out of the college, many of them have a really goo inductry experience, often as pure devs or executives in smaller cmanies.

Monday, April 19, 2004

Very amusing discussion.

I find it hard to believe in dual gene concept.  What is "people skills" anyways?  The distinction between Program Managers and Developers seems like a desperate attempt at self-justification of institutionalism.

The seeming need to "shield" developers from outside obstacles is offensive to their intellect.  Is the goal to promote ignorance of key issues affecting the success of a project, or is it to create a fictional world in which the developers don't have to care since although they probably already know what the issue is, they will be more productive by pretending they don't?

When has leadership and direction become a task of cleaning up shit and performing arts of trickery?  Furthermore, how do you gain trust and respect from peers you are supposed to "lead" and "manage" without knowing EXACTLY what their struggles and problems are?  Institutionalism and buy off on it's implementation with respect to software development is a ploy at preserving mediocrity with basis built on mistrust.

Of course there are business constraints in any project.  There are always limits to resources (manpower, money, time), and with software development being difficult to rationalize into predictable deliverables it is no surprise that leading successful projects is no easy task.  Everybody knows that already.  Hiding behind roles to buffer acceptance of hard choices across all fronts, Management, Project Manager, Developer only serves to promote the illusion that somehow nobody is really responsible.

It's just an unfortunate cancer of large corporate beauracracy exacerbated by the consistent lie that somehow it works.

Program managers should not have to be assigned.  Are you trying to mock the intelligence of your most valuable "creative knowledge asset" (the developers) by assuming they do not know how to take care of their own project and it's success by rationally selecting a "leader" to speak on their behalf?  I have more faith in folks with their jobs and prestige on the line to get very resourceful.

Peter K. Lee
Saturday, May 08, 2004

Re this:
"One correction though -- at Microsoft nobody is promoted into Program Management -- they're hired directly out of school for the career. The one mistake Microsoft does NOT make is promoting perfectly good software developers into management just because they were good coders. "

This sentiment surprises me. Just out of curiosity, how many fiftysomethings did you meet at MS who still worked as developers?  For that matter, Joel, how many 50 year old coders do you have on your staff (no dual-roles allowed, just development…)? 

I’m guessing the answer is 0.

My experience is that coding is great and fun - when you’re young.  As you age, your ability to pull a week of all-nighters to finish those debugs for deadline is greatly diminished.  And nobody cares that you know 50 dead programming languages and platforms, they just need the latest three or so, which younger coders usually are faster at picking up.  And not only can they do the all-nighters, they like them.

Eventually, a developer, no matter how good they are, has to move on to another job that values their accumulated knowledge, not how many lines of code they can crank out in a week.

So the question is, if not program manger as a first step up the ladder, then what do they move on to? Where do they go?

This sounds more like a glib comment reflecting a half-baked philosophy.  What’s all this I hear about meetings at MS where failures are examined so that they can be learned from?  Who exactly does this learning?  If it’s developers, how does MS benefit from all that knowledge if they stay in their coder’s cube and never share it?  How about promoting them up the ladder after a while so they can mentor others?  And how does someone hired “directly out of school for the career“ do the same job?

If it is true and all that MS “lessons learned” stuff is propaganda, , I’d love to know the age that developers at MS wise up about their dead-end career path, haul all of their accumulated knowledge out of the front door, and use it at another company.

Friday, May 28, 2004

I think the Program Manager is mis-named. The title should be called Project/Program Coordinator (PC) for non-tech role, or Project/Program Lead for tech expert on the specific project.

Once there is a manager in the title, dev and test get really picky and upset, thinking why such a stupid can be a manager and manger me? No way!

In PMI view, Program Manager is even larger and hold more responsibility than Project Manager, which is not the case in MS PM position. I think.

Does a PMP can cross industry to be  a PM in IT? Yes, if the position is PC or Account Manager. No, if the position is PL.

Friday, August 20, 2004

I enjoy reading all the buzz words and catch phrases you guys sport.

You would think project management was invented fresh for this industry. Egos? What Egos?

In any other industry these pms would be called "Middle Managers". They are a lot easier to spot when you don't invent a language to hide in.

Tuesday, August 24, 2004

It's a mistake to talk about the role of PMs at Microsoft as though there is just one definition.  Each team at Microsoft defines what their PMs do and who is really in charge.  I've worked on projects where the PMs completely controlled everything; I've worked on projects where the developers controlled everything.  It's a negotiating process on each team.  One generalization:  on UI teams, the PM often has a larger role, whereas on infrastructure and kernel teams, it's the developer.

Something that was noted above bears repeating:  a PM is not a manager.  A PM is equivalent to a developer, just as a PM lead is equivalent to a dev lead.  As I noted above, how much authority each gets is a negotiating process.

On a very simplified basis, the PM writes the feature specs and the developer writes the dev specs, but the best PMs include both dev and test in the brainstorming phase of the product and make sure that their feedback is solicited and used.

Contrary to what Joel wrote above, there actually is quite a bit of crossover between dev, test and PM.  Most of the PMs I have worked with were former developers, with some smattering of folks that came up through the test ranks.  The pay is equivalent at each level for each discipline.

A PM reviews available market research, consults with customers (end users, large corporations, ISVs and IHVs), reviews data from product support, consults dev and test, and comes up with a set of proposed use cases, scenarios and features.  These are then prioritized, again with cooperation from dev and test, and written up in the formal feature specification.

If there is UI associated with a feature, the PM helps spearhead that design, with assistance from the central UI design team and from dev and test and usability studies.

The PM often has some project management duties, as well.  The development team usually owns the schedule, but the PM owns the reports and reviews to upper management.

The PM is usually more heavily involved with managing dependencies, customers and ISVs/IHVs during the development process than is the dev, although the devs will have their own channels for strictly technical details.

There's an appropriate role for each to play.  On the best teams, all three groups, dev, test and PM, each have some involvement in all phases of the process.

Sunday, August 29, 2004

*  Recent Topics

*  Fog Creek Home