6 ms·

How to be a program manager

• carterschonwald 18y 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 18y ago
    Yes, and the correcter version of your comment is 'So the more concise version...' ;)
  • raganwald 18y 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.
    • jimbokun 18y ago
      Yea, Sally. I wonder whatever happened to her.
  • run4yourlives 18y ago
    Yes, in other words, the proper definition of a "really good programmer". (As opposed to the flawed one Joel - and many others - use)
    • jwilliams 18y ago
      For me -- Seems to also fit the (albeit rarely found) definition of a "good architect" also.
      • run4yourlives 18y ago
        I'll give you that. I've never seen a "good architect" that wasn't also a "good programmer" via my definition.
        • jwilliams 18y ago
          Indeed - For whatever reason, I've had the title architect for most of my career, so I hope that's true (as for the "good" part...).
  • pkaler 18y ago
    The Program Manager also understands the timeline/schedule and improves the code without actually coding.
• sarvesh 18y ago
  Joel, in case you are lurking around here, link for the book Don’t Make Me Think is broken.
• peterb 18y 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 18y ago
    Sometimes decent solutions come from not being at one extreme or the other. Not always, but sometimes.
  • jimbokun 18y 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?
    • peterb 18y 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).
      • user 18y ago
        Take it easy dude...It's always easy to bash on any product..what is important is whether you are making money out of it or not and whether it's reaching a wider audience or not. Have fun making software :)
• JoelSutherland 18y 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. -----------
  • spolsky 18y 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.
    • JoelSutherland 18y 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.
    • ams6110 18y 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.
    • akeefer 18y 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.
• notauser 18y 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 18y 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.
  • simplegeek 18y 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.
• simplegeek 18y 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 18y 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 18y 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 18y 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.
• deleted 18y ago
  [deleted]
• cake 18y 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 18y 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
  • spolsky 18y ago
    Yes, good catch
• Longhorn213 18y 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 18y 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 18y 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 18y 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.