Episode 2: Joe Binder🔗

Summary🔗

Joe Binder is an 18 year veteran of Microsoft and Developer Division, with nearly all that time spent as an individual contributor. Joe's my boss today, and we look back on his time at Microsoft and the many lessons learned along the way.

This was a fun conversation about many things, including:

• Explaining what a Program Manager in Developer Division does to three different audiences: his kids, a new college grad, and an industry veteran
• Why he thinks he gets more mileage in his day job out of his English major than his Computer Science major
• How someone can spend three years working on memcpy
• What working with large partners like Windows, Azure, and Office really entails and how to be effective in that role
• Why he really wanted to come to the Pacific Northwest 18 years ago and why he decided to stay
• What it was like listening to customer feedback in the early days of the Visual Basic .NET team
• What we should have built instead of Lightswitch
• How his super power of not taking being yelled at personally contributed to his career success
• The balance and joy that he gets from living near Puget Sound and his fishing kayak
• Why the Azure CLI needed to be rewritten

Transcript🔗

Click here for an interactive transcript.

John: So you've been at Microsoft, working in Developer Division for like over 18 years.

Joe: I have, yeah

John: And almost all of that time as an individual contributor.

Joe: Yes.

John: And recently became a boss, like person here at Microsoft and you're in full disclosure. You're in fact, my boss.

So this could be a career limiting, move on my part. But what I thought, I like to do is focus on that time when you were in individual contributor on, so in other words, most of your time here and I thought an interesting way of jumping into that conversation is to have you try cause both you and I are our fathers, we have kids.

And I think one of the challenges that we often have is trying to explain what we actually do in our jobs to our children. And, so what I thought would make this more interesting.

While talking about being an individual contributor is if you could explain, imagine that I was a child here, and you're going to explain to me what you do in your day job.

And then imagine that I'm a college age person. And I was thinking about coming to Microsoft, like, how would you describe what you do to that person? And then finally imagine you're actually like me a grumpy old veteran person and you're in, I've worked somewhere else, not in Developer Division. How would you explain what you do to me?

Yeah, that's a very provocative question. I do have this discussion with my kids all the time. I don't know I've ever given them a satisfactory answer, but let me try. I think of my job here as a PM at Microsoft, as building things for users, with computers. And if you think about a phone, you tap on the app that you're going to launch. Somebody has to decide what that app does and what it looks like and how it behaves. And that's a big part of my job is trying to figure out what technology should we be building to really make users lives better or more fun. And every project I've worked on has distilled down into that.

But how do you know what you need to make? What that person who is using that thing needs?

Joe: Yeah. I think that's actually, the thing that I love most about being a PM is learning that is figuring out, okay, John, I just built this app. I want to watch you use it. I want to see how you interact with it and learn where are you struggling?

Where are you looking at it? This is not helpful. And. Then also looking at data too, to see what else are people using? What are they familiar with? How can I take some of those idioms that maybe you're used to double tapping?

John: But Joe, what's an idiom?

Joe: Yes. That's a very, I'm actually an English major by trade.

So I use arcane words. Sometimes I think what are the interactions with technology that you really familiar with? So if you're used to swiping left maybe my app that I'm building, should really take advantage of swiping left because that's something that your brain already knows how to do.

And so I should design whatever task I'm enabling for you as a user to really optimize for what you already know.

And by doing so you're learning more about me, right? As as the user of the thing that you want.

Yeah. That is definitely the most interesting thing. I would say that a lot of my work as a PM has started from what would I want.

And it's always really fascinating to me for products that I've worked on for a long time, how much the product pivots away from what I wanted. And I think for me, that's the fun part is like realizing that there's so many user needs out there that are so different from mine that I need to go learn.

It keeps us honest. It keeps it's fun. I think.

John: That's super. So let's switch gears a little bit and now pretend that I'm this college age person and I'm thinking about working at Microsoft, I just went to a career fair and see the logo and lots of fancy stuff about the company.

How would you describe what you do to me?

Joe: Yeah,

John: I took computer science, let's say.

Joe: Yeah. So for computer science student, I would describe what I do as building tools to make developers lives easier. And specifically as a PM, it's really figuring out what are the, what's the workflow that the developer that developers go through today.

If you think about you're sitting in your computer science class, you get an assignment, you got to go back to your dorm room or whatever and open up a code editor. You got to write some code, test it, see if it's actually working. What's hard about that? How could we make that even better? How could we make the process of learning technology even easier?

That's really what my job is about. And because I build tools for developers. I also have an excuse to write code a lot, to really put myself in the shoes of our users and work like they work and see, does this feel natural to me?

But it's different than being a programmer in the traditional sense where I'm spending day in and day out, actually writing the code for the tools that we built.

Instead I'm writing code as our users would write it. I'm writing code to understand how does the tool we build work.

John: So actually using the thing and in reality, as opposed to like theoretically.

Joe: Yes, exactly

Yeah. I to have some real projects that I'm working on, either at home or things, online courses or whatever that I'm taking, that I have to use the stuff that I'm actually building because that's helps me understand.

The strengths and weaknesses, or what's hard, or what's inefficient about the tools that we build is when I actually have to get something done, whether it's a plant watering system for my backyard, when I go on vacation, like I've got a goal in mind and it can't be academic. I really need the water to turn on when the humidity goes down.

John: Yeah. And I think that but it seems to me as a college student, that's a bit different than, proving my professors algorithms in some paper that he published. Like how does my education in computer science prepare me for what a job would be like as a PM.

Joe: I like to think of PM-ing as applied problem solving. I think about computer science as a form of applied problem solving. I always wondered when I was in school, Why do I have to take physics and calculus and all these things that realistically I've never really used in a computer science ish field. And it was all to help me understand analytical problem solving and how to break down problems.

And I think that the thing that you carry forward from your academic the proof for XYZ or whatever, write an algorithm to, traverse all cities in the United States, it's helping you understand how to solve problems in a deterministic way. And I think for PMs, we do the very same thing.

It's just the problems that we solve are actually user problems more often than not. And those are not as well structured as the academic problems that we often get, and that's probably the biggest difference is the ambiguity is significantly. higher. The uncertainty of whether or not we've actually solved the problem is similarly higher. But the core approach, the sort of mental model that you use in school around, how do you write an algorithm to solve a problem is really similar to how you work as a PM. You have to break down the problem into individual steps and figure out the constraints in which you need to solve that problem.

