[danwee]

> The more organisational layers you have between you and the customers - architects, business analysts, and the like - the more disconnected your work will be from the business value.

In every company I have worked for in the last 10 years, the layer in between business experts and software engineers has been always: the manager (either product manager or eng. manager). It's a bottleneck. The flow usually goes like this:

business expert -> manager -> engineers -> manager -> business expert -> manager -> engineers -> ...

Whenever the manager comes with "requests" from the business side, we end up with tons of questions because everything is half-baked. Manager goes back to business with our questions and comes back with some answers, but usually that just generates even more questions. In this way managers feel empowered. There's no way they can let the engineers just talk with business (otherwise the managers would feel like they are not contributing in anything... which is kinda right if the engineers are more or less professionals).

[FuriouslyAdrift]

When I worked disaster recover and continuity, we had to map every business process.

We would make one map from the info the managers told us and one map of the actual processes by talking to every single employee involved.

We frequently found critical processes no manager knew about and also that some random secretary was the focal point for entire departments (mundane processes no one else wanted)

[pjc50]

This is incredibly difficult, valuable work that so few organizations dare to do. Often the answers are unpopular.

[thenobsta]

Whoa, this is unsurprising, but surprising/unfortunate.

I'd love to read a tutorial of how mapping every business process is done in practice. Do you have any pointers?

[FuriouslyAdrift]

You start with any documentation they already have (usually done for insurance or legal reasons) and start mapping much in the same way you would map data flow in a program.

Other sources are any existing ERP or other business process system.

Paperwork of any kind (invoices, quotes, POs, accounting) can also be used.

Even if a business thinks they are a flat org and have few processes, I guarantee there are ad hoc managers/leaders along with shadow processes.

[gbalduzzi]

Well, being the middle man is kinda the manager job. The situation you describe happens when the manager does a poor job and is both submissive to the business requests and unable to comprehend technical issues.

Ideally having a competent person acting as the middle man for most daily operations is desirable though

[christophilus]

This is it. I have had a few really good managers in my career. They were game changers. When they came to me, they’d really done their homework and thought about the problem, or they hadn’t done it at all and were handing it off to me and giving me the contacts and support I needed to do my own research and own a thing entirely myself.

Outside of those managers, managers have been worse than useless. They’ve been an impediment to both me and the business (from what I can see).

So, in my experience, a good manager is worth every penny. All other managers are a net negative.

[RandomLensman]

In a lot of organisations the business side isn't necessarily incentivised to talk to tech, which causes a lot of issues. In good places, it's different and the development cycles work really well with an engaged business side. You still might want some manager in there to manage demands, conflicts, resources, etc.

[themanmaran]

Agreed. There is a role for a good manager to filter ideas from the business side and make sure all asks are building towards the products future. If the funnel is "sales people => engineers" you're likely to get a lot of spurious development that doesn't make the product better.

Reminds me of the "if apple built every feature requested" meme.

https://twitter.com/blader/status/1698369360581337399/photo/...