Providing Value to Your Organization and Your Customer

See more at https://juniortosenior.io/57.

David's notes:

• Providing customer value is providing value to your organization.

• The job listings for engineers are endless-- don't settle for a company you don't like with a product you don't believe in.

• My father used to say, "Be in places where luck can happen to you."

• There are a few metrics that tell if you are providing value.

---

Transcript:

David Guttman:

Welcome to Junior to Senior the podcast for ambitious devs who want to take their career to the next level. I'm your host, David Guttman. Today, I'm joined by David Subar. David, welcome to the show.

David Subar:

Thanks! Very excited to be here.

David Guttman:

All right. So for folks who are just meeting you for the first time, can you share a little bit about who you are and what you do?

David Subar:

Sure. I run a company called Interna. Interna focuses on product management and engineering, and how to make them more effective. So, we spend time thinking about how do you build fast, ship fast, get feedback from the market, and then do it again and again. How do you get product- market fit faster? How do you align engineering and product management?

But I started my career-- I think this might be interesting to your artists. I started my career doing research and development in AI and machine learning in a miitary-owned think tank. And that was interesting but not for the reasons you might think.

What I learned doing research and development was a good project is writing a paper, maybe presenting it at a conference, and then nothing happens. And so that was very frustrating for me. And even though we were working on things that were cool about getting signals intelligence from the bad guys, and trying to figure out what they were trying to do. The problem set was interesting, but we weren't really having an impact. So I switched my career to being a developer at an AI tools firm, first being an engineer, then managing teams and managing larger teams, and eventually being CTO, and then eventually Chief Product Officer of companies. What you talk about in this podcast was a transition I took in my career, but then I got very meta about just how do I build software that people use-- a practical use-- but how do I build teams that build products that people use. And so that's, that's my career and that's what Interna is about, is helping companies do that. And I spent a lot of time thinking about that.

Specifically at Interna, we do four different things and doing these things, we see patterns across companies-- what works and what doesn't work. And the four things are, is we'll go evaluate a product management and engineering team and come back to the company and say, "here's some stuff you're doing. That's really good. You should keep doing that. Here's some stuff you might do differently or should do differently, and here's how." That's the first thing. So we see inside product management teams and in engineering teams things that work and things that don't work.

The second thing we do is, we will mentor and coach engineering and product executives and help them get to the next level. Having been CTOs, Chief Product Officers, other Engineering and Product executives, we've ,seen those patterns. We'll coach that's the second thing.

The third thing is, if a company doesn't have someone to take those teams to the next level, we'll jump in on an interim basis and run product management or engineering or both. Help fix them, help hire someone permanent to run the teams after us. And the last thing we do is we do due diligence for investors and through all those things, we see a bunch of patterns that are interesting to help product management and engineering built fast and ship products quicker.

David Guttman:

Yeah, I love that and I'm sure that there are many engineers listening to the show that I think have some degree of frustration of where they feel like they're working on things that don't matter or not getting used. What was it about what you were doing at the think tank that there weren't any results? I mean, it sounds like what you were doing was very useful and applicable. What was the obstacle there?

David Subar:

The obstacle is what we were doing is advancing science and not doing engineering. Now, Science is clearly a good thing. We need science to do engineering, but we were doing science experiments that someone might take and use in a real project someday or.

And we would never know if they did or didn't. Once again, the world needs scientists. It turns out like Newton was really important, you know, Einstein leading it. So these are all really important people but there are lots and lots of scientists that go in the background and no one ever hears from them, or maybe even takes the results.

I'm not Newton. Right? But I did want to build something that had an impact.

David Guttman:

So it sounds like you definitely moved in that direction. Do you feel like that's the same trajectory moving from engineering and being a CTO to, uh, focusing more on product?

David Subar:

Yes, that's exactly right. And the fundamental thing here: how do I create value? How does my product create value? How does my company create value for the people we serve? And if you understand that, then you can go and say, oh, if I do X and Y and Z, I'm helping advance our mission and someone is getting value out of this. And therefore my role has importance.

