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.
I identify with the "rituals" bit a lot. My most vivid example if this is from a project, much of whose code I had co-written. It was a real-time model delivery system, which mostly used to work fine, except for a few minutes every day (or sometimes once in two days) where it'd hang and had to be a restarted. The ritual was this: it became a practice to restart the process at a predetermined hour everyday!
I tried to convince the team to debug the issue, but no one was having it: why break something that works.
I am somewhat fine with restarting being a fix... only if we know what issue it's s fix for.
> 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.
>And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it.
I got very lucky that my first job is a place where this kind of behavior is not only allowed, but gets me treated like a rockstar. Given how people write about it being received at other firms (apathy at best, punishment more likely), I'm terrified to ever leave.
I've seen this too, and I'm wondering how (or if) this fits into the shapes/additive/subtractive model.
"Ritual" work doesn't seem like it falls under additive or subtractive to me. Maybe it's some combination of being multiplicative / reshaping? If you can multiply/reshape you or others' efforts towards the project, the project (hopefully) becomes easier.
There's a bit of an assumption that someone is "modifying" work in a useful way--multiplying a shape won't help if more of that shape isn't useful.
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.
> 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.
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.
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.
I didn't quite read it that way, but had a similar reaction in that to me it points to a problem with management rather than the people being reviewed.
If a problem gets to the point where the person being reviewed is unaware of it until a review, the system and management above it has failed. This should all be part of the process. Nothing should be surprising, the feedback should be continuous and so should the attempts to rectify things.
I'm not saying disputes don't come up, or that there aren't issues that develop. But the idea of "implied" tasks or project needs that go neglected to me in turn implies that this should have been addressed immediately, not at the time of an annual review or something, after the fact, and after it's been allowed to grow.
To me it's a sign of lack of communication and management being out of touch.
> 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.
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.
> 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.
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.
I liked the way another comment here phrased it of subtractive in the sense that you are working to subtract risks from your project.
That is something we run into all the time. "We need to deliver X, we think the biggest risk is Y, so we will spend some time there trying to quantify what needs to happen and how big the box is"
My daughter got a plaster mold thing with prizes hidden inside it for Christmas and we were working on it just a few minutes ago. You use a hammer and chisel to bust chunks off until you find pieces. I feel like a lot of project development is like that. You know the thing you want is somewhere in there, and the real work is making strategic decisions on what to hit at next in order to make the biggest gains towards finding what you want.
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.
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.
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.
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.
> 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.
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.
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.
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...
[+] [-] Tade0|5 years ago|reply
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.
[+] [-] abhgh|5 years ago|reply
I tried to convince the team to debug the issue, but no one was having it: why break something that works.
I am somewhat fine with restarting being a fix... only if we know what issue it's s fix for.
[+] [-] xvector|5 years ago|reply
My experience too. 'Those people' have a refreshing honesty and no-bullshit attitude.
[+] [-] watermelon59|5 years ago|reply
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.
[+] [-] drewcoo|5 years ago|reply
[+] [-] yowlingcat|5 years ago|reply
Wow. I thought I was the only one.
[+] [-] closeparen|5 years ago|reply
I got very lucky that my first job is a place where this kind of behavior is not only allowed, but gets me treated like a rockstar. Given how people write about it being received at other firms (apathy at best, punishment more likely), I'm terrified to ever leave.
[+] [-] vple|5 years ago|reply
"Ritual" work doesn't seem like it falls under additive or subtractive to me. Maybe it's some combination of being multiplicative / reshaping? If you can multiply/reshape you or others' efforts towards the project, the project (hopefully) becomes easier.
There's a bit of an assumption that someone is "modifying" work in a useful way--multiplying a shape won't help if more of that shape isn't useful.
[+] [-] didibus|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] JoeAltmaier|5 years ago|reply
I've been there too many times to count. But maybe its just me.
[+] [-] whatever_dude|5 years ago|reply
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.
[+] [-] derbOac|5 years ago|reply
If a problem gets to the point where the person being reviewed is unaware of it until a review, the system and management above it has failed. This should all be part of the process. Nothing should be surprising, the feedback should be continuous and so should the attempts to rectify things.
I'm not saying disputes don't come up, or that there aren't issues that develop. But the idea of "implied" tasks or project needs that go neglected to me in turn implies that this should have been addressed immediately, not at the time of an annual review or something, after the fact, and after it's been allowed to grow.
To me it's a sign of lack of communication and management being out of touch.
[+] [-] pimlottc|5 years ago|reply
> 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.
[+] [-] biren34|5 years ago|reply
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.
[+] [-] egsmi|5 years ago|reply
[+] [-] codetrotter|5 years ago|reply
[+] [-] strogonoff|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] war1025|5 years ago|reply
I liked the way another comment here phrased it of subtractive in the sense that you are working to subtract risks from your project.
That is something we run into all the time. "We need to deliver X, we think the biggest risk is Y, so we will spend some time there trying to quantify what needs to happen and how big the box is"
My daughter got a plaster mold thing with prizes hidden inside it for Christmas and we were working on it just a few minutes ago. You use a hammer and chisel to bust chunks off until you find pieces. I feel like a lot of project development is like that. You know the thing you want is somewhere in there, and the real work is making strategic decisions on what to hit at next in order to make the biggest gains towards finding what you want.
[+] [-] mnsc|5 years ago|reply
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.
[+] [-] nine_zeros|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] raldi|5 years ago|reply
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.
[+] [-] MeinBlutIstBlau|5 years ago|reply
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.
[+] [-] unwind|5 years ago|reply
[+] [-] rembicilious|5 years ago|reply
[+] [-] exmadscientist|5 years ago|reply
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.
[+] [-] quickthrower2|5 years ago|reply
[+] [-] hkon|5 years ago|reply
[+] [-] tug0fwar|5 years ago|reply
I knew I was in good hands ;)
[+] [-] threwawaysoff|5 years ago|reply
[+] [-] briansharp|5 years ago|reply
[+] [-] fouc|5 years ago|reply