I have had similar experiences multiple times and you definitely learn not to really care and let it be as this is what it is.<p>It took a bunch of teams of senior devs and other people 1 year to translate some simple excel sheet with formulas into a little Java powered site on top of a database. The cost was a few $100k and the end result was something most people here on HN can do in an afternoon (max a few days), but tech was never the issue; it was the process & politics between the IT dep (which was in another country (Germany), the head office, the hired consultants (I was one of them) etc. My job was to steer the tech people at a high level (they had their own project manager etc; that was not my job) and the consultants (from another company) that did the implementation kept disagreeing with my approach and everyone else kept disagreeing with everything else (like the color of a button). In the end it was implemented like I wanted it in the first place (and they took the credit) and I heard, much later, from one of the seniors that their PM told them to disagree with me to pump up the final bill. Which worked; luckily I never worked 'with' them again after.
Had very similar experiences at not even a "big company" it's more of a mentality of a "Big Co.". People hired to just not care, sit at meetings to make managers feel important and provide some pseudo progress to higer-ups to make things look like they are moving somewhere.<p>In reality, I have not doubt a half decent motivated engineer can replace a group of these unmotivated developers, which I have seen done and did my self in the past.<p>The real reason unmotivated engineers are there and things work this way in a company, in my experience, is bad management. Good people leave, who ever is left does what ever they can, those who care, suffer.
See also: a <i>Web Server Installation</i> story from The Daily WTF. <a href="https://thedailywtf.com/articles/web-server-installation" rel="nofollow">https://thedailywtf.com/articles/web-server-installation</a> It took 33 days for the sysadmin to get access permissions, before the project was cancelled one more month later.<p>Comment: So, everything went smoothly?
Ha I once tried to write a dashboard for our fledgling ecommerce platform at a relatively small company and hit a solid brick wall trying to get it deployed for all sorts of <i>internal politics reasons</i>. After months of back and forth I gave up. After about a year an entire new team was spun up with back end and front end devs to build something like the dashboard but… better… it took months of course.<p>This isn’t just something that happens at BigCorps unfortunately. Any company can have an anti-innovation, anti-hacker culture like this.
On a bright side this allows small companies (free of such problems) to compete with big corps, which benefit from economy of scale and can invest into R&D much more.
I've been in a small company (< 50 employers) with this exact culture. But instead of it being a small dashboard function, pretty much <i>everything</i> took minimum 3-6 months.<p>How did they survive being so inefficient? Huge gov. contracts, where everything takes time.<p>I mean, perfect place if you just enjoy a steady paycheck, while working on side-projects and personal stuff - but even that gets boring, real quick.
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).<p>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').<p>We have all but given up on trying to involve them, as it will slow everything down to a crawl if we do.
You can also use this essay to examine opportunities and pitfalls of horizontal coordination across organizations.<p>I used to work at a big tech company, but now I’m one of a few cloud devs at a startup. One day we realized we needed a dashboard, so I spun up a server and put a single binary on it that saves data to SQLite and renders HTML server-side. Dumb stuff. Took 2 days, problem solved, been humming along for a year, no plans to rewrite it.<p>Now let’s say another dev decided that they wanted to build another dashboard to monitor a service they just built. Obviously I’m gonna insist that they add on to the stuff I already built. I show them where to add the function (literally one function that makes an HTTP request and returns an error), it takes them 10 minutes instead of 2 days, and doesn’t add another entry point for attackers.<p>But now let’s say our company now has 100 devs. There’s now more status info than can fit on a single page. If you don’t do this right, the dashboard communication/management overhead at some point grows larger than the cost to develop a new dashboard.<p>What the dashboard team in OP’s article should’ve done is to create a self-service solution for making a new dashboard: here’s a big template, fill in whatever health checks you need in one of N languages, and tell us when you’re done and we’ll spot check the code and deploy it for you. That way they maintain control of all the dashboards, and teams get their dashboards way faster.<p>(Am I missing a downside, other than that the dashboard team will need to downsize?)
This pains me deeply. As one of the people that can just crank shut out, I find myself frustrated. I then meditate that these people exist for when things go wrong so I can check out. Just rest and vest. Rest and vest is the way.
> April 8: it seems there's now a mock-up of sorts from the team. Inside the group, we start talking about that situation where if you mail the $open_source_project mailing list asking for help with a legitimate problem, nothing happens, but if you make up a shitty version of something and fire it off, then suddenly 50 million people show up and go OI! DO IT THIS WAY! But, three months earlier when you politely asked for help, zip, nothing, nada, zilch.<p>This seems quite interesting to me. I haven't really got chances to interact with mailing lists, is this really the case?
>"this is the only way we can maintain it".<p>So, when you don't have XP with X tech, but you wrote your hacky solution<p>and the person who has XP with X tech tells you that other_solution is more maintainble, then probably...<p>He/She's right.
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.<p>There was a piece few days ago about picking co-founder using the army way.<p>Beside being a well written piece, it made clear one thing.<p>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.<p>(Which doesn't means disregard rules, it means find a way to make stuff happens in the context of the rules.)<p>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.<p>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.<p>These kind of human work and relationships building is fundamental.<p>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.<p>There is a world of difference between:<p>1. Some random guy wants a boring dashboard and it is not very clear the reason and the why.<p>2. That cool engineer has a real problem that really bother it and its whole team and I can easily fix it.<p>Yeah it is not a scalable way to solve problems but dumping work on some oscure Jira board is not scalable neither.
My personal record is 2 years for a text box to be added to a form. To be fair, that's harder than it may sound. The textbox must be in the web version, the app, the api. It needs to be localized, and data stored must be compliant with GDPR etc. The list goes on. It doesn't help task velocity if the PMs switch, the thing gets de-prioretized, re-prioretized and there still being ongoing discussions that question the purpose of the textbox (maybe we should do videos instead of text). After 2 years I'm happy to report the textbox launched... :-/
I work in an organization where the developers pretty much run the show, it sounds like heaven but we bump into churn situations like this all the time.<p>The thing the author doesn't really realize in this article is that building consensus and making sure everyone agrees with the priority of the project is part of the job.<p>It kinda sounds like he had pet project that others disliked so they tried to kill it by claiming the "dashboard team" was handling it. Then he attempted to vicariously micromanage the project from another team.
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?<p>How were other services at “big company” handling alerting? (And why would you rely on a manual process for altering anyway)<p>This story left me confused more than anything.