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.
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.
I found that management's incentives are aligned with the majority. Example reply from management: "our clients are not paying for tests" (yes they are - for the lack thereof, and not with money)
For years I thought that this is some kind of defect that I must work on, so I tried to fit in, but I just can't.
I never had the courage to remain in the role of a "disruptor" for long myself because the resistance I encountered was just too much. It's only the presence of other such people that allowed me to not give in to burnout.
My last job was like this and it was beyond frustrating.
They had essentially re-created the C/C++ language feature of a struct. Rather than letting the compiler/linker worry about where to place the data there was a global array of uint16s. Fields of these ad-hoc structs were placed in this array via defines (sometimes spanning more than one element). Rather than passing pointers to an instance of a struct, they passed an enum which was switched on to find the correct defines to index into the global array and wrangle the data back into a proper type.
So when we were tasked with adding three new instances of a particular ad-hoc struct it cost us tens of thousands of dollars in engineering time. Oh, and all testing was manual as well. The other programmers didn't see the issue and I was just floored by that.
I found a new job, as a sibling comment points out. Sometimes there's no other option.
But that's pretty normal, your vision and your opinion of the situation differs from the powers that be. Instead of getting upset over it, just go through a quick checklist:
* The management and most everyone else around me are in fact stupid and incompetent - just leave the place, problem solved
* The management in fact "gets" my concerns but doesn't think it's the right time to address them - they may have a point? they may see something that you don't see?
* The management doesn't think my concerns are serious enough to invest resources into - they may have a point?
* The place sucks but I get paid a lot and don't want to leave - just distance from it and focus on your part
Either way seems pretty fixable, not much to get upset about.
> 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.
Or actually do, but only after you notice you're not moving forward.
I'm at my 8th role, never lasted more than two years in one and got fired a few times in my career - in most cases because I tried (and failed) to be flexible, obedient and not be the source of any trouble.
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.
> Is it right to expect an Engineer to do the managers' work too?
Who said anything about a manager's work? There's lots of things that can be called "boring" but are still expectations that fall on an engineer, not on a manager.
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.
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.
> 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.
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.
I would argue that, yes, making a single car is subtractive work. There is a specific and finite list of tasks that have to be done to make one car. It doesn’t help to make ten steering wheels for one car. If you’re working in a mass assembly plant, sure, go ahead, they’ll all get used. But otherwise, each piece of work needs to support a single clearly defined goal - a working car. More is not always better.
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.
> Your value is based on the sum of your total output.
If you make 2x car parts per unit of time than you usually do, you'll probably net the plant 1x the profit, because everyone else is working at 1x rate and your extra parts won't be used faster anyway. If you make 4x car parts per unit of time, you might net the company a $1M of loss, because the supply chain people won't be expecting the components to run out so fast and you'll stall the whole assembly line until the logistics can be sorted out.
It seems to me that "addictive"/"subtractive" split doesn't work for any job if you analyze it with the thoroughness the article otherwise applies to software development.
Did you miss the part where the author contrasts the subtractive work mentality in a creative process from the additive work mentality on an assembly line? Your thoughts are addressed by the piece.
Designing a car: iterative, convergent process that can be modeled as subtractive
Building a car in a factory assembly line from a static design: additive work
But the word subtractive doesn't make sense though unless you know exactly what the end product will be. And if you know exactly what the end product will be then designing the car is not fundamentally different from building it since in essence the car is already designed, you just hammer out the details. A programmer who just picks tasks from a kanban is not creative, he just adds code to do the thing the board requests. Doing more stuff from the board all else being the same is always better, he is an additive worker. If he does it faster but produce shoddy work it is the same as if a factory worker works faster but produce shoddy parts on the car, meaning he will get fired because he ruins it.
In most orgs of a size, only a handful of people are adding tickets to the queue. And even then, that's only an "additive workflow" if you insist on ignoring the system the author is describing.
Whether you know all the work to be done or not, there is a quantity of work to be done after which there will be no more work to do. Some of that work might be learning what all the work is. Some of the work might be defining how to do some of the other work. Other work is just picking work off of the pile and doing it. All of these are subtracting from the total quantity of work that will have been done by completing the project.
Not knowing the quantity or boundaries does not change this nature.
> Whether you know all the work to be done or not, there is a quantity of work to be done after which there will be no more work to do.
Does that imply the existential possibility of a finished software product? To me it is precluded by ever-changing requirements and impossibility of bug-free software.
> Some of that work might be learning what all the work is. Some of the work might be defining how to do some of the other work. … All of these are subtracting from the total quantity of work that will have been done by completing the project.
If an activity changes the pile of work, can it be positively claimed subtraction took place?
Given pile of work A and activity ƒ, we can say ƒ is subtractive only if its intention was to make ƒ(A) ⊆ A.
If ∂(A) ⊊ A (intentionally, not because some regressions were accidentally introduced), then I don’t see how ∂ is subtractive. New pile of work may be (but doesn’t have to be) smaller, but it is not a subset of the original pile.
I believe a lot of activity is like ∂, especially in smaller teams where enabling continuous pile-of-work redefinition may be more beneficial than subtracting from the pile.
Interesting. I wonder if we are talking about different things.
To me unclear boundaries imply a degree of exploration and boundary-setting activity, and that is rarely plain subtractive.
True, in a bigger picture this boundary-setting activity still works towards completing some solution—but then in an even bigger picture, I would put forward that in the real world projects are never actually complete.
As a maybe far-fetched example, say there is such and such real-world user problem that was usually addressed via use of spreadsheet- or CRUD website based solutions; now a teammate delivers an Electron-based app prototype which shifts the constraints of what we can do or what level of effort it takes, and even prompts a reformulation of user’s true needs as possibilities previously not even thought about are suddenly on the radar.
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.
Nice analogy. Would you qualify assessing what needs to happen (which may include R&D or PoC work) as subtractive activity? Probably not, since it takes place before you start hitting the mold so to speak?
Yea I really don't know I guess. I think the subtractive / additive distinction is kind of leading people off on a tangent away from what the author was trying to say, or at least what I was took from what the author said.
Really I think what the author was getting at is there are some things that if you don't do them, it's easy for someone else to do them. And there are other things that if you don't do them, no one else is realistically going to come back and take care of them for you. And the whole "shape" analogy is just pointing out that some shapes are easier to fill around than others.
Regarding the whole subtractive vs additive thing, you could build a statue either way. You could carve away at a block of stone, or you could build it up with clay. Both get you a statue at the end. I think some of it just depends on how your mind works.
The thing the article talks about is more of a strategic vs procedural type of distinction I think. Part of being more effective is knowing where to put your effort, and it's a difficult thing to point out to people that their view of what is productive doesn't align with the actual needs of the project.
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.
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.
A manager is supposed to coordinate you and help you be the best you can be. They are not supposed to shape you, only to provide you with the resources that you may need.
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...
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.
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!
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.