8 ms·

What Shape Are You?

230 points by neilkakkar 6y ago

quickthrower2 6y ago
Great article. I like this metaphor and way of thinking
rembicilious 6y ago
Interesting ideas. I wonder how much of this translates to product development. From the perspective of the person assembling the product the work is all additive. Fitting the product to meet customer requirements is more of a subtractive effort. Like popping items off a list.
- exmadscientist 6y ago
  My experience in NPD (New Product Development) is that this article applies pretty much exactly as written, since the NPD part of a NPD project is more or less 100% subtractive. Additive work really has a certain 19th- or 20th-century feel to it. It often involves a clock ("my job is to be the receptionist for these 8 hours") or basket ("my job today is done when I've filled/emptied this basket of TPS reports"). The car assembly example from the article is of this type: the job is to fill the (not actually physical) basket with as many cars as possible, in a shift.
biren34 6y ago
I really like this way of thinking. For entrepreneurs, you could even go far as "all the work" being to subtract all the key risks/unknowns. It's not about building a product (i.e. writing code or designing/manufacturing physical stuff), it's about making a list of all the reasons your idea won't work and then subtracting them all as cheaply and quickly as possible. This is definitely something I wish I could back and beat into 20-year old me. It would have saved me so much time and effort between then and now.
- codetrotter 6y ago
  How old are you now?
  - biren34 6y ago
    42
- egsmi 6y ago
  It’s an interesting thought exercise but there are reasons a product may not work that are not necessarily under your control.
  - biren34 6y ago
    It may be true in some cases, but it's just a mental model--and all models are wrong. Some are useful. Worrying about things out of your control--once you've decided to move forward--is not useful. If you can't stop yourself from doing that, you're probably not cut out for life at an early stage start up. That's not a dig--it's just means you should seek opportunities that better fit you.
mnsc 6y ago
I like this and it got me thinking about the part where the author talks about the the huge _space_ of work that we _start_ with and by the _time_ we're _done_ someone had done all the work in that space. For me this is a good way of thinking when talking about performance and these shapes sure do make much more sense than a bunch of Dnd stats. But taking time into consideration and how things always change it's easy to see how software development isn't always about convergence and subtraction. You may have roles that when they are underperfoming they add work, needless work, to the project. I'm of course talking about the grand architects. The ones that during the project decide, "this isn't working we need to make our solution less coupled and this is my new kinda micro service oriented way of doing things" which totally changes the work space and might introduce subtle holes that no current shape in the project covers even though they all covered the previous work space. But if the grand architect is right, the change could shrink the work space and convergence sped up but then some shapes might be redundant which is another challenge.
threwawaysoff 6y ago
Oh hey, it's the pickup artist guy. lol.
- briansharp 6y ago
  Well, he's my close friend and reblogged that post, but the post is mine. I wrote a follow-up to it, at madeofmetaphors.com, though haven't written in eons...
  - fouc 6y ago
    I found it at https://madeofmetaphors.com/shapes https://madeofmetaphors.com/shapes but blog seems a bit broken (cdn.sett.com issues I guess)
    - briansharp 6y ago
      Ugh he migrated sett a while back and I bet I was doing some bad hardcoding somewhere. Hmm, maybe I'll make some time to try and fix it up. Thanks for letting me know!
  - dotmanish 6y ago
    Thank you for the posts. Do you write / post anywhere else publicly at all now? These were interesting perspectives.
  - jimmydddd 6y ago
    Thanks for clarifying. I was very confused because I follow Tynan and this did not at all seem to correspond with his background. :-) Edit--Oh, I see you listed as the author at the top. Just unususal that it doesn't say "guest post" or the like.
- fouc 6y ago
  Yeah, almost 20 years ago.
didibus 6y ago
The work is substractive I guess only when projects are very clear in what needs to be done, which maybe is the case in gaming? Otherwise I'd say projects are more inventive, because in my experience requirements are never clear. I'd also say if you work on an existing system, that's already used in production, then work can definitely be additive, because quality starts to matter a lot more, as well as cost cutting, so robust code, performant code, code that doesn't require the team size to double every year to manage its increasing complexity, etc. do add value. I do think the author has a point though with the weird shapes. The thing is, you have to put yourself in the shoes of your manager, what are they on the hook for? Once you start to understand what they're on the hook for, you get to have a better perspective on what your time should be spent on in order to get them off the hook for whatever they were on the hook for. That will get you to understand priorities, and what work matters and doesn't.
- burntoutfire 6y ago
  > The work is substractive I guess only when projects are very clear in what needs to be done, which maybe is the case in gaming? Hah, gaming is by far one of the worst fields in terms of fuzzy requirements. Your only requirement is to make the game fun/interesting and who knows how to really accomplish this - so you basically explore the solution space until you hit something good or run out of time/money.
