Fifteen years ago, David Glick was happily at Amazon as a Junior IT Project Manager in the Systems Network Operations Center — until his manager told him to move on from the “dying field.”
Infrastructure was moving to AWS and Dave followed along to a new role as a software leader, with a chief responsibility of building Amazon’s pricing system for all first-party SKUs. This launched a decade of engineering leadership in fulfillment and in-house logistics at the tech giant.
Since his retirement in 2018, Dave eagerly un-retired (“Turns out, it’s kind of boring to be retired when all your friends are working!”) to join warehouse management startup Flexe as the CTO. He owns all product and technology at the Seattle-based company, expertly guided by his rich experience. Dave recently sat with Uplevel to share thoughts about empowering engineers, being authentic, and redefining technical debt.
What has been one of your greatest successes or something you’re most proud of as an engineering leader?
Automated pricing and automated ordering. We built these at Amazon and opened up the ability to scale, so that we didn’t have individual humans setting prices and ordering inventory. As part of that, Amazon has a concept of tenets. Every program needs to have a tenet or a set of tenets to start. I was the progenitor of tenets at Amazon. So I’m really proud of that.
In the fulfillment space, we integrated robots into the fulfillment centers and built an automated receive process using computer vision. We built Amazon Flex, which is a crowdsourced driver delivery program, and Amazon Logistics, which is now, arguably, the third biggest carrier in the world, just five or six years after we started. I’m proud to have been a part of all of those.
At Flexe, we’ve quadrupled revenue in the past two years, based on my ability to attract talent, to drive growth, and to build the features that are needed to open up our target addressable market. Those are all the output metrics that I’m proud of.
Lastly, of the people I’ve mentored, three have been promoted to VP and another three that are about to be promoted. Being able to develop an organization and watch people grow and thrive, and be part of their growth trajectory, is probably what I’m most proud of.
What has been one of your greatest challenges as an engineering leader over your career?
One of the challenges is that I don’t have a computer science degree. I never was a professional software developer. When my manager said that IT is dead and you need to move to software — well, the second half of that was that she said, “You don’t have a software degree, so I don’t see how you can lead software developers.” Fortunately, Suresh Kumar — who’s now the CTO at Walmart and was my mentor — said, “I’ve got a lot of people who can write code. I need people who can get stuff done.” I had never written software at a production level or an Amazon level. That was a challenge.
The second one is that I believe in being authentic. What I saw is the higher you get in the organization, the less authentic people are. They’re all about delivering messages: “How do I craft what I’m going to say based on the message I want to deliver?” I went from Director to VP. I think of myself as someone who’s down in the trenches, and is authentic, and is a friend of the people. At the VP level, you’re on stage, and you have to think a lot more about what you say. I led the All Hands meeting at Amazon for one quarter and there were 8,000 people in the audience. Every word was vetted by the PR team. That was antithetical to my wanting to be authentic.
And then, you know, we had to deliver big projects on short timelines and all those things, but that’s just Tuesday, right? That’s just what we get paid for.
How would you define engineering effectiveness?
We used to do a tech survey every year at Amazon — hundreds of questions. (Uplevel note: Don’t miss our talk with Voice of the Developer creator, Leah Melvoin.) I would think, how can I pay attention to hundreds of things? We would all look and think, “is my stuff more green than my peers?” To focus on what we really cared about, I’d boil it down:
(1) Are we empowering our people to do their jobs? Do we give them autonomy? I think autonomy and ownership are two sides of the same coin. If you take away people’s autonomy or ownership, they’re going to hate it. So that’s most important.
(2) Are we giving engineers the ability to reduce their operational load? Engineers hate doing stupid things over and over again. And the only people who can get the engineers out of operational load is the engineers. They have to do things differently. We, as leaders, have to make space for them to do that. We have to empower them to say, “We could have done this half-assed, but we’re going to take three extra weeks to do it the right way.”
What are some signals you use to know that your team is effective?
When I joined Flexe, all the engineers were unhappy. They said, “No one listens to us. We don’t get to work on our technical debt. We’re just chasing revenue.” I said, “Actually, that’s a feature, not a bug. Chasing revenue is our job. However, we do not want you to feel like you’re just building technical debt.”
On a relevant note, Charlie Bell from AWS hated the term “technical debt.” It’s imprecise. What do we mean by technical debt? Do we have too many tickets? Is something unscalable? Does it need to be scalable? I tell my teams to bring me a plan that delivers this feature for our customer, but bring me a plan that lets you do that and refactor. If it costs us a couple weeks, I will approve it.
Engineers blame a lot on “senior leadership.” When I realized I was senior leadership, I encouraged them to bring me a plan. If you think that senior leadership is telling you to do the wrong thing, stop doing it, put your pencils down, come to my office, and let’s have a discussion. If they didn’t come with a plan, I’d say “Until you bring me a plan to do this better, do this instead.” People didn’t always come with a plan, but they stopped complaining about it, and they felt more empowered to do so.
It comes back to empowerment. The last thing you want is for your engineers to do exactly what you tell them to do. That flipped a switch in my head.
What’s your best advice for an engineer being promoted into their first management role?
I wrote a post on this, actually. It boils down to one piece of advice: Solve problems for your boss. Period. Find out what your boss’s biggest problem is, and solve it. And then find out what the next one is, and solve that. I got lots of feedback that you should be focused on the customer. Very simply, you will never go wrong in solving problems for your boss. Hopefully, your boss and your customer are aligned. (If they’re not, you should go see a different boss!)
My second piece of advice: The answer is always who, not what. Problems get solved by people working on them. Either those people are on your team, and you can assign them, or they’re not on your team yet, and you need to hire them. The difference between people who scale and people who don’t scale is how good they are at hiring.
I credit this framework to Kim Rachmeler, my former boss that pushed me from IT to software: Product, Process, People. When you’re a junior engineer, the value you bring is the product you produce. When you’re a first or second-line manager, you’re building processes, which help the engineers be more successful. You’re doing operational excellence reviews and building sprint roadmaps. When you get to Director or VP, it’s all about people. Your job is to find great talent and hire them. (Or, your job is to find poor talent and fire them.)
As you think of your role in aligning to business objectives, what have you found most helpful in communicating risk or status upwards?
There’s one thing we know: a leading indicator of on-time delivery of projects is whether people are actually working on them. Steve McConnell, who wrote Code Complete and consulted for Amazon in 2003, had the engineers roughly track their hours each week — time spent writing coding, time spent in meetings, etc. We found amazing things. We had five engineers assigned to a project, but it turned out that zero were working on it (for various reasons). It looked like that project would be progressing, but it wasn’t.
Another aspect is recruitment. We had a problem at Flexe where the recruiting team had a goal to hire 73 people in the first quarter, of which 17 were engineers. At a certain point, they had hired 63 of those 73 — and few of them were engineers. If you get to 63 out of 73, and the 10 you didn’t hire were engineers, none of us are going to be happy. We got some of what we needed, but none of those people could come in and write code on day one. It’s that type of metrics — sophisticated metrics that inform the nuance of what you’re trying to do — that is most helpful. I have to communicate nuance in “tech” or “engineering” to leadership. They get lumped together, but each role has a unique responsibility and the organization needs the variety of roles.
Reflecting on your past experiences, what data have you found most valuable to help you manage an engineering organization? Are there any hard metrics you have found to be useful in managing your teams?
I think about input metrics versus output metrics. Since I was the pricing guy at Amazon, I thought about how traditional retail looks at revenue and profit. I can’t affect revenue or profit! There’s no lever I can pull that says, I want to do this, and it’s going to give me more revenue. What I can do is affect inputs to revenue: pricing, selection (number of SKUs), faster delivery. Then, what we can do as leaders is allow our team to be single-threaded. Instead of multitasking, you’re unitasking.
On a closing note, when I was promoted to VP at Amazon, I knew it’d be the last promotion I got there. There were so many VPs and only so many SVPs. At that point, you have to change your motivation. So I came up with VP life tenets: Mind your happiness. Mind your health. Mind your financial situation. Help other people.
Dave Glick is CTO of Flexe, a disruptor in the $1.4 trillion logistics and supply chain industry. You can find his musings on blogs, podcasts, and LinkedIn.