Comment by iambateman | Hacker News Reader

Comment by iambateman | Hacker News Reader

If you haven’t read Stables and Volatiles[0] it’s a great place to start. It’s comforting to know that this is a common, structural management problem and not some one-off. Lots of engineering teams in lots of organizations have faced your challenge.

One of the things the blog post does really well is explain how a volatile can be valuable (even essential) in the lifecycle of a company. I personally tend to lean more toward volatile, so I can appreciate the tensions your colleagues are facing.

I have a few recommendations…

1. It’s very likely they don’t see the value of collaborative team work. You will all benefit from them coming to see the team as important. There’s no magic bullet here, but they’re still human and hopefully reasonable. Questions and conversation can help.

2. It’s possible they’re actually just insecure assholes. If so, work to remove them from the team ASAP. There’s no room for assholes.

3. If they are a volatile and they’re in a team which mostly benefits from stability, try to find a problem which is substantially challenging and useful to the team which you can hand them.

4. If there is no opportunity for that kind of challenging work, they might not be a good fit for the team long-term, and management owes them honesty about their fit.

Overall, I hope it works out for your team. Personality and work-style dynamics are tough but I have seen big changes on teams happen, and it’s possible for yours too!

[0] https://randsinrepose.com/archives/stables-and-volatiles/

If we are briefly going to play astrology-for-engineers then I guess I'm what would be called a "stable", but I kind of take issue with the dichotomy this post paints up in order to achieve what every tech writer seems to want to achieve these days: to be the person who Named Something.

This rigid definition into two different groups of people is pretty absurd if you just spend a minute thinking about it: in what other areas is it really reasonable to define human beings into personality binaries? The common response to this is always "well, it's a scale", like when people say they're a mixture of being introverted and extroverted -- another binary that does not stand up to scrutiny and seems to push the goalposts every time you poke at it, because most people do enjoy being alone occasionally, just like most people do not improve their mental health by avoiding others.

If someone identifies as halfway between a "stable" and a "volatile", that doesn't make them "a little bit of both", it makes the scale useless, because like a flatlander in 3D space it's obviously unaware of an entire dimension of human character and psychology. And yeah, of course these terms are created to "simplify" and "further discussion", but do we really need to put on a red or blue armband before having a discussion?

The picture painted here is one of the "risk takers" and the "risk avoiders", and while it tries its best to paint a fair picture it's pretty obvious it comes from a culturally American idealization of the Maverick, the risk-taking, 48-hour-working engineer who "gets it done(tm)" -- and I get it, that is valuable, and I've worked in companies filled with people who repeat phrases like "it's the way we've always done it", just as I've worked with people who got burned out re-factoring code, didn't care to document it and then quit, all in the name of this creative explosion the post seems to imply -- but if I can take anything from this post, it's not that these are natural laws of character that will repeat until the sun goes out, but rather that anyone solidly in the "stable" or "volatile" camp needs to work on their character progression to learn more from the other camp.

Nobody is born or raised into a role and then doomed to play it out for the rest of their life, we are very complex meat-bags that change over time, especially so in collaboration with others, so for anyone who feels like trying out the "Camp A" and "Camp B" advice when resolving conflicts in your workplace or when putting together managerial strategy, I'd implore you to maybe think again and tread a bit more carefully.

I don’t think we have much disagreement here. My first two recommendations totally connect with needing to help people who are too firmly entrenched in one end of the stable-volatile spectrum.

The blog post itself describes a common evolution from volatile to stable through the course of an individual career, so I’m sure the author would agree that no person is predetermined as one or the other for life.

Lastly, I think ideas like volatile-stable have _explanatory_ value more than _predictive_ value. It can help defuse a tense situation to see that a team is falling into a common, age-old trap and then let the creativity of the whole team figure out how to solve it.

I don’t think we disagree as much as you seem to think we do. :)

Thank you for this comment. I was reading the article and couldn’t agree more. Theres a place for hacking towards a goal theres a place for reliability. If you can only do one, then you are only half an engineer.

If success isn’t defined and these paths are left to individuals, then it seems like you have a problem with project scope and product management.

> Theres a place for hacking towards a goal theres a place for reliability.

Most engineers and managers believe this. Nobody agrees where that place is located.

> hacking towards a goal theres a place for reliability

Yes, but in professional software engineering[1] where the roadmap exceeds 12 weeks, and the cost of a bug is non-zero, and you realize that in software engineering we do far more Reads than Writes to the code), then there are also dominant and dominated strategies[2]. Prototypes should be crafted from large blocks like low/no code solutions or generation... But once we have validation typically this is where good software architecture, and systems architecture come into play. Both the properties of the code that is written eg SOLID[3], and also the emergent properties of a collection of implementations.

