An idea in your mind is 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘁𝗵𝗶𝗻𝗴 as the words you use to convey it.
Similarly, a process your software development team follows is 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘁𝗵𝗶𝗻𝗴 as the document outlining it.
Language is low resolution, and by definition it will leave out a lot of the nuance and details.
Written-down processes are like the string that keeps a kite from flying off and crashing. They give the team some basic parameters to play within. They’re like a rulebook to a spot.
But the execution of the actual process is the kite itself, flying, adjusting to the wind, moving omnidirectionally.
Many managers and “Agile practitioners” cannot tell the difference between the two.
They spend their day writing docs and adding processes like ticket templates, planning pokers, definitions of done, etc.
What’s worse, they actually think these things help.
Such people are one of the biggest wastes of air and space in software development teams. They are actively harmful to your team’s output.
When I say “managing by Jira” I mean the phenomenon whereby some managers want to add more and more pieces of templatized processes. They want to add lengthy issue templates, blockers so you can’t merge code that isn’t linked to an issue, worthless rituals like planning poker, etc. This is often referred to as “meta work.” Excessive meta-work is terrible for three main reasons:
- The sheer waste of time it is. In any given year, a team’s total working hours are finite. Out of 2000-2500 hours an engineer might put in on a given year, if you make them spend an hour more than absolutely necessary on meta-work you’re a bad manager. You’re actively divesting their time away from feature and operational work that is beneficial to customers, and investing it into bullshit. The amount of time that’s necessary to be spent on meta work, even in a BigTechCo like AWS, is somewhere in the vicinity of 10% (around 1% in a startup with a team of 2–3). If you make your team spend 30% of their time on meta work you’re holding the gross productive output back by at least 20% (in reality much more, as we shall see).
- It creates a self-perpetuating vicious cycle of bureaucracy. An environment that places undue emphasis on meta-work invites a particular type of employee: the sandbagger. These individuals excel at creating the appearance of productivity through meticulous documentation and process adherence, while their actual contribution to the product is minimal. In Jira, their work may appear impressive, but a glance at their Git commits tells a different story. This discrepancy is particularly problematic in large tech companies, where there are ample opportunities for paper-pushing. These sandbaggers not only fail to contribute meaningfully to the product but also set a dangerous precedent that values form over function. Then they get promoted and as they do, will typically worsen the situation with more meta-work. After all, they were rewarded for it. Note that not all sandbaggers are actually sandbagging in a sense of putting in low amounts of effort. Some of them work hard. It’s just that they’re sandbagging the stuff that actually matters, the productive work that benefits customers.
- It kills actual productivity. Perhaps most importantly, meta-work interrupts the flow state that engineers need to produce their best work. I’ve lost track of the number of times when I’ve taken immediate action and fixed significant issues in a shorter amount of time than what it would have taken me to fill out the ticket template to the standards of some of the most Jira-worshipping managers out there. The death of inspiration and flow happens in teams where your calendar is filled with useless rituals like planning poker, multi-hour sprint planning, velocity analyses, or where you have to do things like over-segmentation of tasks into sub-daily lengths and story pointing.
I’ve been name-calling Jira a lot, hopefully it’s obvious I don’t mean Jira specifically but any task management software (Asana, Clickup, or if you also work in Amazon our beloved “Simple Issue Manager” and its younger sibling Taskei).
I also want to call out that it is extremely important and helpful to write down and prioritize your work, as well as to learn from your mistakes. This is the difference between teams that move erratically like flies and teams that fly towards objectives like a peregrine falcon attacking its prey. Moving fast in no particular direction is actually worse than moving slow due to wasting time on Jira. Erratic movement tends to create much more cruft and tech debt.
But being a peregrine falcon is obviously better.
I also wanna point out that some of your work output is actually best placed in Jira (or in my case and other Amazonians, Taskei).
Just 2 days ago I worked on an issue. The ticket was automatically cut because of a latency alarm — our service’s latency in a particular AWS region was higher than expected. This was a second occurrence of this ticket so I looked at the work that two previous on-call operators had done. They done log diving and ascertained the following:
- Identified the top calling customer (about 5000 queries per second into our system, mostly sustained during business hours)
- Identified a different customer that seemed to have some kind of syncing workflow triggering every 3 hours, where they would hit us at 10,000 queries per second for a few minutes and then send zero calls until the next workflow
- Chased down a couple of leads that didn’t pan out.
They posted screenshots and log outputs of all these things into the ticket. This is not meta work. It is real work.
From there I went on to investigate our I/O latencies with that customer’s call path and saw that most of their latency was coming from a thing that should have been cached. So then I went on to investigate caching metrics for that customer, saw that our cache was not working as well as it should, and immediately introduced a small TTL increase to the cache.
My teammates saved me re-doing multiple hours of work by putting the work into the ticket. But of every entry that went into that ticket, 0% of it was meta work. 100% of it was real work.
So please understand, interpreting what im saying as a call to ban Jira or something like that would be utterly stupid. Google docs or quip are much worse places for this type of work.
Methodologies are catnip for idiots. It’s simple: weak minds crave simple solutions. They want a paint-by-numbers approach to success, and agile promises just that.
These halfwits see a world of complexity and instead of rising to the challenge, they retreat into a comfort zone of checklists and buzzwords. Agile, with its neat little ceremonies and easy-to-digest principles, offers them a security blanket. It’s the corporate equivalent of thinking a green smoothie will solve all your health problems.
The truth is, software development — hell, any complex endeavor — doesn’t work that way. It’s messy, it’s unpredictable, and it requires actual thinking. But that’s too much for these simpletons. They’d rather play scrum master and feel important moving sticky notes around a board.
It’s the same mentality that has CEOs swearing by their morning ice baths or meditation routines. As if freezing your ass off at 5 AM is what separates you from Jeff Bezos. It’s magical thinking for adults who should know better.
Real success in software development comes from deep understanding, creative problem-solving, and the ability to adapt to changing circumstances. It comes from experience, intuition, and sometimes, just rolling up your sleeves and grinding it out.
But that’s HARD. It’s difficult to resist the siren song of Agile authors promising you better results without you having to stay technically sharp.
Probably the worst kind of manager is the toxic asshole manager, who chooses fear over charisma, threats over understanding, appeals to authority over data, yelling over persuasion, self over team, etc.
Another terrible kind of manager is the micromanaging manager, and there’s many other ways in which managers can be bad. But those other ways don’t concern us today, as the topic of this article is meta work.
Past a certain size, a team cannot operate well without a good manager. But managers obsessed with meta-work are, at their very best, like this guy:
The reason why these managers want to much to go into Jira is so they can have a sense that they understand wtf is going on with their team. This is usually because of laziness, incompetence (lack of technical ability), or both.
As a result, their concept of management is to encourage the team to adhere to these processes. These terrible managers obsessed with meta-work stay on the surface of things. An example:
In AWS our CI/CD system has a feature where it shows a little box at the top right with a warning if they notice you’ve taken too many manual actions. CI/CD should be fully automatic. If you’re having to retry integration tests, or having to override failures to promote code with broken tests to production, or take any manual actions of the sort, that can be a sign of a team that’s in terrible operational health.
A bad manager will see this metric and bring it up in standup in a manner like this one:
Team, I noticed our pipeline is giving us a warning for too many manual itnerventions over the last 30 days. Let’s make sure that we’re not manually intervening the pipeline unless absolutely necessary.
This is the corporate equivalent of a shitpost. It’s the kid above pretending he’s actually helping the train start and stop. It’s a complete waste of air.
A good manager, upon seeing the warning on the pipeline tool, would actually go into the log of manual actions and look over the specific manual interventions that were taken (retrying a deployment or blocking pipelines to run load tests are very, very different things than promoting code that has broken tests). Then they might talk to some of the people who took manual actions in order to to better understand the situation. Then they would make a decision as to whether the “too many manual interventions” metric represents an actual problem or not. If it does pose a problem, they’d ask one of the senior engineers how to solve it and roughly how long it would take. Then they would prioritize solving the problem by deprioritizing something else.
And that’s the crux of the issue: a manager should be technically competent enough to comprehend the value of their team’s work by reviewing pull request descriptions, design docs, and engaging in meaningful discussions about the operation and architecture of the service. A manager should be technically competent enough to make decisions and go through investigations like the one I outlined above.
A manager doesn’t need to be able to write the code themselves. It’s typically better if they can, but this is way too rare and not terribly important — Sorry Elon fans, he’s wrong.
This hands-on approach is akin to a coach on the sidelines, observing and guiding their team in real-time. The coach doesn’t have to be able to rope 3-pointers himself, but he needs to understand the game.
Imagine a coach who never attends games and instead “manages” by looking at a spreadsheet of player statistics twice a week. When he talks to a player, all he can say is “keep it up” or “your ppg is down, you need to score more.” Such an approach would be universally recognized as ineffective in sports, and yet it’s sold as a panacea of software engineering productivity in the world of Agile. It’s snake oil. It’s garbage.
Let’s refer back to the original agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This is very clearly an anti-prescription stance. And it’s a good stance.
It’s a sad reality of life that small minds will always try to find a paint by numbers approach to achieving difficult things. You just have to make sure you go places where the density of these people is very low, and leave their teams if you find yourself in that unlucky situation.
