Hacker News Reader

Comment by shalmanese | Hacker News Reader

This is exactly a perfect example of WTF worthy behavior being treated as totally normal; that it's encoded that there's "leadership" and "not leadership" as binary job distinctions with distinct responsibilities.

I've been in both types of cultures and, by far the healthier culture was the one in which "making the organization better" was treated as everyone's responsibility. I've seen very junior engineers drive quite significant culture changes, simply by leading by example. They did it, not by whining or complaining, but by taking baby steps of trying out small experiments with their immediate team and then broadcasting their success to incrementally greater circles within the company until it became the new normal.

If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes.

View on HN

> If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes.

I've been around a bunch, including the US Air Force, and I can confidently tell you that heavily hierarchical organizational culture is the norm, individuals contributors who want to have effects beyond their job scope do so at risk of offending other stakeholders. They may tolerate you and even give some limited help, but they're not going to shout your name from the rooftops just because you want to be a boy scout.

Not saying you can't buck the system and get away with it, one of my favorite books was about one of my heroes, John Boyd, but if you want to be a hero, you need to go into it with a clear-eyed assessment of what you're up against and so you can tailor your objectives appropriately.

The DoD (!) is hardly representative of the cultures being discussed in the linked article, which is about tech startups (with a bunch of examples from medicine too). Yes, there are worse examples, but those may be beyond help.

I fail to see how governmental organizations should fall outside the scope of the discussion.

And the Air Force is not the DoD. While, technically, the individual branches of the US military fall under the DoD, they all have very different organizational cultures, and the DoD has staff and culture of its own.

> I fail to see how governmental organizations should fall outside the scope of the discussion.

I won't tell you what falls within the scope of this discussion or not, but I can tell you why they don't add a lot of value to it either.

It's already quite hard to somewhat objectively discuss whether a business company is dysfunctional, in part, or not at all, and what are the reasons for that.

It's almost entirely useless to attempt to have that discussion about government. Because politics. Because people root for their home team. Because people are inclined to dismiss the other team's ideas even when they're real good. If I told you the US Government is dysfunctional, someone would counter that I'm not American and I should see my own government. If we move past that and we got into the details of why things are not working properly, invariably Americans will start quoting bits of the constitution, bill of rights and foundling fathers at each other (and from there on it just becomes religion to me).

Discussing whether the function of Military organisation is working properly is even more difficult. In addition to the above problems, there's also hazing and indoctrination, which are incredibly strong psychological forces (without those, like said, people won't run into their deaths without question). And it pretty much divides the crowd in two slices, those "outside" that have no idea how it really works, and those that have been "inside" who are unable to disconnect the indoctrination bits from forming an objective judgement about how well the organisation functions and how that comes to be.

Certainly, discussing businesses has similar problems, but this just amps up the personal emotion factor to eleven. Also one of the reasons why the businesses were kept anonymous in the featured article.

Tech start ups are a rather small part of the overall IT industry. I dont really have the numbers to back it up, so i am not going to speculate as far as the actual numbers, but any discussiona bout workplace IT that ignores everything that isnt a tech start up is virtually useless.

And the IT industry is a rather small part of the overall job market. So therefore any discussion about the workplace that ignores everything that isn't IT is virtually useless?

As an enterprise grows, you either retain centralized control and have hierarchy, or distribute control by treating parts of the org like independent, federated entities (think Berkshire Hathaway).

The military's size, scope, and mission are unique. You need top-down control, because otherwise most folks won't decide to run up a hill into a machine gun on their own. That mission focus (do stuff with force), cascades into the supporting services.

That you chose to mention the UAF as an example suggests that your experiences are really on the far side of what is being suggested here. If there's any place where these kinds of things don't work, it's in government or the military.