Now this is not meant to be about me, but if you want to function well in your ecosystem, you need to provide value in your ecosystem. By the way, it's not just you as a developer who needs to do that, your manager needs to do that. The CTO needs to do that. The whole company needs to do that. If you're not providing value in your ecosystem, then someone will say, "Interacting with this person is not a good use of time or money. Let's try to figure out a way not to do that."

If you're providing value, the opposite effect happens and they say, "Oh, I'm glad to be working with this person. This person is helping push us farther along in what we're trying to get done. How do I engage with this person more?"

David Guttman:

Right. Yeah, totally. I mean, I think this is, this is something that comes up a lot on the show, which is, why? Why should any engineer make software? You know? I think many of the guests on this show have cautioned that, that if you make software in a vacuum and like, it's not making anybody's lives better, it's not providing value. It's not saving anybody time. It's not helping them make more money or do something, you know, get more time doing something they enjoy... you gotta be careful just cause that's ultimately not going to be very rewarding and almost goes against the purpose of creating that software.

Now, I guess one of the things that you mentioned that, that I feel like I kind of lit up at is you spend a lot of time working almost like the space between-- or I guess the space around-- product teams and engineering teams. And in my experience that can often be a very fraught relationship. I don't know if that's your experience, but I've heard in a lot of companies and some I've even been at, the relationship between product and engineering is a little bit contentious. Is that something that you've experienced?

David Subar:

Yes, it can be contentious and it's bad if it is. Now, there's some people who have the idea of like, I want tension between product management and engineering. I want them to fight a little because you know, then we get the most efficiency. I argue that's completely the wrong reasoning.

Product management engineering should see themselves as one team that builds product. And so to like one step further in that, if an engineer thinks only to write code, tell me what you want to write the code, and then I'll give it to you. And it's on you. You have a product manager or product owner thinks your job is to write user stories and it's on the engineers how to get it done... That is only a component of your job. That's not their job. That's necessary, but that is not sufficient. The job is to build and ship a product that serves somebody. And so, it's a cancer for product managers to say, "We would release this, but engineering was too slow;" or engineering to say "We built what they asked, but if it's a wrong thing, it's on product."

Both teams have failed if that happens. And so it's about, how do we work together to build and ship something. Now, I have a lot to say about the Spotify model. I interviewed one of the executives at Spotify about the Spotify model. And you shouldn't overlearn the Spotify model about squads and how they organize because they did that for a particular purpose that they were trying to solve.

Glad to talk about that, but maybe not right now, but the key takeaway that I think is useful there is that product managers and engineers were on the same squad and they succeeded together or failed together. And that bonding, that recognizing that we do the thing thing, is really important.

And I would argue it's not just product manager and engineering that bonds together. There's some companies that say, "Oh, I'm an engineering. I serve marketing, or I serve sales." The answer to that is no, you don't, you and marketing and sales are on the same team that serves some customer. And so that's, that's the way to think about the problem that is most successful, that bonds product management and engineering, and tends to get the right results.

Because then you say "We release this product. Let's retro it. Let's not just retro this sprint, right? People do that. People know to retro this sprint. A lot of people do it well, some don't, but a lot of people will do it well. But you also need to-- if you believe that my job as an engineer with the product managers is to build and ship something that creates value-- after you release it, you should ask, "Did we, or did we not create value?"

And before you actually start it, you should have a thesis about "We're going to build this because we believe we're going to create value in this way." And then once again, you do the release. You test whether you did that or not. And then you update the whole product management process.

And that focus on staring at the same thing of the distance, not gazing into each other's eyes, but going the distance together, gets alignment between product management and engineering, and then gets to this thing that is the heart of this podcast is: as an engineer, how do I go from junior to senior? How do I get people to want to pull me up into the organization? If you're aligned with your managers and the directors on what they're doing to create value for the customers and you're aligned with that, then you'll tend to produce value for them. If you're not, then you'll fall out of alignment.

David Guttman:

Let's see, what's interesting about what you've said about the thesis and evaluating whether or not you created value... You started to sound a lot more like a scientist there with a hypothesis and experiment, and then evaluating the results.

David Subar:

It's funny you said that, I'd never thought of it that way. I think it very much is as agile, but you're, you're absolutely right. That feels very scientific.

David Guttman:

Yeah. The thing that you mentioned about aligning based on serving the customer or the client or the end user I think is, is really important. I think it deserves a special call-out, right? I mean, I think one metaphor that jumped into my mind is that if you're driving on a highway and, you know, if you've got two cars in front of you, you can certainly react with your gas and your brakes to the car directly in front of you. But you could also react to the car, the one in front of the one in front of you. And if you do that, you're also likely to respond the same way. And in some cases you'd react even quicker. You're not waiting necessarily for that, for the information to propagate, uh, you know, from the brake lights. You know, to the car in front of you, to their brake lights, to you, you can react a little bit more quickly.

You can see two cars ahead, brake lights going on. You can, you can even start braking before the car directly in front of you reacts. If the engineering team, you know, doesn't necessarily wait, nor do they really cede ownership of that, you know, the full relationship to product, they can respond a lot more quickly. They can respond a lot better and ultimately make those customers happier and provide them more value. It sounds like you think that that is really just part of the job.

What are some signs that, like, how can an engineer look at this and be like, oh, you know, I'm not doing these things and therefore I should, I should pay attention to this.

Or maybe like, "Oh, I guess that is what I'm doing. And you know, I should keep doing it." Like how should an engineer think about this?

David Subar:

First of all, I would start: do you know who you serve and do you care about them? And I'm going to give you a counter example first. Some number of years ago before I started Interna, I was offered a job to run engineering at a company that did fantasy sports. And the company had, I forgot what it was... a hundred million dollars investment.

The CEO was really charismatic. He was really smart, I just really liked him. Back when people went to office and the offices were beautiful. I liked the other executives and the CEO offered me the job.

David Guttman:

So obviously you took it because everything was perfect.

David Subar:

Except for one thing, I don't care about sports. I like soccer. I like Ohio State football. After that, I don't care. And there's a lot of sports that people commonly know about that I don't even know the rules of. And so I went to the CEO, his name was Richard, and I said, thank you very much for your offer. I could do a very good job here, but I could never do a great job. I can't take your job. I'm really sad about it. Cause I really want to work for you and I really want to work here, but you'd be better served by someone else who's passionate about sports. Because fundamentally, I don't care. And so, I will never be great and I can't do the job. So, if you don't fundamentally care about who you serve, if that doesn't get you excited in some way, you should consider about whether that's the job you want. And by the way, money is fungible, right? You can go to another-- you're an engineer, getting another job is super easy. And money-- you know, one person's dollar bill. Look just like someone else's.

David Guttman:

They're both US dollars that you can pay your taxes with.

David Subar:

Both US dollars. Uh, except for the one with Franklin, they all got presidents on them. They're green.

So find out, do you care about the market? Are you invested in it and then do the product managers tell you the why, why are we doing this? User stories, like if you're going to do scrum, user stories are written in a way that gives you a tidbit of why. Right? But your epic should have the why, the things on the roadmap should have the why, what your goal is should have the why.

And you should understand it as an engineer. There's three ways to do anything. And if you don't have the context, you're not likely to consistently pick the right. Okay. And so first thing to ask yourself is, do you know the why, do you care?

I was consulting recently to a company in Boston called Reify Health, and they do their SaaS service for making clinical trials of drugs faster. It turns out that getting drugs to market. The thing that slows it down more than anything like by significant margin is actually getting patients to take what might be a drug. And it's not a hard process, except that it's all in spreadsheets. And so this company was automating that process and working with Eli Lilly and marketing companies like that.

