
How Do Individual Contributors Get Stuck? A Primer (2017) - luu
http://www.elidedbranches.com/2017/01/how-do-individual-contributors-get.html
======
acephal
This article really underlines how important it is to work at the _right_
place early in your career, or else you'll get railroaded by bad habits and
judgement reinforced by a lack of guidance if you're not an intuitive
wunderkind with discipline. I'm 4 years into my career and I sense more than
ever that I still fall into these traps.

~~~
fortylove
I agree with your statement, but I would change it to the _right team_. Even
great places have teams that aren't high performing, and landing on one of
those can hinder your learnings/career.

~~~
svachalek
(and vice versa)

------
Benjammer
I think it's also very important to realize that sometimes the feeling of
being "stuck" is just generalized anxiety, impostor syndrome, lack of clear
success criteria for your role, or some other composition of any number of
myriad contextual factors in play.

The idea that one should identify these time-sinks, and then that's the end of
the road, is such a manager-centric lens on this. When your final output is
just written feedback for someone else, I guess it's possible to stop here and
still fulfill the letter of your job duties.

~~~
btown
So Camille's book and other writings give a lot more context on this - these
are things to do as a manager _iff_ you have identified that getting an IC
"unstuck" _is_ the limiting factor for them to be able to reach success
criteria, for them to see their own success made incontrovertible in the
team's eyes and in their own. Saying a manager's "output is just written
feedback" does the role, and her take, a disservice - her very first chapter
describes good managers as ones "who care about you as a person, who actively
work to help you grow in your career." So take the post as what it is - one of
many tools in a toolkit for being an effective leader.

------
WalterSear
It's not just developer thing: IMHO, it's universal condition.

IMHO, productivity tools should do more to help us stay on task: they should
help with all aspects of cognition - from capturing ideas, to making plans, to
making good on those plans. Fundamentally, productivity tools need to evolve
to help us deal with the emotional components of 'getting unstuck'. It's the
biggest problem, at least for me.

Which is why I'm currently stuck myself :) I've _almost but not quite_
finished an MVP of a task management tool that addresses those things, via
techniques taken from CBT and DBT therapy. I'm 80%-90% from a public release,
having just brought in a designer to help make the MVP more attractive and
building an approachable FTE for someone who's seeing this for the first time.

If anyone is interested, the first draft of the landing page is at
[https://catchthinkdo.com](https://catchthinkdo.com) . I'm not opening signups
yet, but if anyone is interested, let me know here, and I'll ping you when I
actually launch. Fwiw, I'm not planning on charging my initial users, in
perpetuity.

~~~
BeetleB
> IMHO, productivity tools should do more to help us stay on task: they should
> help with all aspects of cognition - from capturing ideas, to making plans,
> to making good on those plans. Fundamentally, productivity tools need to
> evolve to help us deal with the emotional components of 'getting unstuck'.
> It's the biggest problem, at least for me.

I've not seen any good solution (technological or otherwise) for meaningfully
sorting all the information you've captured and prioritizing. There are plenty
of ways to capture well (Org Mode!). In my experience, the _more_ you capture,
the _worse_ things get. Until someone can come up with a scheme (need not be
technological) to handle all that I've captured, /and/ in a manner that
doesn't consume time, then you've got a solution.

One common approach is to timestamp things and just let anything beyond a
certain date expire if you've not "handled" it. I honestly did not try it -
probably should. The main concern would be that expired things will recur in
my brain again and be captured later - over and over - a problem in and of
itself.

~~~
mntmoss
I have to agree. I haven't found major improvements in projects/life goals via
higher quantities of data capture, but I have found them through better-tuned
filters, queuing and signalling.

With respect to stuckness, I have a kind of rule of thumb for everything
creative now, which I can phrase as "underachieve twice over". The first time
I capture somewhat less than the essentials of the thing I want to address,
but require at least one; the second time(third, fourth, etc.) I plow forward
and build another iteration on that, adding more of the requirements.

It's not different from estimation or calibration in any other sense, it's
just that there is an element of following through on a bulk of knowable,
ordinary work in order to collect the important data, instead of sitting there
perplexed and avoidant when I don't instantly understand the whole of it.

------
jacobkg
“While almost everyone has some areas that they get overly hung up on, some
people also get sloppy instead of getting stuck”

So true

------
Konnstann
This sounds exactly like how I get stuck. As the sole developer on a team of
pretty much all biologists, all of these things come into play constantly.
Especially that bit about the last 10-20%.

~~~
ptmcc
You know what they say: the first 80% takes 80% of the time, and the last 20%
takes the other 80% of the time.

~~~
falcor84
Well, they usually say it with the figure being 90% ;)