Was it the Robert Coram book (https://militaryprofessionalreadinglists.com/books/665-boyd-...)?

That book made it into four different reading lists from various branches of the military (USMC, USAF, Army, and a chair of the House Armed Svcs Committee). That's encouraging in that at least they're aware that his ideas/approaches were productive.

I recall reading somewhere that while military organizations are very much synonymous with hierarchy, they have historically experienced a lot of pressure to flatten and decentralize, at least as far as field command goes. Napoleon's success was attributed to smaller units that responded to feedback more quickly. Unfortunately I can't find that article.

However, this is not to say that in regular administration there isn't still a lot of de facto trust in the hierarchy. I think unbounded hierarchy is generally one of those memes that people grow up taking for granted as something that just works with any layer count. In some ways, it's a self-reinforcing thing - if you climbed ranks for 10 years, you don't want to see the system change and your "sunk cost" go away.

[edit: clarified sentence]

The US Marines are often cited in management literature as an example of an organization where the leadership communicates high-level intent and purpose to achieve strategic alignment, and then totally decentralizes tactical decisionmaking to the people doing the actual work in the field. The stereotype that they are just all about top-down decisionmaking and following orders, is false. They recognize that individuals need to be able to make decisions on the fly in order to react to volatility, uncertainty, complexity and ambiguity.

But it will always remain an inherently misleading comparison, because they get to train people to an extent and in ways that would be unthinkable for a business in modern civilized society to get away with. The training and drilling is such an engrained component in that whole system. Without having that first it seems to me a bit like prematurely spot-optimizing the wrong loop.

Not sure why you are getting so many replies disagreeing with you. Narrowly-defined roles are indeed the norm, even in the tech world. When I was an "individual contributor" I'd get frustrated with Worst Practices all the time, but was told that I was hired to write code not to change our infrastructure or suggest different product features or improve our testing practices--MANAGEMENT makes those decisions. But even when you get into management, there are always managers above you to limit what you can achieve.

There may be awesome companies out there where anyone is empowered to just go fix some practice that's not productive, no matter where they are in the org chart, but those companies are few and far between. I'd love to see one.

Part of it is vinceguidry makes something of a false distinction. Either fight the system and solve X problem behavior or just accept it and don't think about. A third option is simply investigating classes of behavior of this sort and learning something from them.

I really disagree, strongly. It takes time and perseverance, but you can spread better ways of working.

The job would really need to be worth it to work against pushback from above.

That part's true. It's probably almost always easier to find a better environment.

One thing I would consider doing, if I ever start my own company or rise high enough up in someone else's company to implement this, is to give every single employee some sort of discretionary budget to spend on things that make the workplace better. The more experienced and trusted you are, the bigger of a budget you get. I think this would go a long way in fighting the learned helplessness dynamic.

This is a very interesting idea. Have you, or anyone else on HN, ever seen this in action? I would LOVE to hear stories about this, either successes or failures.

It's called 20% time and it works OK. I always used it when I was at Google, although most people didn't.

20% is not specifically for "improving the organisation" of course. It's most famous on the outside for the new products it led to, like Gmail. But actually most 20% projects were small internal things intended to smooth the rough edges off a particular tool or process, or to improve the company in some way. If the particular bee in your bonnet was a type of bug that cropped up frequently in other people's software, making a linter to spot it and driving adoption through the organisation would be a good 20% project, for instance.

Yep. There's a whole philosophy based on the idea that improvement of the organization is everyone's job. It's called Lean, or more simply, continuous improvement or Kaizen.

yeah there are a gazillion companies that claim to be Lean, Kaizen or what else but guess what, in practice only a small fraction actually are :)

That seems like something that is worth (tactfully) screening for in interviews when given the opportunity to respond.

So instead of asking "are you Kaizen?" you would ask about practices performed that imply Kaizen, including the spirit of the law and not the letter.

Yep - this is something that I'm thinking about actively. How do you start the conversation in an interview (as either interviewer or interviewee) that gives you insight into how people treat problems? Is their instinct more individual or systemic? Do they naturally look for improvement, or point fingers?

I've had some success, but they're always very deep interviews, which can either be drastically good or quite startling to the other party depending on what direction it goes. So your note to do it 'tactfuflly' is very prudent.

I have often found that two things work well for this:

* have your antennae out for anything that seems weird (weak signals, indeed) in your conversations about the work

* check references (as an interviewee). That's a fancy way of saying, look to see if anyone you know knows someone who works there, who can give you the straight scoop.

At more than one company, "Agile development" means "the CEO gives his cell number to every customer, and Waterfall development happens very fast."

