A couple weeks ago, I had the pleasure of doing the Developer On Fire podcast with Dave Rael . The audio is about 45m. I figured that reading it might (and that is a huge might) be interesting. It isn’t a great transcription. And sometimes I read like 3rd-grader. Anyhow …

Episode 240 | John Cutler - Making Value
John Cutler is keenly focused on user experience and evidence-driven product development. He mixes and matches various…developeronfire.comDave: Why are you so lit up about making stuff for people?

John: I think that part of it is the experience of working with other weirdos and makers and other people. I obviously take a lot of pleasure out of building something that someone uses and gets value out of, but it’s the whole process that I like. I like the challenge of it. I like the fact that things are often sort of unclear and I like all the weird banter from the people on my team and the characters that we have. I think it’s the variety of people and you’re not really battling this corporate stuff when you’re in the zone as a team, and that’s what I really like about it.

Dave: Cool. That really paints a picture. You emphasize something there of enjoying the journey. It’s not all about a destination. It’s not all about some finished product. That you are getting something out of the actual experience of interacting with team mates and I think that’s something we can really take something away from.

John: I don’t spend a lot of time writing code, but I usually ask my teams, if you controlled the budget, would you hire me? I feel that the product manager’s role is often misunderstood, or it’s stereotyped, just like the engineering role is often stereotyped.

If you controlled the budget, would you hire me?When you peel it away and you boil back to the people involved, there’s a lot more diversity than we make it out to be. I like being there in the trenches and adding value where I can and adding context where I can. Something that I’ve noticed about a lot of engineers is that … I don’t think people outside of engineering truly understand what it’s like to have to show up and make those types of cost benefit decisions all day. Being deep in the code and then thinking about it or rolling back their chair and having to ponder something for a while.

I don’t think people outside of engineering truly understand what it’s like to have to show up and make those types of cost benefit decisions all day.People from the outside look and say, if you don’t see hands on keyboard there’s no work happening. When you’re there working with people, you understand how reflective the work is. I like being part of that because I think that adding context, helping people solve problems by giving them more data and more information, is the number one way that you can help the other makers and people on the team. That’s why I like the role and the role’s often misunderstood, but I have my own version of it basically.

Dave: Certainly, I think it is definitely misunderstood when somebody says product manager, I think that’s a different kind of a role in every organization I’ve been in. You mentioned that you don’t do a lot of coding. Can you tell me a little bit about your background just so that listeners get familiar with? Are you a coder?

John: No. Developers on my team nicknamed me Sudo. That’s my nickname. I did have a startup or two startups where I got pretty decently into Rails. I could get through to the end myself, but I kind of knew the limits of … The limit wasn’t … It’s kind of hard to admit. The issue I had with coding is how deep I got into it as a personality, and I think that’s because there’s a certain point when you have a problem solving mindset, but there’s just part of the guts that you don’t quite understand. When I got heavily into Rails it was like a big eye opener. If you understood where you needed to get, there were nouns and verbs that you could make work. I would go so deep man.

The issue I had with coding is how deep I got into it as a personalityI wouldn’t go to sleep for days on end, and I built like a personal challenge site called, ‘Go for 30’. The whole idea is very Meta because my goal was to relaunch the thing in 30 days. My personal 30 day challenge was building my own product in 30 days. That was my challenge, to spend all day doing it. I did that, I did some other prototypes for people, but it was mostly in Ruby on Rails and then I got into some Python stuff for doing analysis. That’s the extent of my background there, but it’s something about … I don’t know how the great engineers I know do it, because you’ve got to solve the problem. There’s a binary way to solve that problem and you can just hit your head against it. I flirted with that, realized I had other things to add to this, some other types of ways of thinking.

I don’t know how the great engineers I know do it, because you’ve got to solve the problem. There’s a binary way to solve that problem and you can just hit your head against it.My background was music and just figuring out my 20s. I had a post recently on about people being drifters and I think that especially those of us in tech, there’s the stereotypes and that’s how a lot of people got to it. I worked with a great engineer who had discovered engineering a lot later in life, and they took a whole different path with their life. That’s me. I don’t know if I answered the question, but I’m all over the place and I don’t care.

