13 ms·
Speaking as someone big-co track record... that seems like a bit of a strawman though, doesn't it? Not every team, in fact, most teams are not going to be the
by existencebox 8y ago
Speaking as someone big-co track record... that seems like a bit of a strawman though, doesn't it? Not every team, in fact, most teams are not going to be the pivotal shared component behind billion dollar pipelines. Enterprise internal policies re: things like accessibility and security review are _hardly_ reflecting of that, since it's impossible to be fine grained and accurate, so they typically apply "a big hammer" across most groups and "an even bigger hammer" across others.
This is close to heart as I've grown a few teams from "small green-field experimental 3 people groups" to full on 8-10 person launched feature teams, and watched the process slow to a crawl despite the additional manpower. There's definitely a _reason_ for some of the bigco paranoia, but being flexible and accomadative in this sense is certainly not one of our strong points, so you usually get a decent amount of institutional boilerplate/plumbing work too, _especially_ when some of these side groups (e.g. UI) have a vested interest in having their fingers in as many pies as possible.
A somewhat tongue and cheek but accurate picture to draw: I've seen a dropdown menu go from being "code it up before lunch" to "3 weeks of meetings, multiple reviews, and demos in front of stakeholders" task. Were some parts of that useful? Sure. All of it? Probably not.
(To be clear; I don't actually take issue with much of the conceptual process, and like that there's some amount of oversight, but the nature in which it gets placed on teams is often 1. often not fully aligned with their actual "threat model" and prioritization in whatever space this is and 2. often given with inopportune timings and without a good support system. I call out the negatives above pretty exclusively because I think a bigCo _could_ do the processi-fication with a lighter touch and serve the same ends.)
- beat 8y agoIt's like Russian roulette. Sure, five chambers out of six are empty and won't hurt you at all. But you still might want to slow it down with a process to make sure there isn't a round in the chamber. Someone, can't remember who (and I wish I did!) said "Process is the scar tissue of organizations". These processes don't come from nowhere. They come from specific negative experiences the organization had. The problem is that it's easier to add process than remove it or clean it up so it isn't so stressful. So once process is really slowing things to a crawl, it's time to clean up, but it's a real chore. This is my career, basically. I come in to big organizations with big legacy messes to try to make things easier. Reducing the headaches of awkward and often unnecessary process is close to my heart. But a big part of that is recognizing the necessity of process. There's a huge difference between "this is frustrating" and "this is worthless".
- dennisgorelik 8y ago> I come in to big organizations with big legacy messes to try to make things easier. Is your current business - http://congruence.io http://congruence.io ? It redirects to https://congruence.io https://congruence.io with invalid SSL certificate...
- beat 8y agoYeah, Congruence is kind of dead in the water right now. I should fix that, but it's going to be a while before I have the time to tackle the project again. My current work is as an ordinary devops engineer at a very, very large company. I do want to go after the problem space again (mostly, helping find the problems caused by interdependencies of complex, slow-changing systems - "System A changed, so System B broke"). But it's a seriously nontrivial problem, which is why there aren't any good products out there for it.
- user5994461 8y agoIn a multi billion dollars company, there are many billion dollars pipelines and it's very easy for any single person to break one accidentally.