I hesitated to reply to this because what I'm about to say could be taken as pedantic. However, it is my experience that many people experience a good way of working, apply a label to it and then use that label thinking that it will communicate all of the good things that they intended. This is rarely the case. At some point you see many articles entitled "Why X doesn't work" where they describe a broken version of X and why it doesn't work. The broken version ends up getting more popular than the unbroken version for some reason and there is a general consensus that "X doesn't work and anyone that uses X is an idiot", even though X works perfectly fine if you use it correctly.

With that in mind, "lean" as a principle is organized around the idea that it is better have people request functionality (pull) than for you to imagine what people want and then try to sell it (push). Many "lean" organizations happen to be very good at continuous improvement, but you can be "lean" without any capability for improvement.

"Kaizen" is the Japanese word for continuous improvement. It was introduced to western eyes primarily from the "Toyota Way", which is a lean manufacturing system that concentrates on continuous improvement. It is important to understand, though, that while workers have a responsibility for identifying problems, it is the managers who are responsible for working with the workers to implement improvements in the Toyota way. So there are clear demarcations of responsibility, unlike many of the IT processes that borrow the word "kaizen".

Even "continuous improvement" can be a loaded term with respect to responsibilities. The first time I ran across the term was dealing with CMM (the Capability Maturity Model). Once you are up to level 4 or 5 you are using metrics to improve your process in order to obtain continuous improvement. In every organization I've seen that attempted to achieve CMM level 4 or above, the primary driver was management (and often workers were not even consulted about improvements or why they were necessary -- they were only told to do things a certain way). I'm not saying it was successful, but it was very common ;-)

I guess my point is that if you are lucky enough to be working on a team that does continuous improvement well, be aware that what you call "Lean" or "Kaizen" is unlikely to be what other people call it. You can not communicate what it is you want to communicate using those words alone. If you have been reading literature using these words and believe that if you simple follow a "Lean" system and embrace "Kaizen" that you will transform your organization into one that does continuous improvement well, I'm sorry to burst your bubble. If only it were that easy. Unfortunately, all the difficult problems are people problems and those problems almost always require unique solutions. It can be quite tricky no matter what you are doing.

Part of the extreme difficulty in defining a mental model for an organization is that organizations are necessarily complex systems. You're exactly right.

Regarding people problems, my one note is that we are all more alike than we seem, and you eventually start to see the same classes of problems everywhere. This is why an understanding of psychology and behavior is so critical.

I think the lesson to learn from this is to be wary of anybody who says they can look at a system for organising people that works well and write down a recipe for how to reproduce the essential elements of that system. Even if they were partially responsible for creating it. Most likely, nobody understands why it works in enough detail to write down precisely what it would take to reproduce it.

W. Edwards Deming got the closest I think?

System of the organization comprises the relationship between systems within it, how those systems change and vary, the methods of knowledge learning and transfer, and the psychology and behavior of the people within it. And importantly, it's how all those pieces interact with each other that makes the most difference.

It's a system. There are some common elements. Above that base level, there is much truth in what you say, but the most important thing you can learn is a mental model for organizations in the most general way possible.

One of the hardest parts of this is organizations are not separate from there problem domain. A process that works for manufacturing cars (high value) may not work so well for manufacturing radios (low value) let alone banking software. Pay, education, and company size are all huge factors that are often ignored.

I found myself imaging someone writing down a recipe for yogurt like so:

1) Heat up milk 2) Find something with the consistency of yogurt to put into the milk 3) Wait

Having a living thing there that knows what the final product should be and can stand as an example is largely how we transfer culture.

Except this big catch is that employees are compensated for the improvements they bring about. That basically never happens in a typical software company. Maybe if you keep bringing in important changes someone will notice and maybe you'll get stock options or you'll be promote to management

This is half true. People will go out of their way to make the organization better if it make their jobs easier (ex: switching to more modern easy-to-work with technology). But if for instance the project is going in a wrong direction, most of the time you have no good reason to fight to change things (and yes, it's fight b/c often it's about changing opinions and demonstrating repeatedly that things needs to be done different). So sure, do your duty and voice your concerns but at the end of the day just go with the way the boss decides. This is called delegation of responsibility and something a lot of people don't grasp. You need to cover you ass to stay sane.

