The Blog

Schedule a Consultation

Have you read our blog and still have questions? We offer no-cost consultations to portfolio firms and organizations seeking further advice or assistance in strengthening and growing their Product and Tech teams. 

Sign up now to schedule your session with one of our expert principals. 

Recent Posts
What's next?

Interna principals present at events worldwide. We send out a monthly newsletter with information on where to find us next and how to stream our talks to wherever you are. Our newsletter is filled with additional tips and tricks for executive leadership and the latest stories in global tech news.


Stay up-to-date by subscribing to our newsletter using the button below.  

Fostering Engineering Growth and Career Pathing

David's notes:

On the Dr. Knowledge podcast, Dave Gullo and I deconstruct how to successfully drive product and engineering management in the tech industry today.


Dave Gullo:

Today, we have David Subar. Thank you for joining. I think I'd like to just start off by talking about your career path. Let's jump right into it.

David Subar:

Sure. I started my career doing research and development in AI and machine learning at a military think tank in DC. We were doing a lot of different projects for various aspects of the military and some of the other three-letter agencies. They were relatively interesting about some bad guys coming over the hill, how do you determine who they are, and what they're trying to do. Particularly when they're trying to not deliver information to you that's relevant and trying to spoof information.

Some of that stuff I can talk about and some frankly I still can't, but I'm going to give you the big takeaway on what I learned. This is a big pivot point for my career. I graduated knowing I wanted to work in AI and thinking I wanted to work in R&D. That's what we were doing, we were advancing the state of science. I was there for, let’s call it three years. I found out that I did not want to do research and development.

As background-- you have to understand, and this may be similar to many other people that you talk to, many people listening, I grew up as a nerd. I grew up on an Apple II, writing code when I was 12. None of this is probably unique to me. None of that's unique to me. I really thought I wanted to do research and development. What I found out was when you're doing real research, a good output is a paper and some learnings on that paper.

If it's a good paper, you present it at a conference. If it was a good conference, 200 or 300 people listen to you. And then, generally nothing happens. I found that really unfulfilling. Now, I'm not trying to denigrate research. Advancing the state of science is super important. I'm just not built that way. What I wanted to do was answer, “how does technology change markets? How does technology change people's lives in a direct way? What can I show to my mom, and say, ‘I did this’?”

And doing research in a classified environment, you obviously don't get to do that. That was a major pivot point for me. It was very early in my career, and I decided I wanted to write code. I wanted to build products that change things in a demonstrable way. I went from there. I did exactly the opposite, and I went to Booz Allen Hamilton, which was a consulting firm. We were doing applied applications of AI to corporate clients.

I worked there for a few years, then I went to product companies. At first, at an AI tools company, then a variety of other companies. I started out as an engineer. Then I started managing teams, then larger and larger teams. Eventually became CTO of companies, and then CTO and running Product as well. Why both? My fundamental thesis was I wanted to use technology to build experiences, to change people's lives in some way.

By running Product and Engineering both, I had both the what and the how. The envisioning of what to do and the actual building it. That was the point of the arrowhead for me. That's where I wanted to get. I ran a game company along those times. I was CTO, and also running Product of a company called Interthinx that was doing intelligence systems for finding fraud in a mortgage space.

I was at online media companies, but this focus, that pivot point of going from research to shipping product was the fundamental thing. That's, frankly, how I've organized my career. That was the fundamental point: How do I think about everything that I work on, but also how do I think about who I hire, how we retain people? How do we get organized with each other? How do we know if we are really producing value?

Dave Gullo:

Yes, definitely. That's a big bite of what I want to talk about is both attracting talent and retaining them through these kinds of programs for growth and managing the career path. Would you say that that transition from your earlier career where you were just doing engineering over to those engineering management and then eventually CTO roles, can you talk about how that transition happened? Did it come naturally? Was it a lot of hard skills to learn? What was that like?

David Subar:

The answer to both of those questions are yes. I recognize that this is something that I wanted to do. People have this decision to make of “Am I just going to be an engineer, and that's what I'm going to do with my life, and I'm going to be happy with that? Do I want go into management, and where are those diversion? How do you think about them?” I think it was so forward. I'm born a nerd, it's congenital.

I love technology, but I did not want to have my fingers on the keyboard all of the time. I wanted to learn and understand that. I think if you're going to be a great manager of technologist, you do need to rock that stuff. You need to deeply understand it. I started getting focused on “How do I create teams of people that can create great products?” as opposed to “What is my solo contribution?”

To your question, were there hard lessons to learn? Yes, there's a bunch of stuff that I just did not know, that until I started executing I didn't learn. Like how do you communicate timelines? That is a non-trivial thing. How do you understand timelines, and how do you communicate them? How do you communicate what results are important?

I think a lot of people make the mistake of saying I'm going to talk about our increased velocity to the CEO. That is almost always terrible conversation. Those are the conversations that people start out with. Those are the conversations that I started out with. They're frustrating for everybody. But yes, there's a bunch of hard lessons to learn like that about, “How do you get alignment with the rest of the company, how do they see you producing value?”

One of the big mistakes for a CTO is if they are in part of an organization that looks like a cost center as opposed to a profit center. What I mean by that is- and this is why I chose to be a CTO and not a CIO- is if you are in a cost center, at the end of every year when they redo budgets, people say to you, "That was awesome. Great year. Thank you. We want you to do more next year with less."

That's never fun. I wanted to have the conversation where they say, "Great year, last year. That was awesome. What can we do to increase investment in your group, so you can do more, better things." Learning how to have those conversations, not just with the executive manager, but with the team that's actually doing the real work. That's non-trivial to figure out. There were some hard lessons I've learned, and some things that I was told and some things I figured out quickly.

There was a bunch there to do, but it's not just getting aligned with executive management. It's how do you create an environment for the engineers in the organization, for the product managers in the organization, and for everybody else in the engineering or product management organization that they're also on the same page, that they're also traveling the same path.

Dave Gullo:

I wanted to touch on that a little bit because I've seen and been in organizations where Product and Engineering do not necessarily roll up to a CTO. In fact, that's one of the first questions I ask other CTOs I meet at networking events and stuff. “What's your org look like? What's the structure?” Sometimes you see this structure where Engineering goes up to one side of the house and Product goes to the other. There's this wormhole or black hole between the two leaders, and often they don't talk or maybe they're traveling.

Sometimes I've seen basically a CEO takeover Product, and a CTO takeover Engineering. It's really two sides of the same coin. When there are these disparate things at the top, there's often a lot of those disconnects, like you said, with understanding velocity or understanding changes-- the thrash, et cetera. I think that's very interesting that you've taken the reins on both of those things. Do you have any anecdotes or history where maybe that wasn't the case?

David Subar:

Yes, sure. Sometimes it makes sense on both reporting to the same person and sometimes it doesn't. I have some metrics I think about in order to make that determination. Now, these aren't hard and fast rules, but things that I've found generally apply. In B2C companies, it's a lot easier for a Product an Engineering to report to the same person because all of the signals are coming from usage of the product. “What should we do next? How do we think about it? What do we adjust?” It becomes much easier in that case.

In B2B products, sometimes it makes sense, sometimes it doesn't; because signals might come in from sales, from marketing, from other places. In some cases, the outward-facing role of the Product role is just bigger and so much more diverse. In either case, the relationship to whoever is running Product and whoever is running Engineering is critical. If those two people don't get along, it's poison.

Dave Gullo:

In some past experiences I've had, we'll literally sit at the same aisle, at the same desk. We'll be literally joined at the hip in that regard, not just because the small talk that benefits during the day, but it's even a show of solidarity to the rest of the org, too. These two people are together all day, in a metaphorical sense.

David Subar:

I'm super passionate about this. Let me tell you. I've run Product and Engineering for a long time now, but the last six years-- so this will explain my passion. I kept getting more meta in my career. First, I was doing research and then I was doing practical applications, and then I was running teams of engineers, and then I was running teams of engineers and product managers. Now, the last six years I've been spending time consulting to Technology companies about Product management and Engineering.

How would you make product managers and engineers more effective in building and shipping product, getting feedback and doing-- this particular set of questions is near and dear to me because this is what I do. I've worked from small startups to The Walt Disney Company. This is literally what I think about all the time.

Dave Gullo:

Actually, there's one thing I wanted to jump back to real quick on the R&D side of things. When you first mentioned it, I thought of R&D in a corporate sense which has some similarities. For example, it could be documents, it could be research that you present. It also can be POCs, early-stage products, things like that.

I think what they both have in common is that you inherently- well, you might be throwing something away when you're done. In fact, you often are, because sometimes things don't pan out, et cetera. Well, I'm just going to make a statement, but then turn it into a question. In my own path, I've found in earlier stage startups I've been in, I'm the one that takes those arrows because of a couple of reasons.

I'm a hacker too and an engineer-first kind of mentality, I think, like yourself. Also, I found that engineers hate to see their work not come to fruition, even if they know it's just POC or R&D. Oftentimes, I'd say 80% of the R&D I've ever done never even saw the light of day. Some of it gets refactored quickly into production-level stuff. Do you still have that hacker or that bug to code things every once in a while? Do you still get on the keyboard and pound that out?

David Subar:

I do. The reason I do it is, in order to understand new technologies, it's important to exercise them. I don't get to do it as much as I would like to, but I like to go and try to hack something out so I can grok it as opposed to just read about it. I think it's important. With regard to your POC thing on research, I think about that differently, slightly differently than you suggested; and it's a difference in goal discussion.

I argue that all code is short-term. There should be an expectation that it's all going to get thrown away. The measurement of goodness is did we create something of value to someone or are we further on that path of learning to create something of value for somebody? I actually encourage people to-- and I'm going to say this carefully-- to write code quickly and to build and to expect to be refactoring all the time. I don't expect engineers to be efficient. I expect them to be effective.

Dave Gullo:

Yes, absolutely. I found that in coaching engineers. You're not writing your magnum opus here. Pretty much any reasonably designed product that's not too complex can be rewritten in a quarter pretty much. The value of the product is not about that pile of code you've got sitting there, it's about all the learnings, like you said. How does it work? What's the usability? How did you scale it, et cetera?

It's usually younger engineers that want to try and overthink it and overanalyze. The analysis-paralysis that comes with wanting to make something that will last a lifetime. Nothing ever does. I think it's just through experience, you see code bit-rotting. The perfect example with many companies, it was going from angular to react, things like that. You should be able to write stuff so much quicker, and if you can't, then you need to look inwards in your process.

David Subar:

Writing perfect code makes an assumption which is untrue is that product managers should be good at their job. That is a job that's impossible to be good at. What I mean by that specifically is a great fidelity on what the market wants is impossible to say.

The process of envisioning something, creating code, getting out into the marketplace, and coming back and doing it again and again is a walk through the requirements space. If you're making that walk really expensive by making perfect code, you're learning slower.

Dave Gullo:

Exactly. Your learning rate's affected. Furthermore, that's seen by folks as thrash, when it's not. A part of this article is going to go into a little foray or a little tangent I took reading hundreds and hundreds and hundreds of Glassdoor reviews. Inevitably, the view of the senior management, which often includes Product and Engineering leadership is always lower than everything else. I think there's an unreasonable expectation that everybody just knows what the market is going to want. It's a bit of an inflexible type of thinking.

David Subar:

If you've never done those jobs before, it's a reasonable type of thinking, but it's inflexible, as you pointed out. What I say to engineers are, well, there's an assumption that executive management knows exactly what the market wants. Would it be reasonable to assume that you know exactly how long things are going to take? The answer is no, of course not. We're doing this for the first time, and that's exactly the same as what you're doing.