If we're we building an app for a phone that has limited compute as an example of a constraint, are we working on something for users who have difficulty seeing or hearing those are all constraints that we need to think about that, that you don't really have those constraints typically in an academic setting, but in a PMs world, that's part and parcel for what

John: And you also mentioned that you were an English major in college and. Do you think that was that helpful or harmful transition into working in this very technical field?

Joe: I think about that a lot because I got a degree in English and computer science concurrently, and I sorta wagered with myself at the time, which of these is actually going to be more useful.

And if I'm honest, I have enough technological curiosity that I think even if I didn't have a computer science degree, I would still be coding today simply because I find it interesting. It's a really unique way of creating things and solving problems that I think I'd always be drawn to. But the English degree, I think actually is probably more useful because being able to make sense of really dense information is just critical to a PM's job.

And it's also really rare, I think. if I think of all the other students in your computer science class, many of them probably would find it exhausting to go write a paper describing to an eight year old, what a piece of software does. Whereas I actually find that kind of energizing and I think it's really fun to figure out how could I describe this in simple and accurate terms?

That's something that I learned from working in literature and I applied pretty much every day. Like I think as a PM, you have to be excellent at written communication, certainly as well as verbal communication. And that's also the thing that I think helps propel PM's in their career is always trying to get better at how can I help people understand my point of view, the problem that I'm solving.

John: Yeah. I think that when I was in college, I took an international relations history class because I had to, it was one of those things that you you had to take. And that looked as interesting as anything else. And I remember finding my papers from that class in some box at home and I was flipping through it.

And then, cause I remember when I got the papers back, I was like, ah, I gotta B+ that's fine. Throw it in the pile. I'm like, I don't really care about this class, but what I, for whatever reason, I started reading through the professor's comments on my paper and I realized, wow, like all the stuff that I got as feedback in graduate school from my thesis advisor, were exactly the same criticisms as this undergrad history professor gave me. And I just really wished that I had communicated better or that I had learned the lesson at the time. I was supposed to be learning the lessons that, Hey, I don't care.

Yeah.

Joe: It's fascinating. I have a funny story about that one. I was just starting grad school and we had a small research grant, which paid for a semester or two of school. And it was from Sun Microsystems at the time Sun was all in on Java and then. the research grant was basically to build a test bed for this networking library that they were building in Java.

And as part of going through that exercise, of writing this sort of mundane test library, I ended up rewriting the documentation for the library because it was really poorly written. It was really hard to understand. And so we shared that back with Sun at the time. And they said, this is great. Forget about the test harness why don't you go rewrite all documentation?

And it was financially very lucrative for me. But it also opened my eyes to

John: so they paid even more over above the grant

Joe: exactly Yes. And it was really eye opening for me, just how critical it is to be able to capture and clarify exactly the work that we do. And I still hold that near and dear to everything that I do now.

Like whether it's an email I write or something that I work on, it's if somebody's really going to be able to walk away with this with a clear understanding of what I'm trying to say. So, yeah, I think overall English has won out as the as the more useful,

John: the truly useful. Yeah. No, that, that's not surprising. It's funny. I've talked to some of the new hires on our team and one of the things looking back, so I have no idea why I took computer science, it's like none of this stuff, I don't see myself using any of this stuff. And so why did I need to know it in the first place outside of what you said, right?

Which is I needed to figure out I needed some place where I would learn problem solving skills and computer science is probably as good of a domain as any

Joe: Absolutely

Yeah. I think it's also interesting for, I, think about this a lot, just given how many developers we serve now that don't have computer science degrees.

And so in theory, it hasn't been super useful, but practically speaking, there's certain code. If you will, certain jargon, certain even biases that we have. For folks who don't have a computer science background that I've been really reflecting on how do we break those down? So that really folks who are good problem solvers can be great PMs anywhere.

John: Yeah. That's what attracted you to the position?

Absolutely. Yeah. Yeah.

So now shifting gears one more time. So imagine that I'm now coming from somewhere else, let's say in a different company, even and you're trying to explain to me what a PM is in Dev Div Developer at Microsoft.

Joe: Yeah. This is probably the hardest of the three in my mind because PMs Dev Div are quite different from other areas of the company. Certainly areas in the industry because Dev Div has a unique role in the company that I've not really seen anywhere else, which is that we are really are responsible for building developer experiences, developer tools, APIs, SDKs.

Chances are good if you've used a Microsoft product as a developer, you've used a product from Dev Div and what's interesting the role as a PM here is that we rarely actually own the platforms that we support from a experience standpoint. And that is both really cool because it actually enables us to work on lots of different products.

Like I've worked on Azure, I've worked on Office, have worked on Windows, all kinds of from the same chair, if you will. And at the same time, it makes our job really hard because somehow we have to both partner with those teams to really help them understand what are the primitives that they need to go build to help developers understand their platform and be successful.

And also we have to build things on top of that to actually make it accessible, right? There's some, you can only make a, micro-controller so accessible to a developer at some point you need tools. And and I think a lot of,

A lot of what do as PMs in Dev Div is figuring out what's that ideal developer experience?

Where can we actually add the most value for developers to make sure that when a developer comes to a Microsoft platform, they have a really productive experience. That's part of our brand as a company. And I think we've come a long ways from the Steve Balmer jumping up stage developers, but the spirit of that still holds true.

I think. We have developers who come and continue to use our platform because of the tools. And so in Dev Div we hold that really high. I think whether it's VS Code or Visual Studio or Azure platform services like App Service or Functions, productivity is probably single most important aspect of the products build.

John: When I think about what you said earlier about how our tools and div are really at the service of a platform owner, like an Azure, like an Office, like a Windows and how we don't own those things. Those by PMs over in those parts of the company. How would I think about coming here if I've been steeped in product management through this idea that my job is to grow usage or revenue or some other growth aspect of the product itself.

Now what do I do once I get here?

