Fostering Growth && Career Pathing

… in Engineering-first Organizations.

Talent is super competitive to attract and retain. We’ll call them “Brains”. As technology leaders, we gain a competitive edge for attracting and retaining Brains by offering growth programs and career path coaching for each of our team members.

As a Brain, your overall career path is achieved through growth and by adopting a continuous improvement approach to life. We live continuous improvement and learning as a Tech Organization, and we discuss it with each new individual: from first contact to the job offer. We manage it during employment, and even after separation.

Why? Because it’s personal. As a hacker and engineering leader, my goal is to create environments where Brains have the opportunity to do the best work of their lives, be challenged outside of their comfort zone, achieve magnitude level growth across a range of skills, and be worth more in the marketplace during and after their time with the Company.

I interviewed ~20 CTOs, SVPEs, VPEs on their strategies for attracting and retaining Brains through fostering the individual’s career growth and career path. This article includes excerpts from each participant, along with a link to the full podcast.

Please subscribe to the podcast to listen to the entire series of interviews which went into producing this article. It contains~24 hrs of discussions with technology leaders representing 400+ years of professional technical and management experiences:
http://drknowledge.com/cto/

While this article does its best to summarize the “gems” from each convo, please give a listen to the full audio to get the full effect of each interview.

The Market

Tech job seekers have plenty of choices. whether they are entering their first gig, lateraling, or “trading up”. It’s a Brain seller’s market. But comp is not everything, sometimes the decision involves a combination of: level of role, potential internal impact at company, overall impact of the Company, the purpose, the culture, etc...

Looking past the foosball, ping pong, craft beers on tap, endless beanbags, business hammocks, and catered lunches…. the savvy job seekers peel back the layers and ask “what is REALLY in it for me here?”.

Every job seeker should ask: “What are the growth potentials here, and how do they map to my long-term career arc?”.

The many Universes…

In engineering 1:1s or or interviews, I would ask people about where they fit in the left / right paradigm of their career arc. This is to get a sense of horizons between engineering excellence, or engineering management.

It’s not just a binary choice, you can be in the quantum superposition of both engineering excellence and management, or zig-zag your way back and forth between these types of roles at each new company. Some folks have gone from huge teams back to small teams, or from being an engineer manager back to an individual contributor (IC) role.

A role such as a tech lead, or a principal engineer embodies elements of both engineering, management, and an overlay of strong leadership. These can be the quanta of a well-rounded technical individual.
But how do we get from here to there?

“Horizons are always seen but never met, and new horizons are seen by pursuing old ones…”

I saw that in a dentist’s office when I was 7, and now it has profound relevancy in analyzing one’s career arc.

When my kids were 4, and taking martial arts and you asked them “what do you want to be when you grow up?”..

Naturally they would say “TKD Master, SIR!”. Over time, their worldview has changed, and their “grown-up” aspirations have changed substantially. The same holds true with the Brain’s career arc, starting from day 0, until retirement. There are many versions of “the path”.

Not All Management Gives a Sh!t

A common question in a first-contact phone screen is “why are you in the market?”.

You might be surprised with some of the outlier answers; everybody has a story, every company has a story, and life happens.

One of the more common responses was that: “my manager doesn’t understand what I really do, doesn’t care about how I will grow, and doesn’t present me with the pathway of options on how to level-up.”

A lack of confidence in Senior Management in nearly ALL Glassdoor reviews of tech companies is a suspicious trend. There is a ~10% lower average view across the board of Senior Management than all of the other categories.

Granted that disgruntled people are more likely to write reviews, and may focus their rage on a good Senior Manager. However, you can match this up with the reasoning for candidates going back into the market and seeking greener pastures.

It’s not fair to just accuse the manager in the circumstances where their entire Company has not also bought-in. It really requires buy-in from every level to work. In tech companies, there is a wildly varying degree of attention to this detail, which is what we’ll go into further detail next…

The Opportunity

This presents an opportunity for companies who have explicit programs for, and who espouse their beliefs in growth and career pathing for every individual.

This produces a strong, Engineering-first company culture that hopefully many strong Brains want to work with.

Of course it’s good to talk about the org to candidates before they join the Company, but this all kicks into full gear after their first day on the job.

We’ll dive into the highlights from interviews with seasoned tech leaders, who Haul Ass in their own right, who are passionate about how they grow and foster their engineering teams, and we’ll focus on the common themes that arise.

There were three main aspects to each interview.
1) we talked about their career trajectory,
2) and about how they have fostered growth and careers for their teams,
3) and lastly, some notables which were orthogonal to the topic, but worth it.

This article will summarize many of these aspects from each individual, and also link to the full audio interview of each participant.

PRO TIP: If Your City is only 1–2 hrs away from Your City on a workday, listen to the Podcast episodes on your commute!

The Participants

They range from 30+ years of technical and leadership experience, down to ~10 years. The combined total of career experience from the cohort is ~400+ years of professional technical and management experience. The topic certainly resonated with the respondents, as was represented by the rate of response, and number of respondents.

I reached out to the LACTO Forum, 7CTOs communities, and anyone in my LinkedIn with a CTO title. Some of these folks are SVP/VP of Engineering, or leaders in Product in their own right. The key attribute is that each have grown substantially in their career; and each have built engineering-first organizations; many serially.

The “Executive Summary”

Defining quotes and overall take-aways from the podcast interview series are summarized in this section.

When it comes to Growth, it’s certainly a two-way street because the leadership and management must promote an environment conducive to individual advancement, but the bulk of the responsibility lies upon the individual’s willingness to adopt a philosophy of continuous learning and improvement.

Growth comes in many forms, such as learning and mastering the lifecycles in software engineering.

Growth can be awareness of what part of the (Forming, Storming, Norming, Performing) cycle you are in, and leading appropriately in each one.

Growth can mean that you’re adapting to perform well in Team dynamics, and delivering valuable product… and it can also mean you are advancing new skills beyond just new software languages, or engineering techniques.