unwind 6y ago
Meta: title should have "(2011)" in it. Not very important for this kind of content, I guess, but still helpful.
strogonoff 6y ago
> Creative endeavors are not additive. They are iterative, convergent processes, and so they are subtractive: you work until you have converged, and then you stop. Subtractive implies few, if any, unknowns. If you are chiseling away at a well-defined spec along a well-trodden implementation path as part of a large team (as creative as such an endeavor might be), maybe. The smaller the team, the less charted your territory is, the more it becomes about jigsaw pieces fitting together despite individual irregularities. One piece can cause a rather disproportionate effect at the outcome.
- rocqua 6y ago
  Just because something is subtractive doesn't mean the boundaries are clear. The point is, at some point in the future, the project will be done. Even if we don't know the boundaries of that, you can still locally look and decide "I have developed expertise here, which means I am the best or even only person to do this other part." There is an interesting discussion about recognizing the boundaries of the project, but that is also very much an issue someone with an additive mindset has. If you believe you are creating value, you will happily start doing work that falls outside the boundaries of what is needed, whilst leaving behind other things that really need to be done.
  - username90 6y ago
    So making a car is subtractive work? At some point in the future the work is done and the car shipped. Doesn't seem like a useful construct, everything is subtractive then. Just like a software project if someone does shoddy parts of the car it will greatly detract from the value of the car even if the other 99% are in stellar condition. That is true for almost everything, the weakest link mostly determines the quality of your product so to ship good products you need to ensure nobody does shoddy work. The work is still additive though, just that producing shoddy pieces is negative value if quality is so low that it makes the product unsellable.
    - jdbernard 6y ago
      I think there is a difference in the concepts the author describes that comes from the fact that in the car manufacturing process, the goal is to produce a large number of cars. So someone can continue to linearly add value by producing more of the same thing. Your value is based on the sum of your total output. To contrast with software: you reach a point where continuing to crank out more of the same doesn't actually create value. Your value is based on how much of the overall body of work you addressed. How big of a piece did you take out from the whole pie. Personally, I'm still thinking over the additive/subtractive concept. It does seem like you could reframe a problem either way. Include a daily quota and the car example becomes subtractive.
Tade0 6y ago
My rite of passage as a senior developer included starting to ask myself the question: does activity X really move the project forward? But there's another side to this, of which management is often not made aware of: in longer projects people tend to accumulate, for lack of a better word, "rituals" - stuff that's done manually, even though it should've been automated or dropped. These are insidious, because they slow down work, introduce inconsistencies (sometimes even errors), but are largely ignored. And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. From almost every place I worked at I only stay in touch with one person - that person.
- yowlingcat 6y ago
  > And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. > From almost every place I worked at I only stay in touch with one person - that person. Wow. I thought I was the only one.
- xvector 6y ago
  > And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. My experience too. 'Those people' have a refreshing honesty and no-bullshit attitude.
  - Tade0 6y ago
    Last year I witnessed a code review war between a "good shaped" and "bad shaped" developer. He latter eventually won, because it appears that the "good practices" the former so zealously enforced were actually just his practices, and only made sense in the context of his own habits.
- drewcoo 6y ago
  Laziness, impatience, and hubris are Larry Wall's three virtues of a programmer. I think you just hit on all three.
- watermelon59 6y ago
  I’m that person in my current team and it feels very lonely. I keep speaking up about our tech debt and poor processes. Management pretends to care but nothing changes. Meanwhile people keep doing the rituals as you say, as if it were a normal part of life. It’s sad to watch.
