Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Parent Full thread

> Most developers and architects seem to have lower and lower confidence in what is technically achievable without some complex dependency web, and that becomes a self-fulfilling prophecy

One of the biggest problems I’ve had with hiring engineers out of big companies is that they’ve developed a sort of learned helplessness. The longer they spend in big, slow companies the more they’ve developed an idea that everything they do must adhere to mountains of process and approvals and documents.

It can be a challenge to un-teach these ideas from people after hiring them into a company where they don’t need to put together presentations and seek multiples levels of approval before doing anything.

One surprise that I didn’t account for is that many people come to like these process-heavy systems with approvals everywhere and no progress until the rules have been followed. It becomes a safety net to pull as many different people and process into a decision before action is taken. If something goes wrong, no one can blame you because you followed the process and got all of the approvals, right? I think this leads a lot of people down the road of preferring high-process, low-action environments because following the process is a type of low-effort, low-risk work whereas producing something new is high-effort, high-risk.

I've worked in environments like that (in and out of software), and this is almost always driven in reaction to something, which is why it's hard to unteach. In my current office there is a culture of consensus building and feedback. If someone feels they were not given sufficient opportunity to participate in a decision, they will complain, resist or otherwise cause an issue in the future. Sometimes they are correct, which is why it's not as easy as simply firing them. Sometimes the red tape is in response to problems in the past. Policies that were poorly enforced that resulted in negative consequences for customers (support failures or discriminatory behaviors). Sometimes it's there to protect low level staff from accusations of the above or to provide clear guidance when dealing with a high stakes/high stress situation. Sometimes it's to protect customers, such as regular security reviews.

So no, I do not think this is about "low effort", though that can be a side-effect. No one sits in an office wanting to find ways to make their coworkers lives difficult. More often than not the policy is a response to pressure to do something to prevent whatever failure prompted the policy. The people who like the process heavy approach, in my experience, anyway, are often remembering a time when failure to follow a procedure resulted in negative consequences for someone.

> No one sits in an office wanting to find ways to make their coworkers lives difficult.

That’s not exactly what’s happening. It’s not about making coworkers’ lives more difficult. It’s about preferring pseudo-work that looks like progress (meetings, process, consensus-building, planning sessions, endless documents) instead of work that delivers results.

Once a project ships, everyone can see whether it was a success or failure. However, if you can keep it in the planning limbo for as long as possible you can avoid that moment of truth. Another round of meetings and refactoring and consensus building is safe because it’s easy to say you’ve followed the process and therefore produce good process-work. Shipping to customers is risky because then the product can actually fail.

In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.

> In companies where someone’s reputation and promotion prospects depend on avoiding project failures, it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.

Isn't this almost all companies? Remembering one's success and other's failure better seems to be human.

"Jim really fucked the project up" vs. "Our project was a great success" (junior dev Jim getting no mention).

> it becomes attractive (and safer) to deal more in the pseudo-work than the actual work.

More charitably, they feel this work will make the product better. That may or may not be true, but if you've been involved in failures and part of the after action review was "this person should have been consulted because they are the expert in whatever failed", that becomes part of the process. Pretty soon, this refactoring and consultation becomes expected, and so on until we're at the point you are speaking of.

And I say this as someone who is part of the problem. I have unfinished projects right now that are stuck in meetings and consensus building. I want, at minimum, to be able to say, "you were given the opportunity to participate in the process, but you left it to me." but I've also made mistakes and poor decisions for lack of those steps more than once.

I have no doubt that there are people avoiding failure by not shipping, but I do not think it is as simple as that, there are a variety of cultural norms and experience colliding here.

I agree that procedures to follow, meant as a way to benefit from past experiences are usually well intentioned. However, a common problem usually arises over time as the nature of the work evolves: is the procedure still relevant in the current context, still beneficial despite its overhead? Better have some system that can give an idea of the actual usefulness and current relevance of whatever procedures people have to follow.

AFAIK, most people mainly focus on what they do and deliver, as it's what matters the most, but many fail to consider that how they do it might matter as much. Yet, knowing how every aspect of the environment impacts the efficiency of the work would be priceless. Being able to continuously improve and adapt the work environment so that the work keeps being done in the best possible way? One can dream ;)

The technical debt concept somewhat applies to the organizational field: what may have worked well for the small startup is almost always re-worked once the company grows, and even when the company no longer grows in size, but still in age, frequent maintenance is required for the business to stay relevant in this changing world.

Obviously, how to design how good work is done is no silver bullet, but as someone said: “I would rather have questions that can't be answered than answers that can't be questioned.” Like the not-to-be-further-questioned answer I once got: "Look, that's just how things are done around here." ;)

Complex process creates more work, sets barriers to entry for competitor workers, and reduces individual responsibility for something that goes wrong.

So, from the employee perspective complex process means a lot of work to do (job security), higher pay (even if the domain problem is not too difficult process complication makes it difficult reducing the available supply of qualified labor) and less responsibility if something goes wrong.

From the business point of view compexity means, being current, keeping up with the latest tech, signaling you are not a dinosaur. Keeping up with security because the shoddy earlier layers had holes because software engineers do not output a finished work product like other engineers. Even if some dinosaurs may do things cheaper and better.

From the customer perspective the incentives are pretty often the same. Many customers want a touch screen instead of a knob or button because the latest tech all has touch screens. They want to use Slack or VS Code because that's what the cool kids do these days.

From the outer space perspective it looks like humans are building a new tower of babble with their tech stacks. Ever higher layers of complexity not actually going any place or doing much new.

Eventually it might all crumble into a pile of confusion.

Reply on news.ycombinator.com