To many, growth involves accreting soft skills and taking an ever-growing impact on the team dynamic. It can be a tech lead, a first-timer engineering manager, or going from a line manager to a Director role.

Growth in its most impactful form can be identifying and solving a problem that nobody told you fix.

Growth facilitates the movement along the Career Path. It is achieved through a process of continuous improvement and continuous learning.

“Career Pathing” is the management of an individual, accounting for their path before they joined you, vectoring their arc during their time with you, and hopefully orienting them well for their time after working with you.

Pathing is best managed by direct manager, with feedback from the entire tech management chain. Assessing an individual’s career path should be at least quarterly.

The Career Path discussion focuses on where they think they want to be in the future, along with comparing it to where they are currently headed, verses where they want to now be headed. Then aligning it with the needs of the Company.

Some extreme examples of career pathing “after you leave the company” involve assisting an existing Brain to leave your Company. I mentioned in this interview series that I had interviewed ~120 times in ~10 years. Many of the times, I passed on the offer, because the Company didn’t interview well with me. And this helped solve “the grass is greener” types of feelings at the existing Company.

While leading my 1:1s, I’d tell folks that they should occasionally go interview somewhere else. It gives perspective.

Josh Nisenson (below) mentioned that he would be a reference for a current employee to be considered at another Company.

Every effective and growing org needs an established career ladder; usually a dual-track ladder, with stated levels of expectation for engineers and managers. During the pathing discussions, it’s always important to orient the individual as to where they currently sit on the ladder, and where they can go next. The career ladder is the compass for every individual track.

What advances Brains along the engineering excellence track is achieving increasing levels of autonomy. At an early stage, everything a junior does needs to be observed. Over time the work becomes normalized with the team, and one begins to identify and solve more issues autonomously. Towards the peak, one is envisioning and building major features of the company with no required technical input, and often additional technical resources under direct report.

In management, the increasing levels of internal/external exposure defines the progression. At the beginning, an engineering manager might have a team of 7. As they progress, they will end up managing Managers, and then managing Directors, and maybe VPs. Eventually, they will be more and more externally facing. First externally from the team to the executives, then externally from the Company to the World.

Interview Gems

This section will summarize the notable quotes and takeaways during each discussion, including some off-topic (with respect to growth and pathing) gems, but notable in their own right.

Special thanks to all who participated and from the LACTO Forum, my directs on LinkedIn, and 7CTOs professional groups.

Laura Thomson @lxt — Senior Director Of Engineering, Firefox Engineering Operations
Listen to the full interview

Started coding in Australia at 8 years old on the Apple II, everyone else was in 8th grade, I was in 4th grade. So I learned Logo on Apple II, a Lisp. Had many early tech jobs before college. Played with ◼︎ Next computers at a young age.

The first day I saw the World Wide Web, and said “that’s awesome… THAT’S the future … this is what I want to do with my career”.

Started consulting with her husband Luke Welling. Did grad school in Computer Science. Contributed to tons of open source, many talks at open source conferences.

Been at Mozilla for 12 years. Every few years it’s been a new job, ~6–7 jobs. Went from management at the prior role, back to an IC to start there. Worked on the crash reporting service for Mozilla.

lolz: while talking to Cloudera (who were seed stage at the time), they told us H-Base is not ready for production, as we were on-boarding Terabytes of data into it.

Of people I hired as ICs, one is Sr Director of Firefox browsers, one is Dir of Machine Learning Systems, one is a senior engineer who can solve anything.

I quickly went from managing 8 people to 120 people, and it eventually peaked at 250 people. All of that growth happened inside of a year, and how to manage people. A lot of that involved “action at a distance”, and learning how get things to happen through influence rather than authority.

Now responsible for everything Firefox-related that lives on a server.

Learned about scaling resilient and distributed systems, and keeping them up in a state a partial continuous rolling failure.

Implemented the “Go Faster” program, which got Firefox to release daily vs. 6–12 weeks. My co-worker said to me “you can’t come in here and say these things…” and I said “if I don’t bring this up day #1 then it’s never going to happen, and if I don’t do this, then nobody will…”. ½ of this was technical, the other ½ was a cultural change, and one the hardest things I’ve had to do in my career. THIS is now the daily workflow for many people who said “this can’t be done”.

These days the 2 BIG things are:
1) experiment-driven development, getting people to try things in a a cheap way. Least cost, least risk. Sometimes is a survey, a focus group, or a mock website.
2) how do we collect data in a privacy-respectful manner? This has been about process, safeguards and novel technology.

As an IC you have some great and some terrible managers. You model what you think you should be, based on that history. And by the people you don’t want to be. What I figured out early-on was that autonomy is worth ALOT. The ability to have control over your working life and day. Autonomy, mastery, and purpose.

A way to express this is explicit stating team norms. Comms need to be kind, direct and prompt.

As a manager, your best people will leave you… and it’s good for them. The good news is that it’s a very small industry.

One thing that worked very well at Mozilla is this concept of “sponsorship”. They aren’t necessarily there to mentor for you, but rather an internal advocacy about how to move talent around into new challenges.

One of the important requirements for us to become a really Senior Engineer is to mentor others. I describe this as “the most important product of Sr Engineers is more Sr Engineers”.

As a manager I explicitly say to people “I’m going to give you more things and harder things, and your job is to tell me to stop…” It’s like eating at a Brazilian Steakhouse, you have to turn your red-card over when you’re full.

When things are not going so well, that can take a few forms. I’m talking about when someone has been awesome, and they stop being awesome. Could be fine, to not fine. Often it’s personal, life-happens, their output is going to suck.

Sometimes people have been doing the same thing for so long, they’ve stopped growing, or just full-on burnout. It’s vital to have a conversation about it, and understand the causes. You can deal with this by encouraging time off, even a month sabbatical. Often when people come back, you give them something completely different to work on.

Sometimes with underperforming individuals, it’s because the job was not hard enough. Unchallenged individuals are usually bright people who found school easier. It’s worth saying “hey, I want to give you something more difficult to do…”. A lot of people really rise to this occasion.