JoeAltmaier 6y ago
This reads strangely like a manager's fable about how his underlings don't do all his work for him. Their 'shortcomings' are how they don't get the boss' paperwork done, or write simple enough summaries of their work so the manager can hit 'forward' on his email to the boss. I've been there too many times to count. But maybe its just me.
- whatever_dude 6y ago
  I didn't get that impression at all. I'm purely an engineer who 100% prefers being hands on; now that I accidentally have to manage teams, I fully appreciate the article's perspective. I've been on both sides of that argument as well. It's not about a manager expecting an underling to get his paperwork done. I think that is an unfair assessment of the argument being made. It's that there's more involved to the job of engineering than simply pushing code one thinks is clever. Sometimes that means knowing which problem to focus (not just the fun ones), sometimes that means dealing with other responsibilities like mentoring or interviewing or filling up timesheets or getting to work on time or attending meetings or what have you. None of those are unreasonable requests (as much as we hate them). If it's part of the job description, it's part of the job, and, for example, making a piece of code conform to one's own subjective preferences so they can feel clever doesn't make up for missing a deadline on a separate, boring, high priority task. I've frequently seen engineers who think otherwise. Who think their work is so brilliant, they don't need to care about the boring stuff. Some of them have indeed been brilliant. But guess what; they still need to get their shit together, because their brilliance is still objectively not making up for being unreliable.
  - JoeAltmaier 6y ago
    Who writes that job description? Is it right to expect an Engineer to do the managers' work too? (Short answer: no) People are all different. Its up to a manager to get the best from each. Harping on TPS reports is not the way to get there.
    - whatever_dude 6y ago
nine_zeros 6y ago
This is a good post and I have been Nick a few times. I have felt the anger and shock that Nick faces. My gripe was that if management wants me to handle all aspects of a project, why can't they just spell it out? What about communicating this to other stakeholders? Do I barge into meetings and tell people in sister teams to drop their other work and start listening to me because Gloria asked me to change my shape to a full circle? The hand off from regular shape to wholesome shape is not obvious to Nick. And even if it was, they have no authority or power or resources to drive "others" until Gloria spells it out at least one time.
- jmercouris 6y ago
  I understand your upset and feel the same. One thing that I dislike here is this: we are starting somehow with the premise that people are malformed. The job of a manager is not to mold people into correct shapes. Unless you are dealing with trivial work, you cannot bend other intelligent beings to your tyrannical circle shaped will. If you are a triangle, the manager is supposed to help you be the best triangle you can be. They are supposed to arrange and connect the pieces of the puzzle together. Instead, this manager believes that is the managers job to mold their units into identical circles. Disgusting.
  - nostromo95 6y ago
    You are definitely misinterpreting the metaphor... ‘Shape’ != personal identity or ability. Shape is the sum of the work someone does (in fact, a triangle—if that even has any meaning over a circle in this framework—is a perfectly acceptable shape bc it’s convex and simple). If one of a manager’s jobs isn’t to coordinate what work everyone does I’m not sure what you think managers do.
    - nine_zeros 6y ago
      This. If I am handling all the work, what exactly does a manager do?
      - 6y ago
tug0fwar 6y ago
"This blog requires JavaScript for anything besides reading." I knew I was in good hands ;)
hkon 6y ago
When you must realize this yourself. What shape is the management?
pimlottc 6y ago
The key paragraph for me: > You can't truly be a senior employee until you see your work as subtractive, and until you have an intuitive feel for the set of all the work that needs to get done. Once you think in this way, you can interact with any other leader as a peer, working elbow-to-elbow, of one mind on what needs doing. Until you think in this way, without even realizing it, you are implicitly asking for those above you to insulate you from reality, to build you a little sandbox where you can work. I think we’ve all known someone on a project that needed to be carefully “contained”, while there are others who “get it” and can be left alone with worrying. To me, there is where product management is valuable, building a shared vision with the team, so everyone stays aligned and sees how their individual work supports a greater goal. Great post.
MeinBlutIstBlau 6y ago
> If Nick is junior, this is entirely Gloria's fault: it should be possible to explicitly detail out exactly what is expected from a junior employee, with no room for ambiguity. This should be screamed at every single manager to ever exist. If any entry level or junior level person is ever underperforming, management is 99% to blame. You cannot have high expectations from people who have no idea what they're supposed to be doing and are essentially just winging it. In all, I feel like that happens way more than management is ever willing to admit. It's never the musician that's bad, it's always the instrument.
raldi 6y ago
The author seems to be looking around at all the humans around him and asking, why can’t you all act just like cogs in a machine? I’ve had managers like that, and it often went hand-in-hand with poor engineering chops. Yes, of course, to a large extent big companies require just that sort of cooperation and subjugation, but if you hate fitting yourself into that mold, you’d probably be a lot happier... not working at big companies. There are lots of startups and small businesses where you can be a hard-working, high-performance contributor furthering key strategic goals, and yes, an faithful cooperator working in harmony with a tight-knit team, and nonetheless be entrusted with a domain within which you’ll be free to identify what needs to be done and take care of it without having to defend your choices to a bureaucrat who can’t see the forest for the trees.