Joe: Yeah. I would say that the single most important thing, if I were coming to this job or Dev Div in general is to build great relationships first and foremost, because everything we do is team sport, right? If I think about I'm going to go work on Windows tools or Azure tools, it's really shared success with the platform teams. And so building relationships to really understand like deeply amongst the platform team I'm working with, what scenarios are you really trying to enable and make sure I really understand. that because, as I've reflected on my own career, a lot of times when I've had like friction with some of these teams or just haven't jelled it's because I haven't really understood what scenarios most important to them. And definitely say that's the first thing is to really internalize, okay. Before we talk about usage or revenue, what's the core scenario you're driving for and what's the core outcome for that scenario? Sometimes it is something like revenue, where we might be looking at a small number of customers who are just going to pay us a lot of money, or we might be looking at, we're trying to garner usage from millions and millions of developers, understanding what's the business outcome.

What's the scenario. And what are the relationships I need to, build in order to understand that's definitely like the first thing I always find I need to do when I'm working on a new area.

John: So is that understanding the growth needs of the partner team and then figuring out what Dev Div's role is in trying to help them achieve success?

Joe: Absolutely. I think we often, I used to struggle with the notion of being in service to platform teams. And I don't really anymore because I really do think that our job is to multiply the impact of the platforms we support, whether it's Azure Windows or so on. So yeah, certainly understanding what does growth mean for them?

How do they want to grow is the most important question that we need to answer. And certainly in Dev Div, I work on VS Code as well, which also has its own standalone growth objectives. So we do have some things that we own ourselves.

But I would say that for most products, understanding what the platform's Growth objective is the single most important thing I do first.

John: And then from that, all of the, what kind of follows from understanding the why of the partner team.

Joe: Yeah Yeah

John: Excellent. So then switching gears again a little bit here what I thought we would talk a little bit more about is a little bit more about you and how you came to the company. So again you're at RIT you're an English computer science double major. What kind of drove you to come to Microsoft in the first place?

Joe: Yeah. Interesting times. So I had worked ,so RIT where I went to school Rochester Institute of Technology. They have mandatory co-op program, like many tech schools these days.

And that was actually super cool because it gave me a really good sense for the type of work I wanted to do and the type of work I didn't want to do. And I had worked as a sys admin.

I worked at a company called EMC that a pretty low level, like kernel level development.

Exactly. They're still going strong. And I realized after I worked for them for couple of years during college, even, when I was in school. And the main thing that I realized was that I loved the hardcore problem solving and like the technical excellence, but really missed the user interaction aspect of the job and being just a developer.

I worked on for the entire tenure for three years working there. I worked essentially on memcpy operations. And I learned a lot about performance optimization. I was the only person in the entire team that didn't have a PhD in some operating system- like field. And I realized it actually at it came to a head during 9/ 11 which was like the height of when I was trying to decide, what am I going to do after undergrad?

that I realized that I didn't want to just live in a cave, so to speak work down in the depths. So I really wanted serve users. That's what always drove me to get computer science in the first place. And I wasn't quite sure if I wanted teaching and education because I definitely enjoy that aspect of it.

And I teaching in grad school

Or if I wanted to actually just totally change gears and leave my comfort zone. And I actually chose where I wanted to live before I chose where I wanted to work.

So I had lived in upstate New York for quite a while, eight, nine years. I lived in Boston previously and all of them have a super intense, very edgy environment and culture work culture, the tech culture there at the time, I don't know if it still is super intense. Everybody works 80 hours a week drives 80 miles an hour to work like it's very edgy,

Very confrontational And and I needed a change of pace. And I also love my real passion in life is outdoor activities. So I love to Mountaineer.

I love to fish. I love to whitewater raft and it, the Northeast is not really.

that, is exactly

John: It's

Joe: Yeah

John: is missing.

Joe: Totally. So I decided that I wanted to move to the west coast. I didn't want to move to California. So somewhere in the Northwest.

and it just so happened that Microsoft came to campus.

I sorta joked because I had never, I like literally never had a Microsoft products after

John: Windows 95?

Joe: I Like I think we at school one year we had a Windows 95 or 98, like a bench of computers. But otherwise I had not really been exposed to Windows, anything, and I was not super high on Microsoft generally, but I showed up as a joke to my friends, and I'm going to go to this Microsoft interview and then they will pay for your your travel to come out and stuff.

And then so long story short. It worked out. I really planned it as, this is a sort of cliched story, but I really plan to just come out for a year or two and then decide what I really want to do. When I grew up and 18 years later here, I am

John: You thought you'd come out here, get paid to relocate, check it out and then find your real calling.

Joe: Yeah How many years do I have to work here before so I don't need to pay back my relocation fee.

John: So I have to about the memcpy thing. How can you spend three years working on memcpy?

Joe: Yeah, it's interesting. So at the time Intel had all these hardware instructions for like specific scenarios for memcpy and it's like EMC.

I worked in the file server division, and our job was we basically sold giant file servers. So this is the time when you would have a giant rack of hard drives and their big claim to fame was that they had, you could actually buy a quarter terabyte rack at the time with lots of cache in memory cache stuff.

It was a fascinating computer science problem because tiny performance improvements had huge business impact. So our primary customers were credit card companies, air, traffic control, large governments. And so if you tell a credit card company that, you can increase the number of transactions, like financial transactions per second, that they can, it's like millions of dollars per day. And we had a number high value scenarios. One of them was transactional scenarios where literally we had all of these different situations where we try and use hardware instructions to actually perform the operation instead of like higher level C things like that.

was a case where it always really hard to detect in which fork to take, because you often know what was in cache, what wasn't so that,

John: Were you tuning memcpy for specific. This is the L2 cache size on this CPU

Joe: precisely Yeah. Because they sold standardized hardware, so we could actually make a lot of assumptions about, and they had a fork of the file system and everything. It was very optimized for their scenario.

Interestingly, I also, what led me to leave there was one of the other scenarios that we sold, as a, as like a sales playbook was build machines and build clusters for like really large monolithic software.

And I spent three months debugging a intermittent bug in when the machines were configured as a cluster for a build cluster. We had this intermittent storage loss problem. It was super uncommon, but it turns out like you can't really sell something that keeps your data most of the time.

John: For credit card companies.

Joe: Yeah, I spent three months working on that and it turned out to be a bug and Linux and, but, it was I remember fixing the bug and feeling no sense of gratification whatsoever. It was just like, you know

John: Why did I have to do this?