[https://en.wikipedia.org/wiki/Ninety-
ninety_rule](https://en.wikipedia.org/wiki/Ninety-ninety_rule)

------
egypturnash
IMHO it is very useful to be able to recognize why you are stuck on a thing
yourself, too. There are different flavors of stuck - in my comics work, the
resistance I feel when I need to sit down and do some serious plotting is
different from the resistance I feel when I need to go design some stuff, for
instance.

The sooner you can recognize exactly what flavor of stuck you are, the sooner
you can switch mental gears into dealing with whatever needs to be done before
you can progress.

------
daxfohl
This is so important. Anyone with goals of being a "10x developer" (whatever
that is) also needs to focus on being 0.1x stuck.

~~~
scarface74
The 10x developer - individual contributor -is not quite a unicorn but so
close to it it might as well be.

The best way to be a 10x contributor is by having a team under you.

~~~
solidasparagus
The best way to be a 10x developer is focusing on the right work. If we take
the 80/20 rule to be true (20% of the work delivers 80% of the value), that
means the person who is working on the valuable 20% gets 16x more value from
each hour they work than someone who is working on the less valuable 80%.

~~~
scarface74
The developer - the individual contributor - rarely gets to decide what the
“right work” is in any large organization.

~~~
solidasparagus
Then choose the right job.

~~~
scarface74
So which job do you know of where the developer gets to prioritize what to
work on over the business people?

When that happens you end up like Google and have a new failing chat app every
week or like the 1990s Apple with research projects that never ship.

------
RickS
I get stuck on stuff like this constantly, and both the symptom and cause
lists feel very accurate.

------
huherto
Nice list. I almost want to pin it in front of me. It should include reading
HN.

~~~
WhompingWindows
Yeah seriously. First tendency of mine when stuck? Mess around on the web on
SO or HN, get sucked into some rabbit hole that is no longer about what I was
stuck on.

------
s_Hogg
I'm still amazed at how tech culture seems to think that avoiding your
weaknesses altogether is unambiguously good. Maybe to some extent makes sense,
but as a blanket rule surely it just develops learned helplessness in people?

Note this is a general comment, the article itself didn't say that avoiding
your weaknesses come what may is a good idea.

~~~
cosmie
Avoidance as a compensation strategy for weaknesses isn't particular to just
tech culture; it exists in pretty much every discipline.

I've taken the opposite approach: from what I went to school for to how my
career has developed, I've generally made choices that allow me to capitalize
on my strengths while shoring up my weaknesses. And along the way I've
recognized that such an approach in itself is a strength of mine, as not
everyone that attempts to do so can be successful at it.

It's also a meandering path to success. At least from a professional
standpoint, it's far more straightforward to avoid your weaknesses and hone
your strengths. And such specialization is embodied in the organizational
structures of most businesses.

~~~
XorNot
"Challenging yourself" is risky and no guarantee of self improvement though.
You can spend a lot of time thinking something is hard, when really you're
just in a bad environment.

~~~
cosmie
Precisely. This is part of what I meant by being able to take this route is a
strength in itself. It takes a high degree of situational awareness and a
significant amount of self-awareness to be able to suss out the differences
between environmental factors and personal, and take deliberate action to
maneuver yourself into an environment where you can be successful as-is yet
still work to strengthen (or at least blunt) your weaknesses.

------
meristem
The primer reads to me as "Things maximizers do"[0]. I'm left to wonder if
developers with a satisficer bent get stuck at all, or in those same ways.

[0]
[https://en.wikipedia.org/wiki/Maximization_(psychology)](https://en.wikipedia.org/wiki/Maximization_\(psychology\))

~~~
alwaysdoit
Maximizers and satisficers use approximately the same approach with a
different threshold for the amount of the possibility space they are willing
to search through (let's call it p).

Let's eliminate the extremes:

p = 0 is a blob who just doesn't do anything.

p = 1.0 only ever keeps looking at new possible options. Since the space is
almost always infinite, this approach never terminates.

p = 0.01 just does the first thing that comes to mind

p = 0.99 spends an very, very long amount of time evaluating options

People tend towards different thresholds. But the right p value depends on the
context. Sometimes the first thing that comes to mind--the naive approach, is
in fact the right thing to do. If you're building something lower level that
will be built upon later and difficult to change, more caution is often
warranted.

The approach through the possibility space also matters--identifying the
places to explore that might reveal the most risky aspects of the problem
quickly is a skill developers build over time (often via past mistakes they
later regretted).

------
the_watcher
This is a really useful framework. It's pretty obviously useful for providing
peer feedback, but it can pretty easily be used for self reviews or for
identifying strengths and growth areas. Bookmarking for the future.

------
fendrak
Cached:
[https://webcache.googleusercontent.com/search?q=cache:wkT294...](https://webcache.googleusercontent.com/search?q=cache:wkT294QCcR4J:www.elidedbranches.com/2017/01/how-
do-individual-contributors-get.html)

------
dlphn___xyz
you could follow everything in this article but without sponsorship from upper
management you're not going to move past the staff level

------
bytematic
Individual Contributors here can also be Junior Engineers. I know I used to,
and I see other juniors now do the same things

~~~
pavlov
"Individual Contributor" is Silicon Valley jargon for "anyone who's not a
manager". So it covers everyone from fresh grads to research fellows.

------
magwas
Very useful, thank you. But... Sidetracked by refactoring and testing?
C'mon... The rules of profession for programmers include the rules of TDD. If
you do TDD correctly, you cannot be sidetracked by those, because this is your
main job. Production code is mostly written by the IDE, by pressing Ctrl-1.

~~~
diminoten
Okay, so what would you call someone who delivers half of the functionality
they're asked to deliver, but has instead created a _very_ robust test suite?

~~~
eropple
An attempt at reframing a discussion, usually.

A robust test suite implies an exercised implementation.

~~~
diminoten
I'd call them an underperformer. At some point it no longer is your job to
reframe a discussion, it's your job to write code.

One tends not to make money off a reframed discussion, and besides,
programmers often have a _very_ poor view into the rest of the business, so a
programmer taking it upon themselves to decide how the business should be run
is a programmer who will find themselves without a job after a short while.

~~~
eropple
I think I was unclear. I was not referring to a hypothetical developer. I was
characterizing your caricature as that reframing of the discussion because the
way you're approaching this verges on disingenuity.

~~~
diminoten
Ah yes, taking a comment not about you and making it about you. This feels
like a productive way to handle online conversations. I'm sure you're going to
be a productive person to engage with...

------
Benjammer
This all seems like an incompetent manager complaining about their IC working
on quality-of-life things instead of 100% focusing on getting tasks done for
the manager.

Should be titled "How IC's avoid being commoditized task monkeys."

This isn't to say at all that these points don't have a lot of merit when
working within a "task monkey" org structure...

~~~
yowlingcat
I don't like appealing to authority, but I'll make a note for you that Camille
Fournier is conventionally a pretty accomplished engineering manager and
leader, and her blog Elided Branches is full of tons of what I find to be
really well thought out advice from both sides of the coin. It might make more
sense to consider this post not in isolation, but in context of her previous
posts. Certainly, this could be understood to be building on her previous
thoughts there. But, you know what? As I've written this comment, I've
realized that I do agree with some part of the spirit of your comment. I'll
take a stab at addressing what you're pointing out:

While I think that this post is meant to be a map for managers or tech leads,
I find its conclusion to be unfortunately lacking:

> Noticing how people get stuck is a super power, and one that many great tech
> leads (and yes, managers) rely on to get big things done. When you know how
> people get stuck, you can plan your projects to rely on people for their
> strengths and provide them help or even completely side-step their
> weaknesses. You know who is good to ask for which kinds of help, and who
> hates that particular challenge just as much as you do.

> The secret is that all of us get stuck and sidetracked sometimes. There’s
> actually nothing particularly “bad” about this. Knowing the ways that you
> get hung up is good because you can choose to either a) get over the fears
> that are sticking you (lack of knowledge, skills, or confidence), b) avoid
> such tasks as much as possible, and/or c) be aware of your habits and use
> extra diligence when faced with tackling these areas.