230 points by neilkakkar 6y ago

Great article. I like this metaphor and way of thinking

Interesting ideas. I wonder how much of this translates to product development. From the perspective of the person assembling the product the work is all additive. Fitting the product to meet customer requirements is more of a subtractive effort. Like popping items off a list.

exmadscientist 6y ago
My experience in NPD (New Product Development) is that this article applies pretty much exactly as written, since the NPD part of a NPD project is more or less 100% subtractive. Additive work really has a certain 19th- or 20th-century feel to it. It often involves a clock ("my job is to be the receptionist for these 8 hours") or basket ("my job today is done when I've filled/emptied this basket of TPS reports"). The car assembly example from the article is of this type: the job is to fill the (not actually physical) basket with as many cars as possible, in a shift.

biren34 6y ago

I really like this way of thinking. For entrepreneurs, you could even go far as "all the work" being to subtract all the key risks/unknowns. It's not about building a product (i.e. writing code or designing/manufacturing physical stuff), it's about making a list of all the reasons your idea won't work and then subtracting them all as cheaply and quickly as possible. This is definitely something I wish I could back and beat into 20-year old me. It would have saved me so much time and effort between then and now.

codetrotter 6y ago
How old are you now?
- biren34 6y ago
  42
egsmi 6y ago
It’s an interesting thought exercise but there are reasons a product may not work that are not necessarily under your control.
- biren34 6y ago
  It may be true in some cases, but it's just a mental model--and all models are wrong. Some are useful. Worrying about things out of your control--once you've decided to move forward--is not useful. If you can't stop yourself from doing that, you're probably not cut out for life at an early stage start up. That's not a dig--it's just means you should seek opportunities that better fit you.

mnsc 6y ago

I like this and it got me thinking about the part where the author talks about the the huge _space_ of work that we _start_ with and by the _time_ we're _done_ someone had done all the work in that space. For me this is a good way of thinking when talking about performance and these shapes sure do make much more sense than a bunch of Dnd stats. But taking time into consideration and how things always change it's easy to see how software development isn't always about convergence and subtraction. You may have roles that when they are underperfoming they add work, needless work, to the project. I'm of course talking about the grand architects. The ones that during the project decide, "this isn't working we need to make our solution less coupled and this is my new kinda micro service oriented way of doing things" which totally changes the work space and might introduce subtle holes that no current shape in the project covers even though they all covered the previous work space. But if the grand architect is right, the change could shrink the work space and convergence sped up but then some shapes might be redundant which is another challenge.

threwawaysoff 6y ago

Oh hey, it's the pickup artist guy. lol.

briansharp 6y ago
Well, he's my close friend and reblogged that post, but the post is mine. I wrote a follow-up to it, at madeofmetaphors.com, though haven't written in eons...
- fouc 6y ago
  I found it at https://madeofmetaphors.com/shapes https://madeofmetaphors.com/shapes but blog seems a bit broken (cdn.sett.com issues I guess)
  - briansharp 6y ago
    Ugh he migrated sett a while back and I bet I was doing some bad hardcoding somewhere. Hmm, maybe I'll make some time to try and fix it up. Thanks for letting me know!
- dotmanish 6y ago
  Thank you for the posts. Do you write / post anywhere else publicly at all now? These were interesting perspectives.
- jimmydddd 6y ago
  Thanks for clarifying. I was very confused because I follow Tynan and this did not at all seem to correspond with his background. :-) Edit--Oh, I see you listed as the author at the top. Just unususal that it doesn't say "guest post" or the like.
fouc 6y ago
Yeah, almost 20 years ago.

didibus 6y ago

The work is substractive I guess only when projects are very clear in what needs to be done, which maybe is the case in gaming? Otherwise I'd say projects are more inventive, because in my experience requirements are never clear. I'd also say if you work on an existing system, that's already used in production, then work can definitely be additive, because quality starts to matter a lot more, as well as cost cutting, so robust code, performant code, code that doesn't require the team size to double every year to manage its increasing complexity, etc. do add value. I do think the author has a point though with the weird shapes. The thing is, you have to put yourself in the shoes of your manager, what are they on the hook for? Once you start to understand what they're on the hook for, you get to have a better perspective on what your time should be spent on in order to get them off the hook for whatever they were on the hook for. That will get you to understand priorities, and what work matters and doesn't.