David Subar @dsubar— Consulting Chief Product Officer / Chief Technology Officer
Listen to the full interview

Started in R&D in AI and Machine Learning.

Got interested in “how does technology change lives?”. Going from research to shipping product was a fundamental point in my career.

Was CTO at many companies, then jumped over to the product focus. By running product and engineering, I had both the “what”, and the “how”.

This factors into who do we hire, how do we organize, and how do we really product value.

People have this decision to make, “engineering or management?”. As a geek, I loved technology, but didn’t want to have to keep my hands on the keyboard?

Hard lessons to learn were: how do you communicate timelines? how do you understand timelines? how do you communicate what results are important? how do you get alignment with the rest of the company? how do they see you producing value? have the conversations with executives about “what can you do next year to do even more with your team?”

How do you create the environment for the engineers and product management orgs that they are also on the same page?

In order to understand new technologies, it’s important to exercise them. I like to go and hack something out, so I can grok it. All code is short term, and there should be expectation that it’s all going to get thrown away. The measurement of “goodness” is “did we create something of value to someone, or further along that path…”. Build something quickly and expect to refactor along the way, all the time.

There’s an assumption that the executive management knows exactly what they want, which is equally as unreasonable as expecting engineers to provide precise estimates in how long things are going to take. It’s getting that empathy through the entire org, from execs down to engineers is key to getting these groups to work together well.

There are definitely big differences between a small team and large team. Based on how “hands on” can you get within the prod/eng org. How do they get to know you, how do you get to know them, how do you delivery information? Obviously it’s much easier for everyone to know each other, larger than 100 you’re really counting on managers to deliver the message, and feedback. What you’re taking about becomes REALLY important.

There are two versions of “small” and they are different. There’s “I work in a 7 person team in a large company” verses “I run a 7 person startup engineering team”. They way you manage smaller numbers of folks is very hands on, low latency, low bureaucracy, and optimized.

As it gets bigger > 15, now you have several teams and new levels of abstractions. It really starts to change past 25, 75, 125, it changes what you do, how you manage, and what you are looking at.

How do you fractalize it? How do you get the teams aligned in producing value as atomic units, without having to require much day-to-day interaction? The fundamental thing is to think about “how does goal setting happen?, how do results happen?”.

It’s the managers job to set some kind of goal state, and the fulfillment team get to ask a lot of hard questions. After a decision, it’s the execution team’s job is to say “how”, then it’s the managers job to ask them the hard questions. Now it’s time to get it done. It’s the managers job to then check in, and the team’s job to raise the impediments.

You want teams who understand what they’re supposed to get done, execute well, and have all the tools they need.

There is a joint responsibility to the person that wants to grow, and the manager. The ultimate responsibility is with that person, it’s up to the manager to know the people in their group, know where they want to get to, and find opportunities for them to learn these things within the organization. I’m not saying create an opportunity, it needs to align with what the company already needs. It’s a lot easier to accomplish this in a growing vs. a shrinking company.

Asking the individual hard questions about WHY they want to go there, and discuss if their aspirations get them to where they want to go. Feel free as a manager to question about what’s the next step and way.

It’s this alignment between the individual’s growth, the company’s needs present and future, and the individual’s overall goals which ties together continuous growth and the long-term career path.

Eric Herring @erickherring — Co-Founder / CTO Vynyl
Listen to the full interview

UT Arlington was a fine commuter school at the time. Worked for ◼︎ Next as Sales Engineer / Tech + sales role.

Was there when they “rebooted the Internet, due to the Morris worm”… Assembler, c, c++ very early on. Mako super computer…

Some of the people who used to work with me, will still talk to me. They don’t cross the street when they see me coming.

There’s a lot to be said for someone to teach you how to do executive management. I didn’t have that, and jumped right into the firing pan, and then the fire….. I was in possession in unearned confidence, and the burning desire not to let anyone down.

I left a company because I didn’t want the CEO abusing my people. When you’re going into a new job, you have to ask for the things that make your job truthful, ask for the transparency. As an exec, you need to construct an employment agreement that lets you tell the truth, and protect your people.

Did some security focused roles, CSO, Security Architect, but found I liked to say “yes” and build things, vs. the “saying no” of security.

All that matters is getting the best people, and keeping them happy.

The last person we had to let go, was hard because they were a good social member of the team, but it was an easy conversation because I asked him “what do you want to do?”, and they said “I think I need to leave.”. Sometimes the truth is right out there and you just need to have the convo.

*) I do my very best to find good projects, and to keep people moving from projects that have become muscle memory, onto challenging projects.

*) Core goals are quarterly, roughly relevant to our business, and to their professed path. There has to be some tangible proof at the end, but they must share the knowledge. And ideally shared via blog post, a lunch-and-learn, or some other preservable artifact.

*) I make time with each of the engineers. Paying attention to the things that people care about, and interacting with them and sharing your knowledge is an incredibly powerful routine.

In managing people, culture is not a thing that exists. It’s a name we give to a thing that exists. Culture is very much just what you do every day. When you incorporate the best of how others do things, into how you do things, that’s acculturation. If you’re not deciding what you’re going to do every day, in a way that promotes these shared values, then you’re not doing it right. If you go emergent, you’ll get something unplanned.

Everybody needs to remember to give themselves an extra degree of difficulty, when setting core values. To continue to get diversity of points of view.

Management is NOT a promotion. It’s a separate career path.

We’ve got people who are team leads, they write code every day, they review pull requests. They are sitting in the front seat of the boat, calling the cadence for everyone, but they are rowing themselves. Some of those people graduate… either to senior hardcore technical position, or they feel they can program bigger things by managing people. Those people go onto Directors of Eng, VPs of eng, and move to lead other orgs.

There are certain places where burnout is inherent. Eg: game development. Certain product orgs, are repeat offenders. Over promising on dates. Killing engineers to meet them. I am lucky to not have created such an environment. When I find myself in such an environment, I handle it by counseling the stakeholders.

