What Shape Are You?
tynan.com
tynan.com
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 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.
My experience too. 'Those people' have a refreshing honesty and no-bullshit attitude.
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 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.
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.
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.
I'm sorry you had to go through all this.
* 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.
Wow. I thought I was the only one.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
‘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.
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.
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.
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.
I knew I was in good hands ;)