How to be a program manager

http://www.joelonsoftware.com/items/2009/03/09.html

by twampss • 17 years ago

161 43 17 years ago

So the conciser version is the program manager is someone who understands software design, usability issues and can communicate with every role in the company?

jonmc12• 17 years ago

Yes, and the correcter version of your comment is 'So the more concise version...' ;)

raganwald• 17 years ago

You must have been daydreaming about Sally in 11th grade. You forgot that The program manager and the developers have to be peers.

I had this experience at KL Group with the marketing department, who owned the requirements and the UI. Marketing and development were peers, which reflected the company's structure: Greg Kiessling and Ed Lyclama (K & L) were co-owners. Greg ran the business while Ed ran the technology. Steve Rosenberg, the VP of Development, used to echo another of Joel's sentiments: Whenever we were depressed, he would remind us that We own the compiler, meaning that nothing could happen with convincing, cajoling, or otherwise making Development a deal they couldn't refuse. Marketing and Development fought like wild dogs over the specs and shipping priorities, and we ended up taking over our market and making Ed and Greg wealthy men when they sold out.

A while later I worked for another company where marketing owned the requirements and UI, and the VP of Marketing executed a coup and got Development to report to him. The company failed shortly thereafter.

jimbokun2• 17 years ago

Yea, Sally. I wonder whatever happened to her.

run4yourlives2• 17 years ago

Yes, in other words, the proper definition of a "really good programmer". (As opposed to the flawed one Joel - and many others - use)

jwilliams2• 17 years ago

For me -- Seems to also fit the (albeit rarely found) definition of a "good architect" also.

pkaler• 17 years ago

The Program Manager also understands the timeline/schedule and improves the code without actually coding.

sarvesh• 17 years ago

Joel, in case you are lurking around here, link for the book Don’t Make Me Think is broken.

peterb2• 17 years ago

... and this explains, in detail, why Microsoft products are so much more difficult to use compared to Apple (designed by industrial designers) and less functional than FOSS (designed by programmers and domain experts). They are designed by committee and program managers who are smart, but fresh out of school with no real world experience.

fortes• 17 years ago

Sometimes decent solutions come from not being at one extreme or the other.

Not always, but sometimes.

jimbokun2• 17 years ago

I have enjoyed Microsoft bashing a lot over the years, but a lot of real people have managed to do a lot of real things over the years with Microsoft software.

Maybe it is just as legitimate to say "Microsoft products are more functional than Apple products (designed by industrial designers) and more usable than FOSS (designed by programmers and domain experts)," and that is a better sweet spot for software design? For example, what software is better overall than Excel and Word in their categories, when both functionality and user interface is considered?

peterb2• 17 years ago

Agreed. Microsoft has released best of breed products. But Microsoft's product decisions are largely driven by "PMs", whereas open source is driven by technical merit and Apple is driven by industrial design. Microsoft occupies this weird middle ground, call it "pragmatism" (or even MBA-driven design :-).

This middle ground results in weak consumer products like Vista and Microsoft Mobile. They aren't bad products, but lack the polish an industrial design-driven process could have produced. They also lack the technical depth that open source is producing. As a result Microsoft is getting squeezed from both ends.

Joel's products are similar: a good middle ground. Neither awe-inspiring (technical) or fun to use (design).

JoelSutherland2• 17 years ago

I don't understand why Joel calls out Fried on functional specs and describes the exact same 2 step process:

-----------

Joel Step 1:

You start at the highest level: a vision statement, no more than one page explaining the gist of the new feature.

Fried Step 1:

So what do we do in place of a functional spec? We write a one page story about what the app should do. If it takes more than a page to explain it, then it’s too complex.

-----------

Joel Step 2:

Once that’s nailed down, you can develop storyboards… mockups of the screens showing the user’s progression through the application, with detailed notes showing how they work.

Fried Step 2:

Then we begin building the interface — the interface is the functional spec. First with some quick and simple paper sketches, then directly into HTML. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground.

-----------

spolsky2• 17 years ago

Because Fried makes a big deal out of "not doing functional specs' when he's, essentially, doing functional specs, just not calling them that.