Kicked, Bitten, and Scratched is a great book!

Pieter de Zwart @pieterdez — VP Engineering Nexstar Digital
Listen to the full interview

One particular example of seeing growth was “when I joined Rubicon, there was one person who joined with me at about the same time, but who had alot less experience than I did. He was younger, and I think this was his 1st or 2nd Company out of college. I quickly developed a really good rapport with him and as my career grew, I needed people who were going to help me do stuff.

So I said ‘I need you to start helping me with these things, and it’s not core engineering, not writing code on a daily basis’. Then once I figured these things out on my own, I’d actively remove myself from that basis and ask them “ok, I need you to figure this out too”, but I’d do it in a way to setup some guard-rails to make sure they don’t go off the edge.

My premise is (and I used to joke about this) that my goal after explaining to them “how to swim”, to throw people into the deep end of the pool and watch them sputter about and try to keep their head above the water. I’m always there, sitting there with a lifejacket, but I kinda want to see them do it. You can’t just talk to someone about you gotta see them do it.

So later on, that person who started as an individual contributor when I did, by the time I left he had caught up to in terms of growth and was one of my peers in the organization. That to me is probably one of the more rewarding parts of my job. Seeing someone who has the potential, and getting them that experience and putting them into the difficult positions and seeing them grow into it was a really cool part of my job.

At Rubicon, I very quickly realized that being a “manager of engineers” to a “manager of managers” was a very different thing all together.

…even people who outgrow this company become ambassadors and evangelize what happens in these four walls. It attracts others who see the growth and understand it’s a place where they would want to work.

While at Cisco at the behest of one of my advisors, who said that “our goal should be to join the largest possible company, then slowly go to smaller and smaller companies while also getting bigger and bigger titles until you get the title that you want. Then from there slowly go to bigger and bigger companies util you find that right sweet spot of the right title, the right level of responsibility, and the right company size that gives you that sense of confidence, and reward and engagement, and ability to impact change on your surrounding.”

One of my favorite jokes is “experience is that thing you get right after you need it”.

I got a piece of really good advice from a senior executive at Macromedia and he said ‘your job at any given point in time, is to try to replace yourself… because if you cannot replace yourself, you cannot grow into your next role.’

bethanye McKinney Blount @bethanye — Founder CEO Compaas,
Formerly: 2nd Life, Reddit, Facebook
Listen to the full interview

Came in in print design and production in TX. It became a lot easier to figure things out on my own, and got into the ops side of things; sysadmin, backend integrations….

I can field strip an Silicon Graphics Origin 2000! (lots of pulling wires)

Came to Berkeley to work in “product” at 2nd Life. It was the weirdest company I’ve every seen, and either it’s going to take over the world, or fail spectacularly.

Went over to “ops” as the glue between my team and rest of company, because of the many frustrations of growing tech startups. Wound up as an Engineering Director overseeing anything that interacted externally. Website, eCommerce, financial economy, APIs …

Intra-preneuering at EMI music as VP of Engineering.

Sold a startup to Facebook and worked for years on complicated infrastructure projects, data centers, security, disaster recovery. Worked in production engineering. Problems that were so gnarly and amorphous… BUT.. going to kill the company, THAT was my sweet spot.

Current company “Compass” does compensation-as-a-service, providing HR-tech and a platform that helps companies make better decisions about how they are paying employees.

I believe it’s our responsibility as a manager to envision a more bad-ass version of every person who works for us. It’s one of my defining principles as a manager, so it’s always in the front of my mind.

In terms of lagging vs. leading promotions. Eg: when you do the new role first, then you are awarded the title eventually. vs. the old-school of being promoted, THEN being expected to do it. I believe you embrace the risk and take it together, so I like to tend towards leading promotions because it provides a greater opportunity, assuming both parties have opted in.

When it comes to helping someone out who wants to level up, but you as a Manager do not have a role for them: first you optimize for the individual, then the company, then the team, then yourself. Supporting people is the most important thing to keep your company strong and grow.

Sergey Sundukovsky @ssunduko — Co-Founder, CPO and CTO Certemy
Listen to the full interview

So what’s interesting about my career is that I started with the smaller companies, and then over time I went for bigger and bigger companies until I got to Disney, then from there went back to smaller and smaller companies….

One of the biggest misnomers in the industry, is the divisions between jr, mid and sr engineers. I divide that into 10 different levels. There’s 3–4 levels from Jr to Mid, then from Mid to Sr eng. Can somebody be given a business problem without supervision? Eg: here’s somebody who needs to be told what to do, how to do it, and needs to be checked.

It’s interesting that you come out of college, not as an engineer, but as a computer scientist. You’ll know more about hardcore comp sci, O(n) more than your peers, and you will become a better and better software engineer over time, and a worse computer scientist…. Because software engineering holistically is not taught in college. So that’s where the engineering is, it’s at the level 10. You start out knowing to how to write a bubble sort, but not how to implement something useful that can be integrated into a system and deliver business value.

So from the point I interview someone, I need to assess them on that 1–10 scale and say “ok you are HERE, this is what your growth looks like…” and that type of path takes easily 5–7–10 years to become the best engineer you possibly can be. Then from there you’re going to begin to sacrifice technical expertise as you move into learning business or management roles.

Besides the growth tactics of attend a conference, take a class, attend a meetup, I like to showcase the ICs work with show-n-tells, as it’s a great forcing function to share the knowledge, get peer review, and pressure tested by others.

In terms of broader growth goals we have opportunities to present at the Company’s quarterly meeting, either with a particularly cool technology, or a case of business learning, This helps engineers find their voice and put things into business AND technical speak. This helps them get out of their shell, and hopefully provide the needed fermentation within development teams.

Another thing I do is split the work between core development and rapid development. Core dev happens on a quarterly basis, and rapid on a weekly basis. I rotate the membership between teams often, so that they don’t become stale and so that they keep learning.

How do you scale it?

