Alex Weinstein
On Growth, Tech, and Leadership
The Core Pillar That Drives Technologists

This article is about putting labels on people. If you’re a technologist – a nerd at heart – I’m going to put you into one of three categories. I’ll call them D, T, and P. I’ll explain what they are in the end.

D’s like beautiful code. They love complex algorithms, elegant systems, clever hacks. They thrive on discussing design patterns, threading, synchronization. They care about HOW something is built. They don’t care what the thing is – a microcontroller in the pacemaker that saves lives or a mission control system in a nuclear weapon.

P’s don’t give a crap about how something is built. They care about the customer’s pain. They almost *feel* this pain themselves, and this empathy drives every action they take. They want that pain to go away. They want the double entry to disappear. Seeing the “OH MY GOD THIS IS AMAZING!” expression in customer’s eyes is the ultimate goal for them. P’s don’t care if the way this was achieved was through copy-pasting the same stupid code snippet thirty times, creating an unmaintainable, ugly piece of code.

T’s like breaking things. From their early age, they found satisfaction – true, internal pleasure – in pushing the boundaries of our everyday objects. Any creative person might give you dozens of ways to use a paper clip in a few minutes. T’s will tell you how to break a paper clip –  and it will be quite a natural mental exploration for them. T’s just feel so snug inside when they can look at a piece of someone else’s work, and find a way to make it do unexpected things. T’s have a drive to prove their mental superiority over the creator of the product.

Fine, fine, this wasn’t a difficult puzzle. D’s are developers. P’s are PM’s, product managers (Microsoft calls them “Program Managers”). T’s are testers.

Here’s why understanding these core pillars might be useful: when you know what should drive a successful person in this role, you can interview for it.

Test. Don’t ask them whether they’ve written automation before. Ask them to list 50 ways to break an elevator.

Dev. Don’t ask a Dev whether what the difference between ShowDialog() and DialogBox() is. That trivia can be looked up in 30 seconds or less. Ask them a basic algorithmic question; ask them to code it in any language of their choice.

PM. Interview for empathy, and the ability to convert that empathy into designs. Ask them to design an ATM for a 5-year-old kid. Ask them to design a remote-control system for window blinds.

P.S. If you didn’t guess from the rest of this blog yet, I’m very much a PM. Most of the code I write is quite crappy – it’s a means to an end.