Latest / Chief in Tech Deep Dive Shortcast / Chief in Tech S1E36 - Julia Cai : The Engineering Triangle

Transcript

Chief in Tech S1E36 - Julia Cai : The Engineering Triangle · Chief in Tech Deep Dive Shortcast

0:00
You know, usually when a startup gets a massive
0:03
injection of funding, the very first thing they
0:05
do is go on a huge hiring spree. Right. Yeah.
0:08
It's like a reflex. Exactly. You expect it to
0:10
act like rocket fuel. Right. You double the size
0:13
of the team. So naturally, you assume you're
0:16
going to double the speed of your output. I mean,
0:18
it feels like basic math. You have twice as many
0:21
hands on keyboards, so you should be moving twice
0:23
as fast. But then you look at reality in the
0:26
trenches. You hire 20 new engineers, and instead
0:29
of moving at light speed, the entire operation
0:32
just bogs down. It's like pouring wet cement
0:35
into a sports car engine. Add more people, and
0:38
somehow the company actually gets slower. It's
0:42
one of the most frustrating paradoxes in the
0:44
modern business world. And it completely shatters
0:47
that illusion that scaling a company is just
0:49
a matter of adding headcount. OK, let's unpack
0:51
this. For you listening today, our mission is
0:54
to figure out how to scale a team without losing
0:56
that precious early stage momentum. Because it
0:59
is precious. And it's really hard to get back
1:01
once you lose it. Totally. So our sources today
1:04
for this deep dive are a really comprehensive
1:07
article and a fantastic, super detailed leadership
1:10
talk from a veteran head of engineering who has
1:14
lived through this exact wet cement scenario.
1:17
Yeah, they've been in the trenches. Right. And
1:19
they focus on a powerful framework called the
1:21
engineering triangle. But right out of the gate,
1:24
we need to clarify that this is absolutely not
1:26
just for developers. Oh, far from it. I mean,
1:28
the sources really emphasize that today every
1:30
company is a tech company. Right. So if you are
1:33
a founder, a product manager, maybe a designer
1:35
or an operations lead, and you don't understand
1:38
how your technical team scales well, you do not
1:41
understand how your business scales. So can you
1:43
lay out the three sides of this triangle for
1:46
us before we really zoom in? Sure. So the framework
1:49
looks at the tension between three forces. You've
1:51
got business delivery. technology uplift, and
1:55
people and culture. Okay. And honestly, think
1:58
of it less like a literal 2D triangle and more
2:00
like a three -legged stool. I like that visual.
2:03
Right. Because if you keep extending one leg,
2:06
say, you only care about getting features out
2:09
the door as fast as possible while completely
2:12
ignoring the underlying technology or the people
2:14
actually doing the work, the stool tips over.
2:16
It just collapses. Exactly. You have to maintain
2:19
tension and balance across all three legs simultaneously.
2:22
OK, so let's start with that first leg, business
2:24
delivery. Because before a company can invent
2:27
the future, it has to survive today. You have
2:29
to ship product. Speed to market is everything.
2:32
It really is the immediate priority. But let's
2:35
go back to that wet cement problem. Why exactly
2:38
does adding people slow down business delivery?
2:42
Well, it's mostly because of the underlying processes.
2:45
You know, when you have a two -person team, they
2:46
can just shout across the desk to agree on what
2:48
to build next. Super easy. Right. But as you
2:51
grow, if your delivery process requires, let's
2:55
say, five different alignment meetings, cross
2:57
-department approvals, and a sign -off from legal,
2:59
the process itself becomes a physical barrier.
3:02
Wow. You literally run out of hours in the day
3:04
when you add 20 more people to that kind of meeting
3:06
structure. And the sources point out that the
3:08
most neglected part of fixing this delivery speed
3:11
isn't actually the meeting schedule itself. It's
3:15
engineering onboarding. Oh yeah. Onboarding is
3:18
huge. We typically think of onboarding as HR's
3:21
territory, right? Yeah, like learn the company
3:23
mission, sign up for dental benefits, find out
3:25
where the good coffee is. Exactly. But for engineers,
3:29
the assumption from leadership is usually just,
3:31
well, they're smart developers. Point them at
3:33
the code and they'll figure it out. But you can't
3:35
just hand a new hire the entire manual of everything
3:39
the company might build over the next six months
3:41
and expect them to be productive. You're just
3:43
drowning them in irrelevant data. You are. And
3:46
that's why the source insists you need what they
3:48
call targeted documentation. targeted documentation.
3:52
Tell me about that. It basically means giving
3:53
them only the specific localized context they
3:56
need to complete their very first task. Nothing
3:59
more. So no huge overviews. Right. You don't
4:02
teach them the complex architecture of the global
4:05
billing system if their first job is just to
4:08
tweak the color of a button on the home page.
4:10
Makes sense. And you also need to build an internal
4:13
onboarding team. You dedicate actual bandwidth
4:17
from your existing engineers to active guides
4:20
and I love the specific detail from the source
4:22
they say you have to include the people who hold
4:25
the silly institutional knowledge yes the silly
4:28
knowledge is so important because every company
4:30
has weird quirks right like oh we manually restart
4:33
this database on Tuesdays because three years
4:35
ago it crashed and we just never fixed the root
4:37
cause yeah the classic Tuesday database quirk
4:40
because if you don't tell the new hire about
4:42
that they will spend three days trying to fix
4:45
it accidentally break it and stole the entire
4:47
delivery pipeline which perfectly sets up one
4:50
of the most intense metrics from the sources,
4:53
the two -week PR KPI. Ah, yes. And PR meaning
4:56
pull request. So for anyone listening who isn't
4:59
living in GitHub all day, that basically means
5:01
writing a piece of code, getting it reviewed
5:03
by the team, and pushing it live into the actual
5:06
product that customers use. Right, into production.
5:09
Right. And the mandate here is that a new hire
5:12
must do that within their first two weeks. Yep.
5:15
From getting the assignment to being live in
5:17
production. Two weeks. Wait, wait, I have to
5:21
stop you there because this sounds great on paper
5:24
But as a leader, is this just a way to squeeze
5:27
immediate free labor out of a new hire? I know
5:30
it sounds a bit intense. Or is it some kind of
5:33
corporate trust fall? Because a new hire isn't
5:36
going to build a meaningful complex feature in
5:38
ten days. And that's actually the secret of this
5:41
metric. What's fascinating here is that the actual
5:44
value of that first piece of code is almost entirely
5:47
irrelevant. Wait, really? Yeah, it could literally
5:50
be changing the font size on a drop down menu.
5:52
The point is not the code itself. So what is
5:54
the point then? The point is forcing the new
5:57
engineer to navigate your entire internal plumbing
5:59
system. Ah, the plumbing. Right. To get that
6:02
tiny font change live, they have to figure out
6:05
the internal testing tools. They have to understand
6:07
the security constraints. They have to figure
6:08
out exactly which human being they need to ping
6:10
on Slack to get a final approval. So it's essentially
6:13
a scavenger hunt designed to teach them how the
6:16
machine actually works. Exactly. It's a purely
6:19
experiential lesson. It instantly makes them
6:22
an active participant in the community because
6:24
their work is now in the shared code base. That's
6:26
pretty clever. And more importantly, it signals
6:29
the company culture without a single HR memo.
6:33
It tells them right away, speed is our primary
6:36
currency here. We move fast. That makes a lot
6:38
of sense. And there's another experiential lesson
6:41
that ties right into that speed and business
6:43
delivery. customer proximity. Oh, this is a great
6:46
one. Right. During onboarding, they make these
6:49
new engineers shadow the tech support or customer
6:52
success teams. Yeah, because if you just hand
6:55
an engineer a sterile product brief that says,
6:57
you know, fix login bug, it's just an abstract
7:00
technical puzzle. Right. It doesn't mean anything
7:02
to them. But if they spend their first week listening
7:04
to a frustrated small business owner who can't
7:06
access their payroll software to pay their employees,
7:09
the engineer connects their technical task to
7:12
real human pain. Wow. Yeah, that changes the
7:15
stakes. It totally does. They start making decisions
7:18
based on what the user actually needs to survive
7:20
rather than just what looks elegant in the code.
7:23
OK, so we've optimized onboarding. The team is
7:27
hyper -focused on the customer, they are navigating
7:30
the plumbing, and they are shipping fast. But
7:33
even if you have the fastest delivery process
7:35
in the world, eventually the underlying machinery
7:38
is going to start shaking apart. It always does.
7:40
You can't run a sports car at top speed indefinitely
7:43
if the engine block is cracked. So how do you
7:46
fix the engine while the car is flying down the
7:48
highway? Well, the first step the source recommends
7:51
is completely changing our vocabulary. We need
7:54
to stop using the common industry buzzword, technical
7:57
debt. Why? I feel like everyone uses that term.
8:00
It just means the messy code you wrote quickly
8:02
in the past that you now have to clean up, right?
8:04
Right. But the expert in our source argues that
8:06
debt implies a moral failing or regret. And in
8:10
a fast moving startup, past decisions were made
8:13
for business survival. Oh, I see. Yeah, you built
8:16
that sloppy feature three years ago because if
8:18
you didn't, the company would have literally
8:20
run out of money and died. There's no value in
8:22
sitting around feeling guilty about it. That
8:24
is a really refreshing way to look at it. So
8:26
instead of vague debt, we need to identify specific
8:30
technical bottlenecks. What exact piece of old
8:34
technology is actively slowing down our business
8:36
delivery today? And the source provides a brutal
8:39
example of a bottleneck. Let's call it the 150
8:42
-day trap. Oh, this one hurts to even think about.
8:45
It's wild. So the engineering leader realized
8:48
that whenever they hired someone, it took that
8:50
new engineer three to five days just to set up
8:53
their local environment. Just getting all the
8:55
right software, security keys, and access permissions
8:58
installed on their specific laptop so it could
9:01
securely talk to the company's servers. Right.
9:03
Five days just watching loading bars on a screen
9:06
before they can even look at the real code. And
9:08
she was planning to hire 30 new engineers. Which
9:11
is just staggering when you do the math. 30 engineers
9:14
times five days. That's 150 days. Almost half
9:17
a year of paid, expensive engineering time literally
9:20
burned into the atmosphere. Burned. So the lesson
9:23
from the source is you have to fix that bottleneck
9:25
before you hire the people. You have to. You
9:28
fix it by automating that laptop setup process
9:31
first. Because if you bring 30 new people into
9:34
a broken manual system, you don't scale your
9:36
output. You just scale your delays. Which introduces
9:40
a threshold the source calls the magic number
9:42
10. Right, the turning point. Once an engineering
9:45
team hits 10 people, you have to lock in critical
9:48
engineering standards. For instance, unit test
9:51
coverage, meaning writing automated scripts that
9:54
constantly check if your new code accidentally
9:56
breaks any old code. Or monitoring. You know,
9:59
the systems that send a pager alert when the
10:02
website goes down in the middle of the night,
10:03
you... absolutely have to standardize these at
10:06
10 people. But hold on, doesn't forcing strict
10:08
corporate -style rules on a tiny team completely
10:11
kill that scrappy startup move fast and break
10:14
things vibe? You know, you would think so, but
10:16
if we connect this to the bigger picture is the
10:18
exact opposite. Think about what happens if you
10:20
don't have standards and you hire five more people.
10:23
Okay, what happens? Those five engineers arrive
10:25
with five completely different ways of doing
10:27
things from their previous jobs. They use different
10:30
tools to monitor site traffic. They write tests
10:32
differently. Oh, so it becomes a tower of babble.
10:35
Exactly. That variation is what actually kills
10:38
the scrappy vibe. Because suddenly, one engineer
10:41
can't read another engineer's code, you can't
10:43
easily swap people between projects when there's
10:45
a fire. Ah, I get it now. Fixing it early and
10:49
establishing a common language when you are small
10:51
avoids paying a massive 20x penalty later when
10:55
you have to untangle 50 different ways of doing
10:57
the exact same thing. And speaking of untangling
11:00
things, that naturally leads to the big monster
11:02
of technology uplift replatforming. Yes, the
11:05
dreaded replatforming. Right. This is when a
11:08
company realizes their original scrappy software,
11:11
their V1 can't handle their massive new scale,
11:14
and they have to build a sleek powerful V2 system.
11:18
It's huge undertaking. And the source warns very
11:20
strongly against siloing your teams during this
11:23
transition. You shouldn't have one team stuck
11:25
maintaining the old legacy system while a separate
11:27
team gets to build the shiny new one. It is a
11:30
massive management trap. If you don't rotate
11:33
your engineers between the old and the new systems,
11:36
you breed a toxic culture. You know, I was picturing
11:39
it. like a restaurant. Okay how so? Imagine keeping
11:43
your veteran chefs trapped in a cramped greasy
11:47
old diner making the same burgers they've made
11:50
for five years just to pay the bills while all
11:52
the new hires get to play next door in a million
11:55
dollar state -of -the -art test kitchen. Oh wow.
11:59
Of course the veterans are going to resent the
12:00
new menu and the new hires won't have any respect
12:03
for the old system that's actively keeping the
12:05
lights on. That is a perfect way to visualize
12:07
it. You have to rotate them. The veterans bring
12:10
their deep knowledge of the customer's actual
12:12
needs to the new platform, which prevents the
12:15
new hires from building something theoretically
12:17
beautiful, but practically useless. Right, because
12:19
they know what actually works. Exactly, and the
12:22
new hires bring fresh energy and techniques to
12:24
help maintain the old system whilst being safely
12:26
phased out. You decompose those massive tasks
12:30
into parallel chunks and feed them right into
12:32
the daily roadmap. Okay, so we have the first
12:34
two legs of our stool. Delivery is optimized.
12:37
The tech stack is standardized and modernizing.
12:39
But even if you perfectly untangle that code
12:42
and fix your platforms, you're still relying
12:45
on human beings to type the keystrokes. You are.
12:48
And if those humans are burning out, your pristine
12:50
tech stack doesn't matter. Which brings us to
12:54
the third leg people in culture, the human engine.
12:57
Right. And the source digs into some fascinating
13:00
cultural mechanics here. It starts with an adaptable
13:03
team structure. you know, knowing when to leverage
13:05
full -time employees versus contractors and managing
13:08
remote talent effectively. Sure. But the core
13:11
of this section is really about how you foster
13:14
innovation and maintain morale in a high -stress
13:17
environment. And the most striking tactic they
13:19
use for this is the three -day mini sprint. Oh,
13:22
this is such a cool concept. So every three months,
13:25
leadership gives their engineers three full days
13:28
to work on literally any technology they want.
13:30
It doesn't even have to be related to the company's
13:32
core product. Yep. Just total freedom. And at
13:35
the end, they do a presentation showing off what
13:37
they built. But here's where it gets really interesting
13:40
to me. If I'm a founder listening to this, I
13:43
might panic that I'm just burning cash. I can
13:45
see why you'd think that. Right. You want me
13:48
to pay my most expensive employees to mess around
13:50
with unrelated tech for three days every single
13:53
quarter? How on earth is that justified when
13:56
we're burning through venture capital? It sounds
13:59
incredibly counterintuitive, I know. but you
14:01
justify it by looking at the hidden costs of
14:04
not doing it. If developers are just grinding
14:06
through assigned features day in and day out,
14:09
just dragging tickets across a digital whiteboard,
14:12
they get demoralized. Yeah, that makes sense.
14:15
It gets tedious. And worse, they get technologically
14:17
stale because they're only ever exposed to your
14:20
specific code base. So it's essentially an expensive
14:23
retention strategy. Retention is a huge part
14:25
of it. Absolutely. Yeah. Engineers want to feel
14:28
like creative problem solvers, not assembly line
14:31
workers. But the source notes an even bigger
14:33
benefit. What's that? Some of the absolute best,
14:37
most profitable product ideas for the company
14:39
actually emerge from these unstructured sprints.
14:43
Really? Yeah. An engineer might play with a new
14:46
data visualization tool just for fun, right?
14:48
And suddenly they realize it could completely
14:51
solve a major reporting problem for your biggest
14:54
client. Wow. So it breeds accidental innovation.
14:58
Exactly. It's an investment in their mental elasticity.
15:01
And that mental shift ties directly into how
15:05
the source suggests changing the day -to -day
15:07
internal messaging, too. How so? Usually in software
15:10
development. the debate is entirely about the
15:12
clock. Is this a two -week project or a five
15:14
-week project? Are we behind schedule? Right.
15:17
The focus is entirely on the deadline. Which
15:19
just creates anxiety. But the source says we
15:22
need to stop fixating on the timeline and shift
15:24
the entire conversation to problem solving. Moving
15:26
away from the clock. Right. Leaders should be
15:28
asking the team, how do we solve this specific
15:31
customer problem better, faster, or more creatively
15:34
than our competitors? That's a huge shift. You're
15:37
rallying the team around an intellectual challenge
15:39
rather than just threatening them with a calendar.
15:42
Exactly. Changing that prompt changes the energy
15:45
in the room. And to really rally the team, the
15:48
leader in the source does something called a
15:50
competitiveness assessment every six to nine
15:53
months. This was such a great strategic exercise.
15:56
So the leader sits down with the management team
15:58
and poses a hypothetical. Yes. They ask, if an
16:02
investor gave us $10 million today, and gave
16:06
our direct competitor $10 million today. How
16:08
do we win by the end of the year? It's brilliant.
16:11
Because when you're constantly in the weeds trying
16:13
to survive the current week, it's so, so easy
16:16
to develop tunnel vision. Yeah, you forget to
16:19
look at the horizon. This exercise forces leaders
16:21
to step out of their immediate bottlenecks, look
16:24
at the broader market, and actively figure out
16:26
how to push the bar higher. It demands strategic
16:29
competitive thinking. OK, so we have our three
16:31
-legged stool. Business delivery, technology
16:34
uplift, people and culture, keep them balanced,
16:36
and your organization scales beautifully. That's
16:38
the goal. But right now, we are living through
16:40
an industry -wide earthquake that is shaking
16:42
the ground underneath that stool. Let's talk
16:45
about the wild card artificial intelligence.
16:47
We have to. The source dedicates a whole section
16:49
to this because AI is fundamentally warping how
16:52
we measure speed, write code, and manage people.
16:55
Right. And it all starts with the number one
16:57
question every CEO and board of directors is
17:00
asking right now. Can AI reduce the number of
17:04
engineers we need to hire? The multi -million
17:07
dollar question. If an AI can write code, can
17:10
a company just fire a third of its engineering
17:12
team and maintain the exact same output? Well,
17:16
on paper the theoretical answer is yes, but practically.
17:19
Yeah. The source, speaking from the reality of
17:22
the New York startup scene, notes that almost
17:25
nobody is actually doing this successfully and
17:27
consistently yet. Wait, why not? If AI can write
17:29
a script in 10 seconds that used to take a human
17:31
two hours, how is that not an immediate, massive
17:34
boost in speed? Because of the downstream traffic
17:36
jam. The traffic jam? Yeah, think about how the
17:38
mechanism actually works. The AI could generate
17:41
code incredibly fast, sure, but that code still
17:44
has to be reviewed, tested, and approved by human
17:47
beings to ensure it doesn't break the system.
17:49
Oh, I see. Right. So if your AI writes 10 times
17:52
more code, but your human quality assurance process
17:55
hasn't sped up to match, you haven't increased
17:58
your business delivery. You've just created a
18:01
massive backlog of unreviewed code waiting in
18:04
line. Ah. So you didn't eliminate the bottleneck.
18:07
You just moved it from the writing phase to the
18:09
reviewing phase. Exactly. And this leads to what
18:12
we might call the KPI void. OK. What's that?
18:15
We simply do not have industry standards for
18:17
measuring AI productivity yet. If you buy your
18:20
team an AI coding assistant, should you expect
18:23
a 20 % increase in final output? Should 40 %
18:27
of the final code base be AI generated? Who knows,
18:30
right? We don't know. The entire industry is
18:32
flying blind right now. But even with all that
18:34
uncertainty, the Source gives a very strong,
18:37
definitive directive to leaders. If your company
18:39
has a history of struggling with change management,
18:42
meaning your organization is usually slow or
18:44
resistant to adopting new software, do not just
18:46
run a cute, safe little AI pilot program with
18:49
a couple of interns. Yes. You need to force the
18:52
issue. The Source says you must take an AI project
18:56
live immediately. Put it into your actual production
18:59
pipeline with real stakes. Because if you just
19:01
dip your toe in the water, the organization will
19:04
naturally reject it like a mismatched organ transplant.
19:07
People will just go back to their old habits.
19:09
Exactly. Adopting AI isn't just downloading a
19:11
new tech tool. It's a fundamental organizational
19:14
business transformation. You have to force your
19:17
organizational muscles to adapt to the new reality
19:20
by putting it into the wild. Taking a step back,
19:22
the source makes this pretty wild claim toward
19:25
the end. They say AI is basically turning everyone
19:28
into an engineer because the technical barrier
19:30
to creating software is dropping to zero, and
19:33
it's turning existing engineers into product
19:35
leaders. So what does this all mean? Does the
19:38
engineering triangle just become the business
19:41
triangle for everyone? This raises such an important
19:44
question about the longevity of frameworks. And
19:46
the real insight here is that while the specific
19:50
tools change, maybe tomorrow you're prompting
19:53
an AI with plain English instead of typing out
19:55
complex Python code, the underlying physics of
19:59
the system remain identical. How so? Whether
20:01
a human writes the code or an AI writes the code,
20:04
your delivery process still has to be optimized
20:07
or you'll choke on bottlenecks. Right. You still
20:09
have to manage your technology platforms or the
20:12
AI will just generate legacy debt faster than
20:14
a human ever could. And most crucially, you still
20:17
have to cultivate a culture of people who care
20:20
deeply about solving customer problems. So the
20:22
triangle still holds. It has to. You still have
20:25
to balance all three legs of the stool to keep
20:27
moving upwards. That is a powerful synthesis.
20:30
Building a high -performing organization means
20:32
maintaining that tension. Hold all three sides
20:35
equally. Neglect your delivery speed and you
20:38
die today. Neglect your technology uplift and
20:40
you die tomorrow. Neglect your people and you
20:42
have no one around to do the work anyway. The
20:44
shape only holds if you balance it. And I leave
20:48
you with one final thought to mull over, really
20:51
building on that reality of AI we were just talking
20:53
about. Yeah, let's hear it. If AI truly makes
20:55
it so that anyone can write code, if generating
20:58
software becomes as common and easy as writing
21:00
an email, turning everyone into an engineer like
21:03
the source claims, then the purely technical
21:06
side of the triangle might become entirely commoditized.
21:09
Oh, wow. So if everyone can build the product
21:12
instantly, the code itself is no longer your
21:14
competitive advantage. What replaces it? Empathy.
21:17
Empathy. Yeah. If the code is free and infinite,
21:20
the supreme defining skill of a future tech leader
21:23
will simply be profound empathy for the customer's
21:26
pain points. That's fascinating. It's the exact
21:29
thing that tech support shadowing exercise during
21:31
onboarding was trying to teach them on day one,
21:34
understanding the actual human on the other side
21:36
of the screen. It always comes back to the humans.
21:38
It really does. Well to you listening to this
21:41
right now, thank you for coming along on this
21:42
journey with us. Technology is evolving at light
21:45
speed and the tools we use tomorrow will probably
21:48
look like magic compared to today. But the principles
21:50
of great leadership, of balancing the delivery,
21:54
the tech, and the people, those remain timeless.
21:56
Keep learning, keep pushing the bar higher, and
21:59
we will catch you on the next deep dive.