One of the strategies to manage growth, is to say we’re not going to let the company grow bigger than 150–200 people. After that you need a large layer of middle layer management, and some destructive politics can creep in.

It’s impossible to just stunt the growth of the company at 200, so how do you do this? Eg: Amazon and Google have some methods to their madness in terms of their division. Basically organize it by contract and treat them as their own P&Ls, each part is it’s own startup on its own. A small group of people 200 or less, they need to bring value to the company, their contract needs very clear inputs and outputs. It’s very verticalized, not excessively layered. When Amazon acquires a company, they keep its autonomy. They just keep the value contract in pace and do not need to blend into an overly hierarchical parent company.

Other organizations setup innovation labs or used “outsourced innovation”, which makes the employees feel like the weight of the org is not entirely on their shoulders. This plus having many smaller flatter org structures allows companies to scale without too much middle tier management and have large org that don’t feel like large orgs.

In terms of looking a the notion of technical debt, I also define organizational debt as well which accrues both in terms of IC career management, and in terms of poor processes. Every so often, you recognize the debt payments, otherwise you’re going be in trouble.

Just as we have “feature holidays” and pay down technical debt, org debt can be payed down in a number of ways: 1) It’s done in terms of planning, and I almost never impose any deadlines. These are imposed by the developers themselves. And 2) I organize the teams around the clock, so there’s never the case where a single team is burned out. Development occurs on a 24 hr basis and there’s a redundancy. If there are any issues, the overseas team takes over and gives rest.

On the worst candidate experience, I interviewed at a company, and they asked me to reverse it. I said, that’s easy, you just call .reverse() on it. They said no, no, no, YOU need to reverse it… so I wrote a program to reverse it… then after the interview they wrote me an offer and I declined because I said “I don’t want to reverse arrays for a living”. They said, “no, no, no, you’re not going to do that here…”, and I said “then ASK me about the things I’m going to need to do, and I passed.”

I imagine a CTO like the surgeon at the hospital. If you look at them, it’s never one person it’s a team, there’s a complex set of tasks that they can’t do themselves, and many specialties.

They can’t be the anesthesiologist at the same time, and when the hospital admin comes to them as the proverbial CEO, they can’t say we’re using too much soap …. it’s up to the surgeon to push back and say “NO, I can’t do that, I’m gonna start killing people”. That’s my definition of a CTO, it’s not somebody who’s observing the surgery from the outside, it’s someone who’s doing the surgery and someone who understands the kinds of things that start killing people.

Josh Nisenson @josh803316 — SVP Engineering, VideoAmp
Listen to the full interview

Josh is the “Four Leaf Clover” everywhere he has worked.. because pretty much every place has been was acquired!

Started out career with a strong QA background, and on the theory and quality of software and testing. Found early in career that I hated management, because all of the conflict, and meetings, and daily issues.

Found to love management working for Brightroll. Growing people, their career trajectory, career decisions, 1:1s, talking with all the other managers and leaders in learning to resolve conflict, how to iterate as fast as we could, make decisions quickly, how to organize engineering groups and teams, and cross functional team disciplines and guilds.

Then more advance hiring and candidate experiences and optimizing internal talent, on-boarding, and hiring processes. Working with internal talent teams. When asked about hiring process, evaluating all the little steps, first contact, first call, code sim, how you run the onsite, how you test for culture, how you follow up, and how fast you do those things…
So focusing on these things got me super into management.

Early on, growth was more about assigning different kinds of work to people. Which expanded the coverage area, and was a tad “selfish” because it protects the team. As time went on, you start to realize as a manager that most of your value for the people working for the company is relationship building. And through all this listening, there’s a lot of common themes. Eg:
How do I grow my career?
What do I look for?
How do I upscale myself?

You REALLY want to look for people who say later on in their life “Hey, I’m really glad I worked with THAT person”.

One thing I started to do, is I started to say “hey, lets work together on a plan” with every individual. Write it down, and check in 6mons later. A course, ebooks, other learnings…

Some people like to build NEW things for customers, bring features to market that are revenue bearing, I can see data on the use and the value. People want the most impact, and some are into innovation, open source, tech innovation, etc… These two types are often different.

1:1s are the backbone of management. Having structure around that, and leading questions, and feeling where they are feeling the greatest impact or success, and where their greatest difficulties are. Based on 1:1s it’s about action and action plans. Given the info we just shared, THIS is how we’re going to operate to get you to where you want to go, and ALSO where the company needs to get to. Then you need to talk across leadership, and share outcomes from 1;1s, so that we can see the common themes, and adjust accordingly.

One prime outcome from that was on-boarding. We found that many of our 1:1s said we could get better at bringing on new people. We made it a goal across the org to make that more efficient, and that every new employee got something into production by the end of the week. Then we’d measure that process, and ask them questions “how did it go? Who was your “buddy”? … and refine that process. Because the faster you onboard new people, the more efficient the org remains.

In pathing and growth, how can I take YOUR skills and transmit those skills to OTHERS on the team? You become and upscale agent, as an IC. There’s always new people coming in, and the faster you can get people performing better.

How do you help impact the org by taking on challenges, which have not specifically been told to you. You can impact the org in a MASSIVE way by just seeing a problem and solving it.

1:1s, action plans, teaching people about the impact they can have, and talking to them about the skills they are interested in learning.

I’ll act as a reference for you from THIS company, when you go to interview at another company.

Lane Campbell @lanec — CEO Accredited Health
Listen to the full interview

I think empathy goes along way in leadership, understanding what other people on your team home to achieve and learn. Kindness, mutual respect. We all learn through out our lives how to be better leaders.

Growth, continuing education, training, certifications, there’s a lot of different ways to bring even junior talent upwards, and finding senior talent who likes to mentor and filling out an entire environment and culture where theres respect and understanding for the work that needs to get done.

Bob Martin BOOKS: Clean Coder, THE Clean Coder