Dave: What is the role of a product manager?

John: You could take the Meta perspective. The role of the product manager is to find out what the system needs and then apply yourself to that part of the system. That’s a little weak.

I have my version of it, which is you are a context builder. You are bringing information to the team. You’re bringing system’s thinking, you’re bringing decision making frameworks, you’re bringing valuable things. You’re not there to control the team. You’re not there to rush the team. You’re not there to tell them to cut corners. You’re there to help them with data and facilitation and other things to move along the process. I think also you bring a big library of interactions with businesses and users and other things like that. It’s that sixth sense like, ”Hey guys, this seems like I’ve been here before.”

You are bringing information to the team. You’re bringing system’s thinking, you’re bringing decision making frameworks, you’re bringing valuable things. You’re not there to control the team.They want a custom field but they don’t want a custom field. They really don’t want that. Or, they say they’ll pay for that once we deliver that, they’re not going to pay for that once we deliver that.

I think that you bring experience in these interactions with users and customers, and also just knowing that surprises happen. I remember when we had the bartending game. We were demoing it and someone took the mouse and then picked up the shaker and then started shaking their mouse, and we were like, “That’s genius. Wouldn’t that be so cool? Wouldn’t that be so funny if people play the game and you see them shaking the mouse back and forth?” I think as a product person you understand too, where to look for happy accidents and opportunities and stuff.

Not all PMs are the same. Some people work in very transactional environments where their responsibility is to show up in a meeting once a week, tell people what status is and go back to the teams and what they call herd cats. That’s not my background, but I could see environments maybe where that role’s required. It’s just not my thing.

Dave: Yeah, that doesn’t sound so appealing. It’s not having the impact on the product in the way that you talk about and the way your blog depicts. I think that’s the contrast. You had a blog post about the evolving role of the product manager and that very contrast there, right. Kind of the old way of looking at it, so the command and control, they’re pushing the team in certain directions versus being a part of the team. Being somebody who brings that interaction. I think that’s really a big thing there is that a lot of … It’s a stereotype. A lot of engineers have some difficulty with understanding what it is that somebody else wants, and that role to try to bring out the thing that is really needed. The thing that’s going to truly deliver value, not necessarily just the thing that’s being explicitly requested, but that thing that’s going to actually solve the problem.

That’s a unique talent, and that’s something that not a lot of people have.

John: It’s also something you have to spend time on. This is where the balance with teams. Literally one hour ago I’m talking with an engineer before this podcast about particular … We had a couple support requests sitting around and in an environment where someone’s responsibility is to sit there and triage them and then give the team permission to work on one of them or the next one, you do this and you do that. We were talking about it and he made a point. He said, “That thing you were working on until 10 o’clock last night, where you were talking about the big missions we need to solve, and how you were making sense of the problem, is 10 times more valuable than coming in and trying to help us project manage ourselves to do these things.”

That meant a lot. It shows that we have respect for those things. We all wear hats. Sometimes you need that i-dotter and t-crosser because just doing those things could take a whole day for someone. There’s never a solid answer for this about what someone should do or shouldn’t. It’s like a contract with the team. Like how do we want to split what we’re really good at here? Then also knowing the difference between a project manager and product manager. Sometimes you need someone with that amazing skill, which I actually don’t have. I’m not a great i-dotter t-crosser.

We all wear hats. Sometimes you need that i-dotter and t-crosser because just doing those things could take a whole day for someone.Dave: Sure. That’s totally great. We’ve mentioned your blog a few times here, you’re a prolific blogger, you’re getting a lot of attention. Some of the things that you put out there really resonate with people, especially with application developers. Tell me a little bit about that experience. Why do you write the blog and what’s the ultimate objective?

John: I think that a little bit of me thinking out loud. I’ve joked that if I had this conversation with the people around me all day at work and loved ones at home, that I would annoy the crap out of them. I mean literally. It would annoy the shit out of everyone.

Sometimes it’s because I had a really good day and it forced me to understand what something happened a decade ago in my life or with teams, like what was wrong about that situation. I’m constantly pattern matching, I’m constantly reflecting and this is just my way to get it out there.