Joe: I gave somebody a reason not to leave but it's that was the straw that broke the camel's back, so to speak. And I realized that I needed to do something different.

John: So it convinced you no more being a software engineer working on memcopy at the very least.

Joe: Exactly Yeah. And kinda thought maybe moving up the stack.

But I also realized that I am just energized by serving users. Like I really like this interaction it's like being a pro, a an instructor is that seeing light bulbs go off for folks is like a very energizing thing for me. And so I realized that working on something where I had to interact with users and really solve their problems was what I needed.

John: So then you arrive at Microsoft. What was your first thing here that you had to do?

Joe: Yeah, this is going to be an embarrassing couple of minutes here. So I had worked on file system stuff at the time. And so my first at the time .NET was coming out with version two. And it was still we're at this point of indecision, I guess you could say in terms of, we have all these Visual Basic customers who basically put Windows on the map. The ease with which you could build apps.

John: I was of them.

Yeah. It is just incredible how empowering Visual Basic as a tool for users and certainly for the company as well. And so the team that I joined was the Visual Basic team and our real challenge was. like how do we help this huge population of VB classic, non .NET users adopt .NET Because that's where all the innovation is going and overwhelmingly the canonical user of Visual Basic really struggled with .NET because it was written for computer science types. It's one of the first examples that I worked on was, the file API is for VB.NET at time. And I remember going to a user study on reading a file.

And I remember okay, here's System.IO. You got to read a file stream. And I'm like, yeah, this seems fine. It seems like these higher level API. is, And we're really, I'm used to living like down an inodes and stuff like that. So like System.IO was like, whoa, this is super easy. And. All the users were like, I have no idea what this is.

I just need to read the text this file into a string so that I can present it on a text box. Like how do I do that? And that was super illuminating for me. And that kind of became my first job was we worked on this, this set of wrapper, APIs called the "my" namespace. And it was loosely modeled after in Windows, My Documents and all that sort of stuff.

Joe: So we tried to take the mental model of the user and manifest that in a set of APIs that were meant to be easier APIs. So an example would be instead of getting a file reader or a file stream, you could just call a read text method and it would just return a string that had the text from the just Let me pass you the path to the file I want to read and return me as string. That's really what I want.

Yeah. And I worked on that. For quite a while. What was really there was, this was a kind of good, my first lesson in a way, like I learned a lot as a PM in terms of how to do user studies, how to really understand user needs and expectations, because we iterated on those APIs for over a year.

It's just, it's so hard to get the conceptual model right and I gained a deep appreciation for that because I think I, that was the first time I really realized that the target audience we had, they weren't trying to read and write files. They were accountants or they were trying to solve some much bigger problem.

And this was just the tool that they were using in order to solve it. And that light bulb went off for me. And it really energized me in a way cause I'm like, okay, cool. Like I, I'm never going to stop until you are successful. So after the VB product, we worked on the my namespace It never really took off. And in fact, VB.NET at the time as it was affectionately referred. We also were at,

point in time where, a C# was really the brand of .NET and C# were indivisible and we had to really make a choice at some point, of like, how deeply are we investing in VB?

At the time we had a huge VB team that was working in concert. Amanda my boss was the in charge of the compiler and the language for VB.

It was we had a lot of investment in that space because it was so critical to the company. We could not lose those customers. Of course we did lose a lot of them,

John: yeah, exactly.

Those customers, I still remember in Microsoft keynotes, the Professional Developers Conference there'd be these VB zealots, let's call them right. Sitting in the front row. And they would count the number of times that you had mentioned VB and the number of times you had mentioned C# and they would say Microsoft spent three times more times talking about C# than VB.

We feel not heard or unseen. So how was that?

Joe: So I learned a couple things from that. So absolutely. I remember the very same thing, of like really having to be intentional almost to the point of being unauthentic about parity between languages and things like that.

What I found was a couple of things. One was that I realized for the first time that for a lot of folks, those folks who were sitting in the front room of the front row, VB was a huge part of their identity.

John: Yes.

Joe: And we weren't messing with a product. We were messing with their identity and that never dawned on me until, because for me personally, like my job is just my job. It doesn't define me.

John: You were too young, you didn't have history.

Joe: Exactly. Whereas these folks said written seven, eight editions of, business applications with Visual Basic and all these other things. And so I came to understand a couple things from that. One was for me to just personally really reflect on how much of my identity I wanted to be based in my job, because I saw how crushing it was for them to have something intrinsic to who they were outside their control and going in a direction they didn't want. The other thing that I found really striking was we had these zealots as you refer them, like really passionate folks and they occupied most of the soundbites in the room. And I came to the realization as a PM that a lot of what they were saying, wasn't really representative of what users who are day in and day out using this stuff needed and were struggling with.

And that was a super important learning for me because it's always I think as a PM, there's always a email coming in every day, a tweet or whatever, There's some really emboldened customer who tends to have an outsized influence on the team. And so that kind of taught me the checks and balances of these are the most vocal people.

They aren't necessarily the most important folks. And they also aren't necessarily representative of the overall.

John: The squeaky wheel gets the oil.

Joe: Absolutely

John: And was there a lot of that back then on that team?

Joe: Yeah, this is a funny story. I told you that, I worked in this intense east coast environment where people would, you'd go to a code review and it was common to get yelled at.

That was like a common practice. And it was about my first week on the job I had to present to just the zealots. We had a private, I forget what we used to call it.

But it was over in building 20, right across the street from where we are now.

John: The SDRs?

Joe: Yes, software design reviews.

Thank you. Yes. And had to present this, my namespace thing that I had been working on for a total of five days, I think at the time. And it was awful. It was just awful. It was like, designed by committee. A hundred times over where I just got yelled at for a good two hours people I had never met had some deep seated frustration and really frustration was displaced.

They weren't really frustrated with me or with the product, with this sentiment.

But I also realized that was a bit of a superpower for me. It's pretty, I realized like afterwards I was like, yeah, that's just another day. But I realized that can be a skill that I can lean on.

Sometimes I don't really get ruffled very easily.

John: So just distancing yourself from the people checking yup, still got a job.

Joe: Yeah Exactly

John: Didn't get fired!

Joe: Yes. Yeah.

John: So then moving on from there. What led you to your next role at the company? Like how did you transition? How did you choose?

