Hacker News new | ask | show | jobs
by sdiacom 1224 days ago
By saying "serendipity" here, we abstract it into its own unique cutesy concept, preventing proper analysis of its actual tangible benefits. This leads people to talk about it as if it's some magical emergent property of water coolers.

When we talk about some of the tangible things that we might actually want this "serendipity" for, these are the ones that I constantly see pop up:

- Spontaneously detecting and addressing small issues with the product

- Spontaneously coming up with and implementing ideas for the product

- Spontaneously coming up with and implementing workflow improvements

These are all things that should be addressed as part of day-to-day work. The reason they're not addressed is often overzealous prioritization of shiny things to the detriment of everything else. Or, in other words, bad management.

That's all this "serendipity" is actually for: a release valve for the pressure imposed by bad management, which helps mask the effects of bad management.

All you actually need to do, in order to reap the benefits of "serendipity" without locking hundreds of people in the same room together, is incentivize the necessary interactions, provide people with the necessary time to act on their urges, and get out of the way.

Here's some free ideas that I've seen work in real life:

- Have a Slack room for people to share user feedback, and explicitly encourage negative user feedback (maybe a different room for positive and negative, to avoid dampening good moods)

- Encourage employees to suggest improvements to the product and the workflow, and to publicly (yet politely) vent about the current processes that bother them. Don't make a "feature request" JIRA form that dumps it into an endless backlog, never to be seen again. Instead, have people discuss the issue publicly in a Slack room, which allows feedback and potential improvements to be considered and taken into account, then have them create an issue once they understand what it's actually about.

- Your planning should aim to drive around half of the actual work that gets done, under the acknowledgement that the other half will be organically filled with work that needs to be done. It's always easy to pick the next task if you're done earlier than expected and there's nothing else to do. It's a lot harder to sideline planned work that you've explicitly been told to do in order to do something that's actually important instead.

2 comments

No, "serendipity" here has value primarily not within a single team, but as a discovery mechanism between teams. There's research on this. It has its highest value for new starters trying to figure out how the org fits together, but is also useful for inter-team workflow discovery and reinforcement, especially at the start of projects. You shouldn't need it within a single team unless that team is already dysfunctional (which I think is your point).

Basically all orgs need something that acts as a random mixing function so that connections between areas can form and strengthen. Working in the same building can provide that, if the building layout allows for it, but it's far from the only option.

The problem is that managers, particularly those with a strongly hierarchical, Taylorist mindset, won't necessarily appreciate the value of lateral connections between teams. They end up benefiting from serendipity by accident because when they force people into the office those lateral connections form anyway.

Oh, thanks for pointing this out! I hadn't thought of it explicitly in that way, so I didn't write it down. But all the concrete examples I was running in my mind were indeed examples of inter-team collaboration: "helping the HR team fix their workflow", "addressing issues that the customer support team keeps getting complaints about", "fixing some minor product oversight that leads to a worse experience"
IMO that Slack room would be a wasteland, if you've seen it work you're lucky
We have that Slack room and it works fantastic.