I had an engineer friend who said one day, “Look, I write test driven development. What does test driven product management look like?” That hit home in a big way. I was, “Oh, you live in a world where there’s right and wrong and I’m just telling you to just do stuff.” I think that was an eye opener. The couple of posts that had engineer attention really hammered home for me. That we all want to create impact. I think that some people are in environments where they just kind of give up on the business. They’re just like, “You know what? This is just going to play its course. Same old BS, whatever. We have a tight team. We’re hacking away. This is a good thing and we enjoy this.”

I had an engineer friend who said one day, “Look, I write test driven development. What does test driven product management look like?” That hit home in a big way.I just think especially as engineers get older and more … over time, that stops becoming something they can just forget about. Because the technical challenges become more common as your career develops, but the impact challenge becomes something that digs into you as you get into your 30s or 40s.

Dave: Yeah, definitely. One of my biggest experiences was that I designed a system from the ground up to make life a lot better for this company that was an amalgamation of different companies that had been acquired, and replacing all of the legacy systems with this new thing. It over time started to gain traction. Everybody started buying into the architecture and it started to … Some of the emphasis that I had put there on autonomy and teams being able to do their own thing and test and deploy independently and all of these stuff, it took hold and then the company shifted priorities and wound up blowing up the whole organization. All of that effort just went up in smoke. There’s just such a punch in the gut on that.

All of that effort just went up in smoke. There’s just such a punch in the gut on that.I’m not quite sure what my question is, it really resonates with me that that impact is so important, so vital in our experience.

John: I see some movements like craft movements, like code craft movements and things. I’m really psyched about those movements, but I think that there’s a little bit of a retrenching back into the silos of it. It’s a little bit like, I don’t feel that my work has impact but if I join this craft community, at least I know there’s craft for work that I can do. When I think about product development, I think of an overarching development craft that we all participate in.

It’s a little bit like, I don’t feel that my work has impact but if I join this craft community, at least I know there’s craft for work that I can do.A great example there is how you build a machine has as much impact on the ability of that company to scale and do what it needs to do and achieve new other opportunities, then the UX of that thing. Thinking about code as a way to also scale the organization in a smart way, those things are massive. When you look at a lot of companies that are “successful”, but they’ve let all that stuff fall by the way side. They have their hands completely tied. They go out and start to buy other companies. They go out and start … Because the only way … It’s not a problem of cash. They’ve got the cash but they can’t apply the cash to the problem internally, so they’re going to spend the cash outside to get that result.

When you look at a lot of companies that are “successful”, but they’ve let all that stuff fall by the way side. They have their hands completely tied.I think every person has been in a situation like that where you knew that this was going to happen as an engineer. You knew that at some point they were all going to hit the wall because you weren’t thinking about the thing. People don’t pay their money and walk out with a pair of shoes. It’s much more like a service ecology. We all come into work like coming in to work in a restaurant, we all can make the restaurant work better. Sometimes we pull things off the menu, we add to the menu, we figure out how to prep dishes better. For that reason, I think it’s really exciting because I think the engineers on the team and how you architect the product, has as much to do with the long term viability of the company as these other things.

I know we got way off topic there, but I’m thinking about that sense of impact. That all engineers should know that they have the ability to create immense impact in their companies. Even with what are considered more “back end decisions” or architectural decisions.

Dave: I think that’s a lot of what you say with the blog and from the things you’ve said here. Not to the detriment of building the system right, because that does set you up. If you leave that, if you have rocked in the quality of what’s below, then that’s ultimately you’re going to pay a price for that as well. Both of those are things that matter.

John: One thing I actually… I think I started a blog post about it, but then I stepped back from it. I think the dichotomy of build the right thing and build the right thing right, what you see in organizations is you see that create silos in the organization. You see it basically, the CTOs saying, “Well, you got to figure out what the right thing is and then I’ll be able to build it right.”

Product is saying like, “Well, we might need to build to figure out what that right thing is.” Sometimes you need to build it right for right now and so what you see in organizations, instead of focusing on resiliency and the ability to change course. Instead we get obsessed with building “an extensible platform that blanket-y, blanket-y, blanket-y, blanket-y, blank, blank, blank”