He's opposed to BAD functional specs, which is fine, but too many people read his title and decide it's OK to skip to writing the code first.

JoelSutherland2• 17 years ago

It would have been helpful for me to have read that context rather than the weird insult. That only seems to escalate the confusion caused by his title.

ams61102• 17 years ago

Not only writing the code first, but write with the idea that because they're "agile", their code is somehow easier to change 15 times as the complete understanding of the functionality emerges.

akeefer2• 17 years ago

One important distinction that a lot of agile people make is more around writing down the specs; as the PM you still do work up front to think about what to do, make mockups, do your homework, etc., but when it comes time to communicate to developers it's done as stories (much less detailed than specs) and with in-person communication for clarification (or, under less ideal circumstances, over the phone or e-mail or chat). The process of getting to the story in the first place ought to involve plenty of back-and-forth, design vetting, and mockups, but once you get there you don't build something based on a spec of any kind.

The theory there is that written documents will always be out of date, incomplete, stale, and open to multiple interpretations, so we might as well just accept that the face-to-face communication is infinitely higher bandwidth and will have to happen anyway and not waste the time trying to write it all down up front.

So if the PM needs to spec for their own edification, that's fine: do whatever works for you. But I, as the developer, will trust the PM themselves as the source of truth as to what the feature should do, and it's the PM's job to know what they want well enough to answer my questions real-time as I'm building.

access_denied• 17 years ago

I think Fried is in general against shuffling papers (like BAD specs and business plans) instead of getting around to actually making decisions.

tjogin• 17 years ago

When the "functional spec" is the exact same thing as the html code, it is no longer recognized as a functional spec.

The functional spec usually comes before the html code.

Sure, Fried treats his html code as a functional spec, but others who work differently would not be able to find what they are used to calling a functional spec.

KrisJordan• 17 years ago

Though the processes sound similar, the scope and details each is emphasizing are different.

Spolsky: "feature"

Fried: "app"

Suppose either is designing GreenfieldGloryApp - he might start with a one-page vision statement. He might then make some very high level mock-ups of scenarios. Maybe they would even be done in HTML. This is where they diverge: At this point 37signals would start building. Fog Creek would iterate 'specs' many times further by drilling down to feature or feature-set level functional specs. Each feature-level spec would start with a vision statement and then be fleshed out with mocks and "detailed descriptions".

notauser• 17 years ago

Joel's definition of Programmer Manager is closer to what I know as a Product Manager (except for the co-ordinating teams bit).

The APM definition of Program Manager (which covers a lot more than the software field) is someone who manages a portfolio of projects, balancing resources to deliver results. This is also roughly the definition that Wikipedia agrees with.

I agree with a lot of the rest though, especially: "It helps, as a program manager, to be pretty good at coding yourself. This is unfair. Program managers aren’t supposed to write code. But programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are. It is possible to be an effective program manager without being a coder, but the burden of earning the respect of the programming team will be higher." That goes for Project/Program managers as well as Product managers.

joshwa• 17 years ago

The rest of the world calls this role a Product Manager (happens to be what I do, too).

cf. Marissa Mayer, Ev Williams, Joe Kraus, Steve Jobs (on a high level), etc.

In Fortune 500 hell we call it 'Business Analyst' (because in bizarro enterprise software world, users and what they do with your software is called 'the business').

In Agile/Scrum they call it the 'Product Owner'.

Point is that someone needs to keep the big picture in mind and serve the interests of the end-user, all while sweating the details from their perspective as well.

simplegeek2• 17 years ago

I've been a part of Scrum teams and I can tell you from a personal experience that Product Owner cannot do this much in a , say, 4-week sprint. I doubt it. At least, during my stay, I never say Product Owners creating specs, talking to QA and etc.

simplegeek2• 17 years ago

So isn't it really hard to interview Program Managers? This essay should have been more insightful had Joel included some information on how to hire Program Managers? I'm wondering how do Microsoft hire Program Managers?

rayvega• 17 years ago

The distinction between functional design and technical design is very important and often overlooked. Some developers tend to miss it or mix it up.

I have worked with programmers who felt they lost all control because they were not driving the functional design. However, they did truly have control, as Joel points out, because at the end of the day they still own and decide the technical design which is generally better aligned with their unique skills.