burntoutfire 6y ago
> The work is substractive I guess only when projects are very clear in what needs to be done, which maybe is the case in gaming? Hah, gaming is by far one of the worst fields in terms of fuzzy requirements. Your only requirement is to make the game fun/interesting and who knows how to really accomplish this - so you basically explore the solution space until you hit something good or run out of time/money.

unwind 6y ago

Meta: title should have "(2011)" in it. Not very important for this kind of content, I guess, but still helpful.

strogonoff 6y ago

> Creative endeavors are not additive. They are iterative, convergent processes, and so they are subtractive: you work until you have converged, and then you stop. Subtractive implies few, if any, unknowns. If you are chiseling away at a well-defined spec along a well-trodden implementation path as part of a large team (as creative as such an endeavor might be), maybe. The smaller the team, the less charted your territory is, the more it becomes about jigsaw pieces fitting together despite individual irregularities. One piece can cause a rather disproportionate effect at the outcome.

rocqua 6y ago
Just because something is subtractive doesn't mean the boundaries are clear. The point is, at some point in the future, the project will be done. Even if we don't know the boundaries of that, you can still locally look and decide "I have developed expertise here, which means I am the best or even only person to do this other part." There is an interesting discussion about recognizing the boundaries of the project, but that is also very much an issue someone with an additive mindset has. If you believe you are creating value, you will happily start doing work that falls outside the boundaries of what is needed, whilst leaving behind other things that really need to be done.
- username90 6y ago
  So making a car is subtractive work? At some point in the future the work is done and the car shipped. Doesn't seem like a useful construct, everything is subtractive then. Just like a software project if someone does shoddy parts of the car it will greatly detract from the value of the car even if the other 99% are in stellar condition. That is true for almost everything, the weakest link mostly determines the quality of your product so to ship good products you need to ensure nobody does shoddy work. The work is still additive though, just that producing shoddy pieces is negative value if quality is so low that it makes the product unsellable.
  - jdbernard 6y ago
    I think there is a difference in the concepts the author describes that comes from the fact that in the car manufacturing process, the goal is to produce a large number of cars. So someone can continue to linearly add value by producing more of the same thing. Your value is based on the sum of your total output. To contrast with software: you reach a point where continuing to crank out more of the same doesn't actually create value. Your value is based on how much of the overall body of work you addressed. How big of a piece did you take out from the whole pie. Personally, I'm still thinking over the additive/subtractive concept. It does seem like you could reframe a problem either way. Include a daily quota and the car example becomes subtractive.

Tade0 6y ago

My rite of passage as a senior developer included starting to ask myself the question: does activity X really move the project forward? But there's another side to this, of which management is often not made aware of: in longer projects people tend to accumulate, for lack of a better word, "rituals" - stuff that's done manually, even though it should've been automated or dropped. These are insidious, because they slow down work, introduce inconsistencies (sometimes even errors), but are largely ignored. And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. From almost every place I worked at I only stay in touch with one person - that person.

yowlingcat 6y ago
> And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. > From almost every place I worked at I only stay in touch with one person - that person. Wow. I thought I was the only one.
xvector 6y ago
> And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it. My experience too. 'Those people' have a refreshing honesty and no-bullshit attitude.
- Tade0 6y ago
  Last year I witnessed a code review war between a "good shaped" and "bad shaped" developer. He latter eventually won, because it appears that the "good practices" the former so zealously enforced were actually just his practices, and only made sense in the context of his own habits.
drewcoo 6y ago
Laziness, impatience, and hubris are Larry Wall's three virtues of a programmer. I think you just hit on all three.
watermelon59 6y ago
I’m that person in my current team and it feels very lonely. I keep speaking up about our tech debt and poor processes. Management pretends to care but nothing changes. Meanwhile people keep doing the rituals as you say, as if it were a normal part of life. It’s sad to watch.

JoeAltmaier 6y ago

This reads strangely like a manager's fable about how his underlings don't do all his work for him. Their 'shortcomings' are how they don't get the boss' paperwork done, or write simple enough summaries of their work so the manager can hit 'forward' on his email to the boss. I've been there too many times to count. But maybe its just me.