Instead we get obsessed with building “an extensible platform that blanket-y, blanket-y, blanket-y, blanket-y, blank, blank, blank”That’s kind of true on a level, but there’s a platform myth. The point instead of feeling like you’ve got to get everything right, right now or you’re never going to come back and change it. I ask product managers, “When was the last time you pulled a feature?” If I ask that to 100 PMs at a conference, only three will raise their hand. Engineers are being perfectly rational to assume that none of their architectural decisions have any kind of tweak-ability to it. Because they understand that they don’t get the time to go back and fix it. We’re caught in this terrible cycle. Now, if we could just say, “No, we’re always going to refactor this, we’re always going to think about the current state of the system and if you need time to do that, we’ll let you do that.” It changes the game completely.

I ask product managers, “When was the last time you pulled a feature?” If I ask that to 100 PMs at a conference, only three will raise their hand.You don’t create divisions around doing build it right, build a right thing. You work together as partners in that. If that makes any sense.

Dave: I totally like that vision and I think it’s a shame that more organizations aren’t like that. How can the engineer out there who feels like they are turning out features. How can they go about trying to move their organization towards something a little more like that?

John: There’s this great book called ‘The Phoenix Project’, that I would recommend that anyone reads. It’s really, really good and if you haven’t read it, it follows this fictional IT team’s effort in their organization. At a certain point, they were very stuck in reactive work and all the things that we see. For example, invisible work.

Any engineer understands this idea of invisible work. Where if you actually told everyone about the work you were doing, they would say don’t do it or why are you doing it? So you take on the invisible work and it sits back there. You have to create the trust that you can talk about what you’re actually working on. The turnaround in the Phoenix Project is about someone from the IT organization going straight to the CFO of the company and understanding how that company prints money.

So you take on the invisible work.Then, it talks about how instead of thinking about engineering as a resource that you think about, they thought about it as a way to create money or save money. Or add learnings in that thing. This is where the product thinking for engineers is critical. If you spend a month on something it costs 10 X that amount to maintain the complexity you’ve added. The cost of engineers working for two months is not the cost. It’s in the complexity you’ve added to the thing that you’ve built. What I would say to an engineer caught in this situation is, it’s tough to do from the bottom up but it’s to try to change the mindset from your manager or their manager from one of
“our job is to be responsive to the business” and instead to think about, our job is to partner with the business.

The cost of engineers working for two months is not the cost. It’s in the complexity you’ve added to the thing that you’ve built.I’ve known engineers who in five hour hack days saved the company a couple million dollars. That is awesome. You don’t notice, especially teams that don’t have a product manager or maybe have a more technical product manager, you don’t have that team put that up on the banner for the company.

Is it saving money, making money or adding learning which is valuable? Then thinking about that instead of thinking about how many things are in our backlog and just checking them off the list or something. I don’t know. A little bit of product thinking can go a long way for an engineer and a little bit of engineering thinking can go an incredibly long way for any product manager.

Dave: I like that, totally. You mentioned that term empathy and it goes both ways. I guess it’s something really important that we can learn something from each other, but that idea of shifting from, I have something that you have directed me to do, to, I’m an autonomous creature who can make suggestions for how we can turn this thing in the right direction. That’s a pretty powerful shift there.

John: Just start with the leadership of the engineering organization too. Because one thing I’ve noticed is usually a company will be going great and then will go through a tough time. The engineering leadership gets put on the spot about execution. We just need to execute. If the engineering leadership thinks they’re primary responsibility is to just execute. If you tell us exactly what to build, we can build it when you need to build it by at this particular point.

The reality is you get rewarded for it. All the incentives fall into being a great order taker instead of creating business outcomes.

The reality is you get rewarded for it. All the incentives fall into being a great order taker instead of creating business outcomes.I think that that’s a … It’s a really complex discussion, but if you can think about the whole system, you begin to see little chinks in the armor. Recently actually I went to an executive and I said something like, “If we could give you all this right now, how much money would you pull out of your pocket to solve this, to just get the solution to this?” Then they were like, “Oh no, no how much is it going to cost?” I’m like, “No, that’s not what I’m asking you about.” “Well, are you saying compared to what I think another team could do?” I’m like, “No. What is the value if you could get this problem solved right now? You wake up tomorrow morning and this problem is solved.”

