10 ms·
How Do Individual Contributors Get Stuck? A Primer (2017)
- RickS 7y agoI get stuck on stuff like this constantly, and both the symptom and cause lists feel very accurate.
- acephal 7y agoThis 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.
- natalyarostova 7y agoAlso to contribute to some other projects outside of work, with friends, or open source, in order to recognize the breadth of dev patterns.
- scarface74 7y agoThat wouldn’t help in any of the areas that the article listed. Most of the listed examples involve working in an organization with bureaucracy, dead lines, large teams, and time constraints.
- fortylove 7y agoI 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 7y ago(and vice versa)
- rconti 7y agoIt 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
- Benjammer 7y agoThis 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...
- NikolaNovak 7y agoHmm, 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.
- Benjammer 7y agoI meant quality of life at work, not work-life balance. >If manager tasks are not productive, if client's needs and wants diverge, or there's a disagreement with priorities, ... ignoring them and doing your own thing; let alone doing your own thing poorly; is not the way to go. How exactly did you get "do my own thing, probably poorly," from what I said initially? I even said the list is good advice for working in that type of structure where only executing tasks is prioritized. The article even seems to be suggesting that one should ignore all those important discussions and just focus on getting tasks done. It's just so obviously an article for "how to suck up to your manager and do only the things they care about and notice," I'm pretty confused that I'm getting criticized so harshly here. I'm not even denying that these things will materially improve performance reviews of a large percentage of "ICs" out there in the working world. I just don't like the idea that an engineer who chooses to spend a quarter focused more on helping teammates instead of crushing sprint tasks should suddenly be thought of as "stuck." Why must it be thought of as wasted time if an engineer wants to dig around in the architecture or clean up random parts of the code? Are we saying there's no way to make any of these activities pay off for the engineering org and/or the company as a whole? Like pay off directly in the "product value" sense to the same level as any explicitly assigned work. Is anything that doesn't have its value explicitly predicted in advance considered wasted work?
- deleted 7y ago[deleted]
- magwas 7y agoVery 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 7y agoOkay, 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 7y agoAn attempt at reframing a discussion, usually. A robust test suite implies an exercised implementation.
- diminoten 7y agoI'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.
- nitrogen 7y agoIf programmers keep wanting to make bad business decisions, maybe it would be better to teach them the rest of the business and turn them into engineers and tech leads.
- diminoten 7y agoSomeone's got to actually implement the design, and if they're doing that well and at speed, they don't usually have time to absorb the full context of why, and that's okay. Everyone has a role, not everyone needs to make strategy calls.
- Konnstann 7y agoThis 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%.
- deleted 7y ago[deleted]
- bytematic 7y agoIndividual Contributors here can also be Junior Engineers. I know I used to, and I see other juniors now do the same things
- pavlov 7y ago"Individual Contributor" is Silicon Valley jargon for "anyone who's not a manager". So it covers everyone from fresh grads to research fellows.
- s_Hogg 7y agoI'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.
- username90 7y agoIt 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.
- cosmie 7y agoAvoidance 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 7y ago"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 7y agoPrecisely. 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.
- jacobkg 7y ago“While almost everyone has some areas that they get overly hung up on, some people also get sloppy instead of getting stuck” So true
- daxfohl 7y agoThis is so important. Anyone with goals of being a "10x developer" (whatever that is) also needs to focus on being 0.1x stuck.
- scarface74 7y agoThe 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.
- nrb 7y agoOne underrated way to be a 10x contributor is to mentor others to make 5-10 of your 1-2x self, not including the compounding benefits that accrue as those you mentored begin to do the same (having themselves realized the value of mentorship).
- scarface74 7y agoAnd you won’t last too long if your role in the company is to crank out code and not be a mentor. You don’t have to be an official lead, you could even be lead on a project or “single responsible individual”.
- daxfohl 7y agoThat's going a little far. I work with plenty of people who have no desire to do anything but crank out code and have been doing so for 20+ years. The promotion path is slower for sure, but nobody is throwing out a great developer just because.
- scarface74 7y agoI have no problem with people who just want to crank out code, but if you spend half your time “mentoring” and not cranking out code, how will that look on your performance review? I’m officially an individual contributor at a smallish software company (20-25 developers) and while I don’t “mentor” junior developers I do have a slightly louder voice when it comes to architectural and infrastructure decisions just because of my experience (I’m a recovering dev lead from another company). But I fight every week with a project manager who is just interested in getting stories complete when everyone looks to me to answer infrastructure/AWS questions - including CxOs.
- fendrak 7y agoCached: https://webcache.googleusercontent.com/search?q=cache:wkT294QCcR4J:www.elidedbranches.com/2017/01/how-do-individual-contributors-get.html https://webcache.googleusercontent.com/search?q=cache:wkT294...
- huherto 7y agoNice list. I almost want to pin it in front of me. It should include reading HN.
- WhompingWindows 7y agoYeah 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.
- WalterSear 7y agoIt'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.
- unkulunkulu 7y agoSounds wonderful and just the right focus. I would like to try it as soon as possible
- w0rd-driven 7y agoI’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.
- michael_j_ward 7y agoI am interested.
- BeetleB 7y ago> 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.
- the_watcher 7y agoThis 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.
- egypturnash 7y agoIMHO 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.
- tejtm 7y agoTraditionally, in the back by non-contributing individuals.
- Benjammer 7y agoI 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 7y agoSo 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.
- deleted 7y ago[deleted]
- dlphn___xyz 7y agoyou could follow everything in this article but without sponsorship from upper management you're not going to move past the staff level
- meristem 7y agoThe 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 7y agoMaximizers 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).