How not to be an asshole
(Or, for fellow Brits, an arsehole).
A friend of mine worked at a massive multinational company for an unhappy couple of years. The company (can you guess which one?) was renowned for treating its workers like inconvenient vermin even while profiting from their hard work and ingenuity. One weekend, my friend realised that he could make his team’s work a little easier by building a productivity tool that would automate a raft of tedious boilerplate tasks.
Excited, he set to work writing code. He laboured throughout Saturday and most of Sunday. Finally, on Sunday evening, he checked the code in to the team’s private Git repository along with some sparse documentation and poured himself a well-deserved beer.
That Monday morning he was summoned to his manager’s corner cube. He was glowing with pride, expecting a pat on the back for the boost he’d given the team’s productivity.
“What’s this?” his manager demanded, swivelling his monitor.
My friend explained the tool.
“First of all,” said the manager, his voice icy. “There’s no documentation. Secondly, I can’t find a single test. Thirdly, you ignored the mandated style guide.”
“Well yes,” said my friend. “But it’s internal–”
The manager cut him off with a raised hand. “If I ever… ever see a PR of such shoddy quality from you again, you’ll be officially reprimanded. Do you understand?”
A week later, my friend handed in his notice. The big unfriendly company lost an enthusiastic and diligent coder. The asshole probably still works there.
Don’t be an asshole.
Here is another true story. Two thirds of working Britons suffer dread before the working week starts. This is presented as a mental health problem. But what if the problem is the way we organise our our workplace, the way that we frame work, the way we treat each other, the ways we wield power? Then this dread might not be a mental health issue but an entirely rational response to the world.
Here, again from The Guardian, is an example of workplace alienation presented as a mental health issue:
I hate being trapped within someone else’s schedule, sending pointless emails, attending pointless meetings. I hate the nine-to-five, the long commute, asking permission to take leave – it’s just sleep, work, sleep, work.
Letter to Philippa Perry, The Guardian 25 Sept 2022
This alienation is corroborated, and then some, by the testimonies in David Graeber’s Bullshit Jobs
“Unlike members of actual BDSM subcultures, who are entirely aware of the fact that they are playing games of make-believe, purportedly ‘normal’ people in hierarchical environments typically ended up locked in a kind of pathological variation of the same sadomasochistic dynamic: the (person on the) bottom struggles desperately for approval that can never, by definition, be forthcoming; the (person on the) top going to greater and greater lengths to assert a dominance that both know is ultimately a lie—for if the top were really the all-powerful, confident, masterly being he pretends to be, he wouldn’t need to go to such outrageous lengths to ensure the bottom’s recognition of his power.
David Graeber, Bullshit Jobs 2019
This is a massive problem – it means that many people live their precious lives in a state of alienation. That can’t be right, can it? Perhaps you can be part of the solution. But you can’t do that if you’re an asshole.
Some reasons to be less of a dick
I mean, it’s probably obvious, right? Being bad is… uh… bad. Most moral codes, religious or otherwise, include some version of be excellent to each other. Of course, assholes easily twist such rules. The manager from my story no doubt describes himself as hard but fair, to justify his need to assert dominance. In any case, this is not an article about ethics as such. My focus here is practical and not moral.
Note I suggest in this article that treating people well improves outcomes all round. But what if it didn’t? I would argue that you should do the right thing whether or not your actions ultimately serve your interests.
So here are some reasons why resisting the sometimes understandable impulse to meanness and ungenerosity is likely to improve your team’s productivity and make your life better.
- A culture of blame will skew the motivations of team members. The rational objective of an individual in a blame-oriented team is to avoid being perceived as culpable. To that end the most efficient outcome becomes less important than the least blamey one.
- Fostering the ideas and input of other team members encourages innovation – even at the expense of one’s own perceived brilliance. Collaboration and co-operation should therefore trump competition.
- People don’t like hostile environments. Unless there are significant compensations. If you’re made of money, you can pay everyone a zillion dollars and treat them like shit, I guess. Otherwise, if you want to attract and keep talent, build a happy and rewarding environment.
- As a manager, your job is to protect and serve the people who work with you – to clear their way so that they can focus on what they enjoy and excel at and, incidentally, make your team productive.
In essence, being an asshole is bad for business. I believe that we should try to make all workplaces less alienated and more collaborative, but my focus here, obviously, is the software development team.
Annotate, don’t blame
Most version control systems include a blame subcommand which provides information about who committed what and when in a repository. Given the loading to that word is is unsurprising that there is often also praise or annotate synonym. The blame command conjures up a fevered hunt for a scapegoat. Why is the system broken? Who did it? A culprit must be found. A sacrifice must be made.
These are understable questions, but they are not useful ones. First of all, shit happens. Here are a few of the things that I have seen while working with good conscientious people:
- A table containing several million rows of production data accidentally junked.
- A version control system kept together with the work it stored on the only development machine so that, when the box went down, a month’s work was lost.
- Another failure to back up coupled with the accidental formatting of a development machine.
- Numerous white screens of death and exposed error message garbage.
- Various mail-out snafus of toe curling awfulness
- Security holes galore – occasionally exploited
- Runaway processes that filled up inboxes, databases, drives
- Uncountable instances of copy/paste code, bugs, clumsiness, hardcoded assumptions
If we had ritually sacrificed the authors of all of the above issues and of the dozens of other blame-worthy transgressions that did not make the list, then I’d have precious few colleagues left. Not only that, I’d probably not have a job since I’m in the frame for more than one of those. More than two.
If you waste time casting blame, then you’re storing up trouble for yourself. Sooner or later you’ll do something stupid yourself. It’s bad enough hitting return on sudo rm -rf /. How much worse would it be to do so if you’d been merciless to others in your team up to that point? What slack would they feel like cutting you?
By fostering a culture of blame, you shift your team’s priorities. The focus becomes to avoid being seen to be at fault – whether by deflecting suspicion, through forensic defensiveness, or plain old-fashioned lying. This is what happens in police states – gradually, optics become more important than actual progress. Teams in a blame culture become increasingly risk averse. But, like it or not, a certain amount of risk is a pre-requisite for creativity.
So what should you do when something goes wrong? First of all, of course, the priority should be to fix the issue and any fallout. Then switch out blame for annotate. There should be a distinction between a witch hunt and an investigation. You need to understand what happened and how it might be addressed in the future. Of course, some issues can be filed under shit happens and let’s all be me more careful. Others though might suggest a need for more training, improved processes, and improved disaster recovery processes.
If blameyness is taking root in your team, consider draining the poison by accepting responsibility yourself. That’s not to say that you should pretend to have wiped the database or sent the email insulting your customers. But you can step up and identify the systems that weren’t in place to protect against the issue. Most problems are systemic, even if a single action can be found to have been a catalyst. If you’re senior in your team, then you share responsibility. Accept the buck – and shift the conversation from blame to solution.
Protecting your team
While removing blame from your team’s culture is a good step, you should go further and look for ways in which you can actively support and protect the people you work with. If you’re known as someone who has your team’s back as far as possible you are more likely to retain good people. People are very attuned to bullshit loyalty-fostering gestures (see, for example, the British food preparation factory which, instead of offering its staff time off during the Queen’s funeral, distributed unpleasant sausages in buns. Such nonsense is always recognised as the contempt it really is.
In the context of software development there are a few common issues that you can helpfully guard against.
Malign fetishism
First of all, beware malign fetishism. A fetish, or cargo cult, is the confusion of cause and appearance. We’re told, for example, that agile methodologies are more efficient than traditional waterfall project management. I’m not challenging that here. I tend towards a light scrumminess personally. Still, the fetishistic version of this new orthodoxy takes the rituals associated with agile – stand ups, sprint retrospectives, backlog grooming and so on – and makes them magic. So long as you perform the special dance, utter the ritual words, shuffle the sacred Post-its, it does not matter that your fundamental practice is broken. You performed the rite and so the gods will smile upon your project. I have seen this sort of Lord of the Flies nonsense evolve in at least four workplaces and, while no developer was sacrificed, plenty were driven to flee as the empty rituals became increasingly gothic and demanding.
Ordinary fetishism is bad enough and almost always counterproductive. Malign fetishism takes a bad practice and weaponises it. The most common instances of this involve the deliberate substitution first of bottom up tracking for top down surveillance and then of estimates for targets.
In order to work effectively, agile methodologies require that a team measures outcomes against estimates. The objective here is to make estimates progressively more realistic and therefore allow for better forecasting and decision-making. Unfortunately, the tools a team uses to make these measurements and comparisons can be co-opted to help make a panopticon – a malign carceral institution based upon total surveillance – of your organisation. Estimates, which should be a reflection of basic realities (the time available, the scope of the task, and so on) are transformed into targets. In a truly agile project, estimates will be recast progressively to make them more reflective of reality. In a malignly fetishistic project, developers will be encouraged to under-estimate and then shamed or punished for not meeting their ‘targets’. The technology which could help a team track accuracy becomes a tool for coercion.
Resist attempts to influence estimates or to use statistics and charts as tools to assess productivity rather than the accuracy of your team’s estimates. Watch out for signs of the cargo cult. Are you spending more and more time in meetings? Are you noticing an air of dread? Are people working longer and longer hours to make their estimates ‘true’?
Bad cop-ism
Bad cop-ism is the imposition of a new layer of personnel whose job it is to apply harsh measures, thereby allowing senior individuals to benefit from a whip cracked on their behalf whilst themselves remaining the ‘good cops’ – personally jocular and thoughful. As we’ve seen this benefit is dubious at best. A harried team will bleed talent, and will focus on avoiding conflict rather than making real progresss.
Bad cops can be consultants, project managers or a new level on the org chart. Like many drifts into toxicity, this syndrome can be entirely unintentional. As smaller organisations and teams grow, they become harder to manage without more people keeping track of who is supposed to be doing what.
If you are the harrassed lead requiring project management support, brief your new people so that they act as facilitators not enforcers. Keep in touch with people on the ground. Intervene as necessary.
If the new layer is imposed by the business then, first of all, give the arrangement the benefit of the doubt. Project management is not intrisincally problematic. Even if you begin to see a drift into whip-cracking blame culture, this may not be part of a Plan. Toxic cultures can emerge without the need for a conspiracy to conjure them. Communication, both with new the management layer and your business points of contact, should be your first port of call.
If you end up at a stalemate, unfortunately you are left with damage limitation. Find ways to protect your team withough inciting a showdown if you can.
Beware of end-runs
One of the nice features of a methodology like Scrum is the way that lets developers get on with their tasks in relative peace at the same time as prioritising the needs of the business. These outcomes are not at odds with one another – productive developers are essential for any business strategy – but it can still be a hard act to pull off. Developers are employed to build the the business’s vision, the business has a responsibility to let them do the work.
Typically a backlog grooming session will inform sprint planning. The developers are then left to pursue a happy alpha state.
But watch out for sudden requirement requests which might upset this balance. Usually these will start as a favour or two delivered directly to individual developers. A Slack message requesting a quick change (“It’ll barely take a minute”), an email asking if a new task can be squeezed into the queue (“I wouldn’t ask but the client is screaming”). Of course, we all need to be flexible and the occasional hotfix or emergency feature is unavoidable. The trouble comes when the exception becomes the rule. In the worst cases, partners or clients are given direct access to developers, often via messaging apps. Here is Cal Newport writing about Slack in The New Yorker:
Once the team switched to the tool, the rate of back-and-forth messaging intensified, eventually reaching a stressful peak when a demanding client insisted on the ability to directly communicate with Sean’s employees using Slack. The team soon burned out, and two engineers quit. In desperation, Sean moved the company off Slack. When I spoke with him, some time had passed since this incident, but the memory of the service’s omnipresent notification ping remained strong. “I hear that sound, it gives me the shivers,” he said.
Cal Newport, New Yorker, 14 Dec 2020
You might recognise that feeling. I have audible notifications turned off, but my version of this involves the phrase Hi Matt appearing on a notification window… followed by an icon indicating frantic typing. What will the requirement be? Or perhaps it’s a bug. What if it’s my fault? What damage will this do to my day? And still the typing continues. It will continue forever whenever I close my eyes.
From a tech lead’s point of view, the problem lies not so much in the individual tasks but in all the little ways the project’s trajectory is destabilised by ad hoc requests. What’s worse, because they are back-channelled, it becomes harder and harder to know who is doing what. From the perspective of an individual developer, random requests can represent a significant loss of autonomy and a drain on productivity. One of the big problems is that non-developers tend to operate on a manager’s schedule rather than a maker’s schedule. A maker needs time to focus and concentrate, a manager darts from meeting to meeting. So a cheeky task request in the middle of an afternoon may seem like a passing interuption to a busy back-channelling producer, but to a developer it can spell the end of productive work for the day.
As always, the solution here will depend on your team’s situation. Ideally, though, developers should be encouraged to refer requests to a queue that can then be reviewed by an individual team member. In my experience, this works well, so long as the queue is treated seriously and urgent tasks are given proper consideration, even mid-sprint. However you achieve it, the objective should be to let your people work and remove distractions as far as possible.
Of course, the real asshole move is to start making ad hoc requests yourself. It’s easy to do when you’re in manager mode. After all, the task wouldn’t take long. What harm could it do?
The no-compete clause
Abraham Lincoln famously appointed his team of rivals. One hundred and fifty years later, an altogether less illustrious president ran his White House like a reality show, delighting in conflict and competition. Although chaos, in-fighting, self-promotion and scheming probably make for good TV – they are not traits condusive to productivity or a happy working environment.
If you’re in a position to hire people it generally makes sense to hire people smarter than you are – at least within their areas of expertise. That might seem like a given – but we have seen plenty of recent examples of leaders who demonstrate a prediliction for mediocrity for various reasons. Can’t find anyone smarter or more experienced than you are? Are you really sure about that? One famous asshole trait is to over-estimate one’s own abilities.
Once you have a team of smart people, it makes sense to respect their expertise. Don’t compete with your own team. One trick I’ve learned is a practice my colleague calls Bertie Woostering. Named after PG Wodehouse’s affable but dim character who forever gets into scrapes only to be rescued by the much cleverer Jeeves. To Wooster then is to accept, maybe even play up just a little, one’s own limitations with good grace, providing the opportunity for the competent experts about you to step up and save the day. Don’t be an asshole, be a little bit stupid!
Good faith
As we’ve seen, when things tend towards the toxic in an institution it’s often not a conspiracy. Entropy and poor communication are often quite enough on their own to let poison creep in. But, even when a wider organisation tends to encourage discord and to gaslight its employees, individual teams can often still act to protect one another and their project objectives. As David Graeber illustrated, some jobs or institutions are unsavably mired in bullshit. If, on the other hand, the work is worth doing, and everyone on your team can muster a good faith commitment to it, then it should be possible to foster a creative and productive experience for everyone involved.
If you liked this diary entry or anything about this site and its projects you can help us out by spreading the word. You can also sign up to join the Hidden Hat mailing list.
Photo by Gianfranco Grenar on Unsplash
