Comment by nine_zeros | Hacker News Reader

Comment by nine_zeros | Hacker News Reader

The biggest thing that companies need to optimize on - which they don't seem to have caught on to yet - are management processes which create unprofitable overhead.

While "overhead" is an overloaded term, in practice it looks like:

1. Too much documentation, blog posts, spreadsheets (designed for management optics). Every one of these artifacts takes dev time.

2. Excessive stages in CI pipelines, internal tools, saas tools usage (designed for engineering promos). Every one of these takes dev time.

3. Excessive features (designed for IC and management promos)

4. Excessive amount of time spent in promotions, stack ranking, and performance reviews (designed to make management useful)

5. Excessive time on making agile work such as time on Jira story points, backlog grooming, retros, meeting minutes, agendas, scrums (designed to again, make management appear like they are doing something).

6. Excessive number of management layers (manager, sr manager, director, sr director, sr sr director, associate vp, vp, svp). Every person on this ladder is overhead*365 days a year.

All of these are entirely a problem of management layer overhead.

The only and only thing that works in a tough environment is few "skilled" managers who are still very technical and can align people and teams work towards specific goals.

As much as I agree with the high-level message, I disagree with the specific list.

The list makes sense from the bottom, where the goal is to get stuff done. The list makes no sense from the top, where the goal is to make sure the right stuff gets done. Without a lot of those, you end up either with:

- 1000 employees moving in 1000 directions

- 1000 employees working from home doing nothing

... or similar pathologies.

Organizational alignment is hard. I would have written a similar list to yours two decades ago, but right now, I see just how much effort it takes to make sure things don't go in the _wrong_ direction.

The good stuff on your list to eliminate are management layers, excessive features, and promotions / performance reviews / stack ranking.

Most of the things designed to provide communications, alignment, and transparency (e.g. documentation, spreadsheets, blog posts, many types of internal tooling / dashboards, backlogs, retrospectives, minutes, agendas) are very much necessary evils. There might be better ways to accomplish some of those same goals, but if you just cut them, organizations break, and break very badly.

You definitely can (and should) do without those at 1-5 people, and possibly up to 30. It's worth noting "people" here often includes external stakeholders, such as investors.

> 5. Excessive time on making agile work such as time on Jira story points, backlog grooming, retros, meeting minutes, agendas, scrums (designed to again, make management appear like they are doing something)

I lose so very much time to not just the ceremonies, but to wrestling-with/losing-things-in all these bafflingly complex tools like Jira or Asana or "Azure Devops" and such.

Most places I've been use Github or Gitlab. The issue trackers there are fine. They're close to the code, and in a site I'm already using. They're easy to have conversations in. They work well with built-in review processes, and with pull/merge requests. They don't permit enough strict structure that one worries about smashing some PM's carefully-constructed sandcastle by just trying to use them, but have enough filters and tagging and such that you can apply every bit as much logical structure as I've ever seen in Jira and friends, if you want to, it just won't also make it horrible to use when you do.

I wonder sometimes what % of productivity companies are losing by letting PMs pick where tickets & communication about tickets live. Plus the extra cost of the tools themselves.

My previous team is getting into a fight with a new project manager who doesn't want to acknowledge the logistical issues of trying to fit a new agile framework into "Azure DevOps", and the team doesn't want to admit that their current workflow is suboptimal because of the change that will entail.

And of course, the politics of using anything besides ADO will take years.

7. Excessive componentization. Microservices. Many many source control repos. Many many artifacts. Many many highly encapsulated classes/modules/services/entities. All creating a conceptual and practical trail of complexity and usually shipping the org chart instead of a product.

The siloeing is driving me crazy. Everybody works in their own little box doing their own thing without any regard to how things fit together. Microservices, separate repos for some trivial all lead to enormous integration efforts.

I like the phrase “shipping the org chart”.

Rugged individualism: corporate edition

I think this kind of thing is exacerbated by rapid hiring

This is a direct result of engineering teams being let loose and becoming risk disconnected from the wider org. This leads to risk evaluations at a macro level which absolutely destroys efficiency.

Sit down with your risk or compliance officer for a couple of hours and thoroughly explain the ins and outs of your complex CI/CD pipeline to them. Your whole team will be up shit creek by end of the week.

But we don't have those discussions.

agile "agile" is an oxymoron

Agile is a philosophy, not a system. What we most know as agile is the result of systemizing it.

“The purpose of a system is what it does”

Agile is an adjective, not a noun. The opposite of agile are words like clumsy, apathetic, depressed, dispirited, down, dull, ignorant, inactive, lazy, lethargic, lifeless, rigid, slow, sluggish, stiff, stupid, brittle, etc. That's why being agile caught on because none of the opposites sound like a good thing to admit to.

That's why agile is a bit vague and waffly as well. Because world+dog now calls themselves agile. And then you get all these pedantic types telling others they are doing it wrong, aren't pure enough, etc. They are the priests of agile. And they get hired by big companies for lots of money to help them become agile. Of course that requires some compromise and they adapt their definitions and standards until it's all agile and wonderful. Because the alternative would be admitting failure, which isn't mutually beneficial. You are kind of doing waterfall in an agile way For example, you plan 20 scrum sprints ahead and then act surprised reality has different plans. It's still as dumb as waterfall ever was.

Most of these companies of course deliver software just fine. They don't do it particularly fast. Or well. Also they aren't that flexible. Or particularly quick to adapt to changing circumstances. I.e. all of the things one would associate with being agile (in the adjective sense). But it's good enough to call themselves agile and still feel good about it.

People were doing awesome software long before agile development became a thing. That was never conditional on being agile (whatever that means). I've been around long enough to have seen the before and after the post-it shufflers came in and made our walls all colorful. And I can tell you that the average software project is just about the same level of a disgraceful mess as it was thirty years ago. We do a bit more of it and a bit differently. And we got some nice tools that remove some bottlenecks from our process (like automated tests and CI) and make us more productive That's not agile, it's using better tools and it helps. The tools definitely improved massively in thirty years.

"we need you to be agile, but we need you to plan months in advance the agile things you're going to do so we can budget around it."

"And can you update the detailed plan now that we've decided to change a fundamental decision that invalidates half your planning? That'd be great mkay."

Reply on news.ycombinator.com