What was fascinating is that was an incredibly scary question for some of the executives but not for other executives. Some other executive was like, “$25,000,000 if you could solve it right now. I would buy that for $25,000,000.” Think of how different that conversation is from an engineering organization that said, “How many weeks will that take you? How many weeks will that take you? How many weeks will that take you?”

That’s a completely different … That’s not a value based decision. Someone else is trying to decide that. This obsession with estimates. I think that estimates can be important as partnership and as discussion about value, but if all of it is a client server relationship with the team and what’s going on, I think things begin to breakdown. That’s the other trick, think about value, think about dollars, think about solutions like that and then that doesn’t get into the how.

I think that estimates can be important as partnership and as discussion about valueIt’s getting into the what. It’s getting into the why and the who is going to get the value. Again, basic product thinking can go a long way.

Dave: That’s great. I like that view of it’s important to know what it is the … What is the outcome that you are trying to achieve? And without that it’s just going through motions. You said, order taker. That you become just an order taker. I think that also, I’ve talked to a lot of software developers about that in a role as a software developer, there is a ceiling on what you can earn. I think a lot of it is related to what you’re talking about there. That if you get into this mode of being an order taker, then you’re labor. You’re really not a valued part of the organization. You’re somebody who turns hours into features.

John: Actually, it’s way more structural than anyone wants to admit. If you think about a company as operating expenses, and then they have capital expenses, and they’re buying assets and they’re doing different things. For a software as a service company, there’s rules that relate to what you can book as a capex expense or an opex expense. It’s like 42 person weeks is some investment we’re making in our technology that’s innovative or something like that. The other operating expenses, you actually go into separate … When you report to your investors or do whatever, that goes in a different spot. From that super high level, especially with the systems we’re creating there these days which are much more iterative, if you take a step back you think it’s actually easier for your company to go and buy another company in some ways. Because of where it’s going to book that cost.

I think that this is getting super deep with it, but engineers too, to break out of that type of thinking. Again we have to think about what is that problem they’re solving and thinking about that they’re enhancing the … That by innovating they’re enhancing the value delivery capacity of their company and then trying to advocate for the right line item that your bosses are booking what you’re doing.

The funny thing about that is that when engineers are asked to track time on something, almost all the time in a larger organization the time tracking is going about allocating those costs. When we resist that, because it’s like who’d want to track their time, it actually has the perverse end product of not being able to put that time towards the innovative activities and getting booked as an operating expense. There’s all these games.

Figure out how companies work, figure out how their accounting works and then to your point I think that promulgates that order taker thing. It’s super big, it’s bigger than all of us.

Dave: How did you realize that this was something … I can just see your whole expression light up, that this is really … It’s just, you’re on fire about these stuff. How did you get to this point?

John: I just really love the idea of people making things and getting together and doing it. If you saw me you light up about talking about these systemic issues, I love stuff like that. I love it for a perverse reason. Because so many of these things we get down in the weeds about in our company. I think especially with engineers. You show up at a retrospective every week, and everyone’s talking about what’s working and what’s not working. There’s so much burden on us to continuously improve on a team level. What I love about what we were just talking about is that, there are bigger forces at play here in the software industry and how we make things, and what are some left over things from other by gone eras for how we build software.

You show up at a retrospective every week, and everyone’s talking about what’s working and what’s not working. There’s so much burden on us to continuously improve on a team level. What I love about what we were just talking about is that, there are bigger forces at play here in the software industry and how we make things, and what are some left over things from other by gone eras for how we build software.I’m excited by the possibilities that I think we have the chance to elevate the makers and nerds and stuff. That’s what I get really excited about. It’s less that I’m excited that it’s kind of messed up, but I’m more excited by the possibilities that we could create if we understood how these economics were working.

