How to be a -10x Engineer

I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top.

This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint.

Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.

- if you can't define "jerk" well, you're playing into office politics. Who decides who the jerk is?

- there's a typo: "A blog post by the studies authors" should be "A blog post by the study's authors"

- the "studies" linked to seem fairly dubious. Most people who are rude are not so because their boss is. Only 25% said they were. Also, it's qualitative survey data, which it's rarely a good idea to draw anything but first order conclusions from (e.g. yes Donald Trump won the 2016 election, so we can conclude that he got the most votes, but we can't infer from that that voters like candidates with orange skin). And as self-reported data, it's hard to base much on it at all.

- the implication is that removing all this would be the best thing, and that's probably true: having some wonderfully polite geniuses is no doubt the best option. However that doesn't mean we should necessarily prioritise politeness over raw ability, as at least for some tasks, a solitary person who's very smart can do things that even teams of others can do.

This is all true for the somewhat narrow field of commercial software development for the consumer end-user where profit margins determine success or failure in terms of paying off the capital investors, but many organized engineering efforts have other goals, e.g. replacing some organization's decrepit internal data storage, archiving and retrieval system where robustness matters more than anything else, or designing a research program aimed at solving a complex technological problem, writing software that controls an electrical grid, and so on. Applying the maximize-short-term-profit mentality to such problems generally doesn't end well.

* The next developer to pick up the task where you left off

* Your technical lead asking for update

* Your manager needing an update for his manager

* Product management wanting to know where we are on some feature

* End users wanting to know when the bug fix / feature they asked for will be in their hands

Everywhere I have worked, we had multiple apps/ticketing systems/etc all trying to roll up / slice & dice data to get to the above.

In the end it just turns into talking to management pinging the next level below them for adhoc status.

Why? Because product is too ignorant to open Jira nor maintain status themselves. Because management above the line manager level is apparently incapable of opening Jira either, let alone 2-3 levels up. Also no one wants to hire real project managers anymore to maintain all the different views & send the weekly updates they demand to receive.