Bonus Episode with Greg Conklin: Navigating Hyper-growth and Tech Debt at Groupon and Dropbox
In this bonus episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub dive into a conversation with Greg Conklin, exploring his experiences at two hypergrowth companies, Groupon and Dropbox. Greg shares insights on the unique cultural and technical strategies employed at both organizations during their rapid expansion phases. He discusses the challenges of technical debt, team building approaches, and the differing priorities at Groupon's distributed startup-like model versus Dropbox's cohesive, security-focused architecture. The episode also touches upon the role of senior engineering leadership in managing technical debt and optimizing engineering velocity across diverse teams.
- 00:00 Introduction: The Journey of Tech Debt
- 00:22 Exploring Hypergrowth at Dropbox and Groupon
- 01:25 Building Teams and Strategies
- 03:24 Cultural Differences and Technical Challenges
- 04:36 Platform and Ops Teams at Groupon vs Dropbox
- 07:41 Managing Technical Debt and Engineering Leadership
- 10:23 Conclusion and Farewell
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Greg Conklin: https://www.linkedin.com/in/gregoryconklin/
- Greg's Blog: https://gregconklin.com/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #Entrepreneurship #Leadership #Management #EngineeringLeadership #TechnologyLeadership #EngineeringManagement #EngineeringProductivity #TeamVelocity #DevCulture #TeamCulture #EngineeringCulture #Agile #TechDebt #OperationalExcellence #EngineeringCultureMatters #EmpoweredTeams #DevProcess #StartupLeadership #EngineeringMaturity #ScalingEngineering #EngineeringOrgDesign #HyperGrowth #HyperGrowthEngineering #ScalingTech #PlatformEngineering #TechnicalStrategy #TechScalability #DistributedTeams #RapidGrowth #TechOrgDesign #GlobalEngineering #TechOps #AcquisitionStrategy #MultiTenantArchitecture #VelocityVsQuality #TechTradeoffs #EngineeringVelocity #SystemDesign #APILayer #InfrastructureStrategy #SaaSScaling
Guest
Brad: Is four years enough time to build tech debt?
Like I tell you, that's plenty of time.
Greg: So can I ask you about Dropbox?
You heard Dropbox and Groupon because kind of dual question for both of them.
Talk about two organizations that had hyper growth.
I mean, I saw Groupon from the outside as a consumer. It was a cultural phenomena,
right?
And Dropbox, I don't think was as much of a cultural phenomena, but I think was explosively growth.
And then like very technically complex,
I would imagine because you've got all this data.
um
and like tell us about those experiences sure
Brad: particularly like the hypergrowth phase.
Greg: or any part of it but i just think it's you know not everybody gets the opportunity to ride a to be on a ride like a groupon or a dropbox ride
Brad: Oh, it's super fun. I highly recommend it.
Greg: i mean i would i mean i would imagine groupon grew like 10 000 x in a in a year or something like that it was enormous
Brad: It probably...
It probably did.
I mean, it grew.
Let's see, where do I sort of begin there?
I mean, we could talk about building out these teams, and I think Groupon and Dropbox had different approaches to building out teams. And what I found worked well in both cases was that method.
was very much aligned to the strategy and the mission and what how the company wanted to operate so for example Groupon uh was a rather Amazon culture like a lot of what went to sort of gain traction and was growing a lot of the Amazon a lot of the leadership at Groupon was was very Amazonian and it lended itself well yes we had
The deal of the day phenomenon,
which was our first kind of hook that really grew the company enormously,
but the overall strategy was build out a series of secondary products. Okay, sure.
Nail salons and restaurants,
then travel,
then maybe physical products,
then experiences. And it led itself to a more two pizza team GM model.
everywhere.
And so the hiring strategy there was find a leader,
have them build the team.
And so it was very distributed.
I had to trade off you would sort of expect from that in terms of like a very heterogeneous culture to put it sort of specifically.
four years enough time to build tech debt like I tell you I tell you that's that's plenty of time particularly we have engineering you know independent engineering teams all sort of building out separate set of products where where speed was was super important but we had mechanisms in place and the engineering leadership would come together all the time to understand where exactly we needed to
put something together and call it a platform component or where we're just going to let let it rip and then dropbox was was was quite different um it was growing very quickly but the nature of dropbox needed to be secure it needed to be private right um drew house and the founder of dropbox would say
You know, your house is burning down what you go back in to get. It's your kids,
your pets and your family photos.
And Dropbox kind of has one of those.
And so it really set the culture there around security,
privacy,
getting it right,
never lose a bit of data was super important. So as you built the engineering teams at Dropbox.
That is sort of what we focused on when it came to the cultural aspects of the hiring process,
the behavioral aspects of it.
So yeah,
both were very, very different.
And I was sort of struck by how they matched the way they tried to grow with what they were trying to build as a company.
Greg: At Groupon, was there a fairly thick platform layer for all those two pizza teams to work on top of,
or was there a lot of
Brad: No.
Greg: duplicate stuff going on?
Brad: I mean, my judgment was no. And maybe some former Groupon colleagues will hear this and give me a hard time about it.
I remember,
and this is sort of a tongue-in-cheek sort of joke.
Your platform,
you would file, if you're a team and you needed a database, you would file a JIRA ticket and the ops team would respond back with an IP address.
And it was just an image of a host with a MySQL database on it.
And that was it.
We had an ops team that was managing data centers, we had an SRE team that was small but mighty,
but largely it was pretty much a bunch of startups.
We had some platform teams that owned, let's say, like the web framework,
for example.
So early on it was a monolithic Rails application and we slowly moved it over to like a SOA style node based express web thing until we had a small team that was managing that.
But it was pretty light. It was pretty light.
Dropbox only had it was pretty significant.
Maybe a third to a half of the engineering team was what you might call.
platform,
which is understandable,
right?
They were managing and implementing their own massively scalable distributed block storage system, massively scalable metadata and structure data infrastructure and things like that.
Greg: I would imagine Groupon, all those startups in Groupon, they must have shared some things. They shared accounts,
they shared checkout,
a handful of things like that must have been shared between travel and
Brad: They shared...
Greg: between travel and nails and cars and whatever else you guys were selling.
Brad: um
Greg: Or no, was it all were they all independent?
Brad: it was complicated it was it was complicated i mean yeah i think accounts were shared i mean one one of the things that happened at groupon was um it grew very very rapidly and one of our early on we tried to internationalize the rails monolith and you know internationalizing something like that is is hard particularly when you had no
you know very little there to build upon and so the strategy became you remember all these Groupon clones like let's just go country by country buy the Groupon clone and so you and so you ended up with multiple multiple platforms and so yeah that's why I'm kind of like how do I answer the question about single account system no
There was the European one,
there was the Japanese one,
there was the North American one,
there was the South
Greg: Whereas
Brad: American one,
Greg: Dropbox
Brad: right?
Greg: was far more cohesive it sounds like.
Brad: Dropbox was very,
very cohesive,
yes.
Yeah, for sure.
Greg: I think it's interesting,
Greg,
that you're kind of talking about how quickly you can get technical debt and especially like it sounds like with the Groupon approach,
of course, like effectively it's like all a whole bunch of separate little startups all just move in as fast as they possibly could.
Do you feel like?
Do you feel like at kind of the senior engineering leadership level where we're where we're you know if there's more than you know if there's more than two teams like you're already like in your your offset away from the choices they're making how do you how do you think the role or the how do you think a senior engineering leader should should try to address
Yes.
Systems to slow down the creation of technical debt,
Brad: Yeah.
Greg: you know, systems tech culture.
What do you what do you what's our when we're wearing our CTO, our VP of engineering hat,
what do we do?
Brad: Yeah,
that's, it is not easy.
I don't have any magic for that either.
I think it is understanding where the company is trying to...
go like is there a reason okay is there a reason why we had different authentication systems for for different parts of the world the answer was yes because we we decided to take an approach of acquiring them like they didn't they didn't build these new authentication systems once they had joined but you need a plan to figure out okay where where is that running into you
problems or where is that either going to slow us down or be a burden to the business going forward in Groupon's case the burden was North America was running really quickly building features and products and meanwhile international was going slow they were just fewer engineers there so you would look at okay
Where can we get more engineering velocity? And for example, what we had decided was we're going to create a middle layer, like an API layer that will then abstract out the nonsense below it.
So while we had different authentication systems,
inventory management systems,
order management systems,
customer service systems,
we had one global mobile app.
one website that worked globally right and so that was for example what we ended up deciding was the best way to get the velocity because what we were what we were seeing what we were what we were seeing in North America was a lot of product iteration a lot of product experimentation was getting us a lot of good growth and we wanted to make sure that that was easily transferable to other parts of the other parts of the company other parts of you know the business
Greg: Well, thanks, Greg.
Yeah, thanks for coming,
Greg,
and we'll probably maybe have you back sometime.
It'd be great to kind of catch up on whatever you're up to next and more learnings will always be fun.
Brad: That was awesome.
Great.
Greg: This episode of How Many CTOs Does It Take Podcast was edited by Saffron Epigab.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon.
Or at our website at HowManyCTOsPod.com.
And remember to rate, review,
and subscribe on the podcast platform of your choice.
Thanks for listening.