How Do Individual Contributors Get Stuck? A Primer (2017)

Also to contribute to some other projects outside of work, with friends, or open source, in order to recognize the breadth of dev patterns.

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.

It doesn't always show up immediately, either. You might spend your whole career incrementally growing your skillset but never being so far outside of your comfort zone that you have the chance to get stuck

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.

Sounds wonderful and just the right focus. I would like to try it as soon as possible

I’d be interested in something like this as well. I have a discombobulated list of apps and attempted strategies to take notes and can’t seem to stick to something simple.

I am interested.

> 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.

I'm very interested, email in profile.

Have you tried complice?

90% means you're like 1/10th of the way there. It's logarithmic. Or something like that.

I'd like to try it out when you're ready to launch.

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

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.

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.

It isn't specific to tech, most people have things they decided it is ok to be bad at. Outside of tech it is very common to admit that you are bad at math or don't understand computers and so on in the hopes of getting someone else to solve the problem.

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.

Another way of saying “avoiding your weaknesses” is “playing to your strengths”.

I’m a horrible front end developer. I know the technology involved but I am not good at it and doubt that I will ever be good enough at it to command an above average salary. I’m very good at the backend from middleware down to infrastructure. Why would I focus on the front end? When I was a team lead, I contracted that out.

This is true for many areas of my personal life. I pay people to do things that I am not good at it using the money I make from doing what I am good at it.

The modern economy is all about specialization of labor.

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).

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

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?

Hmm, nothing in the article indicates that people worked on these items more than [40|45|x] number of hours a week, or that quality-of-life / outside-of-work items were the root cause.

At the end of the day, "getting tasks done for the lead/client" is the reason, goal and background for majority of people getting paid a salary in the IT and other industries. From a real-life perspective, effective focus on satisfying client's needs / executing manager's tasks is the purpose and what one is being paid for. If manager tasks are not productive, if client's needs and wants diverge, or there's a disagreement with priorities, that's certainly an important discussion to have and where persuasion skills and ability to understand bigger picture comes in handy; but ignoring them and doing your own thing; let alone doing your own thing poorly; is not the way to go.

It really doesn't.

At this point I've mentored a lot of junior engineers and scientist, and a fair number of mid-career and senior ones.

One of the most common things they bring up is "I'm getting stuck", or "I don't feel as productive as I want to be", or "Sometimes I can't seem to finish anything", "I'm not sure I'm working on the right things", etc.

The article isn't bad at outlining some of the common failure modes that nearly everyone falls into from time to time. There is nothing in there specifically about quality of life, etc. and most of it applies very well in any type of organization.

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.