I’d love something like this: I loathe the bullshit factory process has become.
It is true that process tends to naturally scale with org size and longevity because communication becomes more complicated with this scaling - but that only gives you a bit of a lower bound (i.e. if you go below this, you start shooting yourselves in the feet)
This is always a red flag I'm dealing with someone inexperienced, or desperate. Processes can be very unique to each company, especially the problems that they're facing, and trying to shoehorn someone else's process into your own business without understanding the problems that process is solving is a recipe for failure.
"Process weight" is a good concept I wished more people understand. Building released-to-web software without hardware, big teams, long-term API support, etc. should really have almost no process, except for maybe high-level prioritization of features/functional areas (which a small-company CEO or PM can do). Reflecting on my own experience, it's the micro-management of most development processes that kills me -- 45 minute stand-ups where I'm arguing over whether something will take 2 or 4 hours. I honestly don't know and the powers that be just can't accept that. "How do you not know how long doing that will take!?!"
I think most teams would be capable of this, it's just that the people signing the checks get really, really uncomfortable with the apparent lack of accountability.
(I don't mean bean-counter pejoratively; the world needs order and predictability just as much as it needs creativity).
If you're early-stage Facebook or most consumer-facing recreational apps, "move fast and break stuff" with minimal process is great, since the potential downsides of pushing a bug to production are usually far outweighed by the value of iterating quickly. You can trust your developers to do the right thing, because for the most part developers will, and on the rare occasion that someone doesn't, the consequences are not severe.
If you're Signal, or a FinTech company, or NASA, or a medical device company, then you need significantly more robust process to ensure that appropriate quality control, chain of custody, etc. is being applied at each stage of the process. Trust alone no longer works because even though it will get you the result you need _most_ of the time, that is not a high enough success rate.
Put more generally, more/improved process is required when you cannot tolerate a given failure rate, and in general you trade off throughput against failure rate.
Having said all of this, many companies cargo-cult Google and add process when they don't need to raise the quality bar, or implement poor process that fails to increase the quality bar; these would be examples of bullshit process as the GP puts it. However I feel like we're often not presented enough context to disambiguate appropriate process from BS.
The trick is finding a balance, as a friend once told me the sweet spot is "as little process as possible, as much process as necessary".
Is that what I said? No.
I got into computers because I dislike people: leave me alone and let me work.
There are formal codified processes and there are informal tribal ones. Often when I hear people have disdain for processes, it’s usually they don’t like someone else’s process. Unfortunately, standardized processes tend to become more necessary as systems get more complicated in order to ensure an operation becomes fault tolerant by not being reliant on a person that may leave but instead reliant on a process that stays.
Processes mitigate risk. Just because that risk isn’t important to you doesn’t mean that risk isn’t important to someone. With that said, there are smart, efficient ways to mitigate risk and there are inefficient, burdensome ways
Personally, no. I have spent enough time at enough organizations to simply adapt to whatever they do. But if I want to write some code I just do that. I might toss in testing or whatever for bigger projects, but it’s all ad hock.
Processes are about repeatability, but for personal projects you can customize based on more specific goals. If I want speed, accuracy, or whatever I am going do made different choices. I am even going to change things up based on whatever mood I am in at the time.
True but misleading. A lot of the time the difference is simply doing a bunch of process activities versus not doing them. E.g. imagine team A develops software in a more-or-less sensible way, and team B spends 80% of their time doing the same things that team A does and 20% of their time estimating how long those things are going to take. It seems fair to say that team B has not just different processes from team A or less formal processes than team A, but actually has more process than team A.
> Processes mitigate risk. Just because that risk isn’t important to you doesn’t mean that risk isn’t important to someone.
Processes can be a mechanism for mitigating risk. They can also be entirely devoid of value.
I'm not saying all process is worthless, but someone who wants you to follow a process should be able to tell you who that process benefits and how. If the only reason you're following the process is because it's the process, it's probably a waste of time.
Pointing out bad processes does not refute the point that processes exist and they exist because somebody is trying to mitigate a risk. It’s just a comment about the effectiveness of the process design.
You not agreeing with the risk assessment is not the same as denying the intent. It’s also not the same as saying it’s effective at managing the risk.
If there’s a required review, you may think it adds no value. But you may also be ignorant of the downstream risks it mitigates. “You” may not care, but somebody downstream does. “Your” ignorance of the situation doesn’t invalidate the process, although it may speak to poor leadership in terms of making sure people understand why the process exists. You can, however, invalidate the process by interrogating the intent. E.g., maybe the downstream interaction has changed and the review is no longer necessary. Maybe the probability has dropped enough to become a negligible risk because of a design change. The process can be falsified in terms of meeting the intent because the risk would no longer exist.
If the answer is “none”, it validates your point that the process is needless and the claim about risk is proved false. But most responses will be able to articulate what the risk is, whether it’s relevant to your position or to someone else.
Not my experience at all. Most responses to the question as phrased would be "huh?"
I would claim that most processes are not born of an intent to mitigate risk; in my experience there's rarely an intent at all, people cargo-cult the idea that they should have processes without understanding why or even conceptualising that there should be a why.
I’ve certainly worked in organizations that continued processes out of sheer inertia of “this is the way we’ve always done it.” While someone may have inherited a process and continued using it without understanding why, if you reach back to the initiator they will have a risk they were trying to mitigate. Even if their predecessors are oblivious. Again, I would chalk this up to a failure of leadership to explain the “why” when passing it off rather than a failure of process.
Even in instances where people copy processes just because they are emulating a different org, that original organization had a risk they were mitigating. Blindly following suit like an automaton says more about the person pushing it than the validity of the original intent.
A process can certainly outgrow its intent. If I am prescribed medicine and blindly continue taking that medicine after I’m well, it doesn’t mean the there was no original, valid intent. The risk profile changed; the process did not update keep inline with that changed risk profile.
Processes mitigate risk of repeating a mistake, but they don't prevent new ones, unless you have very wise people building them, and keeping them current.
Processes can be thought of as an institutional form of OCD. There are costs, and they shouldn't outweigh the benefits.
I’m not sure I fully agree. Reactive processes prevent recurring mistakes, because they layer on a requirement to close a gap. I think people can go overboard, particularly when they are myopically focused on a single risk in their wheelhouse and miss the big picture.
Better processes can be more proactive. For example, a process requiring a failure-modes-effect-analysis can identify potential faults that have never been experienced. Developers may feel like they don’t need to work on an FMEA because they “know what they’re doing” and miss latent failure modes
Without process, more employees just increase entropy. The process brings everything together.
What’s described in the OP is a process. I run a very similar process myself - contractors, minimal friction, weak deadlines, no stand ups and all. Supremely effective.
For example, in companies that deal with medical data/PHI/PII, having to go through processes is necessary because of liability, no way of getting around it.
If you want someone to pay you, though, you are going to have to let those people have a say in what you do.