And when I got there, I think there was 12 engineers and a couple of product managers, maybe a designer. But we, we had a big mission in front of us and we had to grow some. I was running the team on an interim basis, product management and engineering. And the thing that I had to sell was not the salaries-- they were probably below market salaries at that point-- but we're doing something that's super important. And then COVID happened, and then it became even more obvious to people. Okay. The company yesterday just closed a $220 million round because they were able to create value in the marketplace that's obvious to anyone, even if you don't know about drug discovery. And I-- running the department, which we eventually grew to about 70 engineers when I was there a couple of months ago, I think 13 and product management, similar size and design and data.

I was able to sell to the engineers that were doing something important. And then you have to walk the walk, right? You can't just say we do something important. You actually have to do it. And so we were aligned with how do we serve patients? How do we serve clinicians? How do we serve drug companies? And everything we put on the roadmap looked like that. Having squads that were aligned to different segments of those groups, where people understood that.

And I wanted the engineers to say to product managers, "I understand what you're asking me. We could do that. That's gonna take a long time. Instead, we could do this other thing here, which I'll give you 80% of what you do in 20% of the time, and to engage in that conversation." I also want engineers to say to product managers, "Hey, we have this opportunity to do this thing over here. Why don't we consider that?"

Likewise, I want product managers to say to engineers, "Help me understand that architecture. Why are we building things that way?" At the end, the product decisions belong to the product manager, but I want the engineers engaged. The architecture decisions belong to engineering, but I want product management to engage in it because those are some of the components that you need to build a great product.

David Guttman:

Yeah. I think that's super important. One of the things that I've thought a lot about, and you touched on it is, it sounds like some organizations, some companies have a big advantage based on what they're doing. And this is something that I've noticed.

I run engineering for a number of companies. They're building something that is, that is so much more tangible, right? They are working in education. They want to eliminate student debt. They want to provide incredibly high quality courses. And I feel like that's a really easy thing for an engineer to understand, to empathize with, to get excited about.

When working with other companies that are doing something that might just be more like arbitrage, right? Think hedge fund crossed with internet ads. It can be a lot harder to recruit or get an engineer interested about like why they're building what they're building.

And I think even within a company too, if you're working on something that's touching an end user that you empathize with. That can also be very different than if you're building internal reports that the customer is just the COO and their team or something. And it's all financial spreadsheet-type stuff.

Is this something that has an answer or some kind of way or is it just you just find engineers that are interested in that? Or if like, you are this engineer, do you just move, kind of like what you did? Like, "Oh, you know what, I don't want to make reports. I don't care about CEOs and their teams. I wanna do this for artists or something."

David Subar:

Yeah. So the answer is basically everything you said. Some of it is, you know, different horses for different courses. Like I had this offer job at Bridgewater Capital, which is the world's largest hedge fund. This is another job I didn't take.

David Guttman:

I always think of Bridgewater is like the opposite of Zappos. Like they're just like on opposite sides of them.

David Subar:

A hundred percent. That's exactly right. And my job was going to be doing exactly what you said, was producing reports for the COO. The interesting thing about Bridgewater, it's a really interesting place. Like they think about macroeconomics and how they work and how investments should happen over macroeconomics, over tens or hundreds of years. And what does that mean? Oh, when the Portuguese empire rose and then fell, what happened to economics? How should we best in the United States based on that, how do we look at --

Really, really interesting stuff. And I would have loved to have been involved with that cause like that pickles something in my brain. But my job, would have nothing to do with that. And so I said no. I might've made a lot of money there, right there.

David Guttman:

They're good at making money.

David Subar:

But really, they're really good at that. I wasn't going to be in that part that was interesting to me. Right. So I took other jobs and I did other things and eventually I did Interna. So, but there, but there are some people who like to do those things and so, you know, good for them and they should take those jobs. And there's no, you know, there's no negative for them, but if you're not that person, don't take that job. Just don't, you're not going to be great. You'll be unhappy.

Once again, the opportunity to get jobs is high, and it turns out engineers are generally paid a lot of money. So one of the pieces of advice I give to people is, you're much better off at being a profit center than at a cost center. It's much better to be the CTO than the CIO in general. I don't want to overgeneralize, but in general, because if you're the CTO or the Chief Product Officer in a technology company, you're probably building the thing that generates revenue.