Joe: Yeah, it was interesting because I mentioned that VB was on the down swing and what we realized was that, or this is my interpretation of what we realized. We were missing the mark. We didn't really have product market fit effectively with VB.NET.

So what me, Jay Schmelzer, John Rivard, both of them still in Dev Div today and a few others.

We started just prototyping what we thought was actually what we would serve, the folks that we were talking to the boots on the ground, so to speak, who were using VB back in the day to get their job done, what they really needed, which was like what we would call forms over data. So really simple visual forms talking to a database, creating, transactions, querying data.

John: We called it RAD tools or rapid Application Development tools back in the 90s.

Joe: Exactly Yes We prototyped for awhile. This is when I went back into a little bit more of a dev mode. I did a lot of the prototyping myself.

John Rivard did a lot of it as well. There were a bunch of folks from the data team that owned like SQL Server and all that stuff that we all just had a skunk projects. And we ultimately chose to launch that as a product. It was called Lightswitch. yes And it failed pretty epically and but

it was probably the most important thing in my career to to happen because I had never really worked on something from the up and had to be accountable for figuring out something like product market fit. And I realized about a year or two in that I didn't really have this, the, tool set I needed to figure out whether or not we were building the product we really needed to build.

John: So that was your zero to one experience.

Joe: Yes

John: And then, we do like in the annals of history, there was this thing called Lightswitch that existed at some point, it doesn't anymore. What was it that kept you from achieving product market fit?

Joe: There's an interesting cultural backdrop to the company at this point. So this is during the this is pre Satya and I would say the organizational lines in the company were a lot more pronounced at the time.

There are frequently these kinds of zero to one ideas, just like I am the folks who work across the company on similar things, we put our heads together.

Let's try it. That was definitely not the case at the time. And we ran into a couple things. Like one was the classic large company problem of, if you think you're solving a useful problem, there's probably four or five other teams in the company who are also solving that problem. So Lightswitch definitely had that.

So Access was also going through this journey of their own of like Access had been a super popular tool. It really was the model of Access didn't scale at all. Because you. You used to build these forms over data apps, same thing, but you would deploy the database with your app and

John: It was in a single file, the MDB file.

Joe: Yeah.

There was FoxPro at the time and all these other things. And so everyone was starting to think about cloud type of stuff and trying to make these pivots Power Apps at the time was like in its infancy. So we, ha we were fighting against a lot of folks trying to figure out product market fit in the similar space and rightfully you know, Power, the Power Platform, essentially won.

And I think rightfully so they're actually, because we, what I learned from that was that having this tool that was neither a pro dev tool, nor a citizen developer no code tool, something in the middle. That there aren't too many of those users that actually exist. And that was like something I, I didn't really internalize.

It was like, I can go find all these people. Anytime we went to run a focus group, I could always find them. But like in the overall population, they were overshadowed by, effectively the users that Power Apps serves today.

John: I see. So the low code users that aren't typing a for loop or a simplified for loop.

Joe: Yeah. Yeah. So that was one of the main reasons effectively, we were building a product for a user that did exist, but didn't exist in mass. And we're also building a product that looked from somebody outside the building. It looked a lot like what other teams in the company were building.

And I think at the time the leadership team, rightfully, nipped that in the bud. So as not to create a big product positioning snafu.

John: So if you could go back in time, to, to Joe of that era, what advice would you give younger Joe?

Joe: Oh, that's a great question. The best advice I got this advice about two years after Lightswitch and I wish I had it before.

And the advice came from Cindy Alvarez. She wrote the lean customer development book. And I had the opportunity to go to Yammer at the time to just watch how they did PM there. So Microsoft had just bought Yammer Yes exactly.

Yeah.

And I learned a ton like how PMs work there and I remember sitting down with Cindy, like working on like a similar type of thing. Cause we were trying to figure out okay, that didn't work out. What should we do? Because clearly there's still like unmet needs and she just looked at me and she said, Joe, you have to leave the building.

And it's a profound thing that's always stuck with me that I realized that all of the PM work that I was doing and user understanding and market analysis was in the Microsoft bubble. It was essentially so heavily biased by Redmond Washington that it was totally irrelevant to a lot of the rest of the world. And so I think the one that one bit of guidance of like leaving the building, leaving my bubble, leaving my comfort zone of what the problem domain.

I know the users. I know like we, having worked in the industry for almost 20 years now, I have a long list of folks I can call up and oh, I need somebody in finTech who's doing I know five people But I didn't leave my own network. And so I had a raging case of confirmation bias basically from not leaving the building and in Cindy's words.

John: Yeah. So you're in your ivory tower, your network were people similar to yourself. And so you had a really hard time really empathizing really with the needs of these users that you really weren't satisfying.

Joe: Absolutely. And interestingly that you'll this one will come close to your heart.

So at the time I had started to really realize that Lightswitch was just on a path that wasn't a path we should really continue down. And I think all of us were starting to realize it without really talking about it .

And I got a random side project to do a demo of AWS and Ruby on Rails. And and it was for our VP of DevDiv at the time, his name was Soma, and I needed to do something a little different anyways. So I just needed to like re-energize myself. And I was like, okay, cool. I'll read all about this Ruby on Rails thing. And then I realized, I was like, this is actually what we probably should have built.

And because it was code centric, it took this, convention based model and it didn't try and be magic, but it did try to be helpful and smart defaults and all these things. But I think the other lesson beyond leaving the building it's just be willing to adapt and willing as I take in new information, realize that like the worst thing I can do is, continue to invest in something that isn't worth investing in and be willing to just pivot or adapt or, just own. that, Hey, you know what this isn't going in, the direction that I thought it was going to go, we should

John: Fail fast and iterate as quickly as possible as opposed to we're going to build this perfect thing we're to get enough research so we can build the perfect thing then we're going to go ship it .

Joe: Exactly. Yeah.

John: Yeah. Because certainly seems like that helps you get to a place where you start getting feedback from real people, as opposed to your cherry picked.

Joe: Absolutely. Because the Rails thing really highlighted that for me, it was that a lot of people who were VB customers had migrated to Rails.