I’m excited by the possibilities that I think we have the chance to elevate the makers and nerds and stuff.Dave: A lot of opportunity. I just pictured you’re climbing up this hill and working really hard to do that, only to realize it’s the wrong hill. That there’s another hill you could be going up. That makes a lot of sense. In your experience I think, we can learn a lot about the times that things went well, but there’s probably even more during those down times. Could you just share a story? Tell us about a time that you failed, fell flat on your face or things just fell apart.

John: Going way back in my early 20s making a game, we developed all kinds of adversary relationships with our publisher and all kinds of … Maybe I won’t go back that far, because it’s just all the classic things, but you’re just very … I think that the lesson there that I learnt is that when it’s your thing, you will never see things clearly when it is completely your thing. When it’s your thing, when you’re on the ground floor of something, the ability to stay unbiased and nurturing for that open source community versus who plays the evangelist role, who plays the facilitator role and those things, it plays a big part.

you will never see things clearly when it is completely your thingWhen it’s your thing, you’ve got blinders on and you almost have to realize that. You almost have to do that. Those are those older stories. I’ve been at startups that raised a ton of money and based on market research, like the marketing did a quick focus group and their company raised $50,000,000 bucks and then fell completely flat on its face.

There are some lessons there about you’ve got to get your … Two lessons really. You’ve got to get it out there. The measure of success is someone taking money out of their pocket and handing it to you for what you’re working on, and that it fills a role. You can fool yourself on your projects or your efforts that it has traction, but you’ll know it when you see it. If you find yourself saying, “ Well, I wonder if, I wonder if, I wonder if, “all the times I’ve been in where it’s just working, you could just say it’s just working.

I’ve had startups that have failed too, falling in love with writing, my 30 day challenge thing instead of … I just got so deep. I fell in love with the machine which is okay, but I wasn’t opening my eyes up for the problem. Because you know why? No one has … Like 1% of the population has the gumption to do something for 30 days. I got so obsessed with doing it for 30 days and building the model that these 30 day calendars and you do these things. At no point was I like, “Wait, let’s make the length of the challenge variable.” I was all in for 30 days. There’s stuff like that. I would say that on a personal level, the mistakes I’ve made often have to do with not … I’d say that a lot of us who fall on the category of who pride ourselves on calling it like it is, and I know a lot of engineers fall in this role too.

It just that we feel that it’s our mission to just tell it as it is. There is a right and there is a wrong and this is what it is. This is the situation and this is how it works. Is I feel a kinship with a lot of the engineers, and I know because we think the same way about that thing. I’ve made mistakes where I definitely wasn’t empathetic to the other people in the business that that is not how they think sometimes. I’ve put myself out there in ways that backfired.

I would say that for a lot of engineers …. I have a couple of engineering friends who’ve also fallen for that. They could have waited a week or two to really form this thought together, but it was much more about, you’re wrong, I’m right, this is how it’s supposed to be. Everything’s messed up, we’re not doing it the right way. I think that that is, for some of us, that’s just how we think and I think bringing in a little bit of the skills of reflection, to say, “What is the 1% of truth missing?” Or, “The 10% truth missing.”

Also, I think a lot of engineers and myself too, we think in terms of systems too. One trick for engineers that’s been helpful for me is to … If you imagine the system around you is being highly political, unnavigable, overly emotional, not logical, a good way is to get your head in the systems thinking and thinking about distributed systems and thinking about complex systems. Thinking about that, because you can actually help yourself. You can step back and say, “No, this is not a room filled with people, just who aren’t cutting it in the logic department.” There is a reason why this system exists like it does, and see it more as a refactoring problem instead of a replacement problem. You’re going to have to strangle the code sometimes.

You’re going to have to do cuts through the code. You need to integrate the thing. If your idea is not seeming to take hold, it hasn’t integrated. The test did not pass on what you’re trying to say. I’m just thinking that it can be comforting to think that you can address the problems around you in your natural zone, but not have to quote unquote play the game or be highly political.

Dave: Multiple processes running in this space with communications protocols between them that sometimes break down, yeah all those [crosstalk 00:40:14]. That’s cool. Tests against the system. You mentioned being asked the provocative question about test driven product management. I think you said, that there’s this realm of right and wrong in the engineering, but that’s not necessarily always the case. There is a lot of trying to figure out what this thing does and m I asking the right questions, and a lot of back and forth and is the test wrong? Or is the code that’s failing wrong and all of those kinds of things. Could you flesh about a little bit more? What are some of those commonalities? How can you do a little more of an approach of starting with the end in mind, which is I guess to me really the gist of test driven development.