All of this feeds into the total ROI of the engineering process. Quality issues lead to both churn[4], and slower roadmap (which means you lose out to competitors). People tend to think that "just make it work" is faster, but time and time again I've seen that only to be true in approximately the 6-12week time span. Hacky is fast until it needs to change, until someone else has to read it, until you realize there is a bug.

As well, it turns out that expertise in doing things well makes you faster the next time you go to do it well. I sometimes wonder if people doing things hacky/poorly is only faster because they've practiced it so many times? Often times well structured code is easier to read/write, fewer lines, easier to test, easier to morph into the next evolution. As we practice coding styles that give us these properties, we get faster at it.

So while yes there are tradeoffs, I don't think there are very many ways to take on lower quality implementation for time speed ups, both short and long run. Yes of course there are features you just don't need (your blog doesnt need to use CRDTs to update your post). And that tends to just having discipline in your Executive/Product team-- only ask for something if you have the research to make you think it will work, and the spine to stick it out to implementation. Engineers can also focus on stopping making bespoke software for prototypes. Pre GA mock ups should probably be using almost entirely light weight proxies for the product -- ui mock ups, generated code, SQLLite/PostgREST, low/no code solutions etc. to get strong data about usage patterns, user's needs etc.

[1]: "Software engineering is what happens to programming when you add time and other programmers." via https://research.swtch.com/vgo-eng .. I don't really care what you do in your spare time or on v0.0.0, but when we're on a journey as professionals to craft tools that 1000s to billions will rely on there's something more than just "it compiles, works on my machine"

[2]: https://martinfowler.com/articles/is-quality-worth-cost.html

[3]: https://simple.wikipedia.org/wiki/SOLID_(object-oriented_des...

[4]: (which means you cannot pay high CAC because you'll lose them before recouping cost)

If you can only do one, then you are only half an engineer

In a proper engineering discipline, the only place for hacking towards a goal is within the confines of the lab.

I dunno, man. I'm a (very) volatile person (in this dichotomy) myself and these days I'm aware of it. That wasn't always the case. But it really will piss me off if someone were to static my a$$ about something I really want to do. Now, this is not me saying I should obviously get to do it, this is me confessing to how I would feel about it.

You're right to be wary of pigeonholing people: thinking that Alice "isa volatile" and Bob "isa stable", and viewing all interactions with them through that lens, will be more harmful than helpful.

But there's value in recognizing and categorizing instances of behavior in these terms. It's hard to effect change over something you don't understand, and giving it a name is a useful step to understanding.

Recommendations 2-4 aren’t great.

Instead, I’d recommend really working on recommendation #1 which is working on communication specifically…

1. Tighten the feedback loop for them. We all get the idea of using logs for engineering. People need the same for their performance. This means being willing to have difficult conversations and providing accountability.

2. Discuss in an open forum ways in which to solve the underlying problem and get commitment from the team as a whole to try new things like mob sessions or pair programming.

3. Most importantly, there has to be clear goal-setting. Meaning the team should be a part of that process to decide what they are attempting to accomplish and what their scope will be. This can be helpful for making sure no one is too far afield.

ONLY ONCE THE TEAM HAS DONE THE THINGS ABOVE

And if the engineers choose to not engage in good faith and work in the interest team would I consider termination or moving them to another team.

Thanks for this link. A solid quick read for anyone who has gone through stressful startup (or similar) work experiences.

I changed roles a bit ago and had to spend some time thinking through the battle scars situation that Rands calls out. It's definitely a bias to be aware of when moving on from a volatile, scar-inducing period to something new. I've repeatedly caught myself thinking don't want to do that again but sometimes doing that again is a phase of growth that still needs to occur for a new company or product. Not everything can be skipped because you're wiser this time around and I've had to work to navigate insight from having been there before vs. holding back the team due to baggage.

The new volatiles callout is great too as these teammates frequently need to experience the situations and see the cookie crumble before they can internalize and truly believe the tips others tell them.

The article on stables and volatiles was really great thank you for posting that. Its one of the first times I've seen my intuitions and feelings on problem solving described not only in a positive way, but also as a necessary yin-yang type relationship balancing the other side.

That’s a decent read, but I also take issue with the either/or mentality. Like there’s plenty of people whom the author would call "stables" that are frankly just slow, don't care, and/or don’t want to do much work, no matter how behind a project is. Similarly, there’s plenty of people who they call "volatiles" that aren't just cutting corners and hacking without caring about scale, but are just more comfortable with working and delivering incrementally.

> the value of collaborative team work.

It seems like there is not much evidence for this in the literature, and lots of evidence that extremely common practices around collaboration reduce productivity and creativity of orgs

The trouble is, I never became a stable after shipping 1.0 as the article predicted I would. But then maybe that's just because I was always pushed to do the next thing that required a volatile.

Reply on news.ycombinator.com