Good functional design tends to be technology ignorant by being more focused on what something is going to do from a user's perspective versus how it is going to do that something behind the scenes in code (as defined by the technical design).

While a functional design can be written out as a spec, the technical design can be developed and evolve as you write actual code if you follow an agile, iterative style of development. I think writing a technical spec (not to be confused with the functional spec) and handing it off to junior developers is why people get turned off by the idea of creating documentation on how something is going to work by someone who is not going to be the one actually implementing it. (In Joel's article, it is what Charles Simonyi was trying to define as program manager.) Once again, this is not the same as someone who provides a functional design spec.

Alan Cooper's The Inmates Are Running the Asylum does a really good job drawing out and describing that distinction between the areas of functional vs technical design (although if I recall he uses different terminology to describe the two but the same concept nonetheless).

10ren• 17 years ago

I found it incongruous how Joel seemed to be in charge of the whole operation, with all these long-established gurus reporting to him - a guy fresh out of college, who (modesty?) didn't know anything.

This setup drove home his point for me, that The program manager and the developers have to be peers.

Joel wasn't their boss. He was just the spec guy ("program manager"). Still, he must have some serious smarts to land such a job - possibly great coding chops plus being able to communicate well. Rare.

endtime• 17 years ago

From what I've seen, becoming a PM does indeed require serious breadth of smarts. I don't know about MSFT, but at Google being a PM requires technical skills, communication skills, design skills, and market insight. I interviewed for a associate product manager internship at Google, which is extremely selective (I was told they only take 10-15 APM interns a year). I had two on campus interviews with PMs, then an interview with a PM at Google (most people have a technical interview at this point too, with a Google engineer, but I had interviewed for engineering in parallel so I had effectively had that one already), and then the final step was to write a three page essay to be reviewed by a hiring committee. I didn't get the internship, but they had told me that the essay was the final round either way. Four interviews and an essay might not sound like a lot, but keep in mind this was just for an internship.

The APM interviews and the essay were very nontechnical. They mostly focused on product design and consumer experience (not limited to web/tech stuff), as well as one or two about industry in general (which I was pretty crap at answering). The most technical APM interview question I had involved coming up with strategies for improving AdSense performance and helping suggest keywords to advertisers. However (if the technical interview that regular APM candidates get were like the ones I got as first-round engineering interviews), the technical interview is pretty tough. Not impossible, but harder than MSFT or Amazon first-round...probably on par with MSFT second-round. And as a CS student I found the APM interviews the hardest of all.

cake• 17 years ago

"Lacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU’RE A VULCAN (cf. git)."

Glad I'm not the only one who isn't a Vulcan.

albemuth• 17 years ago

Totally off-topic, that picture of the "Cemetery for soldiers' dogs" is from the Edinburgh castle right? It gave me a weird childhood flashback

spolsky2• 17 years ago

Yes, good catch

Longhorn213• 17 years ago

If you haven't taken the time yet you should read the Copilot spec. It caused me to rethink how specs should be written, and what is the right level of detail.

snowytigger• 17 years ago

I never had much use for the PMs at Microsoft. On the other hand, every PM I knew there had a... let's say "large" sense of their own worth. Guess it was in the job description. Since leaving I have encountered PM-like roles doing everything from just documenting whatever crazy requests the users made, to ignoring the users and pushing for whatever they personally wanted. Occaisionally I have encountered someone who really added to the process, but it takes just the right person, and sadly that's been the exception rather than the rule.

dmoney• 17 years ago

Beware of hidden command structure. If you want to be "peers" with the developers, make sure they understand they don't have to do what you say. After all, most commands in corporate America are framed as questions, and many developers will assume that the burden of proof is on them, since you have "Manager" in your job title.

mattyfo• 17 years ago

Thoughts on how I can move towards becoming a program manager? I have the communication skills, I'm learning to program (ruby) and I'm learning to design webpages.

I'm not very interested in becoming a full on hacker but I want to help build programs and webapps because I feel I'm good at getting 'the big picture' and advocating for users/customers.

How to be a program manager

Related Stories