There’s a book called “How Google Works” which talks about classifying different types of folks. Some people are more orientated towards drama, or creating a bit of a “difficult” work environment. They say, these are very difficult people to work with, but they are the highest performing in the business. The biz has some difficult performing with the broader culture. Some companies want people who will fall in line a little better. But would you not hire Steve Jobs?

No matter what you do, people are going to eventually leave your company. With the challenge in attracting talent, people are much more likely to be referred to you through your past employees. Building that network where people WANT to refer talent back to you, is invaluable, you can’t even put a price tag on it. Foster talent, educate them, grow them, recognize they are probably going to need, and embrace that process. Losing great people is going to happen from time to time.

I’m not a really big believer in the current process for how people are hired. Resumes are broken, referrals can be broken, recruiters are broken. Google for “recruiters are….”

The worst candidate I ever hired came to the interview heavily intoxicated. Had a first-day employee come to work and immediately get arrested.

I’d rather have the first meeting in a coffee shop and not in the office, to chat out in the open in a different environment.

Erik Kellener @ekellener — Leadership Coach, Mgmt. Consultant & Advisor, Consulting CTO

Listen to the full interview

As a kid, I new what I wanted to do, started in middle-school on an Apple II, in the back of a math class. A year later my Dad brought home a TI-80 and we played chess on it all day.

After I had been in engineering for a while, I had an incredibly supportive head of engineering, and he asked me “do you want to take my role?”. Which surprised me, in my views of corporate environments. Here as an altruistic perspective of someone who believed in me. That blew me away. This concept of selflessness was something that was framed for me.

A challenge I have is called “letting go of the keyboard”. I’ve been trained in this craft of software engineering, and now I realize that if I want to be an effective manager, I will not spend much time in front of the keyboard writing code.

It’s kinda like pulling an organ out of yourself and filling it with something else. And I struggled with this for a while, and wondering “can I could ever go back?”

I look a growth in terms of scope and impact. It’s a 2d matrix of both things.

Now I’m consulting as a CTO and Leadership Coach. Being focusing on moving away from titles and more to roles. Where individuals participate with multiple roles, and levels of expertise within these roles. The first step is developing role clarity. What do they need, what does the org need? And how well are they performing at these roles?

I had an engineer who was highly introverted, didn’t like to get up and present and build vision. But he loved working with junior engineers and interns. He saw THAT was were his superpower was.

One thing I recognized as the scope of the teams I managed grew, so did the type of communications I had, and the types of words I chose. When you have a small team, it’s 1 layer, with 2–3 layers of comms, there is a strong possibility of miscommunication.

Another thing I learned was how to influence how delegation happens in an org, and how to get good at it. So it was communication and delegation when I was managing managers.

A tool that I use to highlight high performing individuals is called Succession Planning. 9-Box. It’s a great tool to look at your org or your team, relative to each other. You map out performance and potential axes, and look for the folks in the top right, high potential and high performing.

You don’t just want to create a healthy culture. You want to create an environment where good culture can happen.

When I’m interviewing someone, I look for curiosity. If they don’t understand something in an interview, are they willing to ask questions.

John Shiple @FreelanceCTO
Listen to the full interview

Book: Rich Dad Poor Dad — Own your destiny

Looking inward is very very difficult, its important to visit all your plans, the people around you.

Cross training is super important to learn as many diverse sets of skills across many disciplines.

During out scaling at BigStep, we got to the point where we had 30 Rock Stars. It’s like the Grammys or Rock-n-roll hall of fame where all these personalities are on stage, people are NOT going to buy that record. So I like “symphony”.

With 30 of them in the room, things started to not get done, arguments, QA goes to war with UX, filling each other’s bugs, etc…. So we moved to a symphony model. Maybe you bring in an expert like YoYo Ma for a solo, etc… you can be the best you can be, but there’s still a conductor.

Mark McEachran @MarkMcEachran — VP Product Nexstar Digital
Listen to the full interview

SO it’s 2002 and I have no job, and nobody is hiring, and so there’s no nothing, no investment in Internet. 9/11 just happened and everything was withdrawn from business investment in “The Great Withdrawal”, So what do you do as an entrepreneur? I started another company…

It’s important to know that you have social skills, in-as-much-as you understand the languages you know, or how deep you go in a key-value store… I also want to know where you soft skills like, where your social skills lie… that’s AS important when you’re building out a team, or have team members. You need a full spectrum of people that vary.

Mentoring has been very much on my mind. I’ve seen a lack in mentorship among my peer groups at big companies. It’s been terribly disappointing. … When I come into an org, I’m not as concerned about making it org-wide. My approach is always to take it upon myself to mentor my team, and those around me, and try to present the mentorship whenever possible. You DO want it known that you’ve taken your whole team under your wing.

In my project management space, most of the time the folks want to become manager of a team. They went from eng to prod to be more interactive with people. If this is the case, I work to start building their team with them. To the point where I make an attempt to step out of the way, and take charge of the product that I’m responsible for.

Brian Leonard @bleonard — Technical Co-Founder / CTO Task Rabbit
Listen to the full interview

Recommends internships!

“If everything’s green in the test suite, then everything’s alright, right?”

One of the biggest journey was one of our interns at Task Rabbit, we ended up hiring 4 French intern engineers, which was half the team. And it didn't’ work well to just let them work on whatever they wanted, but I didn’t have the time to help scope out a project for them. So we very quickly got them in the critical path flow, and on core projects. 2 of those we hired and both were with us for 4+ years after their internships. Ruby to start, then iOS engineer, a react native project, and transformed their interests going from Intern to a Senior Engineer.

We had people speaking at conferences, and writing blogs, and getting prominence in the community, also Lunch and Learn or “Learnch” and they would teach about wildcard topics, and tech topics and new fronts.

We also posted our architecture to our engineering blogs , and really helped with on-boarding. So for a while we had the same blog platform used internally, and people were willing to do more documentation, when they approached it as a blog post. Because they weren’t committing to keeping it up forever and ever. Since it had a perma-timestamp. Some of those went from internal to external.

