[wolframhempel]

As a tech lead, when you're asked to deliver more, the first impulse tends to be asking your team "how can we do more work?"

The correct question should be "What can we NOT do?" - and usually there's a long list of things that don't generate business value - from processes, meetings, reporting and overly detailed planning sessions to technical hurdles including slow builds, pre-check in hooks, sign off requirements etc.

I know that most feel that they absolutely HAVE to do these things, since there are part of the business process/ definition of done/company guidelines etc... but here's the thing: If your team delivers value, people stop asking questions. It might take some forceful pushback and even some fights initially, but even if your team is absent from meetings or doesn't jump through every hoop, as long as you churn out value, you make yourself, your superiors and the business as a whole look good and in turn will be cut some slack.

[d0mine]

The general thesis: "to optimize, do less" is correct (even tautological in the time performance area) but specific examples without additional context are troubling: I see an enthusiastic manager reading your post as an endorsement of dropping tests, code reviews, git, any kind of automation, etc (as it doesn't bring direct business value). Obviously, it is shortsighted. You'll pay dearly for any time you initially save by dropping these practices in most contexts.

[Breza]

I run the data science department in a corporation. The best thing I've done is banishing Excel from our reporting workflow and replacing it with various types of automated reporting. Stuff like that is what you should cut, not something that'll end up adding technical debt.

[wjnc]

This is what I keep telling my (senior) managers. In order to let people do “more X”, you should have available a list of Y they are already doing and Z that will fall below the fold if prioritizing X. If you don’t have that list, any discussion about resources and priorities is an emotional one, not a rational one based on an adequate view of what teams are delivering.

[ISL]

To piggyback there -- people stop asking questions when counterparties meet or exceed expectations. It is essential that expectations are set reasonably, otherwise one or both parties are in for a world of hurt.

[helge9210]

> I know that most feel that they absolutely HAVE to do these things, since there are part of the business process/ definition of done/company guidelines etc...

Anecdote: at current position I've noticed 100% of my team time goes to "these things". As a team lead I tried to figure out the actual necessity. After I've "lost" the half of the team insisting on doing all the rituals the remaining half started to deliver actual value with much less stress.

[hbrn]

As the company gets bigger, it naturally starts doing more rituals. Some are justified, most are a cargo cult.

The sad part is that since rituals are an inherent to a big company, following (and enforcing) rituals is synonymous to being professional. And fighting them is often seen as amateur.

No, I'm not doing performance reviews and weekly 1:1 with each team member. Not because I'm an amateur, but because I'm in the trenches with them every day. Maybe I'll start doing those when we get bigger. But let's get there first.

[helge9210]

> As the company gets bigger

In first startup I was working we were four engineers and our whole shared context could fit into two whiteboards and Kanban board in GitHub.

Next one was a couple of hundreds of engineers and a lot of coordination activity directed by iron fist of program managers.

Next one was fifty engineers but with the same amount of coordination activities (for the sake of the process) and much less progress.

And the current one had ten people in engineering, three chapters (backend, frontend, DevOps), incident board, 1-1s, retro, planning, refinement, weekly, quarter retro and planning and sprint review.

Fun fact: at current place no one knew the term "cargo cult". When I explained the meaning some colleagues considered it offensive.

[hbrn]

A good question to ask: why is it a part of our business process to do things that don't generate business value?

The honest answer is usually: we don't really know what is the right process for us, but because we couldn't admit it, we tried to replicate somebody else's process.

"Nobody ever got fired for implementing OKRs".