To a manager that is actively interested in mentoring and growing their
engineers, this is horrible advice, frankly. It's horrible because it's
essentialist, and it's not going to help you as a manager. The obvious first
answer is "it depends" and "get more detail" \-- rather than resigning
yourself to the current state of who "is good to ask for which kinds of help,
and who hates that particular challenge just as much as you do" it is better
to figure out why things are a certain way for a certain individual getting
stuck.

Is it specific to them? Are there team to team dynamics getting in the way? Is
a particular manager not integrating well into the rest of the org, and so
their team takes the heat? Is another individual contributor within the org or
team stonewalling them, perhaps unintentionally? Are the requirements unclear,
changing, or in need to refinement?

Without understanding this underlying context, it's impossible to get a sense
for the institutional foundation your report or colleague is develeoping,
evolving in, being rewarded and punished in. It's perhaps the most important
part about developing an effective response as a leader -- you need to figure
out the extrinsics that are shared before you can untangle that from the
intrinsics, or you'll probably risk conflating the former with the latter.

Perhaps, though, these kinds of utopian organizations exist where every
problem an IC encounters is due to a lack of development or intrinsic ability
that they must either work past or accept, and these other kinds of things
I've pointed out never occur. I've certainly worked at smaller organizations
where, due to sheer lack of complexity, these things aren't as big of a
problem. But, at larger orgs, these things have always become an issue. As
such, a huge amount of this blog post could be distilled into the values and
skills of prioritization, thoughtfulness, curiosity, and communication. If you
notice your teammates or reports having these issues, you should figure out
which of one of these things you can help them with. This is mentorship work
and coaching work -- it's high effort, high nurturing, high reward work. Once
people feel supported and safe, they become orders of magnitude more effective
at self-debugging any of these lower level issues she points out.

~~~
Benjammer
Thank you for replying earnestly to what was probably an overly emotional and
flippant response to this article from me to begin with.

I couldn't possibly agree more with your description of subjective management,
and the underlying context questions to explore with each subject
individually. IMO, people management is literally the most subjective
generally-applied skill on the planet.

The reason that I came off like that in my initial comment is that the article
gives me (an IC) the feeling of a manager expressing frustrations with ICs, in
a way where it's mostly that the person seems to be frustrated that ICs are
actually individual humans with subjective interests as well as competencies.
The list seems to be pointing out areas where the "human" parts of curiosity,
teamwork, and creativity poke through cracks in systems designed to treat the
ICs like interchangeable parts. It's _literally_ generalizing as the thesis of
the article itself.

It also comes off like it's written for other managers or tech leads to read
in a sort of "virtue signaling"-ish tone. It's a list of high level vague
points designed to land emotionally with other middle manager types. The only
thing this seems to be telling me as an IC is that my feelings for how to add
value are mostly wrong and I should just shut up and do what my manager says,
because my assigned tasks are far more important than anything I could come up
with on my on which to spend my time.