Leadership leads. This is a tautology. It is unhealthy to pretend otherwise.

Lets take for Leadership decides to incur technical debt to allow a faster entry into market, Development Team Lead decides this is unacceptable, and does not take on the Technical Debt, but instead does things 'The Right Way'. This leads to competitors entering the market first, snagging customers and mindshare, which eventually leads to the company going under.

Was the Development Team 'Right'? Even if lets say he was 'Right', is it his decision to make, should he intentionally sabotage or ignore direction from his superiors ?

Most true WTF processes tend to come from decisions made that are out of the control of the parties that they directly impact.

GP is not pretending anything. Further, taking a position on technical tradeoffs (your example) is an orthogonal concern to defining leadership structure, which is also distinct from the possibility of making bottom-up changes. No one is proposing anarchy here, just people fixing what they can.

OK, I think there are some unspsoken givens that I need to spell out to make my point clearer.

Typically people resolve the issues that directly cause them pain pretty quickly if it is in their control. Further "control" requires understanding how the levers a party influences impact the obstacles that cause the pain.

WTF level issues typically occur when the above conditions aren't met, usually that means the 'pain' doesn't impact the party that has the control to end the pain. next most common is the party that has the control doesn't understand how its levers affect its obstacles.

just fixing what they can is not going to resolve WTF level issues...

One should always keep in mind that a WTF-level issue is very possibly a critical oversight on the issue-holder's side. Lots of things in the world appear very fucked up, but are in actuality slight improvements over even more fucked up states of affairs. One should endeavor to find out the history of the situation before jumping to judgment.

"Lets take for Leadership decides to incur technical debt to allow a faster entry into market, Development Team Lead decides this is unacceptable, and does not take on the Technical Debt, but instead does things 'The Right Way'. This leads to competitors entering the market first, snagging customers and mindshare, which eventually leads to the company going under."

To be honest, how often does this actually happen? I'd doubt it happens often enough to worry about it. Most startups aren't doing anything that special, and so this whole, "We have to move at twice the speed of light or we're all dead!" attitude doesn't belong anywhere.

> Most startups aren't doing anything that special, and so this whole, "We have to move at twice the speed of light or we're all dead!" attitude doesn't belong anywhere.

burn rate/runway is a critical survival factor to startups

> Was the Development Team 'Right'? Even if lets say he was 'Right', is it his decision to make, should he intentionally sabotage or ignore direction from his superiors ?

That's a bit of a loaded question.

You assume there is a right and a wrong that can be determined before knowing the outcome (a.k.a. deontology).

It's easy to see this is not at all clear-cut if you consider the other possible outcomes. What if it turns out that DevTeam's decision was what saved the company (and maybe even their competitors are now buckling under Tech.Debt).

Would that have made them right? Maybe yes. But in other's eyes maybe not because they still disobeyed their "superiors". But maybe the company would have fallen if they had listened.

Can you categorically say, beforehand, that one decision is right and the other is wrong?

You could, but others might disagree (and rightfully so, IMHO).

Say you claim it's always right to do what management tells you, and it's wrong to decide to go against that. And you can argue this because a large business needs that kind of structural dependability, otherwise it would fall apart in chaos and specialisation is a good thing, so management specialises in determining long-term vision that a Dev.Team leader is not as knowledgeable about. Sounds like a pretty tight justification, no?

Well, except when you're Dev-team and your livelihood (maybe family) depends on this job and following management's will crush the company, you decide to disobey management, and it turns out that indeed the tech.debt would have crushed the company instead of the entry-to-market delay. Then Dev-team gets to claim they were right. Even if management says "you saved the company this time but in general you ought to always listen to us even if you think it's a bad idea", except that (obviously) protecting their livelihood ranks a lot higher on Dev-team's ladder of oughts than following orders to facilitate a smooth tightly-run company.

If you want for everybody to fix things, everybody should know things, share the vision.

If management is planning to do things quickly and badly, the dev lead should know that and plan accordingly, trying to do it in the best possible way.

If he's kept in the dark, of course he might blunder. But that's not his fault, assuming a company that encourages initiative and fix it yourself attitudes.

Best leadership leads by empowering people, not by enslaving them.

Reply on news.ycombinator.com