Hacker News Reader

Comment by Jensson | Hacker News Reader

Doesn't mention the benefits of attrition. A network can be robust since none of the pieces leaves, but what is even more robust is a network that constantly renews itself and gracefully handles the process of swapping out parts. Constant attrition means that your company never starts relying on individuals, instead the process survives and thrives on its own, hiring new people who then hire new people before they leave etc. Such a process isn't very attractive to individuals, of course, but they are very attractive to the owners.

View on HN

I mean, for assembly-line production this might ring true (I wouldn't know, never did it). But for what one might reasonably categorize as "knowledge work", my experience is that knowledge reigns supreme. Some of that knowledge is shared by a whole community of practitioners, other parts of it is local and contextualized. This part probably makes up a sizable proportion of an organizations competitive advantage.

To make workers replaceable is to rely mostly on the knowledge you can reasonably expect to regain on rehire. Remember: Management (up to owner-management) are also workers, so running some kind of special culture-and-knowledge preserving über-organization is predicated on somehow retaining the structures that support and maintain this secret sauce. Military services around the world have researched this extensively (for obvious reasons), then again, we refer to a well-seasoned and experienced practitioner as a veteran. Veterans are invaluable in military service, as they are in any other endeavor. Trade them off against ease-of-management at your own peril.

> I mean, for assembly-line production this might ring true

Not there either. You mess up more in the beginning. Experienced workers have better flow.

I would assume this as well, when i think about it. I guess learning about the industrial revolution in school kind of messed up my preconceptions.

Anyhow, this military comparison just keeps sprouting thoughts in my head. Isn't an owner-management almost perfectly comparable to aristocratic officership? Is GGP's theory of defensible churn basically a modern incarnation of feudalism and aristocratic privelege?

In the military attrition is even worse because you can't fill gaps by hiring from any competitors!

French Foreign Legion would like a word.

https://en.wikipedia.org/wiki/Russian_Liberation_Army

> Veterans are invaluable in military service, as they are in any other endeavor. Trade them off against ease-of-management at your own peril.

I never said that experience isn't valuable. The question was whether experience at a particular company was more valuable than experience outside of it. Every time you hire a senior engineer from another company you learn a bit of their secret sauce, making your company stronger. Participating in that knowledge trade is extremely valuable, and without churn you will be left out as most of your engineers will have mostly experience from your company, that is a really bad thing.

Excellent point IMO! For an organization to believe itself the sole proprietor of relevant and useful knowledge within it's domain of operation is pure hubris.

So too is believing it is anything more than a community of individuals, cooperating on the basis of shared- and tacit knowledge as well as skill to perform the different tasks that comprise business operations. Tacit knowledge and skill resides in the specific individuals, and shared knowledge in the specific relations between individuals. Losing an individual is losing part of aggregate tacit knowledge and skill, as well as all the specific relations shared by the individual. The organization as a thing-in-the-world loses part of itself not captured by it's charter and governing contracts (or share value, or business strategy, i could go on). These things are hard to quantify on the best of days, so to assume (or even mandate) that this cost is incurred with net benefit (by, as you say, hiring some industry heavy-hitter who is expected to bring the goods) is fraught with unknowns, and on balance likely hubris.

If your business requires a lot of knowledge specific to your products, think adobe Photoshop, it is hubris to think a new hire experienced even in relevant fields could meaningfully contribute for a long time. If your product uses an industry standard framework or standard, think adobe reader, then yeah, you can probably have someone hit the ground running. But a bigger problem is that when a new hire leaves after 2-3 years and you replace them with a couple people fresh out of school, so that anything they don't come out knowing has to get taught again. And if it takes some large fraction of the 2-3 years to learn your domain specific knowledge you are done for.

I don't think that hiring people to get outside knowledge is that useful in IT.

From what I understand there is no such other occupation that is sharing so much information between people. You have blogs, loads of free and paid materials, you have loads of conferences where you can send your staff to see "how others are doing it".

Other thing that I often see ... a lot of developers really invest in "outside knowledge" and common problem in dev teams is building stuff with new shiny tech or in a new way they saw on the conference.

> To make workers replaceable is to rely mostly on the knowledge you can reasonably expect to regain on rehire.

Fortunately, we developed systems of writing, so that the limit to this relearning is higher now than a few millennia ago. (Society does the ultimate “rehiring” continually.)

I think that far too many companies (including my own) rely much too heavily on “things that are in people’s heads” and don’t spend enough time and money on making the company knowledge effectively outlast any individual employee, making it easier to put the essential knowledge into new people’s heads.

Society doesn’t rediscover pi, e, I, and calculus from first principles every half-century, but rather we’ve instituted that knowledge into books and mechanisms of teaching.

Well yes, if we could only train new employees for 20 years in the specific curricula of the organization, as that is how long we spend getting pi and calculus into the heads of kids.

On the scale of lifetimes, I don't think we can refer to it as "churn" as understood in the context of a modern company.

I'm being facile, of course. Developing a good library of knowledge as you propose is hard, takes a long time and many iterations and there is the unfortunate matter of time taking it's toll on the relevance of such recorded knowledge (esp. in our line of work). Not to mention costs. Even academic institutions, who are in the business of doing exactly this, guard their staff with tenure (some of the staff anyway, the big boys)

It takes 20 years because kids come from all kinds of backgrounds and there isn't enough funding for individualized support. A company should be able to get someone up to speed faster since that person is presumably chosen for that role based on existing proficiency. It's easier to piece together an understanding of the system from the napkin scratch notes of the person who got hit by a bus than it is to hope they come out of the coma before the business fails. Imperfect documentation is better than none.

We are not in disagreement here. I was making a comparison in kind as a cheap rhetoric trick. Documentation is good, no documentation bad, good documentation can be better.

Slide along the scale towards more and better documentation and our perceptions might diverge. I don't think all the valuable know-how that goes in to fulfilling a specific role in a larger organization (and in particular the marginal knowledge, relations and skill that increases performance) can be captured in words. Even if it were, there is so much of it and it is full of subtle nuance and context sensitivity. On top of that each individual person takes to different parts of it in different ways. The things you can only learn by jumping in at the deep end. We all know, deep inside, that this is the stuff that matters and I see no reason to play charades and pretend we can know or see how even half of what we do really works. If we did, the world would be a very different place. Until then: tacit, implicit, context bound and relation contingent knowledge and skill will be the light that shines on our practice; and what we can put in to words, a mere shadow.

True enough, but look at your last point.

> Society doesn’t rediscover pi, e, I, and calculus from first principles every half-century, but rather we’ve instituted that knowledge into books and mechanisms of teaching.

How long and how many resources does it take to train someone to understand pi, e, and calculus?

Or, to apply your nice analogy to the topic under discussion.

what are the expected costs (time + training support) to get a new hire trained on all of the written materials which describe the system?

For a non-trivial system, those costs can be very high.

“I think that far too many companies (including my own) rely much too heavily on “things that are in people’s heads” and don’t spend enough time and money on making the company knowledge effectively outlast any individual employee”

Totally agree but I have never seen a company implement this consistently. They seem to expect that while you are under constant deadlines you also have time to document your stuff thoroughly. We also need systems to organize the documentation so you need to hire tech writers who do that. If you put this on engineers they most likely won’t do it because they don’t have time.

> very attractive to the owners

And yet I’ve worked at software companies that will go to great lengths to avoid attrition. For exactly the reasons mentioned in the post, they encourage people to move to other teams to build up the inter connectedness of teams while keeping employees motivated and engaged. In fact, even if you weren’t looking HR would reach out and ask if you were interested in looking at other teams within the company because you had been in your current team for 18 months.

Side note I don’t know if I’ve just been lucky but I can’t relate to this talk of “companies are evil and act maliciously against their employees at every opportunity”. That hasn’t been true in my experience.

> For exactly the reasons mentioned in the post, they encourage people to move to other teams to build up the inter connectedness of teams while keeping employees motivated and engaged.

That isn't to avoid churn, that is to have more people around in general. If you leave your old team it means you no longer use your knowledge, the important part is to have engineers around, not to have the same engineers working on the same tasks.

For example, Google encourages churn by making it really easy to move to other teams in other areas. You don't talk to your old team again, so that is effectively the same thing as you leaving the company and them getting a new engineer, ie for the teams it is equivalent to churn.

Military veterans of some theater of war are desired exactly because they will perform well in the next theater of war.

I don't think i can fully appreciate how mind-bogglingly huge a company like Google is, so it might well be the case that tacit knowledge, skills and relations acquired in one team don't transfer meaningfully to another. I would have to see it to be convinced however, even more so to make me believe this kind of transfer was the norm.

> If you leave your old team it means you no longer use your knowledge,

If you move from Team A to Team B, you may not use your knowledge of the details of their codebase.

But you know precisely how to sort out the problems caused by the company's weird internal certificate authority, and their weird internal deployment tools, their weird internal inter-service auth system, and their weird internal multi-cloud system. That 'secure' way of managing secrets in production that makes 'unauthorized' errors almost impossible to debug? You know how to debug it. You know how to operate the purchasing system so your orders go through right the first time. You know precisely what the criteria are to get your subordinates promoted, and how to coach them to meet the criteria.

That can be worth a lot, when it comes to getting things done.

I think there’s a combination of some people with really bad experiences and a larger group of people that exaggerate.

That said, it’s a fact of the contemporary employment market that most companies do compensation such that sticking around in one place means making significantly less money then moving around all the time. Companies bring new people in at higher comp but don’t push the comp of existing people doing those jobs to the same level even if those existing employees are performing well. I don’t think this is evil or malicious but it certainly feels hostile.

> Side note I don’t know if I’ve just been lucky but I can’t relate to this talk of “companies are evil and act maliciously against their employees at every opportunity”. That hasn’t been true in my experience.

I think this heavily depends on the type of industry you work in. In some industries the abuse is so normalised that everyone takes it for granted.

In retail you have the example of companies scheduling workers just under the number of hours at which they'd qualify for insurance or other benefits.

Hospitality work often expects you to be available any time they're short staffed, if you aren't you'll probably find your shifts cut.

On the white collar side last year we heard about junior analysts at Goldman Sachs being made to work 100+ hour weeks[1].

Game development is widely avoided due to a similarly toxic work culture, where you'll often be forced to "crunch" for long periods of time[2]. The worse places will also lay you off after the game has shipped.

At the software companies I've worked the biggest issues have been terrible raises for current employees, to the point that graduates were being paid the same or much more than people with 3+ years of experience.

[1] https://www.theguardian.com/business/2021/mar/18/group-of-ju... [2] https://www.polygon.com/2020/12/4/21575914/cyberpunk-2077-re...

My past company tried to present these moves as a career option while failing to come up with a guide to promotion, and not really having the higher level of technical job. I changed jobs and got three promotions in five minutes by accident.

Do you have any evidence to your claim? It’s possible to ad hoc rationalize pretty much anything.

A real statistic against your claim is one of the highest predictors of defects in a code base is whether or not the original team is still working on it.

Not to mention vision that will change due to new ideas or influence that new staff brings to the team. It's not always beneficial for the project. It can go wrong in so many ways that it ends up being dead.

Don't get me wrong, change is good but too much change is just too much to handle sometimes.

> highest predictors of defects in a code base is whether or not the original team is still working on it.

Defects is a metric businesses doesn't care much about. If you have a good team that can create products customers wants, then it is better to have them keep making new products rather than maintain what they already have, then you can have less productive engineers perform maintenance, defects might go up but this way you will have way more products which businesses seems to care more about.

You would have a point if maintenance was something companies cared deeply about, but they don't. They want new products, and company specific knowledge doesn't seem to be very valuable there.

from a different angle: "non original team" might have higher defects, but i propose that "non original team" without process or time to understand the code base would be more accurate.

changing people requires a time investment. and the learning curve is steep at the beginning

>Defects is a metric businesses doesn't care much about.

This depends on both the defect and the business. Just because critical regressions and recurring denial of service has become normalized as somehow par for the course in our line of business does not mean it comes without cost. It's all situational and subject to calculated tradeoffs but every shop i've worked with/in has classes of defects on the "Never Again" list, and sometimes on the "NEVER EVER EVER AT ANY COST" list.

That sort of anti-fragility isnt a guaranteed outcome of attrition though. You can just as easily be left with a pool of under-performers that can't/won't leave, while talent moves to organisations that invest more in staff vs processes.

I don't think it works like that. Constant attrition does not prevent your company from relying on individuals. You don't fire you good employees and they won't leave if it's a worthwhile job. With constant attrition you get a core group you rely on. However that group is not as productive as they could be because they spend a lot of time training and integrating new employees that don't stay.

That’s a management pipe dream. The software verification teams at my company have very high attrition rates and it’s getting really tiring to deal with newbies who don’t understand the product or why things are the way they are. You can’t really replace experience with process. It works well only in very simple and well understood cases.

Hmmm...I and a few other top developers on a corporate team just left a project and company because we were being mindlessly driven by management.

Management really tried to be accommodating, transparent, and woke in their treatment of employees but the work load was just too much. One sprint into the next without any breath in between.

Tenure averaged about one year on the team. The project has been going without release for three or four years.

The only people left are juniors (college grads basically) who don't realize how bad it is wrecking their health.

The only thing keeping their main SME dev is the generous PTO. She is always out sick, randomly. A lot of it was obviously the stress. She would always let out this lengthy loud exhale on calls and in grooming sessions. When I started doing that I began the exit.

Sounds like wasted effort. Relying on individuals are good, since it means they are somebody to rely on.

Anyways, hand over in high turnover places is shitty anyways, since they are shitty places to work at.

I think the rate of attrition matters. Too little change and you get stagnation -- you do need that ongoing renewal you call out, and the incentive to create good processes. There is a tipping point though, where attrition isn't renewal, it's erosion. It's the difference between "small fires that clear out the undergrowth and a few large trees" vs "large fires that denude a hillside that then destabilizes into a mudslide."

This is very true. Attrition helps with cross pollination as well as enforcing process and knowledge sharing.

However, I'd submit that it doesn't matter how good the docs and process are, you're going to lose a lot when an engineer who has been at a company for, say, 3+ years leaves:

* historical knowledge * personal relationships * intuition about the systems

Some things you can't get except by putting in the time.

Think about having a robust network like being able to fly.

You don't develop the ability to fly by placing yourself in positions that require flying...

Most companies that have lots of attrition have bad processes in place and are suffering due to attrition, although I think there are some companies that are developed enough to benefit from attrition like you described.

In order for a part to be entirely interchangible, you should choose the smallest common denominator of all parts to rely on as the highest value that you can get from one. I think that one must find an equilibrium but it requires active management and careful thinking to be executed properly.

Or to have great onboarding, people learn a lot, are effective quickly, and leave after learning enough. The know-how is then embedded in the process not in people, which guarantees stability, while people are guaranteed to change.

If you can embed all of your organization's knowledge in a few weeks of a single person's study, then you don't have much knowledge to begin with. Such stuff might be good for a small factory, but for nothing more complex than that.

Reply on news.ycombinator.com