This video introduces the "altitude slider," a concept for engineers to decide when to focus on high-level strategy and when to dive into hands-on coding. The speaker, Curtis, a principal engineer at Slack, explains how to recognize signals that indicate a need to shift focus between these two modes. He also shares personal rituals and techniques to ensure engineers are working at the most effective "altitude" for their team and company goals, rather than just doing what's comfortable.
Key Takeaways
1
The "altitude slider" helps engineers decide between focusing on strategy and diving into code, ensuring they spend time on the right tasks.
2
Engineers should assess their natural tendencies, as many senior engineers prefer coding and systems work over strategic thinking.
3
Spending too much time at the strategy level can lead to analysis paralysis, where too much planning prevents actual implementation.
4
Signs of being too focused on strategy include building the wrong thing efficiently, unwarranted complexity creeping in, and lacking detailed knowledge of the systems.
5
Signals to drop down to a lower altitude (coding) include long shipping times due to setup, needing a proof of concept, or noticing "code smells" like excessive copy-pasting.
6
Regularly checking your "altitude" by observing signals and being mindful of your work level helps in calibrating and adjusting your focus.
7
Daily or weekly rituals, like reflecting on whether your work aligned with team needs or just personal comfort, can help manage your altitude.
8
Staff-plus engineers possess a unique ability to understand code and systems, allowing them to prototype solutions and guide business goals effectively.
9
By intentionally setting their altitude through rituals and self-awareness, engineers can ensure they are providing what their team needs at any given time.
No matching segments found
0:09
Hey everyone. Uh, I'm Curtis and I'm
0:12
going to be talking about the altitude
0:14
slider, which is kind of a silly thing I
0:18
made up to talk about that seesaw effect
0:20
of focusing on strategy and diving into
0:24
code and when to do both and how to know
0:27
that maybe you're spending too much time
0:29
on one side or the other. But, um, I'm
0:32
here for from Denver, Colorado. I'm a
0:35
principal engineer at Slack. Oo, woo.
0:37
For Colorado. There we go. Um, I took
0:41
this opportunity to bring my ent my
0:44
whole family with me to view the city
0:46
and I thought it would be a great idea
0:48
to do the last finishing touches on my
0:51
slides after a day of sightseeing. And,
0:54
uh, that didn't work out too well, but
0:57
um, we've had a lot of fun and I'm
0:59
excited to talk with you about this
1:00
today. So, uh, the senior IC's dilemma.
1:05
Have you ever built something perfectly
1:08
that no one needed? Any show of hands?
1:12
Yeah. Yeah, that that happens sometimes.
1:15
Um, have you ever heard of like a
1:18
company that built something on what you
1:19
would call an old tech stack, but
1:22
everyone needed it somehow? Um, I
1:24
remember interviewing for a company that
1:26
was built on Pearl and thought, "How
1:29
could this company be successful?" And
1:31
yet they were. Um, or have you been
1:35
focused on a project you were building
1:37
and maybe a stakeholder comes and
1:39
approaches you and says, "Curtis, we
1:41
need we need this feature and this
1:44
feature and this feature and you're
1:46
eager to code." Because that's what we
1:48
as engineers love to do is just, oh
1:50
yeah, let me code that. But take a step
1:53
back and think about is this a right
1:55
thing to build at this time? Um these
1:58
are kind of circumstances where the
2:01
activity slider or altitude slider will
2:03
come into play. Um but before we get
2:06
into that, I think it's important to
2:08
take your own like personal assessment
2:11
on your own proclivities, what things
2:14
you tend to focus on and gravitate
2:16
towards most. Um, for me, and I suspect
2:19
for many other engineers that have um,
2:22
started at associate level engineers and
2:25
have gone up to staff and higher, you
2:27
probably love systems, coding,
2:30
architecture, and that's the easy part
2:33
to stay and and focus on. Um, and at
2:36
times, at least for myself, it's much
2:39
harder to take a step back, put the
2:41
keyboard away, and to think about
2:43
strategy. Um, think about business. I
2:47
think someone earlier was talking about
2:49
business time. So, um, focus on what
2:54
your own natural altitude is and where
2:56
you're most comfortable, but keep that
2:59
in mind as you, um, go about your day,
3:02
your week, about what your company may
3:04
need from you in later days. So when we
3:09
talk about these different altitude
3:11
signals, there are different signs that
3:13
you may see that um are signals to a
3:17
change in altitude may be coming much
3:19
like uh any any clo coding agent users
3:22
here. Um, have you ever used a coding
3:25
agent and it starts to spiral and go
3:28
down this rabbit hole and you have to
3:31
stop it and be like, "Let me just fix
3:33
this part to get you unstuck because
3:35
there's no prompting that's going to get
3:36
us out of this hole." Um, you kind of
3:40
need to do that a little bit. At least I
3:41
need to do that myself when I'm like
3:43
very focused on coding and on systems
3:46
and stop myself and say, "Okay,
3:49
what signals am I seeing here? what's
3:52
the best use of my time to move forward?
3:55
So, um,
3:58
one of the my personal mantras that I
4:00
have is a known problem is easier to
4:02
solve than an unknown one. And I believe
4:04
someone earlier was talking about
4:06
deferring that complexity and deferring
4:08
that decision-m to later. And it's easy
4:12
to um when you're at the strategy level
4:15
to to focus so much on the design of the
4:18
system, the design, the edge cases, the
4:21
stakeholders, designing the most optimal
4:24
thing that's going to uh delight your
4:26
customers.
4:28
But sometimes that can be a trap like
4:30
analysis paralysis where you spend too
4:32
much time on all of these little things
4:35
and you're not spending enough time
4:36
actually implementing the thing. Um and
4:40
with one particular project I remember
4:43
we were migrating from a
4:46
one team always builds AI stuff in our
4:49
company to every team can build the AI
4:52
stuff in our company and my job was to
4:56
let's build like an SDK or platform at
4:58
least so it's easier for other teams to
5:00
build these different features. Um, and
5:03
I spent a lot of time talking to
5:05
different teams, listening to their
5:08
requirements, figuring out um, looking
5:11
at what had been built before, what was
5:12
hard to build. And it got to a point
5:15
where I felt like there was no single
5:18
solution I could build that would solve
5:20
all of these stakeholder agreements. And
5:23
for me, that was like a moment of I'm
5:25
I'm spending too much time at the
5:27
strategy layer that instead I need to
5:29
focus and get building. So, I'm going to
5:32
take my best guesses of what needs to be
5:35
built and actually build something, dive
5:38
into implementation, see where the rough
5:40
edges are, and that's going to be a
5:42
better use of my time than sitting in
5:45
this ivory tower trying to design
5:47
everything that's going to solve
5:48
everyone's problems.
5:51
>> If you're enjoying this, then Lead Dev's
5:52
got loads more to offer, and there's
5:54
tons to explore.
5:56
So the reason I love lead dev so much is
5:58
they've got such a range of content on
6:00
so many different topics in the world of
6:01
engineering leadership and management.
6:03
>> So lead helped a lot on building my own
6:05
career, right? And it's great to also
6:08
see how it's helping the new generation
6:10
as well.
6:11
>> Make sure to sign up and join us at
6:12
leadv.com.
6:19
>> What's it look like when you spend too
6:20
much time at the strategy altitude?
6:23
Um,
6:25
so if your team is like able to build
6:28
the wrong thing but really efficiently,
6:31
that may be a sign that they need some
6:34
more direction. Um, if un unwarranted
6:38
complexity starts creeping in, there's
6:40
this acrony acronym acronym called
6:44
YAGNY. Um, you're not going to need it.
6:47
If you see those types of thing creep
6:50
things creep in early, that may be a
6:52
sign that it's time to come out of the
6:54
strategy stratosphere and down into the
6:57
implementation layer. Um, or if you're
7:01
if your own knowledge in the systems
7:04
that you're responsible for or the
7:06
systems that you support, if you're
7:08
lacking the details to be able to
7:10
contribute effectively in those domains,
7:13
it may be a sign that it's time to come
7:15
down and get your hands dirty.
7:20
on the low altitude side. Say um you're
7:25
working on a feature and one example was
7:30
we had a hard time shipping and
7:34
delivering this feature and most of the
7:37
time I noticed was spent setting the
7:39
test harness like getting the system in
7:42
the right position to be able to test
7:44
what we were building. Um, and in that
7:47
circumstance, I decided to take a
7:49
different TAC and focus on building a
7:52
test harness that with a click of a
7:55
button would put the system in the
7:56
proper state so we could then iterate on
7:58
the feature we were developing.
8:01
That was a signal to me that okay, the
8:04
team is ready. They're working very,
8:06
very hard on shipping this feature, but
8:09
we needed a architectural unlock that
8:11
made the iteration time quicker. Um,
8:15
also if uh if if you want to do like a
8:18
proof of concept of validity strategy,
8:19
that could be a good use of like a low
8:21
altitude signal.
8:24
Uh, and um, if there's times when there
8:28
are code smells, um, a code smell I I
8:31
call those when I see like code reviews
8:32
or I'm reviewing code and there's a lot
8:35
of like copy and place proliferation or
8:38
some of the patterns that are
8:40
representative in our codebase aren't
8:42
really um, shining in these different
8:45
PRs or the business logic is just
8:47
sprawling to its tentacles throughout
8:49
the codebase. it could be a sign that
8:52
it's time to drop down and work on at
8:55
the lower altitude level to deliver.
9:00
Um, and just by observing some of these
9:04
signals and being mindful of them and
9:07
being mindful of what level you're
9:09
working at,
9:11
it almost helps you just calibrate and
9:15
know that you need to change the
9:16
altitude level. Um, just by observing it
9:19
and being mindful of it.
9:20
So, we'll go into like a few more
9:23
rituals that I use to complete to check
9:26
my altitude from time to time. Um, and
9:28
these are just examples, but some of
9:30
them may work for you as well.
9:33
Uh, so sometimes in the mornings, like
9:36
I'm starting my week off in the morning
9:38
and I'm trying to figure out, am I
9:40
coding because it's comfortable for me
9:42
because that's my natural proclivity.
9:44
um or is there something that I could do
9:47
here that can be an unlock for the rest
9:48
of the team. Uh so one example for us
9:52
early in our AI journey we kind of built
9:55
all of these abstractions based on the
9:57
state-of-the-art models at the time and
10:01
those abstractions broke fundamentally
10:04
and it became hard to add even simple
10:06
features to our tech stack. Um, so I
10:10
took that as a sign that I should focus
10:13
on implementing um, a new way to expose
10:18
these native features to developers and
10:21
that wasn't necessarily tied to an
10:22
individual project or individual
10:24
feature, but a crosscutting concern that
10:26
would work for the rest of the
10:28
organization.
10:29
Um, also at the end of the day or the
10:32
end of the week, whatever cadence works
10:34
for you, reflect on whatever your
10:36
strategy, whatever altitude you were for
10:39
parts of that day and see if you flew at
10:42
the right height that day.
10:45
Also, there's project rituals. So,
10:47
during a project lifestyle uh life
10:50
cycle, you may choose to focus on am I
10:52
focused on the right area here? Um, if
10:56
it's crunch time, am I using my
11:00
abilities at the best at these high
11:02
leverage times?
11:06
And then finally, recovery techniques
11:10
at the end of the week, end of the day,
11:13
reflect on what levels I flew at. Did
11:16
these oper did my time at these levels
11:20
help to better my company, better my
11:22
team?
11:24
or was I just leaning into what I find
11:28
easier or natural to do first?
11:33
So, your own flight plan is probably
11:35
going to is depends a lot on your own
11:37
proclivities and where you are in the
11:40
organization.
11:43
But as staff plus engineers, one of our
11:46
superpowers here is we understand code
11:49
and systems in a way that the rest of
11:53
our team or like a manager or PM doesn't
11:55
necessarily do. And we have the ability
11:58
to prototype solutions and prototype the
12:00
path to make things um accomplish our
12:03
business goal.
12:05
And um because of that with our rituals
12:10
to force our altitude checks, we can
12:12
exercise this excellent excellence in
12:15
intentional altitude setting. So it may
12:18
not be the perfect altitude at all
12:20
times, but we can set our altitude
12:23
appropriate for what our team needs from
12:25
us at that time.
12:28
And that's everything I have. Thank you.
12:33
Hey, hey, hey.
Start a conversation
Ask anything about The altitude slider: Knowing when to dive into code vs. drive the strategy
100/100 free messages remaining
AI responses may be inaccurate. Verify important information.
The altitude slider: Knowing when to dive into code vs. drive the strategy
LeadDev