Seems like the robustness principle could solve some of that.
A process for everything, but as much mitigation for the consequences of doing it all wrong as possible.
Seems like pair programming would help. At least one of you will know the process(Conservative in what you send).
And there's a natural cushioning against you looking bad if you both forget. There's no individual to blame and it suggests the process itself was too hard. It's a bit more uncomfortable for a manager to hate on both of you at once for a simple mistake(Liberal in what you accept).
Process makes you look bad if you don't do it 100%, which is stressful.
I'm always much less stressed when there are more people working with me. I can just double and triple check my work instead of 10x check it.
Even just having a few more in a GitHub pull request thread seems to cut bugs and stress.
I don't understand how anyone tolerates pair programming.
After many years of software work I still spend half to three quarters of my time googling/experimenting with how to do things. When I'm writing/tracing code I don't want anyone else on the keypad which I have to explain a half baked thought to. Sometimes I want to just see where a half-baked idea leads! Sometimes I want focus time as I know exactly how I intend to do something and don't want to be questioned every other line of code.
I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
I think it depends on the nature of the task and on the experience of your pair.
If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools.
If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable.
For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs.
> I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.
If someone was literally questioning every line I wouldn't want to work with them at all, they probably fuss over details and have refactored 5 line functions multiple times in one day.
Otherwise, pair programming keeps people from getting "brilliant ideas" that actually aren't, or having an episode of laziness and doing something obviously not best practice. If you parse HTML with regex, your partner can tell you to stop.
It's also like a real time test of code quality. If they ask what you're doing, then you know your approach isn't instantly obvious.
The only time I get annoyed is when I work closely with the simplicity-loving dependency-fearing types, and the hacker types who always want to solve interesting problems.
My best skill as a programmer is finding ways to reinterpret a problem in terms of things that are already widely used, and make the whole project into just some glue code. I'm not too happy when someone is trying to replace my Ansible with Bash and my framework with vanilla, or my Etcher with dd.
But even then, those people are very good at spotting weaknesses in whatever I was planning, and the product is better for it, once the best-practices solution inevitably wins put eventually.
I’ve done it sporadically to help someone out of a tight spot, or for interactive deep dives on a code base as a teaching tool. I have found it helpful in short bursts for teaching a junior engineer how to work on a code base.
Thanks for raising this topic. “Thanks for the feedback” is one of my top ten recommended books.
When there is “process on process” you get the high process culture you described.
It’s subtle in application, but significant in impact.
I’m imagining the low process culture also was single node - your performance review was more an encoding of an organic discussion.
The high process culture positions the performance review as an input to another process, I’m imagining how your leadership evaluates where you are as an org.
The overhead cost of high process is usually what people discuss - is it worth it? Is it justified? Could it be easier?
Yet in practice I’ve seen making the process easier creates an incentive to add more to the process.
For me that begs the question - who is this process truly for?
I like to keep all employee surveys/feedback systems anchored to a simple principal - it must provide more value to the participant than the perceived effort to provide it.
I’m curious - how do your two experiences compare on that?
This article touches on it, the _why_ of the process, and Bezos put it really nicely in one of his shareholder letters.
"The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you're doing the process right."
People change, organisation evolves and the process becomes the goal -- and that's when the process falls apart. Which is why I have a bit of aversion towards strictly enforced processes. Good organisations will seek feedback on processes, encourage you to ask questions, and _sometimes_ old processes will get reverted because they are not applicable anymore but because of inherent inertia it's always a little too late.
I'd make that "sometimes" stronger -- if you're not failing often, you're not trying enough things! That goes also for process change.
Processes should be invented by the people who use them, and they should continuously evaluate their appropriateness and suggest adding, removing, reordering, or changing steps based on their day-to-day experience. These suggestions should run in limited trials and then either reverted or made permanent.
In the ideal case, you run a new experiment every week (or if the process is used more rarely, perhaps every quarter.)
----
Also note the critical distinction: it should not be "the organisation" that creates processes and seeks feedback on them. It should be the people the process applies to who creates it and they will naturally get feedback as part of their job executing on it.
Think of it not as "regulation" (an authoritative body demands something) but more as "standardisation" (the involved people come together to agree on the best way to do something, based on their collective experience.)
The only thing worse than a strict process is a quickly changing process. Because then people will be forced to keep track of the changes and it becomes even more difficult to become compliant. Ideal process would include the feedback from day 1 and iterate either based on demand or at fixed intervals placed as far as possible.
Moving targets make 9-5 work more like entrepreneurship in the sense that you have strict processes that are common-sense (effectively) but to stand out you have to be creative at the process level on top of being creative at a context-specific job level too.
>The process becomes the proxy for the result you want.
this is really common for legally mandated process, and perhaps even to be wished for by the organization - hey we followed the process you guys set up, what do you mean all this money we got is dirty?
Friend of my worked in banking for many years. Came up with a clear process and policy for illiquid FX trades. Part of the policy was that the counterparty banks needed to be separate from the FX currency pairs.
People in another branch applied the process to trading rubles. Made a ton of money. Until a crisis hit; turns out the counterparty banks were all Russian. Position went to zero basically immediately, all prior profits zapped, and some uncomfortable conversations occured.
The other branch was upset, they thought they'd followed the process. But they'd missed an important aspect of the policy doc.
Point is: Sometimes short-term results get favored over process, this can be equally dangerous.
The amazing about that quote is tgat Amazon's logistics ops are the most standardized I've seen so far. There were signes of prioritizing the process over the goal, as Bezo's wrote. And still the goal always won out in the end. It's those small things that make Amazon the company it is.
All that is only valid for my time there, no idea how things are now.
>"Companies get confused. When they start getting bigger, they wanna replicate their initial success, and a lot of them think somehow there is some magic in the process of how that success was created. So they try to institutionalize process accross the company, and before very long, people get very confused that the process is the content. And that's ultimately the downfall of IBM : IBM has the best process people in the world, they just forgot about the content."
[...]
>"In my career, I found that the best people are the ones really understanding the content, and they are a pain in the butt to manage, but you put up with it bc they are so great at the content. And that's what makes great product : it's not process, it's content."
> ...the question of repeatable processes versus the flash of brilliance.
> In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.)
> ...the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes.
Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments.
> ...
> Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition.
> ...I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.*
Regulatory / legal compliance? Solid process = good
Non-customer-facing repeatable operations? Solid process = good
Financial controls (with the right level of flexibility for smaller/quick decisions to be made)? Process = good
Restricting creative/knowledge worker teams - whether design, product, marketing, engineering - with over-burdensome "process for the sake of the process" = quick way to lose good talent and kill good ideas before they come to life
Gerald Weinberg has an interesting (and more finely grained) take on this.
- Level 0, the Oblivious pattern, corresponds to one or two people just solving problems with code. They don't have any external customers, and they don't even think of what they're doing as software development. Think accountant scripting a spreadsheet and you get the idea. This is obviously a culture with little process. You will likely not even find best practises like version control, testing, code review, etc.
- Level 1, the Variable pattern, is a lot like level 0 except there are now external customers. These make demands, but the software developers generally still spend time doing what they feel like. This scales up to something like 12 people (as suggested by Boehm), and Brook's surgical team of experts (from The Mythical Man-month) is probably a good model for team composition in this pattern. To support collaboration, you start to see things like version control, code review, etc., based on the likes and dislikes of the team involved. In this pattern, failure is often ignored or downplayed in the interest of moving on with things. Still a low-process, winging culture.
- Level 2, the Routine pattern, is what usually happens when organisations grow. The Variable pattern stops working because the organisation can no longer hire exclusively experts. Management is tired of the unpredictability that comes of a Variable team of non-experts, so they Institute processes based on best practises. However, since the processes are enforced from above, and nobody really understands their purpose, and they aren't fit for that purpose anyway, most real work gets done by secretly abandoning the processes.
Especially during time pressure, even management will suggest to throw out the process because "we don't have time for that". Since nobody understands why the process is there anyway, the Routine pattern tends to devolve into the Variable pattern at the first whiff of failure. The Routine pattern is effectively the organisation trying to be systematic but not having the necessary understanding to do so.
It honestly sounds like the author was suffering under the Routine pattern, to me.
- Level 3, the Steering pattern, is a better but more demanding approach than the Routine pattern. The Steering pattern starts with a respect for observation, understanding, and feedback. It institutes processes that are appropriate for their purpose. It treats failure as an opportunity to adjust process.
Most normal projects in the Steering pattern looks like the Routine pattern. The difference is that a lot more projects become normal in the Steering pattern, because they don't throw out processes when they need them the most. They understand their purpose and collectively adapt them to always be relevant.
----
As some sort of summary:
- In levels 0, 1, and 2, people aren't very good at using feedback at all. It's mostly ignored or used as a stick to beat people with.
- In level 3, people can use feedback from individual projects to evaluate and adjust the same projects.
- In level 4 (not described above), people can use feedback from individual projects to evaluate and adjust the processes and teams that drove those projects, meaning feedback gets used more generally.
- In level 5 (not described above, also never observed by Weinberg), people do all of the above observation, but also meta-observes: they use feedback from projects to evaluate and adjust how they use feedback from projects.
I think this has helped me understand exactly how I feel about process.
Any process that stops you from doing what you know is the right thing to do, is bad process. And any time you lack process that could have saved you from doing the wrong thing, is bad. The sweet spot is process you never think about, that makes things just work right.
Let's say you work on a HIPAA project. You have been through the HIPAA training. You know how your product is supposed to work to comply with HIPAA. A bad process would constantly gate-keep and nag and hold you back, checking every 5 minutes if anything you do is compliant. But also a bad process would not provide any checks at all, making it easy to miss something important. The good process prevents things falling through the cracks, while not holding you back from doing your job.
Good process helps you do your job better. Bad process makes it harder to do your job well.
I've seen this in a lot of places that I've worked. I find myself coming back to Des Traynor's talk at the Web Summit[1] when thinking about process. One point that hits home is hist quote that every process will slow us down, and some will make us better. Organisations need to have a natural resistance to new processes, and a willingness to drop ones that are no longer serving the business.
Anecdotally, I see this a lot in organisations that have various operations teams (product ops, design ops, recruitment ops, etc.). It is often the responsibility of these teams to create processes and frameworks for other teams to work within. I think there's less willingness to push back against these teams when they want to introduce new processes than if, say, a single product manager(or designer, recruiter, etc.) proposed a new process.
I've hated almost every* high-process environment I've been in. To me, "process" feels like overhead. Overhead is anything not contributing to the value proposition of the company's products or services. Overhead is the friction and heat of a sloppy machine. So a couple job hops have been to smaller/newer companies that haven't gotten baroque yet.
* The exception was one company that knew it. The attitude was like, "yeah, we're kinda overbureaucratic, but we're gonna be _good_ at it." And indeed, the process slowed down the overall work a bit, but the process was kinda well done and not painful.
I think that it's all relative (of course! ;) and you have to tailor the processes to what you're trying to achieve (duh!). However, in my humble opinion, the most important thing about processes is to always, _always_ remember _why_ a certain process exists, it's spirit and goal. If creation or modification of a process does not actively discuss or recall the reason for a process's existence then imho trouble will occur eventually.
If the reason behind the process is not given proper visibility and importance then, in my opinion, eventually you'll end up with Five Monkeys Experiment [0] kind of situation - everyone follows some process with no idea why, even if the reason for that particular process has long evaporated.
Sometimes high process is necessary. (I've worked in an FDA-regulated environment. They're really trying to not have medical devices kill people. That's worth doing.)
But, even when it's necessary, that doesn't mean that I want to work there. High process forces me to become a bureaucrat. I do not want that in my life (or in my career).
> Sometimes high process is necessary. (I've worked in an FDA-regulated environment. They're really trying to not have medical devices kill people. That's worth doing.)
There are lots of ways to kill people.
You don't want to approve something that will kill someone but you also don't want to delay something that will save someone.
I've worked in very high process environments (CMM 3 as one example) on occasion and for the most part they've been really awesome and focused on greatness. More please!
That's not the narrative I see here (these comments), so maybe the foregoing is surprising to some of you.
For many reasons I take it as fact that we aren't nearly as rational about technology choices as we tell ourselves and each other. (My father was a shrink.) Seems to me like every part of the mythical technology stack comes with ritual (alleged best practices) concerning build practices, code management, coding styles, you name it. Indeed you can, at least in a caricaturish fashion, diagnose personality associated with languages as sadistic, masochistic, romantic, hysteric, nostalgic, narcissistic and so forth.
These practices don't build greatness. Based on what I've seen over many years, so-called "best practices" are often, if you will, part of the "affect" informing such diagnosis.
There is something I refer to as "crazy" (noun), and when I write code one of my guiding principles is avoiding / reducing crazy. We all know how we feel when things are crazy, right? Sure, I know you personally are immune to the effects of crazy, but what about those around you?
They probably get a little neurotic and fall back on habits; so it's good if best practices align with those habits. Actually, I'm kidding.
Minimize crazy, or it ends up as tech debt in your tools rather than your product.
I consider my philosophical differences with the author to be of no particular consequence. The article really resonated with me especially the observations that you can't enforce greatness and the tendency of people to think their job is to follow policy when they're in a kettle of crazy.
I like processes that systematize getting decisions in front of people with expertise and good judgement (peer and committee review, etc).
I despise processes that enforce rules perhaps once born of good judgement, but now divorced from the judgement-having person's assumptions about context or her ability to change her mind when presented with new information.
30 comments
[ 1.4 ms ] story [ 54.2 ms ] threadA process for everything, but as much mitigation for the consequences of doing it all wrong as possible.
Seems like pair programming would help. At least one of you will know the process(Conservative in what you send).
And there's a natural cushioning against you looking bad if you both forget. There's no individual to blame and it suggests the process itself was too hard. It's a bit more uncomfortable for a manager to hate on both of you at once for a simple mistake(Liberal in what you accept).
Process makes you look bad if you don't do it 100%, which is stressful.
I'm always much less stressed when there are more people working with me. I can just double and triple check my work instead of 10x check it.
Even just having a few more in a GitHub pull request thread seems to cut bugs and stress.
After many years of software work I still spend half to three quarters of my time googling/experimenting with how to do things. When I'm writing/tracing code I don't want anyone else on the keypad which I have to explain a half baked thought to. Sometimes I want to just see where a half-baked idea leads! Sometimes I want focus time as I know exactly how I intend to do something and don't want to be questioned every other line of code.
I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
Why would anyone want to do this?
If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools.
If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable.
For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs.
> I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.
Otherwise, pair programming keeps people from getting "brilliant ideas" that actually aren't, or having an episode of laziness and doing something obviously not best practice. If you parse HTML with regex, your partner can tell you to stop.
It's also like a real time test of code quality. If they ask what you're doing, then you know your approach isn't instantly obvious.
The only time I get annoyed is when I work closely with the simplicity-loving dependency-fearing types, and the hacker types who always want to solve interesting problems.
My best skill as a programmer is finding ways to reinterpret a problem in terms of things that are already widely used, and make the whole project into just some glue code. I'm not too happy when someone is trying to replace my Ansible with Bash and my framework with vanilla, or my Etcher with dd.
But even then, those people are very good at spotting weaknesses in whatever I was planning, and the product is better for it, once the best-practices solution inevitably wins put eventually.
You haven't tried it, but you're telling everyone what you think about it anyway?
When there is “process on process” you get the high process culture you described.
It’s subtle in application, but significant in impact.
I’m imagining the low process culture also was single node - your performance review was more an encoding of an organic discussion.
The high process culture positions the performance review as an input to another process, I’m imagining how your leadership evaluates where you are as an org.
The overhead cost of high process is usually what people discuss - is it worth it? Is it justified? Could it be easier?
Yet in practice I’ve seen making the process easier creates an incentive to add more to the process.
For me that begs the question - who is this process truly for?
I like to keep all employee surveys/feedback systems anchored to a simple principal - it must provide more value to the participant than the perceived effort to provide it.
I’m curious - how do your two experiences compare on that?
"The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you're doing the process right."
People change, organisation evolves and the process becomes the goal -- and that's when the process falls apart. Which is why I have a bit of aversion towards strictly enforced processes. Good organisations will seek feedback on processes, encourage you to ask questions, and _sometimes_ old processes will get reverted because they are not applicable anymore but because of inherent inertia it's always a little too late.
Processes should be invented by the people who use them, and they should continuously evaluate their appropriateness and suggest adding, removing, reordering, or changing steps based on their day-to-day experience. These suggestions should run in limited trials and then either reverted or made permanent.
In the ideal case, you run a new experiment every week (or if the process is used more rarely, perhaps every quarter.)
----
Also note the critical distinction: it should not be "the organisation" that creates processes and seeks feedback on them. It should be the people the process applies to who creates it and they will naturally get feedback as part of their job executing on it.
Think of it not as "regulation" (an authoritative body demands something) but more as "standardisation" (the involved people come together to agree on the best way to do something, based on their collective experience.)
this is really common for legally mandated process, and perhaps even to be wished for by the organization - hey we followed the process you guys set up, what do you mean all this money we got is dirty?
People in another branch applied the process to trading rubles. Made a ton of money. Until a crisis hit; turns out the counterparty banks were all Russian. Position went to zero basically immediately, all prior profits zapped, and some uncomfortable conversations occured.
The other branch was upset, they thought they'd followed the process. But they'd missed an important aspect of the policy doc.
Point is: Sometimes short-term results get favored over process, this can be equally dangerous.
All that is only valid for my time there, no idea how things are now.
>"Companies get confused. When they start getting bigger, they wanna replicate their initial success, and a lot of them think somehow there is some magic in the process of how that success was created. So they try to institutionalize process accross the company, and before very long, people get very confused that the process is the content. And that's ultimately the downfall of IBM : IBM has the best process people in the world, they just forgot about the content."
[...]
>"In my career, I found that the best people are the ones really understanding the content, and they are a pain in the butt to manage, but you put up with it bc they are so great at the content. And that's what makes great product : it's not process, it's content."
I think this is from an interview made for the documentary Triumph of the Nerds, so 1995.
https://www.youtube.com/watch?v=rDqQcmVqAm4
> ...the question of repeatable processes versus the flash of brilliance.
> In many cases, there isn't much of a compromise between the two. A really great novel is never written using a repeatable process (although pretty good mass-produced junk fiction can be and is). Meanwhile, a widget factory runs on repeatable processes, and doesn't require much brilliance once it gets going. (Hopefully there was some brilliance in the original widget design.)
> ...the never-ending conflict between "Software Engineering" and "Computer Science." Software Engineering claims that software can be created faster, better, and more reliably if you can just define repeatable processes and hire a bunch of code monkeys to implement those processes. For some things, like banking applications and warehouse management software, it works: well, at least it works better than trying to do the same thing without your repeatable processes. Computer Science, on the other hand, is all about the flashes of brilliance and the "aha!" moments.
> ...
> Unfortunately, it seems that two totally different social structures are needed to produce repeatability versus brilliant insight. A structure that encourages repeatability will stifle creative insight; but a structure that encourages creativity produces non-repeatable results, almost by definition.
> ...I do know the form of the solution: you want a process that repeatably produces brilliant results. If you could do that, you would be unstoppable.*
More compromises (2006), https://archive.is/EEMxl | https://apenwarr.ca/log/20060210
Regulatory / legal compliance? Solid process = good
Non-customer-facing repeatable operations? Solid process = good
Financial controls (with the right level of flexibility for smaller/quick decisions to be made)? Process = good
Restricting creative/knowledge worker teams - whether design, product, marketing, engineering - with over-burdensome "process for the sake of the process" = quick way to lose good talent and kill good ideas before they come to life
- Level 0, the Oblivious pattern, corresponds to one or two people just solving problems with code. They don't have any external customers, and they don't even think of what they're doing as software development. Think accountant scripting a spreadsheet and you get the idea. This is obviously a culture with little process. You will likely not even find best practises like version control, testing, code review, etc.
- Level 1, the Variable pattern, is a lot like level 0 except there are now external customers. These make demands, but the software developers generally still spend time doing what they feel like. This scales up to something like 12 people (as suggested by Boehm), and Brook's surgical team of experts (from The Mythical Man-month) is probably a good model for team composition in this pattern. To support collaboration, you start to see things like version control, code review, etc., based on the likes and dislikes of the team involved. In this pattern, failure is often ignored or downplayed in the interest of moving on with things. Still a low-process, winging culture.
- Level 2, the Routine pattern, is what usually happens when organisations grow. The Variable pattern stops working because the organisation can no longer hire exclusively experts. Management is tired of the unpredictability that comes of a Variable team of non-experts, so they Institute processes based on best practises. However, since the processes are enforced from above, and nobody really understands their purpose, and they aren't fit for that purpose anyway, most real work gets done by secretly abandoning the processes.
Especially during time pressure, even management will suggest to throw out the process because "we don't have time for that". Since nobody understands why the process is there anyway, the Routine pattern tends to devolve into the Variable pattern at the first whiff of failure. The Routine pattern is effectively the organisation trying to be systematic but not having the necessary understanding to do so.
It honestly sounds like the author was suffering under the Routine pattern, to me.
- Level 3, the Steering pattern, is a better but more demanding approach than the Routine pattern. The Steering pattern starts with a respect for observation, understanding, and feedback. It institutes processes that are appropriate for their purpose. It treats failure as an opportunity to adjust process.
Most normal projects in the Steering pattern looks like the Routine pattern. The difference is that a lot more projects become normal in the Steering pattern, because they don't throw out processes when they need them the most. They understand their purpose and collectively adapt them to always be relevant.
----
As some sort of summary:
- In levels 0, 1, and 2, people aren't very good at using feedback at all. It's mostly ignored or used as a stick to beat people with.
- In level 3, people can use feedback from individual projects to evaluate and adjust the same projects.
- In level 4 (not described above), people can use feedback from individual projects to evaluate and adjust the processes and teams that drove those projects, meaning feedback gets used more generally.
- In level 5 (not described above, also never observed by Weinberg), people do all of the above observation, but also meta-observes: they use feedback from projects to evaluate and adjust how they use feedback from projects.
Any process that stops you from doing what you know is the right thing to do, is bad process. And any time you lack process that could have saved you from doing the wrong thing, is bad. The sweet spot is process you never think about, that makes things just work right.
Let's say you work on a HIPAA project. You have been through the HIPAA training. You know how your product is supposed to work to comply with HIPAA. A bad process would constantly gate-keep and nag and hold you back, checking every 5 minutes if anything you do is compliant. But also a bad process would not provide any checks at all, making it easy to miss something important. The good process prevents things falling through the cracks, while not holding you back from doing your job.
Good process helps you do your job better. Bad process makes it harder to do your job well.
Anecdotally, I see this a lot in organisations that have various operations teams (product ops, design ops, recruitment ops, etc.). It is often the responsibility of these teams to create processes and frameworks for other teams to work within. I think there's less willingness to push back against these teams when they want to introduce new processes than if, say, a single product manager(or designer, recruiter, etc.) proposed a new process.
1. https://www.youtube.com/watch?v=ZQjhrLYww7c
* The exception was one company that knew it. The attitude was like, "yeah, we're kinda overbureaucratic, but we're gonna be _good_ at it." And indeed, the process slowed down the overall work a bit, but the process was kinda well done and not painful.
If the reason behind the process is not given proper visibility and importance then, in my opinion, eventually you'll end up with Five Monkeys Experiment [0] kind of situation - everyone follows some process with no idea why, even if the reason for that particular process has long evaporated.
[0] https://intersol.ca/news/organizational-culture-and-the-5-mo...
But, even when it's necessary, that doesn't mean that I want to work there. High process forces me to become a bureaucrat. I do not want that in my life (or in my career).
There are lots of ways to kill people.
You don't want to approve something that will kill someone but you also don't want to delay something that will save someone.
That's not the narrative I see here (these comments), so maybe the foregoing is surprising to some of you.
For many reasons I take it as fact that we aren't nearly as rational about technology choices as we tell ourselves and each other. (My father was a shrink.) Seems to me like every part of the mythical technology stack comes with ritual (alleged best practices) concerning build practices, code management, coding styles, you name it. Indeed you can, at least in a caricaturish fashion, diagnose personality associated with languages as sadistic, masochistic, romantic, hysteric, nostalgic, narcissistic and so forth.
These practices don't build greatness. Based on what I've seen over many years, so-called "best practices" are often, if you will, part of the "affect" informing such diagnosis.
There is something I refer to as "crazy" (noun), and when I write code one of my guiding principles is avoiding / reducing crazy. We all know how we feel when things are crazy, right? Sure, I know you personally are immune to the effects of crazy, but what about those around you?
They probably get a little neurotic and fall back on habits; so it's good if best practices align with those habits. Actually, I'm kidding.
Minimize crazy, or it ends up as tech debt in your tools rather than your product.
I consider my philosophical differences with the author to be of no particular consequence. The article really resonated with me especially the observations that you can't enforce greatness and the tendency of people to think their job is to follow policy when they're in a kettle of crazy.
I despise processes that enforce rules perhaps once born of good judgement, but now divorced from the judgement-having person's assumptions about context or her ability to change her mind when presented with new information.