John: Yeah, totally. I think it can be … I have a very specific example that we do an exercise with teams sometimes, where we look at the data we have right now. A lot of teams get a little pissed off if you do something and then you just get shifted to some other project. What I would do with teams is to say, “Look, five months from now we’re going to present back to the organization, engineers as well as product people. We’re going to make a commitment to do that. We’re going to do tech talk, we’re going to do something about some work we did. What we’re going to do right now is we’re going to write the presentation right now. We’re not going to do it five months from now. We’re going to write the presentation right now, and we’re going to put the data we have now in the slide presentation and we’re going to leave the other charts empty. Or we’re just going to draw squiggle lines on them at the moment.”

A lot of teams get a little pissed off if you do something and then you just get shifted to some other project.We’re going to get together and we’re going to do that as a team. Because we’re all going to be on stage when we do it. So we all have to have pride in what we show and we all have to think it passes master for the engineers, and for the business people who are in the audience. So it’s setting a pretty high bar. Before we even get started, we do that activity. In a way, it’s exactly like creating a test. It is exactly like … But it’s not exactly like it, it’s sort of you’re setting yourselves by, I think that what you see there is that agreeing to talk about it later, is like agreeing that that test will run every time you work on it. You put a stake in the ground that you will reflect on whether the test does. Then you can also look at it periodically during those five months.

If you have a … The thing that’s great about that is that is, even that team was a temporary team and got shifted off to another effort in that company, you still come back together as a team, and everyone wanted to know. Everyone wanted to know whether it would work. I think that that can be … I’m just giving an example to demonstrate the point, but I think that that’s an example of how it can work. Put some emotion into it and start with the end point that you’re willing to expose yourself to for the organization. Then work and agree to come back to it later.

Dave: That’s brilliant. I like it a lot. I like the idea of here’s the presentation and does it match reality. If not, why? Is reality better than this vision that we had before, and then … There’s lots of sources of feedback there. You’re figuring out whether you’ve hit the target and all of those things and what are the next steps. I think there’s a lot of meat in that. How do you stay current of what you need to know?

John: Oh, men. That in itself … I just try to time box it. I have on my calendar every week time to try to reflect on the new stuff and read the stuff. I think that time management is incredibly difficult for product folks in a way that’s different than … Engineers are battling for their time in a different way. Keep us out of meetings. Keep us on this thing. For product, it is about getting shuffled between meetings all the time. Actually career development for product people is really challenging. I wanted to talk about that briefly. Because I think it’s something that engineer’s experience. I’ve been to conferences with engineers, or coaches or scrum masters or whatever and it’s always the product person’s fault.

It’s always, they’re not this genius, they’re not this fortune teller, they’re not a super hero. And why can’t they tell us exactly what we need to build, we feel like we’re … Actually and maybe that’d be even be good for some situations. Sometimes you’re not even being told in that highly prescriptive way what to build.

I think the challenge at the end of the day is that you really might have unskilled product people on your team. They might have come from a project environment and so I would say that trying to keep up with this is like a lifelong thing, and you have to make time for it. Because otherwise … And you have to spend time on your teams, because if you get pulled into a lot of low leverage tasks as … If you’re all your acting as is, oh I went to the other end of the building and they said we needed this, and so we got this and then here is this thing.

If all you’re doing is you’re just like a … You’re just a part of the communication network, that’s just a relay. If all you are is just a relay in the organization, then you’re not adding value to that information that gets passed through if you’re not amplifying it, or filtering it, or doing whatever, you’re not adding value. The reason why it’s coming back to learning is that, trying to figure out how to manage your time as a PM is the critical thing to unlock staying current. Because the reason why people don’t stay current is that they claim they just have no time at all.

It’s interesting that there’s a direct path to being an engineer. Computer science grads or other paths. There are people who have been trained in this and it’s obvious that they’re coming here, and product is much more of, we’re pulling people in from different parts of the business and it’s not really as much that you’ve got a formal background in it. That’s really interesting.