How did your focus change at acquisition? We went from 12 to 30+ engineers, and I was still code pairing with the team, and building… 2 years later we now have 7:1 ratio, and have scale the team into pods, all reporting to a manager, and with 5 managers and a director and the VP and me. Alot of those managers are playing the Player Coach role.

How do you maintain the mojo as you’re growing? Finding a great VPE made all the difference to get that Yin/Yang. As we scaled, and more than ½ the team has been there less than 1 year.

Forming, Storming, Norming, Performing framework. Where each team recreates their norms, every time that a new person joins the team which causes a lot of storming. Weekly, monthly, etc… New norms are continuously being created as you’re scaling fast. Each team gets their own norms, and the best bubble up to the other ones within the org.

Dave Arthurs @arthurs_david — CTO / Co-Founder Fishbowl, formerly SVP OpenTable
Listen to the full interview

After the dot.com bust, we started a new company and I went from a VP of Engineering of 60 people, then down to a startup where I was “everything of one”. Set a lot of standards, and did many firsts in our industry.

Some of the best people who become managers, don’t ask for it, they get asked to do it. Often times they look at their own performance critically enough, they may not feel that they deserve it. With the Spotify it allowed people to matriculate through, and to groom those people. Of all the people I finished with, only one was hired from the outside, the other ⅚ were matriculated as managers in that environment.

When we had “regrettable attrition” it was 85% due to poor management, so it would become a PIP and the individual had an opportunity to go back to engineering.

The CEO at OpenTable had a very clear ladder for career path, as you move up the management levels, your AORs increases from you and your team, to the group, to the company, you and outside the company. Basically “where is your engagement contribution to the company”.

Team lead, is your immediate team, and getting all the work done at the elemental level. On the VP the other extreme, your responsible for partnerships, contracts, speaking at conferences, working with business owners, peers, people development in your directs. Inward to outward focus. That was our focus for leadership within the company.

It’s all about how do you understand the Candidate’s motivations why they are leaving and what they are looking for, you gotta understand their motivation and make challenges to them on the way in, for other positions up the ladder.

Matt Nunogawa @amattn — Interim VP Engineering
Listen to the full interview

There’s different types of languages and ways of doing things, but you’ll always need managers.

Many of the common practices in engineering hiring are actually bunk. They’re common but not amazing, just thinking how to hire from an engineering perspective, what are the metrics, what are the things that matter, how to remove false negatives and false positives.

As a manager it’s not about the work that YOU do any more, it’s about the work other people do, and the people you bring in, and the work that they do. And that was a shock…

Mastery is part of your job, I expect everybody here to get better at something. And for engineers it not just coding, could be public speaking, writing, presentations, giving and receiving feedback. MOST do involve tech, and you should be embarrassed from your code 6 months ago… that’s normal and good, and a sure sign that you’re growing.

It gets harder at a Senior level, the levels get harder each time, the opportunities are more difficult, you have to impact a larger number of people or surface area .

By mandating growth as a function of your success, I expect both YOU to grow, AND the people around you. You don’t get to advance, unless you are elevating the team around you.

If we’ve got a promotion cycle coming up, in a month or two, it’s too late to advise an IC about what they need to do. You need to start like a year in advance. I expect that IC to be performing at a higher level already, once they get promoted.

When I move someone into management, I use a dotted line approach. Even though their first 2 reports report to me, there’s a dotted line on the org chart. The new manager gets started with 1:1s, the feedback, all the ceremonies.

Emad Georgy @EmadGeorgy — Consulting CTO & Advisor
Listen to the full interview

There are decisions you make early on in a company that impact the durability of your applications. There’s a series of small decisions over time that are not immediately visible.

What we don’t talk about more is “Leadership Debt”, in that scaling teams, you really want to be aware of the decisions you are making that impact the long-term durability of your team.

I have a 1:1 with every person on my team, no matter how large it is. Even if it takes 2+ weeks every time. Get to KNOW your people. Understand the reality.

One of the things that builds teams is deliberately not changing anyone on the team, and seeing what we can do together once we have built trust. There are hidden gems in every org, people who just need a shot.

I don’t believe in time-based promotions. Only goal-based, and based on achieving the attributes for that next level. Understand your baseline, map to the next level, identify the gaps, and close those over a period of time. Companies either don’t define this at all, then it’s up to the opinion of your manager, and it hides the big picture view as a team if you don’t carry forward this mindset.

I’ve built a Leadership Maturity Ladder program, customized to the Company, and this sets the stage for the progression. Some things required for a role has technical competence, some leadership behaviors, perhaps some management. This sets the baseline for every person at every level, identifies where they stand, and where they are going to close the gaps.

I keep detailed notes on every IC’s performance, and in our 1:1s I give them specific feedback from what I’ve personally observed. Don’t just say “great job team”…. make the acknowledgements very specific when giving praise.

You do the same thing monthly a 1:1 by checking in on a yearly career plan. Where do you stand on the leadership maturity matrix, and have a feedback loop against the plan from both sides. By the time the performance review comes around, there are zero surprises. It’s just a formality. Along the way, when opportunities arise, you can make the market and match the two.

Let’s talk about the values that make a good leader
1) a sense of ownership, team, self, the entire company. You’re a problem solver, not a problem reporter.
2) having an engineering mindset: technical chops, but also are you making hard decisions to improve the durability of the architecture over time?
3) knowledge by experience. We want leaders are operating from a place of first-hand experiences.

How do you operationalize this? For all teams that are doing retros, at the end they get to rate their leader against these values. How did You do on Ownership, Engineering Mindset, and Experiential knowledge? Bubble up to the CTO level and build a dashboard on all leaders in the org, this is just one thing you can measure. And from a single dashboard, you can SEE the trends across teams.

Dwamian Mcleish @dwamianm — Founder/CEO, Journely
Listen to the full interview

I’ve almost always found myself at the top of orgs, or the divisions of orgs I’ve been in. What’s been most meaningful in my journey has been understanding people.

We have a player-coach model, where you are skilled at the engineering or programming, and we wanted those managers of engineers to also be engineers.

