Common misunderstandings about large software companies

Honestly it sounds to me like the author doesn't truly understand the inherent conflicts of interest at a large company. For example a really common anti-pattern is "Nobody knows X thing is a problem my team manages in a problem (e.g. our app eats battery usage), but if I draw attention to it they'll want to measure it forever. So do not make it a focus."

In short pretty much never does any employees/manager's/executives interest align with the company.

Obviously doing this makes sense when possible, but in cases where you see it, it's usually due to a fair amount of work to have made this possible.

To give a simple example, I work on a class of problems that require a VP level approval for new instances of $thing. I've gotten this down to a pretty straightforward process where I can work with folks who are proposing a new instance, get things working, and then the VP usually is happy to stamp the work we've already done. Though in some cases they aren't, and they have (good, probing) questions or changes they'd like us to make. But that's only possible because I have a longstanding relationship with the set of folks who ultimately approve this kind of thing, I have worked with them on a process that they like, and I have the experience to shepherd things effectively, and their trust and buy-in. And I'd argue that my case is pretty simple, because while there are a handful of responsible people that I could go to, there's rarely any individual concerned.

Consider a different, relatively common case, of a client and a server that are owned by different teams. The client wants a feature in the server, and perhaps is willing to do some development and loan headcount to implement the feature. Who is the single responsible party here?

It should probably be either the manager of the client server team or the mutual manager of both if the teams are fairly close in the wider org, but then you have multiple indirect layers between the people doing the work (client team members) and the accountable person (server team manager), and that's the state you get to after you've done a bunch of coordination work and gotten everyone to agree to that division of labor and accountability.

What I _have_ seen is several companies afflicted by this really strange characteristic of the software development industry: We appear to be the only industry on the planet where it is common to pick leaders (executives) that know nothing about the product or how it's made.

You can't run a bridge building company without knowing how to build a bridge. You can't run a law firm without knowing law.

You don't need to know all the nitty gritty - big picture is important - but understanding the product _in depth_ is a requirement in any business.

bad meetings beget bad meetings

> If they got value from those meetings, they wouldn't be complaining.

This part actually felt quite relevant. Several years in the govt, and there was definitely a difference. Many meetings that felt inane, or meaningless to even attend, where you constantly questioned why you're even there, or bothered to show. Much phone swiping, and social media browsing. Often 10x+ attendance to people that ever participated. I often felt weird even asking anything, cause nobody was participating, and it felt wrong to even try to understand the endless charts on-screen.

However, a rare few that honestly felt quite worthwhile. We arrived, discussed what needed to said, and left with a better comprehension of the situation and the tasks necessary.

Understanding the product is often important, but equally often it is something you can delegate to others. It's only the younglings that think intimate knowledge of the product is the hallmark of a great leader, because that is the only thing they themselves bring to the table.