I think that this is one thing that I tell teams to do too is, there’s great exercises that you can do. One is just called the hats exercise. You just decide what hats you need and you give them funny names and you just understand that on a team sometimes, you’ll be wearing different hats. It doesn’t mean that that person needs to be wearing that hat all the time. You always need a devil’s advocate. You always need someone who’s the unbiased facilitator. You always need these things and I think that that’s an important thing that product people can do to help define the role that they’re doing. Because I don’t think that engineers understand how many hats we’re juggling sometimes.

And just facilitate. Facilitate that product management just like product development is a team game and everybody helps out. That’s great. I want to wrap up by asking you my final question, to provide three tips for delivering more value. They don’t have to be programming or product management related but it certainly can be. Three things you do and recommend to really make sure you deliver.

Figure out a way in your organization to pick up a phone and call a customer directly right to the team. Even if it seems like not so fun thing to do, and for a lot of people it’s fun. Get them on the phone, get working software in front of them, get feedback directly from the source about the people who are using what you’re using and don’t just ask them what they want. Really try to … If you can bring that voice to the team, it’s a game changer for people. Even if initially they say, “Well, is that really our responsibility or whatever.” When you do it, you see people’s eyes light up. I would say that that would be one very important thing. I think the second thing I alluded to earlier is just stop, think about a world where you’re not the order taker, where you’re the value maker and apply that to what you’re working on.

Ask questions that relate to that. Because I think that if you can take that leap as a team, it just maps literally to your question. The main shift there is that you have to think about economics, you have to think about how the business makes money or saves money, and one thing I’ve noticed about that is that I’ve never seen an organization that when a team actually gets up there and reflects on their work from an economics standpoint. The problem is usually middle management layer. If you can get a situation where you get the upper, like a C level or VP level person who sees, here are the engineers talking about the money they saved or the value that they created, and here’s the data, oh my God the VP loves that.

It’s the people in between those that tend to want to run their little territory. The reason why I say that in terms of creating value is the more you can do that, the more autonomy you’ll get to create value. Because people will be much more psyched about it. Those are the dollars and cents and visibility thing. Then I think the final thing would be, resist premature optimization in terms of process on your team. Every process you have is like a hypothesis about how you’re going to work. It’s like any systems design. If you over optimize around one factor dimension initially, it means that by nature you don’t have flexibility. For example, things that are fun sometimes, like pairing or mob programming or taking the day off to go and visit a customer, feel wrong at the time.

They feel like a waste of time, but you think about your teams as building resiliency on your team. The reason I say that is to create lasting value and to get out of the order taker mindset, you need to have resiliency as your team. If you’re fly by night, these are like distributed systems. It’s the exact same thing we’re talking about. If you need the human load balance or A.K.A project manager to function as a team, it will always be a limiting factor on the success of your team. If you can figure out the minimal amount of process necessary to solve the problem you need right now, and resist that temptation, you can go a lot further towards creating value. Otherwise you’re just going to play the part of the order taker. Those are the three I’d leave you with.

Dave: When parts of your distributed system are susceptible to flu, then you’ve got a chaos monkey that’s out there and knocking [crosstalk 00:50:41] all the time. That’s a great way to look at that. Thank you for those. Before we go, how can our listeners follow you and keep up with what’s going on in your world?

John: Back to that time management thing, all I can have bandwidth for is Twitter. If you want to reach over on twitter, it’s @johncutlefish. It’s probably good, even LinkedIn, I can’t stand that thing. It’s twitter or you can email me. It’s my name, my middle initial is P at the place that starts with G, and then just email me there and we can chat.

Dave: All right, great. I’m sure that twitter links up the medium blog, so they can go check out all that stuff too. Thank you John for your presence today. It’s been really great connecting.

John: Cool. Yeah, I had an awesome time.

Dave” You’ve just heard the amazing and inspiring story of top notch geek. Thank you for listening. Go and find these show notes on developeronfire.com. Support this show on developeronfire.com/support. Join the team and engage at facebook.com/groups/developeronfire.