Being a PM

I started my job at Microsoft five months ago today. I had the opportunity to write a small post about what I do for Wes Weimer, my former software engineering professor. I thought I’d share some of it here.

Hi everyone! I’m a program manager (PM)1 at Microsoft, working on high-performance computing. Professor Weimer asked me to write about my job to give you some industry perspective on what you’re learning right now.

Large software companies have an interesting problem: they have a lot of work to do on each of their products. Whether that’s implementing a new feature, improving performance, or working with another team to create a product integration, there’s often so much work going on that it’s hard to prioritize what to do next. That’s where PMs come in!

For every 5 to 15 software engineers writing code to build or improve a product, there’s one program manager figuring out what those software engineers should be working on next. With that comes a whole other bunch of responsibilities: specifying the behavior of new features, working with partner teams who have a stake in decisions you make; representing your product in meetings with finance, marketing, and documentation folks. The list goes on and on.

Everbody has a different definition of what PMs do. Many people say a PM’s job is to be “the voice of the customer”, but that makes software engineers sound ignorant of the customer, which they’re not. Software engineers and PMs both have the needs of the customer in mind–it’s just that PMs have a better understanding of what customers need most because they’re busy prioritizing everything that needs to get done to improve the product.

At least at Microsoft, PMs don’t actually tell software engineers what to do. Rather, program managers persuade software engineering managers2 that certain things need to get done. If our arguments are persuasive, software engineering managers will allocate their software engineers to work on what we think matters most. Software engineering managers often call this “funding” a certain piece of work (i.e. “we’ll fund that feature you seem to care about so much”).

From the perspective of a PM, slide 6 of the “Requirements and Specifications” lecture really drives home an important point: if a mistake happens and it’s not discovered until later, it becomes very expensive to fix. So expensive, in fact, that you won’t be able to deliver on all the other features you promised (and who likes breaking a promise?). As a result, priorities need to be reset, and somebody–you, a friend, that team you were working with–is going to be unhappy.

That’s why PMs are often assigned to write specs–a document that describes [in painstaking detail] the requirements for how a new feature or integration is going to work (see slide 33 of the “Elicitation, Validation and Risk” lecture). There’s no doubt that software engineers could write specs if they wanted to–it isn’t too hard. But why burden them with more work when they could be coding?3

Feel free to ask any questions in the follow-up section. I’ll answer as best as I can.

1 Depending on where you work, PM can mean program manager, product manager, or project manager. Each of those job titles means something different depending on who you ask.

2 If you become a software engineer, your boss is a software engineering manager. At Microsoft, software engineering managers assign programming tasks (“work items”) to the engineers that report to them (their “direct reports” or “directs”). They’re often responsible for leading design and [re-]architecture efforts as well.

3 Probably the easiest way to describe what a PM does is “anything that would get in the way of a software engineer from checking in code”.

Create a Flow Journal

I’ve talked about the concept of flow here before. As I focus on writing and meditating more, I’m going to start keeping track of conditions when I experience flow.

The idea is that if I can find similarities in the conditions before, during, and after flow, I can try to reliably reproduce the mental state. Things I’ll track include:

  • Date
  • Time
  • Weather
  • Mental state
  • Duration of flow
  • Activities preceding flow
  • Activities completed during flow
  • Activity when flow ended
  • Substance of last meal
  • Hours since last meal
  • Hours of sleep the previous evening

This project will be similar to a decision journal, which I first learned about over at Farnam Street. You’ll note that I borrowed some of the entry items from their template.

If you like the idea, try it out. Email me your thoughts.

Want More Alpha? Hire From Different Schools

Proprietary trading is all about having an edge–firms can’t make a dime unless they know something no one else does (or, for the more skeptical, unless they guess at something correctly that nobody else guesses at correctly).

As director of sponsorship for a large hackathon, I read a lot of recruitment pages to understand if a company would agree to a sponsorship deal. A lot of trading firms all recruit from the same places: a few of the Ivy Leagues, MIT, and the University of Chicago. A handful of Chicago firms recruit at Michigan and UIUC as well.

There might not be a problem with that educational homogeneity: companies are better when smart people work for them; trading is no exception. Since smart people go to shiny schools, you get the most bang for your recruiting buck by going to shiny schools exclusively.

But for an industry where edge determines whether you eat or starve, wouldn’t you expect there to be a little more educational diversity (or any diversity at all)? I’d posit that smart students from universities with less name-recognition think differently than those at universities with more, by nature of the fact that they didn’t go to the same school. You might say that high-caliber universities create diverse student bodies–and therefore diverse ways of thinking–but recent data suggests that not to be the case. Racial diversity has been dwindling at elite schools over the past three decades.

I see diversity in educational training as an advantage that translates directly to alpha generation. McKinsey research has suggested this same idea for years: diversity helps a company’s bottom line, period. I wager that trading is no different.

These are just my musings. But if I ever start a proprietary trading firm, don’t expect me to be recruiting solely from two schools in Cambridge.

Thanks to Kellie Spahr for reading a draft of this post.

Neural Networks Are Not Evil

I recently read an interview with Gary Marcus, a professor of psychology and neural science at NYU. In the interview, he questions whether the big data approach to AI–that of training neural networks on terabyte-scale datasets–is successfully moving humanity towards the intelligent, sentient computers that we all dream of.

Roughly years have passed since that interview, and Marcus has now resolved his own question with a piece in the New York Times: “trendy” neural networks are not moving us in the right direction. He says this is because they lack basic concepts of the world that humans seem to learn by osmosis, like the natural laws of physics or linguistics.

I’d argue Marcus is jumping ahead a bit–nobody is saying that neural networks are the only key to AI’s future. I imagine an AI system in the future will encompass multiple systems, much like the human brain: a neural network for pattern recognition, a memory store for recalling things it has learned in the past, a physics simulator, a sentiment analyzer for understanding emotion. Most of these things already exist, and perform pretty well independently. The exercise now becomes piecing all of them together.

One other point I think Marcus fails to address is that of quantum computing. While it’s correct to say that our current AI methods are held back by computational resources, it’s incorrect to say that there’s no solution to that on the horizon. Ask anyone who’s working on quantum right now and they’ll say that the technology will transform the way we live within our lifetime. I think the computational limitations Marcus alludes to will be lifted by quantum computers, and conversations I’ve had with quantum researchers suggest the same thing.

Large scale collaborations are all well and good. But I think preparing AI research for the advent of practical quantum computers is the most important next step for the discipline.