Build up the people and provide good leadership to them, so they can understand where they fit within the org

Foster those disciplines that the org needed as we grew, and instilling QA and metrics, production pipeline metrics,

Frustrations stem from unmet expectations.

The willingness to learn is pretty important to me, along with willingness to teach. When interviewing candidates, I try to look for “is the candidate looking to join an org, and continue to push the limits of what they’ve already done in the past”.

One of the things we do in the interview process, we try to convince them not to work for us.

We used Elixr, which forced people to know functional programming. We used pair programming to encourage new engineers to adopt this programming paradigm. We created many opportunities in the process for people to explain why they do things, like peer-reviewed pull requests.

Alex Zub @azmorf — Co-Founder / CTO Handsome
Listen to the full interview

Grew up in Omsk, Siberia, Russia. Learned to code in a lab environment and at home. Started building sites of all types and doing full stack. Growing up we were very much self-driven.

All of my career has had no technical leader above me. We were implementing what we were learning into the work we chose to do.

I turned a remote group of freelancers into a local office in Omsk. Took Stratoplan.ru as a management training course.

I like to setup my team members are setup for success and have the right level of freedom, and the right level of supervision to course correct when needed.

One of the challenges of my career was building a team outside of the USA in Omsk. Quite a few things have changed over time, but the nature of the relationship and how we kept everyone well-engaged was to involve the engineering in as may of the phases as possible, and during on-site visits.

What the Omsk engineering team lacked the most was direct exposure to the other parts of the business. There was a lot of interest in people being closer to the design process, and being involved with it. Every software engineer (in my hometown) mostly come from dev shop experiences. What is a common experience among them is this “throw it over the wall” approach to design where they may get a design file and that’s it, they are off to the races. Far too often important questions about the design are neglected.

We’ve designed the process of product creation that includes every single member of the team, including engineers. And with remote engineering, it’s easy to forget them. So we use intentional work to build processes that include everybody.

Conversely, we include designers in the engineering process. This often yields better user experiences by creating these feedback loops.

For growth, we established a number of guidelines. As an agency, we need a wide array of capabilities. One of the org goals was “increasing the bus factor”, by having our team members cross-discipline train and learn many different skills. We preferred strong generalists… aka “T-shaped” expert, or my favorite “rake-shaped”. When we were hiring, we’d look for folks who wanted to are willing to be generalists, entrepreneurial, and business problem solves.

I try to get every one of my team members to get a mentor. Whether inside the company or external. I encourage them to go out to meet-ups, networking events, etc… so if you can’t find your mentor here, go find one!

We built a competency matrix, like a spreadsheet, to formalize what a Jr, Mid, Sr developer is, a principle developer, or technical director. The dimensions are: collaboration, team-work, technical breath, soft skills, conflict management, ability to prioritize, workload management, leadership skills, biz dev capabilities, interdisciplinary collaboration, and bill-ability. We fill out each of the cells, which sets the expectation with each of our roles. This gives an informed decision about to the people we interview, and what kind of role we should be interviewing for.

Amit Nayar @nayar_amit — VP Engineering, FloQast
Listen to the full interview

Cobol CI/CS on a mainframe was a foot in the door for me.

It’s an interesting challenge leading leaders. When you lead ICs you have near-real-time feedback. But with leading managers, your ROI and feedback loop becomes much longer.

With candidates, we always leave time at the end for questions, and give them an opportunity to interview US, it’s about gauging the fit in both directions.

Interesting questions from all levels often want to know about what’s the company trajectory, where’s the company going? What’s the vision? What’s the likelihood of success? Unpack the cultural philosophy? What’s the roadmap for engineering?

Growth is like an instrument, you can’t just sit down and be a virtuoso, you have to PRACTICE at everything.

Paul Mestemaker @PaulMest — Technical Co-Founder / CTO Circadian Risk
Listen to the full interview

Right now overseeing a 10 person org, primarily engineers at Circadian Risk.
Spun up a bunch of teams in SF for a long time before that. IC and Sr Program Manager at Microsoft, and learned:
‘I shouldn’t, nor should anyone else in my company need to play the “authority card” before moving forward. Every idea should move forward by it’s own merits. This is the root of how you should be as a manager.’

Really understanding people’s motivations is essential. With a junior engineer, they may not have thought about what they want to do in 5 or 10 years. Understanding what currently excites them is what you want to key into. Then pull them into higher level thinking, as to “what IS the next phase for you?” and navigate the multi-tract paths, eng, ops, leadership, management…

You have to differentiate between what they say they want to do, vs. what the really want to do. Also management is not really the ultimate path for everyone.

I’ve worked primarily remote for the past 5 years, and we’d have 1:1s on a weekly basis, and I’ve made the rule to my team that my directs get at least ½ hr of my time daily. This allows us to have a forum to sync on any technical issues, and address any other needed rituals. Once on-boarded, 30 mins / day is not needed. Then we talk on higher level items. At 90 days we have a reflection and take in all the feedback from team and management on the individual’s progress.

With startups there’s not always a defined career progression, but on some interval, 2–4x per year, there needs to be a reassessment of the direction we’re going both as Individuals and the Company.

It’s really important to figure out with each person, what makes them feel the best about themselves.

We have a Google Doc of “Helpful Training” with dozens of links to Youtube videos, and these helped with all kinds of topics: eg: “rebasing in git” …
Even with candidates who don’t succeed, we send them links out of this document.

Created the Today I Learned (TIL) channel in Slack.

From the interview phase, the first thing is “you can understand what’s expected in your current role, and you’re adding value as soon as possible”. By the end of the first quarter, you should be checking in towards this goal, along with where your path is heading.

If you made it this far… THANK YOU! By chatting with so many experienced and varied individuals, we had many wonderful discussions and heard many perspectives. The podcasts reveal much more than can be contained in Exec Summary and Gems. Please take the time to subscribe to the podcast, to hear all of these interviews.

I appreciate your feedback in the comments below, or @davegullo

#cto-interviews