Treehouse for Teams
writes on August 26, 2018
“We will never — and never have to — sacrifice business objectives to achieve a diversity goal. Likewise, no one should ever feel like they have to sacrifice a fair and inclusive working environment or hiring process to achieve a business goal. They are co-equal goals and they can absolutely be achieved together.”
Today on Engineering People:
Zak Stengel is the SVP of Engineering at The Trade Desk, a global technology company that provides a platform for advertisers to reach target audiences across any device in real time. Since 2013, Zak has led their engineering team through massive growth — from a single team of eight people to a global organization of nearly 200 employees working in 12 offices across North America, Europe and the Asian Pacific. In this time, the team has driven a technological expansion to a scaled platform that now services more queries than searches by Google, tweets by Twitter and snaps by Snapchat – combined.
Zak is most proud of the fact that this has all been achieved while maintaining an agile culture based on trust, connection and empathy, where every team member works closely across geographic and functional lines to ship product to clients every single week.
Depending on how you count, Zak has between 15 and 30 years of experience as a professional software developer and technology leader. He holds a Bachelor’s Degree in Religious Studies and a Master’s Degree in Computer Science from the University of California, Santa Barbara. Throughout his career, he has always been the happiest when he is making others better.
(Original episode released on August 26, 2018)
Show notes:
Zak on LinkedIn
Zak on Twitter
Transcript, edited for clarity:
Ryan Carson: Welcome to Engineering People, the show where we interview the world’s leading engineering managers to learn from their stories and their experience.
In case you haven’t heard of Treehouse, we’re an online school that has taught over 850,000 adults how to code, and if you’re looking how to hit your hiring plan and create a diverse team, just give us a shout at teamtreehouse.com/go/talentpath. Let’s get to the show!
Today, we’re joined by Zak Stengel from The Trade Desk. Thanks so much for hanging out.
Zak Stengel: Yeah, it’s a pleasure to be here.
Ryan Carson: It’s good to have you on the show. So that our audience gets to know you a little better, please tell us your title and then all about The Trade Desk.
Zak Stengel: Sure. My title is SVP of Engineering and, at a high level, The Trade Desk is a global technology company that provides a platform for advertisers to reach their target audience across any device, anywhere in the world, in real time.
Ryan Carson: Awesome. I geek out on org structures, so tell us about your org structure and how you fit in it.
Zak Stengel: I lead the entire software development team. Anyone who contributes code to our platform or is responsible for its operational health reports up through me, and I report to our CTO and co-founder, Dave Pickles.
Ryan Carson: Awesome. Great. And, tell us what are your colleagues in your org?
Zak Stengel: My peers are head of product, our VP of Corporate Operations, our Head of Integration and our support team — all of those teams are considered our technical org and they all report up through our CTO.
Ryan Carson: How large is your total engineering org underneath you?
Zak Stengel: I have nine direct reports, but the full org is just about 200 developers.
Rebelling from studying Computer Science by majoring in Religious Studies
Ryan Carson: I would love to dig straight into stories of your career, as an SVP of a large organization. I think, for listeners, it sounds intimidating — like you just always had it figured out. Tell us a story about your career progression that might encourage or shed some light on how you did it.
Zak Stengel: Sure, I took a little bit of a circuitous route to being an engineer and being an engineering leader. I was always a technical kid when I was younger, with tearing apart and putting together computers from a really early age, but when I got to college I decided that, because I didn’t rebel a lot as a young teenager, my act of rebellion was to not study engineering or computer science, like everyone expected me to. Because, it was my, “You don’t know me,” kind of moment. I ended up falling in love with Religious Studies, actually, just through a random course I took my first quarter of my freshman year. That’s what I got my undergraduate degree in.
Ryan Carson: That is not computer science, you’re right.
Zak Stengel: It is not computer science. I spent the first year out of college actually working as a pastor at a church.
Ryan Carson: No way! I was going to be a pastor, so maybe we should talk about that sometime.
Zak Stengel: After a year, that church ended up closing and I was out of a job. I really thought, on a whim, “I wonder if I can get a job working with computers.” Because I had done some side programming projects throughout college, and I was like, “I kind of enjoyed it. I wonder if I can get a job?” I ended up just finding the perfect job for someone with my background — sort of a hybrid role between customer support and quality assurance. That was my step in the door and that also gave me full access to the source code for the product that we build, and I just started studying that. Eventually, taught myself how to truly program as a professional software developer, learned enough eventually to get into a Masters program for Computer Science. I got my Masters Degree.
Ryan Carson: Did you have to first get your Bachelor’s?
Zak Stengel: No. I took a few undergraduate courses in preparation for that application and then took the GRE, but just went straight into that program.
Ryan Carson: Gosh, you gave me chills because you are the success story. You didn’t study computer science in college — you studied a completely unrelated topic, you didn’t get a tech job out of college and then you got in the door through QA support — and now you’re an SVP of a large organization. That’s so encouraging.
Zak Stengel: Yeah. I did not plan it this way at all, but I think my undergraduate degree in Religious Studies prepared me better for even a career as a software engineer — especially as an engineering manager — than I think an undergraduate degree in Computer Science would have.
The two most important things about engineering and management
Ryan Carson: If you could go back to the young Zak, grab him around the shoulders and say, “Hey, you should know these two things.” What would they be?
Zak Stengel: Where my mind goes first is, lessons to a young manager Zak, because that’s where I feel I learned my hardest lessons. The first one, which is something I really wish I had internalized earlier in my career as a manager — and if I’m honest I wish I internalized more even right now — is that it’s not about you. Sometimes, people think that being a manager is about being in charge or making the right decision all the time. And, of course, there are times where you will have to make a final and sometimes hard decision, but more so than being great at making decisions, I think a great manager is great at making decision makers more than being a problem solver. Your role is to build problem solvers. That’s something I’m constantly trying to remind myself of.
Ryan Carson: Right, so it’s not about you. That’s lesson one.
Zak Stengel: It’s not about you. The second thing, which I think I have internalized but I am constantly working to get better at, is that a manager’s core skillset is trust building. You don’t need to be the best engineer to be a great engineering manager, but you do have to be the best on your team at building trust. That’s the first thing that we look for when we’re hiring or transitioning anyone into a management role.
Ryan Carson: Gosh, oh boy. You’re speaking truth because I learned that lesson the real hard way. For years, I thought it was about being a compelling leader or a decisive leader, or all these things, then I realized it was all about trust because, no one can do anything unless you build trust. We use a book and a system called The Speed of Trust, just to help us do that here. What would be something tactical our listeners could do to build trust?
Zak Stengel: I’ll talk first at maybe a higher more strategic level. I think what we have done to build trust is to put in place mechanisms and procedures and process that helps to build connection and empathy. One example of that is our development organization is really spread out. It’s highly geo-distributed. We’ve got developers in 12 different offices across the United States, the UK and Asia. We have worked really hard to break down any kind of geographic silos, because one of the benefits of hiring in so many different places is that we hire people from many different diverse backgrounds but all of that diversity would go to waste if we didn’t have in place mechanisms for those people with diverse experiences to add value to one another.
Vital work lessons learned by getting fired from a bank job at age 11
Ryan Carson: So, again in the spirit of making you accessible, which you’ve already done, but I would just love to hear, if you want to share your worst or most interesting job you’ve ever had. [laughter]
Zak Stengel: My first actual job where I was paid by someone other than my parents, was when I was 11 years old. Somehow — I am not sure how, because I’m sure it violated some child labor law — a family member of mine got me a job at a bank.
Ryan Carson: No way. At 11?
Zak Stengel: At 11, which might sound super impressive until I tell you that my job was to sit in an un-air-conditioned closet during the summer and shred an endless mountain of paper.
Ryan Carson: This has to be illegal. [laughter]
Zak Stengel: Yeah, this has to be illegal, right? I was breathing paper dust. I was so bad at it that I actually got fired, as an 11 year old, by a member of my own family. [laughter]
Ryan Carson: That’s terrible. How do you be bad at that, just not do it?
Zak Stengel: My mind just kept kind of wandering to the contents of the paper that I was shredding and 20 minutes would pass while I was trying to figure out the story of a page of a ledger, without actually shredding anything.
This taught me, actually, really two important early lessons in my career: The first is the importance of contribution. It doesn’t matter who you know or how much potential you have. Ultimately, you have to produce. The second thing that it taught me is a lesson about motivation. Mostly that money isn’t a great one. I was paid minimum wage, which was a fortune for an 11 year old, but there is no amount of money that bank could have paid me to make me meaningfully better at that job.
Ryan Carson: Right. That’s so great. Wow. Okay, so we’ve had some hilarious jobs that people have listed, but shredding paper in a closet at age 11, that takes the cake. And, getting fired, that’s even more.
Zak Stengel: And getting fired.
Distributed scrum teams: How to prevent geographic silos and their culture of contempt
Ryan Carson: Let’s dive into some of the nitty gritty on managing engineers. I’ve been reading a lot about Spotify’s “tribe and squad” method. What do you think about that? What type of structure do you use at The Trade Desk?
Zak Stengel: It’s really interesting that you mention Spotify, because there’s actually things that we have borrowed from their playbook. I’ll talk first about our general organizational structure. We are split up into about 20 different scrum teams, which are all mission focused, generally product focused. That’s very deliberate instead of, for example, organizing around components. There’s a lot of reasons why we’ve chosen to do it that way. That’s one of the key aspects of our organizational structure.
The other key attribute of how we’ve organized is that each of our scrum teams is deliberately and explicitly cross-geography. There is no one team that’s in any one location. This, more than anything else, is what has made our culture work, at scale, across so many different regions and even time zones.
Ryan Carson: Right, so the team is always distributed?
Zak Stengel: Always distributed, yeah. We are distributed first. That phenomenon which I’m sure you and many of your listeners have experienced, where you dial into a meeting where everyone is around a table on a white board that you can’t see and you can barely hear anyone in the room, and your ability to participate is very limited. That just never happens here, because everyone is communicating across geographic boundaries all of the time, day in and day out. The most important thing that gives us is, it is just impossible for geographic silos to get established, so there is this phenomenon of contempt that floods in when you don’t have connection and empathy. It would be really easy for the Ventura, CA team of developers that we have to say, “Those developers in Boulder, they don’t know what they’re doing.” That is just impossible at The Trade Desk, because you’re working with those people, day in and day out, in the trenches. You know them. You know what their problems are and challenges are. That’s a really important part of how we’ve organized.
Ryan Carson: So, in those scrum teams, tell me about the job roles in each one.
Zak Stengel: Yeah, there is a technical lead, a scrum master, who helps with work assignments, helps unblocking the team, some of the traditional kind of scrum master roles, as well as providing general technical leadership. There is at least one product manager. Sometimes, there are multiple product managers, depending upon how that team slices through our organization. And then, within the team, there will be a variety of roles: Software developers, for sure, but sometimes specialists such as engineers that focus on the front end, or DBAs, or site reliability engineers, UX designers, etc.
Switching teams but having the same manager
Ryan Carson: How does reporting structure work? Is it that developers all have an engineering manager and designers have a design manager, or do they report up to the scrum master?
Zak Stengel: Great question. This is another one of the somewhat unique things about what we do. Just as it was important for us to have our teams be cross-geography, it’s also really important for us to have the manager relationship be local as much as possible. We try to balance that geographic distribution with connection with your local team as well, which is a good and healthy thing. That means that you are reporting to someone who, in some cases, is your technical lead and also your scrum master, but more often than not, they are day-to-day working on a different team.
One of the really great benefits that we get from this is mobility. It’s really easy for an engineer to move from one team to another to get a different experience with a different area of our product or a different area of our technology, but it’s not a re-org. You don’t change your manager. It’s really easy to make those shifts, which was something that was really important for us.
Ryan Carson: That’s smart, and I can see the value. That’s one thing I kind of got from reading about Spotify’s method, is that you could switch teams but keep your same manager. I work a lot with the revenue team here at Treehouse, and I think, actually, there’s a lot of similarities to the way other teams could work in this manner. It’s interesting how engineering always seems to have more cutting-edge collaboration models, and other departments do not.
Zak Stengel: We certainly have felt freedom to innovate in all areas. One of the traits that we look for in engineers is that spirit of innovation, where they don’t feel bound by the way things are done. We carry that spirit out into, not just technology, but also into how we’re organized and the tools that we adopt. We do tend to be early adopters.
Ryan Carson: Did you create the system at The Trade Desk or did you walk into it and it was already built? I’d love to hear the story of how you achieved all that.
Zak Stengel: I started at The Trade Desk about five and a half years ago, which wasn’t quite the very beginning of The Trade Desk. We’ve been around for about nine years. But, the team was really small so the engineering team was, I think, eight developers when I started. We were all just one big scrum team at that point. We grew pretty quickly, so to about 200 engineers in five years. So we have had to put a lot of thought into how to stay ahead of that growth — how to put in place mechanisms, just in time, as we’re scaling. It was myself and our CTO, Dave Pickles, who together thought from the beginning about how we wanted to be structured, what was really important to us. One of the things that we decided really early one was what I already mentioned, that we didn’t want that geographic separation to become cultural baggage.
Ryan Carson: Were you already distributed, though, as an engineering team?
Zak Stengel: Just slightly. Most of the engineers were in Ventura, CA. We had a small team in Boulder, CO when I joined, but we knew early on that we were going to be highly geographically distributed. That’s actually one of the key parts of our strategy for acquiring talent, to hire from many different talent pools. We knew we were going to be geo-distributed, but we had seen that ruin so many other companies that we wanted to be really deliberate about it not ruining us.
Ryan Carson: Did you apprentice under somebody or learn from someone, or did you just gather a bunch of resources and build this as you went? How did you end up at what sounds like a very effective structure?
Zak Stengel: I’ve learned a lot of lessons from a lot of people over the years. I haven’t seen anything that is quite the same combination of elements that we have at The Trade Desk. That was something that we really designed for our unique situation and also our specific values.
Achieving diversity goals and business objectives at the same time
Ryan Carson: We were talking about this before we hit record. We are both passionate about equity, diversity, inclusion, really prioritizing that. What are a couple of things that you’ve done that have helped you create a diverse team and retain that team so far?
Zak Stengel: First, I want to be sure to say that diversity is important to The Trade Desk — not only because it’s good for business, which it absolutely is, but also because it’s just good. This is something that one of the women on our team helped me to realize and articulate. I think the whole industry, that I can certainly speak for myself, I have in the past talked a lot about how critical it is for your business to have a diverse workforce, to have diversity of thought on your team, and that is very true. But I haven’t talked enough about diversity being important simply because it’s just, which is equally true. What I’ve realized is that emphasizing the business value of diversity while not also emphasizing just a human and moral value runs a risk of making others — and even yourself — believe that the value of diversity is only in service to business goals. That’s not true. At least, it’s not true for us at The Trade Desk.
Ryan Carson: Amen. Agreed.
Zak Stengel: We will never — and never have to — sacrifice business objectives to achieve a diversity goal. Likewise, no one should ever feel like they have to sacrifice a fair and inclusive working environment or hiring process to achieve a business goal. They are co-equal goals and they can absolutely be achieved together.
Ryan Carson: Thanks for stating that.
Zak Stengel: There are three things that we’ve focused on, and I think you have to get right to have a healthy and diverse workplace. The first is your culture and working environment. I think you have to start there because everything else flows from this. The core thing that we have done here, as I’ve already mentioned, is develop programs and structure and process that promote connection and empathy. It’s my belief, at least, that most of the world’s problems can be reduced fundamentally to a lack of empathy and human understanding, so that is something that we have tried really hard to foster.
The second thing that you have to get right is your evaluation process for new talent. There are a few things that we have done here. First is that we train and continually encourage our interviewers to specifically look for evidence of unique approaches and ways of thinking that are different from their own and from the broader team. In this way, we have tried — and I think we have — developed a hiring culture that values and specifically seeks people who are in meaningful ways not like us.
And then the other thing that we do is train interviewers to have thought through their evaluation plan ahead of time. Because bias can creep in anywhere, but it’s easiest when there aren’t clear standards for evaluation. So when you make a hiring decision based on emotion or gut feel or whether you want to have a beer with someone rather than clearly demonstrated performance against a common standard, that’s when you are most vulnerable to bias. For example, one of the first steps in our process is a take-home coding exercise, which is effectively untimed, specifically so that candidates can complete it at their own convenience, and the amount of time that a candidate has in their life doesn’t unfairly advantage or disadvantage them. Then, it’s also independently graded by an engineer who’s looking only at the design and code the candidate has produced, so that social or demographic cues that might bias their evaluation are minimized as much as possible.
Ryan Carson: They literally don’t know the gender or color or sexual preference of that person writing that code?
Zak Stengel: They will communicate, usually over email, with the candidate. They have their email address. They have their name, because you just need a name to be able to communicate as a human. [laughter] There are assumptions that they can make, sometimes based upon name. We didn’t see a good way to avoid that, but they’re not asking questions like, “What do you like to do in your free time?” And stuff like that where it’s so easy for bias to-
Ryan Carson: To creep in. Gosh, those are great, solid, tactical steps. I love that. Sadly, I hear a lot of people say, “Well, you know, we put our job postings on diverse job boards,” and it’s like, gosh, nothing’s ever going to change. So, those are powerful tactics.
The reason why I asked about the name and gender data, we actually built a simple application here for people to apply to, and we strip all that out in the initial screening process, because it’s just so hard to not start imagining people once you even know their name. When I see “Tamiqua” versus Emily, it’s just impossible not to think, “Okay, Tamiqua’s probably black. Emily’s probably not. I’m white so maybe …” As soon as we did that, we actually started hiring more women.
Zak Stengel: Interesting.
Ryan Carson: Yeah, which is kind of embarrassing to admit — like, “Okay, we definitely have a hidden bias problem.” I applaud you for taking those concrete steps. That’s awesome.
I really appreciate you sharing the stories and being vulnerable too, and honest about all your answers. I respect the company and culture you’ve built. It’s awesome. So, in closing, where can people chat with you online if they want to say hi.
Zak Stengel: LinkedIn is the best place to find me.
Ryan Carson: Cool. And, if they want to learn more about job openings y’all have or if they want to get to know the company, where they should go?
Zak Stengel: thetradedesk.com. You can find our careers page there, and we are absolutely hiring.
Ryan Carson: Awesome, and for you listeners, Zak is spelled Z-A-K, and last name’s S-T-E-N-G-E-L, so in case you want to search him up, as my seven year old says, on LinkedIn.
Thanks so much for your time, Zak. Really appreciate it. Take care.
Zak Stengel: Thank you very much, Ryan.