If you're the CIO-- I have a friend who is COO of a major grocery chain, and he's talking to me about the CIO position. And he said, you would never take that job, would you? And I said, Nope! Because you would only talk to me when the cash registers didn't work. It's like electricity. You will only notice me when the lights go out. Other than that, you'll say "Next year, do more with less."

There's some people who like that, right? And there's some people who want that kind of job and want that kind of role. One of my friends plays bass guitar for a band that is kind of well-known. And he never wants to be the lead singer. He always wants to play bass guitar. Good for him. Not that I want to be lead singer, but I want to have a role.

Like once again, I want to know how I'm affecting some market and somebody. And so those are the kinds of roles that I've put myself in. And by creating value, that's how I got pulled up.

David Guttman:

Yeah. So junior to senior, we have a companion private community. One of the things that we do is we talk about questions come up.

One of the ones that we were discussing recently is, you know, for engineers, like what are you working on? Are you working on something customer facing, or are you working on something internal? Is this what you want to do? Why, why not? And, um, I think this really relates to it because I think oftentimes when you are working on those internal things, you're not necessarily part of that value creation to the customer. You're not serving your customers, your clients, your users directly. It's one of those things where you may not be changing your company's position. You may not be pushing your company farther along in terms of position, but you might be increasing the velocity, right?

You're going to be helping the rest of your team move faster. In my past, I've definitely would take on jobs that I had a high visibility to the executives and the CTO. I feel like that worked really well for my career. But on the other hand, I can also see that it would make a lot more sense in some ways for an engineer to mostly just be involved on features and projects that, that are going to lead to more money directly. Do you have an opinion on this?

David Subar:

I think both are fine, and maybe you switch off from one to the other. I think what opportunities present themselves to you and what do you think you're gonna be good at? What do you think you're gonna be excited about doing? Doing things of high visibility or good-- things that create a lot of value, tend to become high visibility.

And so I think, I think both are good. And by the way, I just want to go back to the Bridgewater thing. If I had an opportunity to do right report to Ray Dalio, the CEO of Bridgewater and then interact with him and learn things from him... even though my job wasn't that important, that would be interesting to me. I would learn a lot. And that would be, that would have been a great job except for working for him might be difficult.

David Guttman:

Either a good time or a good story. Right?

David Subar:

Exactly. That's right. But that was what, even though I wasn't pushing the product ahead, just being in a room and learning things that there's a bunch of ways to do interesting jobs, to have interesting careers without being the person on the front of the product.

My father used to have an expression: "You need to be where luck can happen to you." You know, besides learning, working directly for Ray Dalio-- not that I was offered that I just to be clear-- yeah, luck could happen to you there, right?

David Guttman:

If your goal was to be struck by lightning, you know that that's rare, right? You would need some elements of luck. There is many, many places where that's not going to happen. You would have to seek it out, and be a little bit intelligent about where you were and when, if that truly was your goal. I don't recommend that that be anybody's goal though.

And on the subject of a Ray Dalio, just real, real quick, I do highly recommend his book, uh, Principles for anybody who hasn't read it.. Well, it will tell you a little bit more about him, Bridgewater, and my Quip about Bridgewater being like the anti-Zappos is that Ray Dalio has very strong opinions, even call them "principles," of how to manage teams, build companies, how to get the most value from people, and it's really interesting. And a lot of that is experimental that he's refined over the years and it's, it's incredibly impressive. But when you read it, it comes across almost like a polar opposite of somebody like Tony Hsieh, who also thinks very deeply about how to get the most out of his teams and build companies and you know his philosophies.