whatever_dude 6y ago
I didn't get that impression at all. I'm purely an engineer who 100% prefers being hands on; now that I accidentally have to manage teams, I fully appreciate the article's perspective. I've been on both sides of that argument as well. It's not about a manager expecting an underling to get his paperwork done. I think that is an unfair assessment of the argument being made. It's that there's more involved to the job of engineering than simply pushing code one thinks is clever. Sometimes that means knowing which problem to focus (not just the fun ones), sometimes that means dealing with other responsibilities like mentoring or interviewing or filling up timesheets or getting to work on time or attending meetings or what have you. None of those are unreasonable requests (as much as we hate them). If it's part of the job description, it's part of the job, and, for example, making a piece of code conform to one's own subjective preferences so they can feel clever doesn't make up for missing a deadline on a separate, boring, high priority task. I've frequently seen engineers who think otherwise. Who think their work is so brilliant, they don't need to care about the boring stuff. Some of them have indeed been brilliant. But guess what; they still need to get their shit together, because their brilliance is still objectively not making up for being unreliable.
- JoeAltmaier 6y ago
  Who writes that job description? Is it right to expect an Engineer to do the managers' work too? (Short answer: no) People are all different. Its up to a manager to get the best from each. Harping on TPS reports is not the way to get there.
  - whatever_dude 6y ago

nine_zeros 6y ago

This is a good post and I have been Nick a few times. I have felt the anger and shock that Nick faces. My gripe was that if management wants me to handle all aspects of a project, why can't they just spell it out? What about communicating this to other stakeholders? Do I barge into meetings and tell people in sister teams to drop their other work and start listening to me because Gloria asked me to change my shape to a full circle? The hand off from regular shape to wholesome shape is not obvious to Nick. And even if it was, they have no authority or power or resources to drive "others" until Gloria spells it out at least one time.

jmercouris 6y ago
I understand your upset and feel the same. One thing that I dislike here is this: we are starting somehow with the premise that people are malformed. The job of a manager is not to mold people into correct shapes. Unless you are dealing with trivial work, you cannot bend other intelligent beings to your tyrannical circle shaped will. If you are a triangle, the manager is supposed to help you be the best triangle you can be. They are supposed to arrange and connect the pieces of the puzzle together. Instead, this manager believes that is the managers job to mold their units into identical circles. Disgusting.
- nostromo95 6y ago
  You are definitely misinterpreting the metaphor... ‘Shape’ != personal identity or ability. Shape is the sum of the work someone does (in fact, a triangle—if that even has any meaning over a circle in this framework—is a perfectly acceptable shape bc it’s convex and simple). If one of a manager’s jobs isn’t to coordinate what work everyone does I’m not sure what you think managers do.
  - nine_zeros 6y ago
    This. If I am handling all the work, what exactly does a manager do?
    - 6y ago

tug0fwar 6y ago

"This blog requires JavaScript for anything besides reading." I knew I was in good hands ;)

hkon 6y ago

When you must realize this yourself. What shape is the management?

pimlottc 6y ago

The key paragraph for me: > You can't truly be a senior employee until you see your work as subtractive, and until you have an intuitive feel for the set of all the work that needs to get done. Once you think in this way, you can interact with any other leader as a peer, working elbow-to-elbow, of one mind on what needs doing. Until you think in this way, without even realizing it, you are implicitly asking for those above you to insulate you from reality, to build you a little sandbox where you can work. I think we’ve all known someone on a project that needed to be carefully “contained”, while there are others who “get it” and can be left alone with worrying. To me, there is where product management is valuable, building a shared vision with the team, so everyone stays aligned and sees how their individual work supports a greater goal. Great post.

MeinBlutIstBlau 6y ago

> If Nick is junior, this is entirely Gloria's fault: it should be possible to explicitly detail out exactly what is expected from a junior employee, with no room for ambiguity. This should be screamed at every single manager to ever exist. If any entry level or junior level person is ever underperforming, management is 99% to blame. You cannot have high expectations from people who have no idea what they're supposed to be doing and are essentially just winging it. In all, I feel like that happens way more than management is ever willing to admit. It's never the musician that's bad, it's always the instrument.

raldi 6y ago

The author seems to be looking around at all the humans around him and asking, why can’t you all act just like cogs in a machine? I’ve had managers like that, and it often went hand-in-hand with poor engineering chops. Yes, of course, to a large extent big companies require just that sort of cooperation and subjugation, but if you hate fitting yourself into that mold, you’d probably be a lot happier... not working at big companies. There are lots of startups and small businesses where you can be a hard-working, high-performance contributor furthering key strategic goals, and yes, an faithful cooperator working in harmony with a tight-knit team, and nonetheless be entrusted with a domain within which you’ll be free to identify what needs to be done and take care of it without having to defend your choices to a bureaucrat who can’t see the forest for the trees.