And, also, like I remember interviewing in a customer interview since somebody who was on the VB team, who now worked at a Rails shop, and I remember like, how did this happen? Like he used to be one of us know and And, it was really fascinating because it's I we, he was working at a startup He's we started this startup, we just needed something up and running quick and, and it highlighted for me that there was this whole other community that I wasn't learning from.

Cause I wasn't talking to, and that, that whole leave the building thing, leaving the comfort zone. I realized that's probably the most important way to de-risk what I'm working on is if I'm actually talking to folks who aren't using my products, then I'm going to learn as much, if not more than folks who are.

John: Yeah, absolutely. Because there's some reason why people left to go do some other thing. And if you go through life kind of being ignorant to those reasons then you're really not going to learn. It's really hard to grow that way.

Joe: Yeah.

John: And the echo chamber here is strong in Redmond.

And cause it could reminds me of a long time ago with the I still remember the very early Ruby confs. This is circuit 2005, -06 before I came here and what was interesting about Ruby was really more that it attracted a certain kind of person, especially in those days.

Rubyconf back then was a single track 200 person max conference. And when I look back at the people who were in the room physically in that room and the kind of value creation that they created both around Ruby itself, but mostly let's be honest around Rails is astounding, right?

We had the GitHub folks. I actually wasn't quite the GitHub folks but the people before they even thought of creating GitHub were in the room, which was super interesting. Shopify Toby was there. He gave a talk at that conference and it was just like, ah, I'm just trying sell snowboards online. And this Rails thing was awesome for doing that.

The Twitter folks were there.

It was almost like the beauty or the elegance or the kind of the aesthetic perhaps of the language. It brought people in. That alone I don't think would have given you those pragmatic people that you saw.

But I think that it was really DHH and Rails that and in particular, the demo the Rails demo is just this incredible demo is I'm just going to type some stuff with the command line and boom, I've got this whole application and people go, oh, how do I get more of that?

Joe: Yeah. I think the other aspect of this, I remember seeing some demos of real Rails apps at the time.

John: It wasn't just a toy

Joe: Yeah. And I think it was User Voice or some of these other web platforms. And it stood out to me that the thing that I love most about my job is actually seeing what people create with technology. And seeing to me, it's we often think about as PMs, like, what should we talk about at conferences and whatnot?

And the thing I realized from all of the open source communities I've engaged with over the years is that the things that really create the energy is sharing. This is what I built, and this what I learned. And that's such a powerful thing. That I think it's also a bit of a now it's in my sort of toolbox If I can always looking for, if I'm working on something, who's actually building something cool with it?

It's a kind of a nebulous signal to use, but it's an important one. Like you kinda know it when you see it and if there's a vacuum and you haven't seen somebody, who's like wow, I built something cool with. this. That's probably a tell and I want to drill into that, but yeah,

John: Tim O'Reilly built an entire empire, O'Reilly publishing around what he called the alpha geeks or what are the alpha geeks looking at right now, because that's, that, that is an indicator where the industry is likely to go.

Joe: Yeah. And I think it's also I worked after Lightswitch I worked on Azure stuff pretty much until present day and that story has played out time and time again, in terms of container orchestration, CI systems, et cetera, et cetera. It's not really the best that wins often.

It's the one that folks have found the most useful and who are willing to stand on a podium, so to speak and share how useful it's been and contribute back to it because, oh my gosh, we rely on this. Now we need it to be better.

That playbook is super it just continues to repeat itself.

And I think Microsoft has done a better job of recognizing that over the last several years, but at the time, way back in the early 2000s , that was not that was not really in our wheelhouse.

John: Yeah. And so you live through that transition, the transition from this very kind of like inward-looking echo chamber-y kind of company that I still remember cause he brought up Soma.

Before I had to give a talk at OSCON the O'Reilly open-source conference, we wanted to announce that we were going to contribute some tests back to RSpec or Ruby spec, which was this test suite that kind of, because there was a proliferation of Rubys at the time and we needed, and there was no spec, right?

The language, the spec was the implementation. So we needed something that would validate whether or not something was Ruby or not. And all we want to do is contribute some tests to this Ruby spec suite and I had to get Soma's permission, which finally came at midnight , the night before I was going to give my talk at 8:00 AM in the morning.

Oh, that's cutting it a bit close folks. And and that, that was the environment, right? Like we're contributing tests to some tests suite and I needed senior vice president approval in order to go get that done. So how is it from your vantage point like that transition point from, this kind of super inward looking company to now the number one open source contributor, I think out there in the world.

Joe: Yeah. It's it's really interesting. I did have a front row seat to some of that because it's at the, contributing back to RSpec like the precursor to that for us was when I was working on Lightswitch, we had a web client and it required legal approval and VP approval to use jQuery.

And jQuery obviously at the time, it was like, you really couldn't build a website without jQuery, practically speaking. And it was hilarious, but I think over the, after Lightswitch my focus started to be on non .NET languages and customers on Azure. I pivoted there. I came back from parental leave and I was like, told my boss. I was like, I just need to work on something different, throw me on something different and I'll go. And and it was interesting because if you, at the time we actually had a separate organization. MS OpenTech

John: Sam Ramji's thing.

Joe: Yes exactly. It was like a subsidiary of Microsoft to work on open source.

And I had come back just as that was dissolved and it was really interesting because at the time we were trying to get tools like Jenkins, Ansible, and so on to work well with Azure. And there was still a lot of friction for a long time of if we got Ansible to run well, is that going to erode Powershell's share on Azure and things like that?

And I learned a lot from that because I also found that sometimes the open source things ... it seems like at the time folks viewed them in an almost binary way. They were either amazing and perfect. And we should just drop everything and use them, or they were the bane of our existence. And, we should wipe them off the face of the planet or whatever.

And what I realized is that, as I because I had this learning now, that it's I need to see customers building something. Like when I was working on the Jenkins stuff or the Ansible stuff or Terraform in the early days of Terraform, it's the first thing I wanted to do is I want to really get to know every customer who's using this so that I can learn from them.

That was like my big lesson learned. And it gave me a lot of insight into ... Nothing, there is no panacea in technology, everything has limitations and drawbacks. And I think it took us a few years as an organization to recognize that open source had pros and cons just like everything else.

And so can we actually I think now we've definitely gotten to the point where we're super objective about it. We understand the critical role it plays. But working through those kind of growing pains was definitely challenging. I remember being I was working on Jenkins stuff as well as we had chosen to rewrite the Azure CLI because we had this really old node CLI which most customers failed to actually install successfully.

