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.

---

Transcript:

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 Lynda.com 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.

Dave Gullo:

Absolutely.

David Subar:

It's important to know the people in your organization know what they want. It's important, by the way-- this is like extra credit, but extra credit that I definitely suggest-- ask them hard questions about why they want that. Does it really get to them where they think they want to go? I was with a junior engineer for coffee over the weekend. He asked me for some time to give him some advice. We went out for coffee.

He had a particular career goal, and I asked him why. His answer was, "I thought that--” it wasn't this cute, but it was, well, “I thought that might be a good thing to do, but I'm not really sure." I asked him why. He didn't really have any reasoning to back it up. We got to some fundamental questions which were, “Where do you want your life to go? What do you love?”

Then from there, we were able to come up with some more fundamental-- like, “Here's a path that you should try, that you take this next step.” I'm trying not to give away who this candidate is, I'm being general here. For someone who might know him-- “Here's the next step that you might try that will open up these four doors, and don't be so convinced that this door that’s seven steps ahead is the one you want.

“Go through this next step. Look at these four doors and then take the next step and the next step.”

Feel free as a manager to question the person who has worked for you what their next step is and why. Then, to the extent you can provide them those opportunities, to the extent that you have the tools to provide.

Dave Gullo:

Absolutely, I think you're threading the needle there perfectly in the relationship between growth and your career path. You're talking about making sure that the immediate growth you're focused on, the things that you're working on-- are they internally consistent with where you want to wind up going? Number two, does that also align with the company?

In most growing companies, like you said, those opportunities emerge. It's like emergent space time, it gets bigger and bigger and all kinds of needs pop up through different company cycles. One other quick tangent story that's fun is, my boys have been taking martial arts for fifteen years now since they were three years old. You ask a four-year-old or a five-year-old what do you want to be when you grow up? Every single one of them will say, "Taekwondo master, sir," because that's what they think the other person wants to hear. They themselves are in a very early part of life. They're trying to connect the hard work they're doing right now, which is basically dodgeball and jumping over pool noodles and things like that, to some kind of thing that they think they would be respected for.

You'll see that too in this notion that engineer- or developer-type folks, their only real path is to go to management someday. That's been disproven as tech companies have gotten bigger. There's no more of an industry now than there were 30 years ago or whatever. That's a great way to put it. I like how you tied those two things together because a lot of this type of work-- I jokingly say you are being an armchair psychologist and a camp counselor with people. Just ask “Why?” 10 times-- the Socratic method, et cetera, is so effective. I love hearing that. Great analogy.

David Subar:

The other thing is the world's a very big place. When you're just starting out, you don't know how big it is. You don't know what all the opportunities are. Being asked the question, being introduced to different kinds of things, I didn't even know that was a choice. When someone doesn't know that something is a choice, they don't think of a path to get there because they don't know there's a there, there.

Dave Gullo:

Yes. Absolutely. That goes to some of these orgs and folks I've talked to who've put an emphasis on a published career ladder, and actually locating from your first day at work, or even beforehand before you're hired, you would be here-- Engineer Level 3 or whatever it is. This is the kind of expectation, this is the level of autonomy, et cetera, that is expected of you at this level.

Based on your career, experience, your CV, and what you've told us, we think you're there. Provided you stick with us, you're going to go to Level whatever, and dah, dah. If you want to jump over to the management ladder, you can do so. A lot of good conversations in the series about how folks have done that and stuff. It's interesting that one of the interesting quotes was that, “It's not a promotion.” I like that actually. It's lateral at best. Even somebody else said, “I wanted to demote people just to make sure they were in enough to really want to do it.”

They can't take a pay cut obviously, but it is a different kind of set of skills, and there are people who are really good; and engineers have to learn a whole bunch of other soft skills. Some make it, and some don't. Some orgs give a safe enough environment where when you go back to engineering, it's not a shame or a fail. It's like it was understood you're dipping the toe in the water and stuff.

David Subar:

I'll give you my personal example. I started my career doing research and development and AI and machine learning at a military-owned think tank in DC. I spent three years there. My frame was like, "I've got to stay in AI, and this is what I should do the rest of my life and anything else is a sell-out." Then I tried something else, and I tried a couple other things. Then I ran a game developer, and that was great; but what I'm doing now, I consult to Product Management and Engineering groups about how to make them more effective. I think I said this in the beginning, with small companies to large companies. I didn't imagine that this was a thing someone could do, and I am so much happier.

Dave Gullo:

When you're in that kind of bliss, you can't even fathom what retirement would be because you're just bored and staring at the four walls. That's a great place to be.

David Subar:

Yes. It doesn't mean you got to do what I do to be fun and have fun in your career and be happy. You need to do something. It doesn't have to be this. There's other choices. Different courses for different horses, but you've got to find the one for you.

Dave Gullo:

You did a really great tie-in between growth and career path, and that's one of the most succinct ones yet, just the alignment and so forth and really questioning like, "Well, why do you think you want to be there?" We can probably align a lot of things for you as an individual here at a company, but the why part. Mixed into that you get scenarios where people have maybe been there for a while, even after a couple of years-- 2, 3, 4 years. Definitely, if there hasn't been a lot of movement out of a role, someone's going to get stuck in a rut, for sure. What do you do about that?

David Subar:

I'm a big believer in squads. Over time, these models might change, but the Spotify squad model is one of the better models for doing development. There are others that are good as well, but my thing about being in a squad is you're required to stay in that squad for 90 days. You're in a particular part of the architecture of a company as a developer, and you're required to stay there 90 days, and after 90 days, you can raise your hand and say, I've had enough of this one, I would like to go to another one. That doesn't mean you get to immediately change, it means you get on the list at the next natural break to swap to something else.

In asking people to raise their hands-- not telling people that they can raise their hands, but to ask people to raise their hands-- they get opportunities to see other parts of the architecture, other things they can do as developers. That answers part of your question, which is, "How do you not get stuck in a rut?" As a manager you actively say, "Who wants to raise--" or you recognize someone who's there and say, "Do you want to raise your hand or not? You don't have to, but you may."

That answers in this role, or in another part of the architecture, but there are other questions like, “I'm a developer, I want to be an SRE.” or “I'm in SRE and I want to be in QA automation.” or “I'm in one of those and I want to move to a management role.”

A large part of this has to be generated by the person. "I’m bored, I want to see what else is there." Once again, being in a company that's growing makes a lot of this easier, but it behooves a manager to ask their people.

There's a disincentive for a manager to do this. I've got a really good person working for me and I'm going to ask him or her, "Do you want to move out of my group?" Writ large, great developers, great engineers of any type are hard to find. I'd rather have them in my company than in someone else's. If they're going to be bored in my group, then sooner or later, they're going to make a change. I'd rather have them go down the hall than to the company next door. It's good to have them down the hall in your company. It may hurt you in the short term, but better for you in the long-term if people tend to stay here.

Ask your people, but also once again, the primary responsibility-- I had someone who worked for me and said, "You're responsible for my career growth." I said, "No, I'm not. I'm here to help you because I'm trying to be a good guy, but you're responsible for your career growth, but because I like you and because I think you're talented, I'll help you with that." As a manager, you ask for someone; but as a person, you have to think about what I want next, and you have to decide, do you trust your manager to mention that? How do you find that?

Dave Gullo:

Yes, definitely. That's been a theme. A lot of these conversations lately have gone a little bit off-track into effective one-on-ones and how that goes down and stuff. The way I've seen that work well is, in one-on-ones, the best people are bringing their notes to the table, they're reading their notes for the first two minutes before we start, they're taking notes as we're talking, and they're capturing their own goals themselves.

Where I've seen sort of a silly fail is where, as a company, we have software to track your growth or your goals or whatever. As software developers and engineers and stuff, we don't clock into work. We don't clock out of work anyways, so who wants to go to a bean-counting program to say I'm 27% to goal learning Rust right now or whatever? That's awful.

David Subar:

What does that even mean?

Dave Gullo:

Exactly. What does it mean? It's like people get a little crazy on measurements. It's like when it's for the individual's growth, they either come to the gym and do the reps or they don't, but the best, or even having an extra layer of organization, their little black book and their notes, whatever they want to do. Just like with any other meeting, you're not leaving the room until there's outcomes and assignment of outcomes.

Usually, it's always on the IC, although maybe if you're enabling them to do something or you're enabling them to move lateral-- you as a manager need to do some internal comms as well. There's some facilitation, but you're right: It's mostly all the individual, and the better organized they are and the better they take notes and remind themselves of what they committed to, et cetera. Again, this is not just in team success. That's already a given. We want to talk about the extra stuff that keeps you even more well-engaged.

David Subar:

I will tell you, with my one-on-ones, all of them are shared Google documents where we're jointly typing in the document as we're meeting and making commitments and goals, but also retaining a record of what we said, that we can revisit it.

