BYOMSPM

This post could be one of the most useful posts I’ve written for BYOMSPM (despite its brevity). It strives to answer the question: how can we, product managers with less technical backgrounds than the engineers we work with, best understand and support our tech partners?

Grade I gave myself for this assignment:

The bulk of this post is based on a podcast from Product Podcast (see Works Cited).

First, the guest on the podcast busts some myths about software engineers. One of them is that often people perceive software engineering as a very independent and private job; his argument is that coding ends up being very public and high stakes since the main metric of success is binary — whether the code works or not. How can you have more empathy for engineers living this reality? I definitely have given my engineers a hard time (whether explicitly or not) about being really nervous about a release or reacting strongly to a bug/prod issue that is discovered. I think need to keep in the back of my head that the success of the code is the primary indicator to them and their bosses of whether they’re doing their jobs well (which is super different than the metrics of success for my job), and that will help me better relate to their nerves and reactions.

He then discusses the types of people who he’s noticed are drawn towards coding: perfectionists. He explains that there is a big coding community and culture around optimizing and improving code so that it’s as close to perfect as possible, and the people who find and stick around in software engineering are usually people who appreciate those kind of ideals. Have you noticed this at all in your work with engineers? Yes! A lot of the engineers I work with get really excited about cleaning up code, improving code, and optimizing it. Also, I’ve noticed engineers who are really self-conscious at the potential that someone reviewing their code might perceive it as not the “right” way to have written it.

He advises that product managers should be empathetic about engineers’ desire for perfection so they are more likely to be open about whether there’s a viable less perfect option to consider. Also, he recommends being communicative about the purpose of the code so the engineers can use their own judgment about how perfect it needs to be; without knowing the purpose of the code, an engineer’s default is probably going to be to make the code perfect.

Another thing the guest discusses on the podcast about engineering is that there are generally not only tons of unknowns, but also tons of unknown unknowns, and as a result many engineers will build in a big buffer for any time or effort estimates they give. He suggests that to ameliorate this, product managers should try to break down unknowns, blockers, etc. into more digestible chunks and aim to ask about “blockers” in more creative ways than just “do you have any blockers?”

The last thing I captured from the podcast is that, contrary to popular belief, coding is actually a highly creative and emotional activity, and it’s critical that as product managers we fully appreciate that. This is in reference to some of the points above, such as the stakes of coding, but also the levels of investment, frustration, and pride engineers often take in their code. Is there anything you do at work that feels emotional/creative? There are a few things: one is customer interviews, as it takes a deep level of empathy to put yourself in someone else’s shoes, and the success of the product is riding on how deeply you are able to do that; also, and this might be less universal, I think making any sort of visual design is a creative and somewhat emotional task (think: important deck).

Thanks for reading.

---

Works Cited

“Understanding Engineering Challenges without a Tech Background with Warby Parker PM.” The Product Podcast. 14 September 2017. Spotify