So they both have methods that work, but they are both very different. And I have to imagine a lot more crying goes on in the Bridgewater bathrooms than Zappos. But I don't actually know for sure. So, okay. I wanna know a little bit more about what you think engineers can do to get into the right places, because I think some of our listeners may be right out of a code school. They might be more of like an aspiring developer and they're going to be thinking that they, they really can't be so picky, that if they do get a job working for internet marketers or something who they consider really sleazy, they just have to take the job anyway. Do you think that that is untrue or is it more along the lines of like, look, if that's what gets you, your first job where you can build up experience, go ahead and do that. And then, you know, in a year or two, then you can really think about who you want to serve and how.

David Subar:

I would try to avoid that. If you could, it, it might be the right path to, to take a job that you don't want in the beginning to hone your craft and to get some points on your resume. But I would try to avoid that because A, the demand is very strong. And B, What's going to be the quality of the experience that you have there for honing your craft. So maybe. Maybe that's the right thing to do. Maybe that's the thing you have to do, but I would try to not do it. Um, Ross Perot once talked about the giant sucking sound of jobs going to Mexico during NAFTA.

There's a giant sucking sound for engineers all across the world. It's hard to believe that would be the only choice. If it is, do it! Better to get started than not, better to eat than to starve. But be looking for, what am I going to put into this? What am I going to get out of it? And what am I doing next? Working with sleazy people just like bad things tend to happen. It's, you know, what's the expression, uh, sleep with the dog and wake up with fleas.

David Guttman:

Yeah, that, that makes a lot of sense. Let's say, they they're able to hold out. They're able to find a company that they agree with the mission, right?

They like the world that exists in that future vision. They want to help make it come true. They are interested in the customers, they believe in making those people's lives better or easier. How do they know when they're being effective? Because I assume you don't think that they just leave it up to product to tell them what, how... how can an engineer know that they are they're being effective?

David Subar:

Well, there's two parts: how do they know the product they're building is being effective?. And how do they know they're being effective? Right. I think you asked me the latter. I think we might've covered the former. Right. Which is how the thesis of why you're building something, release it, see if you made the metrics. And if I have a formula for that, which I'm glad to share in a minute.

How do you know you're being effective? Think about what are you building: the quality of what you're building, the velocity of what you're building, and the cost of what you're building. So let me take those backwards.

The cost of what you're building is, how do I minimize costs to prove something. That doesn't mean I'm going to build crap, right? But I want to build the smallest possible thing to see if we are, or are not producing value. I want to build something that I could refactor and build on top of, but did I build the smallest possible thing of high quality?

Am I producing leverage for the other engineers that I work with? So leverage there might be, "Hey, I built a tool for myself. I shared it with other people." " Hey, we paired and I helped bring someone up." "Hey, I had a good idea about architecture that I shared with him. We're a team." This is not a fixed pie where the bigger slice I get means a smaller slice you get. It's, am I helping increase the pie from an engineering standpoint so we're all successful? And by the way, did I learn something? Did I teach something to the people? Did I learn from them? Did I teach them something that makes us all better?

Everyone knows this: don't visualize a code. There's a bunch of things you should not measure. Some of this is subjective, but: is the product, is the team better for me having been here? I'm going to contradict myself in just a minute.

Guy Kawasaki said this thing, "Don't worry be crappy." Right? I think that's true. If the definition of crappy is I'm building the smallest thing to see if we produce value. And the thesis behind that is all product managers are bad at their job. They're bad at their job because it's not a job you can be good at. If good means, " I'm going to tell you exactly what the market wants and we're just going to build it."

So if you overinvest as an engineer in building an infrastructure that's going to serve you for the next two to three years, you're investing in some future truth that may not be true. Because the product managers don't know. So build the small thing, understand it; but the next thing you need to do to be good at your job is to constantly refactor.

Don't ask for permission to refactor. Oh, I'm in this bit of code I was in before now. The requirements have changed. I'm going to refactor this bit of code I'm in to expand it, to meet the old requirements and the new requirements, and I'm going to do that all the time. And that way I build a sustainable code basis, sustainable engineering model.

Now, if I have to refactor a giant thing that's gonna take three months, now, we've got to have a conversation. But a good engineer's refactoring a little bit along the way, all the time.

David Guttman:

Oh man. I agree with that. So, so much. It's funny, I was like driving down the street. I feel like so many auto body shops in LA look the same. And there's so many of them, they're just like in the middle of everything. And you see this like kind of rundown building with a bunch of cars in the parking lot, one, you know, actively being worked on. But so many of those shops are such a mess and I'm like, you don't have to let your code base do that. I'm sure that many engineers just think that. Kind of have no choice. Right? I have to get this feature out. Everyone wants it. People are waiting on me. My, my manager wants it, the project manager wants it. I can't write tests, I can't refactor. I just have to build this thing, and you get it out the doors as soon as possible.

And that's just not really true in most situations, even your engineering manager or your tech lead don't really know how long it's gonna take for you to do the thing and writing that additional test, doing a little bit of extra refactoring, you know, that's only really going to add a few hours, you know, in many cases. Just do it. That's not going to have a huge impact on the delivery, but it is going to have a huge impact on your teammate, especially if you get into the habit of doing it.

There's really good advice just in normal life, which is that anytime you leave a room, bring something with you that doesn't belong there. If something needs to be thrown out, you're leaving the room anyway, just take it and drop it off in the trash can, or, this doesn't belong here at belongs in the kitchen. You're in the kitchen. Oh, this doesn't belong here. It belongs in the office. You know, if you get into the habit of doing those things, that continuous little bit of effort goes a long, long way.

And so I thousand thousand percent agree with what you're saying there. I feel like there's a connection, right? You're talking about product manager. It's very difficult to be a good product manager because being an excellent product manager means that you can almost predict the future to some extent, and I don't think the answer is "Okay, engineers, just be sure that you work with a clairvoyant product manager." I feel like that would be difficult to achieve. It's almost like the bigger the swing, the longer it takes to find out whether or not you are right. The unhappier everyone's going to be.

And that's almost the same way on engineering too. If you are working on a feature and you structure it in such a way that. It's only going to get released and no one else can really see it until you kind of finally put that Keystone in to complete the arch, but it took you a long time to get everything up.

And then you put that in and then finally you can walk across the bridge or whatever-- my metaphor is horrible. But the point being, if you take forever before you can evaluate it, that is way worse than if you build something more incrementally, right? If you're building a bridge, like get the rope across first and then get more ropes across, and then get the wood planks across and then more of the wood framing, and then eventually the stone and everything like that.

Um, trying to, trying to make everybody wait until you get the steel and concrete version out, that can be bad. Cause like what you said, it's a bet. Like you think that this is going to be valuable to people, but you don't know. And if you wait until you've invested a ton in it to find out, you can't really get that time and energy back.

David Subar:

By the way, building the big bridge and leaving it under covers and not letting anyone see it until it's done is a great way to get fired because here's the following things that are going to happen:

First of all, even if you were right on what the bet was when you started, the road's moved. A. B is, it's going to take you longer than you thought. C is the people you're building for don't know what building a bridge is like, and so they're getting nervous the whole way. They may not even have seen this bridge.

And, by the way, there's gonna be bugs in it. We're going to build this great thing. Don't look behind the curtain. It's going to be awesome. It's going to be done in three months. And you're going to love it. It's going to change your world.

And now you built the bridge. It's late; by the way, there's potholes in it and the road's moved. And now it's like, well, that's stuck. I don't want to work with someone who produces the wrong thing late at low quality. And if you could predict exactly what needed to get done... Here's where waterfall's really good, when you could produce-- there's a couple places, but one is, you know exactly what needs to get, how long it's going to take, and you know exactly how to build it. Great, awesome. Use waterfall.

The other time, by the way, to use a waterfall: if the cost of release is really high, like you're firing a rocket. Iteration's' really harder when firing rockets. Waterfall is probably the right thing to do. Actually, there's one other situation. I did some hardware development and augmented reality once, like that's the mix of hardware and waterfall. Other situations, do something in agile.