Dave Gullo:

That's a great idea. Plus, you have the ability to comment and resolve and all kinds of things, so you know that things are checked off the list. It's a great workflow. I didn't even think about that.

David Subar:

I do coaching too. I coach CTOs, and Chief Product Officers and do the same thing there.

Dave Gullo:

Continue. If you want to riff on that, go for it.

David Subar:

No. It's the things that you just added to. By the way, just for the record, particularly if they're on Zoom, they're recorded. I use software that does audio transcription real-time with the audio, which then you can reference back to the Google document, which you're jointly typing, which you could put action items on, which you can throw out to Asana. This is all part of an infrastructure I use. You don't have to be as complicated as I am to do this, but there's tools out there that will help you track where you've been and where you're going and make commitments and see if you've done them or not.

You don't have to use my set. You can use any set, but I encourage you to use a set, and I would start with Google Docs.

Dave Gullo:

Yes, totally. In this day and age, there's no excuse for anything. There's so much tech for everything. Even with my kids growing up, it's like everything that you ever wanted to know is on YouTube. Of course, they go and learn the cheats on Minecraft or whatever. I learned to fix my mower. There's every bit of knowledge you ever want. You can watch thousands of it.

David Subar:

It's incredible.

Dave Gullo:

It's in this day and age. Back in the day, maybe 30, 40 years ago, you needed an encyclopedia set in your room to do a book report on something. Nowadays, there's really no excuse. It just literally takes motivation.

David Subar:

There's no excuse for not finding the data from a third party. There's no excuse for not running your life like the Truman Show. You don't have to broadcast it to everybody, but you could broadcast it to yourself.

Dave Gullo:

Yes. I like that. Now we go to the last piece, which is my wild card round. Wild cards are something I even did a lot when I was interviewing lots of people just to have a fun side conversation, or another related conversation to work and stuff. In this case, the theme was bad interviews or bad candidate experiences from either side of the table, whether it's been when you were interviewing somewhere back in the day or when you're conducting interviews. It's pretty much an open book, just anything from the interviewing history you've had that makes an interesting story.

David Subar:

Bad candidate interviews for me are ones where someone shouldn't actually be applying for the job. There's one thing where I ask you a set of questions and you don't know my particular field and maybe you don't perform well on the thing that I'm asking you about in particular, but you have a raw set of skills and you have the capability of learning. I might not hire you for that job, but I might! Talent is hard to find, and smart talent is really hard to find.

I certainly don't expect you to know my particular platform, but I might hire you; but people who don't have and I can think of more than one example, they don't have the basic skills of doing the job on an IC level. As a developer, you don't know algorithms; you don't know architectures, you just have hacked a few things together in your career like those go poorly. As a QA engineer, you don't have a thesis about how to write tests; what to write a test about-- what to test, what not to test. As a manager, you don't have a sense for organization-- not personal organization, but how to build an organization and how to make an organization work and how to make an organization effective.

I particularly care about whether people are aligned to their company. When I see people who are coming into the office and it feels like a transaction, "I can make more money here than I made at my last job, so I'm going to stay here until I make money at the next place." I've had a couple of those. Those don't tend to go well. For places that have interviewed me, it's the mirror of that. If the person that's interviewing me-- if their primary goal is to make a stockholder wealthy, that tends to not go well for me. I don't feel good about it.

I want to be involved with companies, even in my consulting, where we're trying to produce a product that makes the market better, it makes someone's lives better, it makes some other company better, where money is a side effect of that. You can smell the difference when you're in the room if it's a transaction or if the company is actually pushing for something. I don't know if that was specific enough for you, but those are the nature of things that work well for me on either side.

Dave Gullo:

That's good. That makes a great amount of sense. A lot of them already come up in this series where people-- you alluded to it earlier, where somebody else on the other side of the table is coming to you with a puzzle or something they've had plenty of time to think about and sprung on you. That kind of stuff.

David Subar:

Yes, I've had a few of those. Some I've performed well on, some I've not. I generally find them to be fun, frankly. Some of them are so obscure. I'll give you a obscure one that I like, but it's a terrible question to ask in the interview, which is a Google one, this is one from several years ago, which is: you're in a room and the other room next door has got three light bulbs with three switches and you don't know which switch goes with which light bulb and you need to figure it out. I'm going to probably screw this up. You can only go between the rooms once and what do you do. You've heard this one?

Dave Gullo:

