Big company tale: six months for a list and a button

Um so?? It was on the roadmap. They had other work to do. I get you want everything right now, but it first work that way.

This is too real. But not only big companies, even startups with good funding and mid-sized team can behave like this.

This mimics my mobile product team's battle with the marketing team that is supposed to own the companies 'tone-of-voice' in all material (digital, printed etc).

Have multiple stories on waiting for resources, such as images and text that took weeks to get and then were not used as they didn't follow the guidlines given ('text can be max x char long', 'image resolutions need to be w times v').

We have all but given up on trying to involve them, as it will slow everything down to a crawl if we do.

I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with.

There was a piece few days ago about picking co-founder using the army way.

Beside being a well written piece, it made clear one thing.

The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need to create in order to exist and sustain itself.

(Which doesn't means disregard rules, it means find a way to make stuff happens in the context of the rules.)

In the article there are dozen of things that are just expected given the conditions. But there are also a lot of stuff that the author could have done differently in my opinion.

For instance figure out the resources that was suppose to create the application, pass by its office, offer its a coffee and communicate clearly why the things is important and how important it is and what is the goal of the project and finally reassure the resources by putting in whatever work tracking system all the details.

These kind of human work and relationships building is fundamental.

It seems easy to you just ask another department "please do this" and when naturally things takes too long to look reasonable complaining on the internet.

There is a world of difference between:

1. Some random guy wants a boring dashboard and it is not very clear the reason and the why.

2. That cool engineer has a real problem that really bother it and its whole team and I can easily fix it.

Yeah it is not a scalable way to solve problems but dumping work on some oscure Jira board is not scalable neither.

So much of this story doesn’t make sense to me. What is a “dashboard team”? Is that data engineers and report developers or is it a dev-ops reporting team? When I think the former, I think ETLs, data warehouses, tableau/powerBI and when I think the later I think uptime, memory, cpu, fleet metrics, etc. in the FAANGs I’ve worked, individual service teams are responsible for their devops. You needed a single page that talked to your service and a button that contacted you. Put it in your team’s roadmap. Why would you outsource your service’s alerting infrastructure to a team that doesn’t seem to have any expertise or broader ownership of other alerting infrastructure?

How were other services at “big company” handling alerting? (And why would you rely on a manual process for altering anyway)

This story left me confused more than anything.