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.
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.
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.
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.
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...
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 best way to be a 10x contributor is by having a team under you.
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.
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’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.
Note this is a general comment, the article itself didn't say that avoiding your weaknesses come what may is a good idea.
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'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.
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).
A robust test suite implies an exercised implementation.
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.
Everyone has a role, not everyone needs to make strategy calls.
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.
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...
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.
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.
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.
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 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".
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.
>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 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 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.
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?
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.
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.
> 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 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”.
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.