Yes. Literally an hour ago in my last podcast interview, we discussed this. Once it gets out that you touch the light bulb and see which one is warm, it permeates through all over the world. All these answers become online. Another person I talked to yesterday had a recruiter leak their code SIM tests. The next coders were completing it in 20 minutes and even people within the company took 60.

David Subar:

Right. There's one about leaking that. The Google one is a cute question, but it's not dispositive of who's going to be good because that is not-- I did not figure that answer out. Someone told me that answer, and I was like, "That's really interesting. A really cute answer." I don't know if that tells you who's good with technology.

Dave Gullo:

Yes. You're right. It's cute. That's the perfect word. When you're searching for immediate epiphanies, it's not fair because think of it this way. When you come to an interview, even as confident as we can be, you're on a different footing. You're presenting yourself, you have a potential towards a fight-or-flight response. Your brain is activating in a way that's very different than when you solve problems. Surely maybe it shows what kind of problem-solver you would be or whatever, but it's looking for genius in a laboratory and I don't think it's a fair way to look for it.

David Subar:

It's the Edison quote. Genius is 99% perspiration, 1% inspiration. It's hard to do that in an interview.

Dave Gullo:

100%.

David Subar:

People are talking to me about my helping on a professional services basis on Product management and Engineering. I've got a bunch of opportunities, so no one of them makes me nervous because if I don't have this one, there's the next one. It's fine. People feel differently about jobs and it's hard; and people who don't do this interview a lot-- you talk about interviewing 100 times in 10 years, I think you said. You probably got pretty good at it and pretty good at not caring about a particular outcome.

Dave Gullo:

Yes. It's like VCs and startup CEOs. You want to raise money when you don't need it, right?

David Subar:

Right. Exactly. Yes. For me, I tell people what I do and they want one, or they don't want one, and it's okay. I hope they want one, but if they don't, it's fine. It puts you at a different footing when you're having the conversation. It's more of a pure footing than a typical interview where you're hoping they like you. Particularly, if you don't have a gig, then it's even more.

Dave Gullo:

Some people have crazy horror stories. I've got too many, but if I share it with you, it will be redundant of the other conversations I've already had. Do you have any--

David Subar:

I've got some typical bad ones. Just like, back in the day when I only worked with contingency recruiters, some of them are good and some of them are scum, and it's scummy ones who shop. I don't think I have any unique bad stories, just typical bad stories back in the day.

Dave Gullo:

It's just the nature-of-the-game kind of stuff.

David Subar:

Yes. There's some of them I would work with again, some that I would gladly recommend, and some of them, if I see them down the street, I'm crossing to the other side.

Dave Gullo:

The other side. Right.

David Subar:

Yes. Then I take a shower when I get home, anyway, just in case.

Dave Gullo:

[laughs] Wow. That bad, huh?

David Subar:

Some of these guys, they're just trying to put paper out there and they don't care what the outcome is, and some of them are really good. You learn as you work with a few.

Dave Gullo:

I was saying to somebody else lately, "The best ones are relationship builders and they're taking people out to one-on-one dinners and basketball games or whatever it is. They take a really long time to build a relationship with every person such that--" It's usually that they're doing this with senior people that are hard to--.

David Subar:

Exactly.

Dave Gullo:

It's such that they get to the point where they think they're going to be in the market, they become what you might call a pocket listing-- they're not even listed as available like a real estate listing-- but of course it's a brain, not a thing that we're talking about here.

When they want it in our market, they reach out to that recruiter they have the best relationship with, and then they will shop them to folks like you and me, and you never could have found them through any other channel.

That's the most valuable data that there is, is knowing that someone is in-market or passively in-market. You just need a little bit of extraction energy to get them out of some other valence or orbit rather than the type of activation energy you need starting cold, which is so difficult. A lot of the unscrupulous recruiters are making a market out of the ether. They're trying to make a two-sided marketplace and they often don't have one or the other things really in hand.

There's this whole facade or this game that they play to make you think they've got all the people or to make candidates think that they've got all the companies. There's a lot of shysters out there. The big agencies, the big groups put a lot of pressure on their younger talent and that's why they turn them over so much too. You'll see a ton of churn at these agencies when you work with them.

David Subar:

That's right. I didn't pick to go into that line of work. I don't envy those people. It's hard. That line of work fosters bad players more than a lot of others, maybe not more than all of them, but more than a lot of others, so the ones who do stand out are particularly worthwhile to know.

Dave Gullo:

Yes. Definitely.

[END OF AUDIO]