Cause getting node on your box is super hard. It was really slow and it was also a lot like the PowerShell interface. It just didn't feel like a POSIX style tool.

And I remember going to various teams in Azure, describing Hey, we really need to build a real command line tool for our Linux audience.

And yeah, for a while, I was yelled at pretty pretty frequently purple in the face, very senior folks. And I learned a lot from that, but I think ...

John: So your earlier thick skin thing really helped you.

Joe: It definitely a super power of yes, I'm always willing to be yelled at because honestly, like I've always found that I've learned from those those moments a ton.

Like I remember having a discussion with Jeffrey Snover, the creator PowerShell and he was really upset. And it took me to why he was so upset to realize that actually there were a lot of this plan that I had put together that I really hadn't thought through that mattered a to him and I, it was one of those times when I I really because I ended up having dinner and we went to a shared dinner and he happened to be there.

And and it this light dawned for me, because a, fact that I hadn't really or defensive meant that I could now sit across the table from him at dinner, without it being super awkward. I also learned a ton and it really taught me that like in a company like Microsoft, even as big as it is, you always, people are in your network forever.

And so how you respond in those moments, it's going to be the lasting memory that person has of you. And. And it was just a good reminder because I was pretty close to flipping the bit on that one. I'm like, you know what, I don't really need to put up with this. And but overcoming that I think was a good, it was a big milestone for me I'm just like realizing that wow, like actually we ended up collaborating on something the very next month, which was like the porting PowerShell to be cross-platform.

So they're building on dotnet core. And I was like, hey, I sit in the same room as the dot net team, let's work on this together. And it really worked well, but it's one of those things that I think, that was like the next milestone in my career of just learning how to be patient and recognizing that people, the the sort of permanence of one's network in a company like this.

John: And also that ... The one thing that I've learned I think is that people aren't, I don't know, mean or difficult or whatever it is because it's what they are, who they are, but the rather it's almost always a mismatch in priorities. Your priorities are different than Jeffrey's priorities.

And because of that, you look at the world through the lens of your priorities.

Joe: Absolutely Yeah.

I think a mismatch in priorities, and then a different point of view in terms of what requirements we're actually trying. What's our objective that we're really going after, because sometimes I think I've assumed a shared objective when there really isn't one.

John: Right

Joe: And it's no, actually, like we just have different objectives and it's okay, cool. Once I understand then it's actually much easier to engage.

John: Yeah, one thing that, again, that's always really challenging is assuming that you're on the same page when you're not actually on the same page.

Joe: Yeah. Yeah. I think the times when I have not been at my best are the times where I've had those whoa, what just happened there moments it's because I made assumptions that I didn't actually test about where we were as, two teams working together or something, even two people. That's that's a lesson I I continue to learn from I think it's not always it's not always roses, but I think figuring a better system to like always check assumptions about what problems do you think we're solving?

What problem do you think you're solving? What are you driving? What are we, what's our outcome having that explicitly up front, just save so many problems.

John: Yeah. Because in the absence of that, everybody just makes up their own story in their own mind.

And they think, yeah we're on the same wavelength here

Joe: Yeah. Yeah And then they get upset when something different happens.

John: It's somebody once said to me a long time ago it's impossible to over-communicate in a professional or in a work setting. That's just hard won experience from things like this. And I certainly seen in the past when people have a completely different idea about something that I thought I had explained super clearly.

Joe: Yeah.

John: And and that's really hard. So again, like we've few interesting things that you've done in your career. Was there something looking back over the entirety of it that you wish that you had said yes to, but you didn't at the time?

Joe: Yeah. That's a tough one. I have to say I don't... I am usually a yes- and type of person.

John: Improv.

Joe: The examples of things I wish I said yes to I, I'm not sure I'm really not. I think the only thing that I actually wish I said yes to are things that happened outside opportunities I had outside of work that I didn't say yes to because I committed. to work.

And I definitely, I think those are the most profound things for me, where like at the end of the day, my impact at work is not predicated on whether or not I'm here this week or next week or whatever.

And so. it's hard For sometimes to recognize that

John: The place is going to fall apart if I'm not here.

Joe: Yeah, exactly. Yeah. I think those are probably the biggest examples. Yeah.

Yeah.

John: You rarely find anyone at the end of their life looking back and I'm like, oh, I wish I've worked that Saturday. Yeah on whenever that was Yeah. Yeah.

So again, looking back at everything, what's the thing, what's something that you're particularly proud of as an accomplishment? Not necessarily because it had huge impact or anything but something that really changed your trajectory.

Joe: Yeah. The thing that changed my trajectory, I think was this is a longer answer. Most of my role, the first 10 years of my career, like working on VB, working on Lightswitch, that kind of stuff. I worked in a pretty isolated team. And I didn't really know how to collaborate cross team.

And I think a switch flipped for me when I realized that everybody that I'm working with also has a life. They also have emotions, they have feelings that they are just trying to get their job done and I can play a role in making their lives better that to actually help them in some material way.

Okay. I tend to spend a lot of time with Kusto and telemetry and stuff. It's you know what, maybe I can spend 20 minutes helping you write that query for whatever. Realizing that the sort of human aspect of the work environment and that I did have a role in like lifting people up that actually changed my career trajectory in a pretty profound way, because it meant that I was no longer entering problems trying to be like, I'm trying to get this outcome.

Like I needed a decision made and I'm going to go like beat this person over the head until the decision is made or give them all the information, like machine gun the information to them until there's no other answer but yes.

When I realized that at the end of the day, what gives me the most joy from my job is actually seeing other people thrive and playing a role in that. Then I realized that I was actually doing a much better job myself because it was a natural filter, like in my career, as I've grown, it's no longer possible to have significant impact as one person.

A lot of times I find that if I take, if I just pause and say okay, like how can I lift up the people around me so that we all have impact that we have?

That's been like a game changer for me. It's it's made me more successful. It's made me happier as well. Cause it turns out that's a much, much better way to live.

John: Yeah. And when I think think back to, folks coming in from college oftentimes they've spent their entire life just doing things on their own.

