The title needs work, but if you get the idea, especially if you’ve experienced it before. Spoiler: The title is also a lie. I actually have no concrete idea on how to successfully avoid reworking that project, but I have some ideas. So read on, fair maiden.
(The previous title was: “Maintaining sanity as a creative specialist while dealing with conflicting requirements from the people who sign your paycheck“. Big improvement, I think we’ll all agree)
Its difficult to choose the right words that express this exact problem that programmers/designers/machinists/tailors/headhunters/hairdressers/engineers/UI-UX designers/ad-infinitum-skilled-artisans-who-possess-a-certain-specific-fine-honed-skillset specialists face when burdened with fast changing requirements made by other people, usually people with less knowledge of the specialist’s particular field. And unfortunately unaware of the headaches these changes bring.
I’m still not really succinctly nailing the issue, am I?
Look. Here is another way of expressing this basic problem, from the lens of software development:
This overused stat was taken from the excellent 2005 report on risk management in big software projects (“Why Software Fails”) by Robert Charette. Its a long but extremely insightful read (PDF).
If 50% of project time spent doing aVoiDaBlE rework is the case for people working with code, in organizations big and small, with management both understanding or less so, with communication structures flat, or toweringly vertical and siloed, then it really doesn’t require fertile imagination to assume this is a universal problem.
Why though? The oversimplified story is that there is a lack of common understanding. In other words, more discussion together would have made things better. In other, other words, more time could have been spent asking questions and getting specific answers. In other, other, other words, more time could have been spent on design, and then trying really hard to follow through on those plans.
Often, this does not happen.[citation needed]
We have many specific words to express this problem as it appears in different industries.
One specific word is HIPPO. Before I go on, I want to make clear that I deeply loathe the term “boomer”, because it’s a total oversimplified, biased stereotype. A stereotype of an entire slice of generally quite nice people on the planet, and I was born in the late 80s. So there. Nonetheless, hardcore managers definitely are a thing, and they come in many genders, ages, shapes and sizes, and the nature of their job can make them resistant to being the so-called team player.
“Highest paid person’s opinion” slash “highest paid person in the office”, or HIPPO. It describes the tendency for lower-paid employees to defer to higher-paid employees when decisions need to be made. Importantly, the HIPPO is usually kind of old. This is a phenomenom[Spell check alleges the spelling is wrong, but I’m the HIPPO around here. I know exactly how to spell phenomenom, and don’t need some new fangled feature creep to tell me how to spell….good…and stuff] that definitely exists, but varies by culture and company, and deciding where to lay blame is not so simple. Is it that younger, lower paid experts and specialists are scared to speak up for fear of consequences? Is it that the work environment is too friendly, and no-one wants to rock the boat? Lack of leadership, so someone has to step up and make a hard decision? Or just that older people struggle to listen to the young? You decide.
Another term is “Feature-creep”, the excessive addition of new features in a product, especially software, video games and electronic devices.
Or as Liz England, team lead game designer at Ubisoft Toronto expressed it so well, The Door Problem. Its an incredible feat of technical communication to explain clearly to others what the job title “Game Designer” actually does. Its a very wide term that means different things to different people of different backgrounds, and some of these different people may not know anything about games.
And when we’re going beyond a small team, and talking about a huge organization:
This is a perfect explanation, because nobody’s job is ever simple, so how could anyone quickly understand, let alone empathize with their challenges? Not all customers or clients have that empathy, and why should they? They are in a hurry, and probably have someone else breathing fire down their neck.
Selling Good Ideas/Unselling Bad Ideas
In my experience, becoming really good at Explaining Things™ is one way to combat our badly defined problem: taking some complex idea and making it simple and easy to digest. and working on learning how to be convincing (without bullshitting): taking an idea and really selling it to someone, with the correct choice of verbal MSG and positive-connotated words. Oh, and thoroughly unselling terrible ideas successfully also requires that you be convincing.
This defensive mode of actively trying to shut down a terrible idea is one important battle we must enter to fight avoidable rework – decisionmakers often just want to come up with an idea, send the workers off, and not have to think about it – but proactively organizing talking time can avoid a lot of headache later.
Execution-incapable dingwads are quite capable of bullshitting, but if you, the expert who knows what you’re talking about, are unable to make a stand at convincing decision-makers about your input, you only have your own bad communication skills to blame. Well, they still might not listen to you anyway, but…like…you did try make a stand.
If that didn’t work, what else is there?
More communication skill, one harder to do, because it is deeply undervalued – defensive documentation. The excellent Lewin Edwards book “So you wanna be an embedded engineer” has this pearl of wisdom about writing ability, but note the final point (that I solidly agree with):
…
Sometimes you will need to take initiative to write and send a report, a contract, a serious email, or a request for a parley, not because you were asked to, but as a defensive action. Some issues and misunderstandings completely evaporate due to this kind of action, and the sooner you believe it and start creating your defensive papertrail, the better your professional life and mental health will be.
But what do I know, I’m just some random dude on the internets.
In the line of stressed professionals, here is a sticker I made, dedicated to those facing fast approaching deadlines, lousy work environments, self-employed programmers, freelancers, and the soon to be retrenched:
Your support helps me with my own Progressive Screwdriver drinking habit.
Paul Hoets is a freelance maker who lives in South Korea. If you liked this article and would like to contribute to his empire of dirt, silicon and tech. education, buy him a coffee!
The Electronics Deli 