Hacker News Reader

Comment by elictronic | Hacker News Reader

Currently working at an older style defense company and this fits but I think momentum is a better reference. There are no financial incentives to risk on new process. Gatekeepers, siloing, bureaucracy, and risk aversion act to stop and slow.

I have worked startups and early stage companies prior and used that experience to force developmental projects and gotten prototypes and patents through the resistance. My coworkers who lack that experience get shut down often before they even start.

If you are not in the chosen group or have a fully fledged business case with 5 levels of managerial approval it’s dead on arrival. To anyone in this sort of role it’s not blindness where you lose the skill, it’s stagnation. The moment you leave you move again. The blind fish never gets their eyes back.

View on HN

You're correct. But have you been on the other side: something you know is not perfect, but someone convinces you to try something, you agree, it isn't great but it gets used... then they leave and you are stuck with something that is a pain clean up.

I understand it can suck: but what is lacking isn't your technical demonstration (unless it is truly ground breaking), but your demonstration to clean up your own mess and be responsible.

I just told you I have run multiple projects through at a large defense contractor.

The entire system there is old projects dropped by some new manager, retiree, or corpse. I work on systems that are older than I am and I was born in the 80s. There is no side in Ba Sing Sah.

Assuming you are working on anything of importance, there's a pretty good chance that you, and/or your coworkers, already have our interfaces installed in your organism. (as does most of NATO)

You might want to get on top of that, and start advocating for neuro-auditing your assets, mr. project manager.

When I was in a large org, it was a common failure that a manager would come in from a smaller firm - and assume that our design practices etc. were meaningless overhead.

Inevitably they'd try to do a "rapid prototype" of a feature that had been tried a hundred times before and declared "too hard/unworkable/uninteresting." as they wouldn't talk to those who had done this before, or look at any past work... the invariable result was a project shut down within 6 months and the manager would be shown the door some time later.

The main takeaway from the above is to listen to people around you when you join an org, and observe the habits of successful leaders. Odds are good that at least within this particular org under these circumstances... those habits are the ones that work.

So I'm on the other side of this usually.

Most places I land there's deference to the status quo and those that came before. People assume that efforts of that past were well considered and that good work was done.

But ultimately when pressed, there's generally no evidence of the above, and when there is evidence, one can generally demonstrate the flaws in the approach, so I press on anyway and it hasn't really bitten me yet.

Of course, in many of these projects there's now deference to decisions I've made. Some of those decisions were well made, with evidence and supporting work, to make them challengeable should the understanding changes. Some of them are gut checks because they didn't matter to me at the time.

Either way the take away is good, but often practices exist simply to frustrate.

Yes and it’s still always better to try new things then wait for approval or something to be perfect if you want the company to keep innovating.

A company at a certain point moves from “make it work” to “don’t break it”. Both have good reasons to be honest but “don’t break it” has far more restrictions.

Perhaps what separates the good companies from the Great companies is that the latter always tries to make it works, doesn't rest on it's laurels, and takes any bet which is +ev.

I think the main trick is balancing the two. Companies that take any +ev bet, no matter how big, will tend to explode spectacularly eventually (SBF famously had this philosophy, for example).

Skunkworks is a decent example of how this can work: you set up a subset of your larger company to operate more like a startup. But importantly this isolation both limits the risk to the company as a whole as well as isolating the subset from the bureaucracy of the larger organization.

I tend to agree. This is just the intersection of two age-old problems; Kelly Criterion (pareto-optimal sizing of bets) and Organizational Management.

Related, the craziest emergent behavior I see is non-technical managers killing projects because they themselves can't understand how it could be implemented. I firmly believe many managers think they're in the positions they are because they're technical, rather than managerial.

Exactly, you need to be in the chosen group. The trusted group.

The system grows to stifle itself.

The system is not stifling the system. It is stifling innovation.

Not like startups where every meme that the architect read on some blog must be used in production are better.

This is frankly one of my worst fears.

Now consider what happens with a government agency!

wondering if i can run something by you

Reply on news.ycombinator.com