I have to write this test. I have to go do this project or this assignment and every now and then there's some group project or something that's thrown in there. But but it's, but now all of a sudden they're in this different world and they working on their own because they think I need to get credit for this thing that I'm working on. So I can get the "A" and I can't do that with other because then could be their work or something. And so overcoming that, it's you said it took you 10 years to get to that stage.

Joe: I think there's a certain irony of being an individual contributor as a PM.

The irony is that you have to be really great at working with others, because everything that, as an individual contributor, like everything that you do is influence without authority, and so people have to want to work with you. And and so that's one aspect of the individual contributor career path.

I would not have been able to continue growing in my career if I hadn't learned that lesson of actually, this is really a team sport, I'm here to actually lift others up because it's actually, they're the ones who are largely going to do the work that I'm trying to make sense of here. And I've actually found that as I've shifted to a manager that has served me super well because it's actually possible to go down the manager path and just own your own team and not really have to work with others, but that can be limiting to.

John: Yeah. And so now you're in this role where your job really is to help grow your team and help those individuals succeed. In addition to the people that perhaps you talk less to, now that you're your manager person that you used to talk to in as an individual contributor person.

Joe: Yeah. Yeah. It's it's it's a really fun journey, it's kinda, I made the switch largely to be honest, because I realized that actually that was what brought me more joy than like the hardcore technical stuff.

As I enjoyed the technical stuff, but after 20 years or so going from memcopy similar types of like down in the weeds things, it was actually the helping the folks around me grow that was actually what was bringing me the most joy. And that's why I made the explicit switch.

John: Yeah. I remember some sage words from an old boss of mine was software engineering is a social science. That was Steven Sinofsky and that, that really stuck with me. Cause that's the hard stuff, in lots of years of observing Microsoft I have no doubt about our ability to execute on some technical thing. That's not hard it's executing on the right technical thing, that's the really hard part. And that's where all the squishy messy people's stuff shows up.

Joe: Absolutely Yeah. It's like how can you bring out the very best in everybody so that you more commonly do find the most important thing to work on.

John: So to wrap things up, I thought I'd just ask a couple of fun questions. Like what's something that you purchased or got, or acquired were given to you recently that brought you like an outsized amount of joy that you would have never predicted.

Joe: Yeah. I have to say, so I, I love to fish. Fishing is like always been a big thing. I grew up working on a farm and stuff, so I've always been outside and during COVID I bought a kayak specifically for fishing and I have friends who have boats I have a whitewater raft and other things

But the kayak has been just like this great source of joy because I can throw it on my car. I live 10 minutes from Puget Sound. Be on the water at 5 and still make it to work by 8:30 no problem. That has just been a really awesome.

John: So what's the Zen of fishing for you?

Joe: Yeah, it's it's really about observation for me. So I like to take in all of the signals, so like I fly fish a lot and It's like understanding what the fish are doing, understanding what insects are hatching, what temperature do the insects hatch at, that sort of stuff I think is it's really fascinating for me because I have to immerse myself in it. And I think leaving work, leaving, the stresses and challenges of being a parent and all that stuff for a period of time and immersing myself to just observe everything is that's the Zen.

John: So fishing is like a solo activity for you. It's not a ...

Joe: I have, I one good friend that we usually go together, but yeah, we it, there's not a lot of talking a lot.

John: And so you're out there, you're in your... what's a fishing kayak what's different from a regular kayak?

Joe: main difference is that they have pedals instead of using a paddle. And the reason for that is so that you can fish with your hands while you're moving.

John: Oh, so you can move forward by like my, like a bicycle pedal or, yeah. Interesting

Joe: They're a little bit stable also than a sea kayak, which, are very long and skinny, but also very tippy.

John: Very tippy.

Yeah.

Joe: Yeah

John: So how does that work. Is it like they're outriggers or is it ...

Joe: There are no outriggers, they're just bit wider.

John: And then what's a a story that you've shared with others and in particular, and what was it about that story that kind of made it compelling to you?

That story could be anything. It could be a book, could be a movie. It could be ...

Joe: A story that I have heard or a story that I have told?

John: Either one.

Joe: I think that. I have a significant recency bias with this. I love to read, I probably read two or three books a week. And I recently read a book called The Golden Spruce. It's a non-fiction book and it's about this huge Sitka Spruce in the Queen Charlotte Islands that has for reasons that nobody knows has golden needles.

And it's about, this seemingly deranged, perhaps not extremist who cuts down the tree. It's like a thousand year old tree. And what struck me about that story is that it talks a lot about the Haida native population. It talks a lot about logging environmental ism. And what struck me about the story that I think was really powerful was that It presented a really genuine, but diverse set of points of view in a really compelling way. Often I find like whether it's at work or in literature or documentary or whatever, that there's always some heavy bias, that's hard to unravel. And what I appreciated about that story was that there is no clear answer for why this tree existed or whether it should have been cut, whether cutting it down, actually achieved the objective, which was to highlight the hypocrisy of logging in the area and things like that because they were highlighting how wonderful this tree is while they were ravaging the rest of the Queen Charlotte Islands, basically.

What struck me about this story was the really diverse points of view in the sense of conflict that's unresolved, because I find that a lot of times stories want to have a resolution, I told you as an English major. There's always some resolution. In life there's a resolution.

And I always gravitate towards stories that are unresolved.

John: So the story left a lot of tension in the air? But at least it exposed you to the tension as opposed to just watch, sweep it under the rug...

Joe: Yeah. It's one of those books that I'm like, I still don't know how I feel about this. Who, do I believe in that the sort of antagonist point of view and that sort of thing. Yeah that one stays with me.

John: Wow. On that note I think I'd like to thank you for the conversation. This is a super fun for me and hopefully folks got something out of this as well.

Joe: Well thanks, That was super fun. I I appreciate you doing this and it's always fun to chat and get to know one another, on a more human and personal level than just talking about shop all time.

And we're actually in the same room doing this right now. And unlike, and one of the impetuses for this was just all the isolation that we all felt sitting in our bedrooms or wherever ...

totally

John: ...talking to each other.

Joe: Yeah. It's I have to remind myself how long the last couple of years have been ...

John: It's been a couple of years

Joe: Reconnecting in whatever form, whether it's through things like this or in person or whatever it's been really awesome.

Long overdue. Yeah. Yeah.