It's getting that empathy through the organization, not just with the engineers to the executive manager, but executive manager down to the engineers. That's the key to making these groups work together well.

Dave Gullo:

If you could maybe, you mentioned earlier just about the different kinds of companies that you're inside of and so forth. Starting from around the time you were in Engineering leadership, maybe talk about the different companies in just broad strokes.

David Subar:

Yes, sure. Been involved in different companies, different sizes. Everything from small startups, mid-size companies, large companies. I'll give you a couple of examples. I ran my own game developer. We did games for Electronic Arts and Activision, and companies like that. That was a company where we had 12 engineers, and we hired outside for artists and game designers.

In the initial internet boom, I was CTO of companies of sizes 20 to, call it, a 100. I ran Engineering for a while on an interim basis at before they got sold to LinkedIn for $1.5 billion. It's crazy. I was consulting to the president of Disney ABC Television Group. First the CTO, and then AVP, then the president in ABC Television Group.

I did work at a company called Meta where I was on an interim basis, running hardware, software, Product Management, neuroscience. They were doing augmented reality headset, physical device, but we were building an operating system and an API and an SDK. That company was 75 people-ish, maybe it was 90 people. Most of it was some kind of Engineering. Companies of all different sizes, different stages, but the main focus has been the stuff that I mentioned before about how do you build teams that can build great products.

Dave Gullo:

There's got to be some differences in, say, a 20-person team versus maybe that 100-person team. Can you maybe describe some of the differences in your strategies to have that trickle down through your org?

David Subar:

Yes, sure. There are. In a 20-person team, a 100-person team, at Disney, the team was much larger. There are differences. Part of it is based on how hands-on can you get with the people in the organization, Engineering or Product management. How do they get to know you? How do you get to know them? How do you deliver information? It's much easier in a smaller team, but there are inflection points, like 5-15 is, you do it one way.

Under 5, you do it one way. 5-15, do it in another way. At 20-25, that's another inflection point. There's another one at about 50. Maybe there's another one at 75. Another one at 120. When the teams are smaller, it's much easier to communicate directly and it's much easier for everyone to know each other. When the teams get to be 100 or bigger than that, you're counting on your managers for delivering the message, for getting feedback.

This is where empowerment gets really important. What you are talking about becomes really important. When you're a team of 100, certainly maybe before then, you can't get to low levels of the architecture, but you can get to, “Here's what we're trying to solve for,” and “Tell me how you're going to solve for that,” and “Let's beat on each other's ideas a bit so we get to fidelity, to where we want to go.”

How you recruit and how you retain and what you measure and what you talk about is critical as teams get bigger and bigger, because it's very easy to see the person who is much higher on the org chart or much lower on the org chart as not a person.

Dave Gullo:

Yes, absolutely. That's a good segue there. Just to tie into the next piece here. I like to think of the Engineering talent market as very much a seller’s market. It's really hard to find good talent, and similarly to be able to retain good talent. Some of the examples I use for this is-- Well, here's a quick little side story:

I used to interview every month for about 10 years. It was in the early 2000s. I was a senior developer engineer at the time. I just had my first kid and so forth. I was really freaked out about losing my job. I went to a lot of different companies all over the place. Inevitably, I started to see, I was interviewing them even more than they're interviewing me. I started to look at like, how do they function? What are the people look like? What kind of questions are they asking me? Really, what's in it for me to be in an org like this? It became almost a guilty pleasure. I think I interviewed probably over a hundred times in this program just for a decade, like I said. Then furthermore, being on the other side of the table for another 10 or so years, and interviewing and hiring lots of people.

I could almost tell who were the outstanding performers because they're doing the same thing. They want to peel back the layers and go deeper into examples. Good people would say like, can you give some examples of people who have grown here? You keep talking about growth. Let's see that, give me some examples. Conversely, I've had people- you ask people, “Why are you in the market?” They'll tell you that they come to work every day, it's like Groundhog Day. It's the same thing.