There may be some other case I missed, but like that situation of building the bridge-- the metaphor we're using-- don't build a bridge behind a curtain and won't let anyone see behind. You're gonna get fired. And by the way, you probably deserve to get fired.

David Guttman:

I like that you brought that up. I'm sure the re are situations where "measure twice, cut once" makes a lot of sense. Those cuts can be very expensive to get wrong and iterating. It just may not be an option. You touched on something too that I think is really, really important. As an engineer, your power, your value to the organization is proportional to how you're helping others. Creating a tool that other people on the team can use. Right? You create it once you use it. And then other people are getting sped up by it. Their work becomes less error-prone. Faster. It is easier for other people to understand, the dividends keep going.

Uh, you also mentioned pairing, right? The information that you know-- maybe you're stronger on the front end, they're stronger on the backend, and now you pair with them. You didn't transfer your front end knowledge in the sense that you lost anything. You created it, it went, it went from zero to one on their side, but it didn't take you from one to zero.

It's almost like you shared fire: you still have yours, they have theirs. And the more opportunities I think that an engineer can do this, their reputation grows, the value to the organization grows, and there's probably even second-order effects.

You teach that engineer and then they teach other ones. It keeps compounding. Do you think-- it's two things. Is there a reason why an engineer wouldn't do this is, is one question. And then, the other is, how does an engineer know when to start doing this?

Let me rephrase. Let's say an engineer considers themselves to be quite junior. They recognize that this is important for them to grow. Is there anything that they can do or do they need to wait? And if they're waiting, what should they wait for to know that, okay, now is the time to start to influence other engineers?

David Subar:

No, you shouldn't wait, and you can start by asking questions. "Oh, that's interesting. Why, why are we doing it this way? Why wouldn't we do it that way?" Right? Because now, at the very least you're learning, but you might be pointing out a flaw in someone's reasoning that they might not recognize. And so, as opposed to telling, say, "Oh no, no, we, we need to use Jason in a different way here." I'm just making up something arbitrary. That's wrong. Ask the question. Even if you do know well, ask the question, don't tell them. Because by asking questions, you'll tend to find out if maybe you misunderstood. Maybe that way is right. So don't wait. So when's a good time not to be an information sharer. Well, gee, if you're concerned about protecting your job, then being the sole person who has that knowledge will do that; but I'm going to argue that that's not actually particularly valuable to you because-- if there was a shortage of jobs, then protecting your job would be important. And being that kind of jerk, who like keeps information to his or herself just to protect you and not being, you know, not trying to expand the pie... when there's a lack of jobs, that may be the good strategy. That's not the world we live in. That's not the world we're going to live in for quite some time.

If you grow your reputation, you'll tend to find more opportunities will come to you. Maybe you're not going to agree with my philosophy, try it out and see. But I'm arguing that my philosophy will expand the pie, not just for the company you're working on, but for you as well. You'll get the reputation of "Here's someone who adds value. Here's someone who is helpful. Gee, I tend to want to seek those people out as opposed to the people that are difficult to work with.

David Guttman:

It's like you're developing a gravity, right? People are going to be attracted to you because of how you make their lives better, make their lives easier, save them time, delivering value.

I really liked what you said about asking questions and not telling. I feel like it's pretty universal. I think most teams really just do not have as much documentation as they would like. You don't need to be an expert to ask questions and then write down the answers.

And yet, that is incredibly valuable. So I agree with you. There's no reason to wait on that.

Hey David, this has been great. Where can people find out more about you online?

David Subar:

There are a couple of ways. My company is Interna, I-N-T-E-R-N-A. Go to our website, https://www.interna.com. You could contact us there, you can find us there. I am DSUBAR, almost everywhere on the internet. D-S-U-B-A-R. Like the car Subaru without the U. S-U-B-A-R. you can find me on LinkedIn, hit me up there. People have questions, they can reach out on the Interna website, hit me up on LinkedIn, tweet at me. I'm glad to be helpful.

David Guttman: Fantastic. And we'll put all of that in the show notes. So if you just go to juniortosenior.io, you can find links to all of those things.