My rite of passage as a senior developer included starting to ask myself the question: does activity X <i>really</i> move the project forward?<p>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.<p>These are insidious, because they slow down work, introduce inconsistencies (sometimes even errors), but are largely ignored.<p>And for some reason the arrogant, disobedient, oddly-shaped person is the only one noticing it.<p>From almost every place I worked at I only stay in touch with one person - that person.
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.<p>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.<p>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.
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.<p>I've been there too many times to count. But maybe its just me.
The key paragraph for me:<p>> 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.<p>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.<p>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 <i>won't</i> work and then subtracting them all as cheaply and quickly as possible.<p>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.<p>Subtractive implies few, if any, unknowns.<p>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.<p>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.
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.<p>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.<p>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.<p>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?<p>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.
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.<p>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.<p>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.<p>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.<p>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.