Their management doesn't really understand well what they do, et cetera. What we'll talk about next is, “How do programs specifically work for individual growth, what are your strategies and tactics for implementing these things?” Similarly, it's two sides of the same coin when it comes to managing someone's career path because that's something that usually spans before they started working with you.

It's something that is definitely gonna go beyond when they're working with you. You can tie those two things together. That's really a big part of what I'd like to talk about next.

A lot of my questions often wonder about the differences of how people go from being in a small situation-- you might start out as an engineering manager, you have one team, maybe there's 7 people or 10 people. To manage an org at that size is much different than one with many Engineering managers, directors of Engineering, and a whole management structure. I'm wondering if you could take the conversation towards, “How did you really scale this?” and get the ethos to permeate through an organization.

David Subar:

Let's take two versions of being small. Small is: “I run a team of seven people, ten people in a larger organization.” That's interesting- and I'll talk about in a second, versus “I'm in a start up and there's only seven in the total Engineering population of the whole company.” The way you manage small numbers of engineers is very hands-on. It's very different than when you get bigger.

It's easy for everyone to sit in a room, or if you have a road team, to be on Zoom with each other all day and have this high-touch interaction. That's great for small teams. It's very low latency, a low bureaucratic way of doing things and optimize. Then your team gets bigger. You get to maybe 15. Now you've got a couple teams.

There's some level of abstraction in the communications, but you can still get hands-on with people quite a bit, but you're not necessarily in code every day, doing it yourself, because there's too many things to do. You can ad hoc that still. Maybe you'll use some agile technique like Scrum or XP or Kanban to start doing things in a more formal way there, but a lot of that still tends to be ad hoc.

What really starts to change is when you hit a threshold of 25 or 75 or 125. Each of these places, things start to change what you do, how you manage, what you're looking at. The key is certainly when you get into bigger and bigger numbers is, how do you fractalize it. What I mean by that is how do you get the teams aligned and producing value as atomic units, without having to require much day-to-day interaction?

How do you do that where people not only feel a part of their team but part of their company, and know that whoever's CTO or Chief Product Officer still cares? How do you make sure that you have alignment on mission among those? There's different techniques, and the communication patterns are different as you grow, but my fundamental thing that I do, the fundamental thing I think about, is how does goal-setting happen?

How do results happen? I believe that there's a social contract between a manager and someone who reports to that manager, whether that person is an independent contributor, individual contributor, or whether it's a lower level manager in the organization.

The contract goes like this: it's the manager's job to set some goal state. Here's what we want to get to and here's why. The person or people that are fulfilling that goal state get to ask a lot of hard questions. They get to ask, “Why is that important? Why are we thinking about this? Shouldn't we consider this?” At some point, you get to a decision-- hopefully quickly-- like, here's the final goal state. We agree.

It was set generally by the manager and punched up against by the people that are going to get done, but we've agreed on what it is and that's what we're going to get done. Now, it's the people that are actually executing it. Their job is to say how. They go away and say-- come back and say here's how we're going to get it done. Now, it's the manager's job to ask them hard questions. There's asking instead of telling, because in asking, you learn things you might not expect. They might know something you don't know.

If a manager tells someone who works for them what to do, they will tend to do it whether it's right or wrong, just because of the power of the office. If you ask, then you find out like, here's the way that person thought of it. They might be wrong. They might be right, but in asking, you find out. My experience as a manager, by asking people questions, when they get used to it, they come to meetings being more thoughtful about what they do.

First stage: set the goal set. The people that are going to execute ask the questions. Second stage: the implementation gets discussed, and the manager ask the questions. Now, you've hardened on goal, you've hardened on implementation, now it's time to run. We've agreed. Go do it, go get this done. The manager's job is to check in, make sure it's getting done approximately.

