How Do Individual Contributors Get Stuck? A Primer (2017)(elidedbranches.com)
elidedbranches.com
How Do Individual Contributors Get Stuck? A Primer (2017)
http://www.elidedbranches.com/2017/01/how-do-individual-contributors-get.html
87 comments
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.
Also to contribute to some other projects outside of work, with friends, or open source, in order to recognize the breadth of dev patterns.
That 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.
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
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.
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.
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.
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 . 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.
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 . 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.
> 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'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 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.
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.
90% means you're like 1/10th of the way there. It's logarithmic. Or something like that.
It does feel like a cliff.
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.
Sounds wonderful and just the right focus. I would like to try it as soon as possible
I'd like to try it out when you're ready to launch.
I'm very interested, email in profile.
Have you tried complice?
(Creator of complice.co here, summoned by HNWatcher.)
I'm glad to see this thread because yeah, most productivity apps are just organization structures that don't support metacognition at all, and so people end up in all kinds of stuck modes.
Complice is definitely better, in that for instance it has different phases for planning your day, working, and reflecting on your day, or that if you say you're going to do X today then don't do it, it doesn't just go on your list for tomorrow but instead you're prompted to break it down or come up with a new plan.
And, I think there's a huge amount of potential here that's yet to be explored, both in Complice and other systems. Relatedly, if you're familiar with developmental psychology or subject-object shifts, we've started strategizing on how to design Complice to guide people through growing into different ways of relating to the world, themselves, and their goals.
I have a different very simple workflow I use for this stuff that I call a Captain's Log. Basically it's like a journal but instead of reflecting after, you intentionally start journalling as soon as you're not sure what you're doing. Link to that: https://malcolmocean.com/2017/11/captains-log-ultra-simple-t...
I'm glad to see this thread because yeah, most productivity apps are just organization structures that don't support metacognition at all, and so people end up in all kinds of stuck modes.
Complice is definitely better, in that for instance it has different phases for planning your day, working, and reflecting on your day, or that if you say you're going to do X today then don't do it, it doesn't just go on your list for tomorrow but instead you're prompted to break it down or come up with a new plan.
And, I think there's a huge amount of potential here that's yet to be explored, both in Complice and other systems. Relatedly, if you're familiar with developmental psychology or subject-object shifts, we've started strategizing on how to design Complice to guide people through growing into different ways of relating to the world, themselves, and their goals.
I have a different very simple workflow I use for this stuff that I call a Captain's Log. Basically it's like a journal but instead of reflecting after, you intentionally start journalling as soon as you're not sure what you're doing. Link to that: https://malcolmocean.com/2017/11/captains-log-ultra-simple-t...
I am interested.
“While almost everyone has some areas that they get overly hung up on, some people also get sloppy instead of getting stuck”
So true
So true
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%.
You know what they say: the first 80% takes 80% of the time, and the last 20% takes the other 80% of the time.
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
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.
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.
This is so important. Anyone with goals of being a "10x developer" (whatever that is) also needs to focus on being 0.1x stuck.
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.
The best way to be a 10x contributor is by having a team under you.
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%.
The developer - the individual contributor - rarely gets to decide what the “right work” is in any large organization.
Then choose the right job.
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.
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.
One 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).
And 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”.
That'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.
I think scarface74 is right. At my last job, it was clear from the job descriptions that certain people (like me) were expected to spend a substantial amount of time mentoring, leading and working on higher-level tasks, and others were expected to primarily code. IIRC, the pie chart showed that I was only expected to code around 15% of my time.
But that was because the organization realized that after a certain point, the knowledge of the senior developers was best used to bring up the level of the team rather than just crank out code. If you're a dev who's expected to basically produce code all day long but you decide you'd rather spend your time helping others, you shouldn't be surprised when you take a hit on your performance review.
This isn't a problem with the organization, per se. It's a problem with a dev deciding to do something other than what he's expected to be doing.
But that was because the organization realized that after a certain point, the knowledge of the senior developers was best used to bring up the level of the team rather than just crank out code. If you're a dev who's expected to basically produce code all day long but you decide you'd rather spend your time helping others, you shouldn't be surprised when you take a hit on your performance review.
This isn't a problem with the organization, per se. It's a problem with a dev deciding to do something other than what he's expected to be doing.
I 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.
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.
I get stuck on stuff like this constantly, and both the symptom and cause lists feel very accurate.
Nice list. I almost want to pin it in front of me. It should include reading HN.
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.
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.
Note this is a general comment, the article itself didn't say that avoiding your weaknesses come what may is a good idea.
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.
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.
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.
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.
"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.
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.
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)
[0] https://en.wikipedia.org/wiki/Maximization_(psychology)
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).
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).
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.
[deleted]
[deleted]
you could follow everything in this article but without sponsorship from upper management you're not going to move past the staff level
[deleted]
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.
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?
An attempt at reframing a discussion, usually.
A robust test suite implies an exercised implementation.
A robust test suite implies an exercised implementation.
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.
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.
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.
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...
If 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.
Someone'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.
Everyone has a role, not everyone needs to make strategy calls.
Sure, but it's easier to stay motivated and effectice in whatever role you have when you have enough context. And some roles are too small for some people as they develop in their careers.
I totally agree, however there are only 8 hours in a work day, and programmers need to understand that their 8 hours have to be focused on producing code, not on understanding the business, if the choice ever does come up (and it ought to).
Pretending like every single employee needs to have a complete view of the entire business is absurd, I hope that's not what you're suggesting.
Pretending like every single employee needs to have a complete view of the entire business is absurd, I hope that's not what you're suggesting.
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...
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...
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.
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.
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.
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.
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.
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.
But the article isn't talking about individuals and their anxiety as it relates to work process. It's literally saying that an IC who is too fixated on the architecture might spend too much time digging into tech debt and "get stuck" on assigned task work. Do you find that this type of person in the one who comes out and says that they don't feel productive? It just seems like the opposite of "I feel stuck how can I not feel stuck anymore." It's more like "these are ways where ICs might lose track of the bigger picture and get off task in a way that hurts team productivity."
Are you really saying that an IC who spends enough time on mentoring/tech debt/on-call fires that it's impacting their task completion is going to throw their hands up in the air and say "I can't figure out why I'm not getting more tasks done"?
Are you really saying that an IC who spends enough time on mentoring/tech debt/on-call fires that it's impacting their task completion is going to throw their hands up in the air and say "I can't figure out why I'm not getting more tasks done"?
I guess partially I am, particularly with junior people. Although often they don't really track their time precisely enough to see where it is going.
I say partially because much of the time it isn't "I'm not getting assigned tasks done". With junior people it's often "I don't know why /my estimates are off/i am slow/i get stuck/". With more senior people it often boils down to "How can I have more impact".
I say partially because much of the time it isn't "I'm not getting assigned tasks done". With junior people it's often "I don't know why /my estimates are off/i am slow/i get stuck/". With more senior people it often boils down to "How can I have more impact".
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.
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.
I 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?
>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?
Because at the end of the day, most of us go to work to get money deposited into our account. Why wouldn’t you optimize your time at work to achieving that goal?
That's a good way to prioritize if you're desperately poor, if you have a chance of a quick life-changing payoff, or if you urgently need money for a family member’s medical treatment. Most of the rest of us will do better if we prioritize other things over getting money.
If you're old, you should probably prioritize making your time enjoyable, and finishing up whatever projects you want to finish before you die. Time is shorter than you think, and an unexpected heart attack can take productive years from you even if you don't die from it. Money is worthless to you if you don't spend it before you die. This doesn't align particularly, or sometimes at all, with employment.
If you're young, most of your earnings are in the future. To the extent that you can trade off $1000 now for $100 every year of your working life, you should. Your future earnings depend on your skills, on your reputation, and on your relationships with your coworkers, not on your manager, unless you're working at Google and don't plan to leave. Your workplace is much more valuable as a source of learning opportunities, mentorship, and connections, than as a source of money. It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
If you're old, you should probably prioritize making your time enjoyable, and finishing up whatever projects you want to finish before you die. Time is shorter than you think, and an unexpected heart attack can take productive years from you even if you don't die from it. Money is worthless to you if you don't spend it before you die. This doesn't align particularly, or sometimes at all, with employment.
If you're young, most of your earnings are in the future. To the extent that you can trade off $1000 now for $100 every year of your working life, you should. Your future earnings depend on your skills, on your reputation, and on your relationships with your coworkers, not on your manager, unless you're working at Google and don't plan to leave. Your workplace is much more valuable as a source of learning opportunities, mentorship, and connections, than as a source of money. It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
The problem is taking a low salary at the start limits the increases you can get for the rest of your career and your also ignoring the time value of money.
Don't tell future employers or clients your previous salary; then it won't limit the increases. (Again, not applicable if you're at a company that it's reasonable to work at for your whole career, but I'm assuming that's not the case.) What will limit the increases you can get are things like staying at the same company too long, living in an economically depressed area or in Britain, ex-coworkers who don't want to work with you again, a résumé with 10 years working on a shitty project in a forgotten language, and not being able to deliver results to clients and employers.
The time value of money is maybe 5% per annum. Your skills are a much better investment than that; you should be able to average 10% per annum increases early in your career, mostly by switching jobs for a 25% raise or more. And remember that things like living expenses don't accrue investment income the way savings do. A 35% raise means more than a 35% increase in your savings per year. So focusing on immediate earnings is not justifiable based on the time value of money, at least for most of us.
The time value of money is maybe 5% per annum. Your skills are a much better investment than that; you should be able to average 10% per annum increases early in your career, mostly by switching jobs for a 25% raise or more. And remember that things like living expenses don't accrue investment income the way savings do. A 35% raise means more than a 35% increase in your savings per year. So focusing on immediate earnings is not justifiable based on the time value of money, at least for most of us.
Why would “prioritizing my projects” include working for less than market wage for a for profit company?
And how much career growth and future financial returns do you expect to get from doing PHP for WordPress?
Also looking at their salaries after their “trial” they still pay much less than a bog standard Enterprise Developer in Atlanta with 5-7 years of experience. You can do that without having to do a “trial”
I’ve already paid my dues. Why would I spend 3 months of my life making less in 2019 than I did in 1999?
And how much career growth and future financial returns do you expect to get from doing PHP for WordPress?
Also looking at their salaries after their “trial” they still pay much less than a bog standard Enterprise Developer in Atlanta with 5-7 years of experience. You can do that without having to do a “trial”
I’ve already paid my dues. Why would I spend 3 months of my life making less in 2019 than I did in 1999?
Perhaps I'm misunderstanding your comment, but your parent wrote a well thought out comment, and your response shows not indication of having read it, to the point that I'm wondering if you happened to respond to the wrong comment?
The part about:
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,"
As an employee - especially as an individual contributor - your manager is the company. They have the ability to suggest raises to your company, assign you the plumb projects, etc.
You should optimize so that your goals are your managers goals.
Even if your manager prioritize “quick” vs “right” because he knows his manager is more concerned with the company surviving long enough to get the next round of funding/exit/looking good to the shareholders.
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,"
As an employee - especially as an individual contributor - your manager is the company. They have the ability to suggest raises to your company, assign you the plumb projects, etc.
You should optimize so that your goals are your managers goals.
Even if your manager prioritize “quick” vs “right” because he knows his manager is more concerned with the company surviving long enough to get the next round of funding/exit/looking good to the shareholders.
> You should optimize so that your goals are your managers goals.
Which was addressed with:
> Your future earnings depend on your skills, on your reputation, and on your relationships with your coworkers, not on your manager, unless you're working at Google and don't plan to leave.
Replace Google with any company.
And:
> It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
Focusing overly on pleasing your manager reminds me of "penny wise, pound foolish". My experience matches his. If you want to rise within a company, then yes, please your manager. And if your manager is decent enough, your and your parent's approach are aligned. But all too often (and more often at larger companies), what is good for the manager is only good for you in the short term. A lot of managers want you to focus on the immediate needs, and do not value skills development, for example. I've seen managers where the path to promotion was to become really, really good with an in-house tool, and with in-house processes. Those who stuck to that job often tell me now that they have trouble finding any job outside because their experience was not valuable.
Which was addressed with:
> Your future earnings depend on your skills, on your reputation, and on your relationships with your coworkers, not on your manager, unless you're working at Google and don't plan to leave.
Replace Google with any company.
And:
> It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
Focusing overly on pleasing your manager reminds me of "penny wise, pound foolish". My experience matches his. If you want to rise within a company, then yes, please your manager. And if your manager is decent enough, your and your parent's approach are aligned. But all too often (and more often at larger companies), what is good for the manager is only good for you in the short term. A lot of managers want you to focus on the immediate needs, and do not value skills development, for example. I've seen managers where the path to promotion was to become really, really good with an in-house tool, and with in-house processes. Those who stuck to that job often tell me now that they have trouble finding any job outside because their experience was not valuable.
If you replace Google with almost any company, you're going to have a pathetically poor career if you stay there for your entire career, whether you measure by earnings, by lasting achievement, or by working conditions. There are a few exceptions.
How much “skills development” do you think you will achieve by going against your manager’s goals? You won’t last long enough at the company to do too much of anything.
If your manager is of the type that stunts your skills development, it’s time to leave the company. Don’t get me wrong, I’m all for Resume Driven Development but I’m not going to go against my manager and not be seen as “team player”.
If your manager is of the type that stunts your skills development, it’s time to leave the company. Don’t get me wrong, I’m all for Resume Driven Development but I’m not going to go against my manager and not be seen as “team player”.
> How much “skills development” do you think you will achieve by going against your manager’s goals? You won’t last long enough at the company to do too much of anything.
Why are you speaking in binaries? I don't think anyone here is advocating "going against your manager's goals".
Not "focusing overly on pleasing your manager" is very different from "going against your manager's goals". There's a lot of area in between. And my experience in a big company that's not a startup: In most cases not focusing on pleasing your manager will not result in a job loss, and most managers simply do not expect to have more than 1 or 2 people in the team who'll focus on pleasing them.
And if you are in a situation where not overly pleasing your manager means losing your job, then you and your parent are in agreement. What he said:
> It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
What you said:
> If your manager is of the type that stunts your skills development, it’s time to leave the company.
Which was why I was wondering if you meant to respond to someone other than kragen.
Why are you speaking in binaries? I don't think anyone here is advocating "going against your manager's goals".
Not "focusing overly on pleasing your manager" is very different from "going against your manager's goals". There's a lot of area in between. And my experience in a big company that's not a startup: In most cases not focusing on pleasing your manager will not result in a job loss, and most managers simply do not expect to have more than 1 or 2 people in the team who'll focus on pleasing them.
And if you are in a situation where not overly pleasing your manager means losing your job, then you and your parent are in agreement. What he said:
> It's worth putting up with bad working conditions in exchange for learning opportunities, but not for mere money.
What you said:
> If your manager is of the type that stunts your skills development, it’s time to leave the company.
Which was why I was wondering if you meant to respond to someone other than kragen.
I didn't write that.
I have no idea what you're talking about. WordPress? Atlanta? Who? Maybe you meant to respond to someone else's comment.