Now, hopefully, you have a team that's executing that will bring problems up before the manager recognizes it. Like here's something that happened, it's different than what I thought. We have to change plans that way. That's optimal, manager checking in, enforces that. One role of the manager is to check-in. The second role, and maybe the more important role, is to get impediments out of the team's way.

What is it that you need in the environment that I can do for you so you can run, so you can get this stuff done? Now, I described that generically. When I talk about the fractalization of how to run organizations as they get bigger and bigger, this methodology tends to work well at different levels of extraction. A team of seven that exists in a team of several hundred engineers and product managers. A team of 25 that might have several teams of seven in it.

Seven’s an arbitrary number. A team of a hundred. This methodology tends to work well. There are different companies that implement this in different ways. Amazon famously had the six-page memo where everything's written up at six pages. The final six-page memo for Bezos is composed of a bunch of six-page memos for his direct reports, which are composed from a bunch of six-page memos under.

That's one way of implementing this conceptualization, but what you want is-- you want teams that understand what they're supposed to get done, execute well, and have all the tools they need. As you get to a bigger and bigger scale, you can't have your hands in code. You may not even have your hands in the lower-level parts of the architecture. What you want to do is have an ensured process of everyone running along the same mission and executing well.

Dave Gullo:

I love that analogy. I love the self-similar analogy that you get with fractals, that regardless of the level you zoom in or out of. That's a great way to look at the scaling process in general, across the org. When I'm looking at growth, granted inside of all of that-- there are challenging situations. People are making commitments in scenarios where they themselves need to be stretched in some way professionally. Maybe they've never led such an initiative or done such a thing.

That growth is the gimme part of it, in my opinion, because it's an expectation of the role they're in. It's an expectation of every individual contributor, et cetera, to be growing along the way in that regard. I'm also looking at that next level where every IC has a manager or somebody who's also managing their own personal growth path which, in any successful company, the alignment needs to be there.

You're not just learning Swahili or something like that unless the company needs you to, but learning rust or going or some other thing, because the company might go there, there's that, et cetera. I think there's a possible way to superimpose that self-similar nature to the process you just described; but with respect to the individual, and specifically that Socratic method,

the expectation setting, saying, "Look, this is the next hill you're going to climb." In fact, just let me put that-- The individual says, "I think I want to climb this hill” in getting that validation and so forth. In this next direction, beyond just the expectations of what's needed for a team, that baseline growth, how about the outsized growth? The extra step of growth that a lot of engineers and people need just to feel well engaged, that they're going somewhere in the long term.

David Subar:

You mean individually.

Dave Gullo:

Individual growth.

David Subar:

Yes. Individual career management is an interesting thing, for individuals. How do you get to the next step? What is that next step? I want to go from developer to senior developer to lead to architect. Or I want to go from developer to some management layer to managing larger and larger teams to becoming a CTO-- where a CTO, in that case, is just maybe a VP Engineering the way I described it; whereas it’s described as the manager of people and process. That growth is interesting because there's somewhat of a joint responsibility. The joint responsibility is the person who wants to grow and the manager that that person might report to. The ultimate responsibility for the person's growth is that person.

Dave Gullo:

Ultimately, yes, agree.

David Subar:

As a manager, particularly, if someone I want and if it's someone I don't want in my organization, I need to solve it in a different way. Certainly, I only have people in my organization that I want, I want to provide them with opportunities so that they can learn those things and they have it. Now, if you're in a growing company, it's a lot easier to provide opportunities than if you're in a shrinking one.

If you're an individual contributor, I suggest that you want to be in a growing company rather than a shrinking one for a bunch of other reasons. It's important as a manager to know the people in your group, and know where they want to get to, and provide them opportunities as they occur in the organization.

Now, I'm parsing that very carefully. What I'm not saying is, “Create opportunities that don't naturally exist” because it has to be the person and their career trajectory, and the needs of the company have to be aligned.