The downsides of collaboration between coworkers | Hacker News Reader

The downsides of collaboration between coworkers

uk.businessinsider.com

80 pointslxm53 comments

It's pretty easy for those overly successful coworkers (I've been such a folk) to setup a knowledge collaboration platform, like a wiki, and share this way the knowledge and let people read it instead of asking per email or phone.

That's what I did. It doesn't really make sense to answer each and everyone individually.

This is the right answer, but in my experience, there's still a balance between wanting to be friendly, supportive, and engaged with the team, and wanting to protect your own time. At its worst, the approach you outlined devolves to the "read the manual!" cultures that everyone hates, but if you can strike the right balance between writing documentation and helping people understand it, then you're in really good shape.

I've found a pretty good balance to be giving answers that have 3 parts:

    1. a short answer (about 1-2 sentences)
    2. what section of what manual to read for fuller information
    3. other resources; possible "gotcha"s

Then, if they come back and still don't understand, don't just take the time to help them, but also update the manual with whatever you tell them!

Yeah, but this is a classic problem of long-term vs. short-term optimization. In the long term having great, living documentation of everything the experts know is clearly the best, but in the short term it looks very expensive.

I'm actually working on a wiki built on Slack to solve this exact problem. If this is happening to you, checkout http://tettra.co.

We just launched our beta last week and are looking for companies to work closely with to improve the product. My email is andy@tettra.co if you want to discuss more too.

This doesn't work in environments where:

(1) There's simply too much information, or too much specialised knowledge required for more junior employees to properly utilise and assimilate it, possibly due to widespread hiring of underqualified or inexperiened people;

(2) There are too many one-offs, unique or short-term items that are not really economical to formalise -- this is usually a problem of business model, or short-term survival strategies (e.g. consulting);

(3) The details are changing too fast for the Wiki to stand a reasonable chance of remaining current and useful, as is often the case in fast-growing, rapidly pivoting and evolving startup companies.

In those cases, there's really no getting around the role of "go-to people".

1) That's what docs/training are for.

2) Writing the answer down in a wiki takes exactly the same amount of time as writing the answer in email. It doesn't need formalizing, just recording.

3) Again, the time it takes to tell someone is the same as the time it takes to write it down.

This is a solvable problem, we just have to break the perception that "documentation" is onerous and heavy-weight. That's what wikis were meant to solve.

For example - ppl are only allowed to answer questions with wiki links. My team did this, it worked very well. Everything was documented and everyone learned to check wiki first....

No, writing the answer down takes much longer than just vocally expressing it.

1. Few people type as fast as they talk.

2. When talking, you already have all the context of the problem of discussion. This usually doesn't need to be explicitly communicated in detail, both people are currently close enough to the issue to have most of the background. In a wiki you need to establish enough context that the page is useful to someone who comes to it with no other help. There is no point in having a wiki if you still need to talk to one of the guys who wrote it to understand it.

3. With a wiki (or any other secondary doc system) you need to organize the information and make it findable. This is a non-trivial effort as the knowledge base grows.

Personally, I'm a big fan of documentation in the code paired with a wiki or other secondary system for longer or higher-level documentation. But it is definitely more work.

I have a weird idea... What if, on condition of answering the question, you require that the receiver update the wiki? This may not work with close collaborators, but it would work with more distant ones on the threat of withdrawing further collaboration.

In a wiki you need to establish enough context that the page is useful to someone who comes to it with no other help

Bingo.

The idea that answers can just be written in a wiki ad hoc is one of those pleasant-sounding pithy conversation-stoppers, but it's strictly notional. It's certainly true for small, bounded, well-defined, trivial and/or obvious stuff, but that's not usually the stuff people pester the experts about (well, one would hope).

That's why mailing lists are great.

1. Okay, they don't address this, but that's a marginal advantage, easily outweighed by the advantages of asynchrony and distance agnosticism alone, never mind the benefits of re-use.

2. Mailing lists hit the nail on the head here, because you have the context in the discussion thread.

3. This is a big win for mailing lists with a good search function (such as that provided by Gmail). Sure, it's not as nice as having the information painstakingly organized by a subject matter expert, but as you say, the human effort required to do that organizing is not usually available, and having the information there and searchable is far better than not having it.

That's an interesting idea, and one I have considered at length before. If I ever end up managing an organisation of any nontrivial size, I do believe we will have Mailman lists for a lot of things.

1. That's fine, most ppl don't need the answer now, they need it soon enough to not be blocked.

2. Any answer without context is useless, even verbally. So include the question with the answer when you write the doc.

3. Internal wikis are inherently trees, add the answer to an existing node or create a new node.

I see most of these replies are failing wiki docs for not being perfect - you just need to be good enough. It's a living document, as it's used it will mature. The important part is capturing the information somehow, somewhere.

Stop propagating tribal knowledge and document it!

> 2) Writing the answer down in a wiki takes exactly the same amount of time as writing the answer in email. It doesn't need formalizing, just recording.

Not usually true in a wiki of any size (unless you mean creating a new page without reference to what's there and shovelling the information blindly in).

"Writing the information down in a wiki" really implies doing so in a useful way. Probably: - identifying where the information should go - cleaning it up to remove redundancy (stuff already in the wiki) - correcting existing wiki content which you discover was wrong/out of date as you go to make your changes - changing to adopt the writing/layout style of the wiki - etc. etc.

Of course its common for wikis to not be maintained like this - maybe even the norm - which is perhaps why the "dump and then search later" strategy of gmail, slack etc. is pretty successful.

That is the answer. It is essentially a knowledge management problem if the most knowledgeable are already documenting their work and process and status in a manner that is accessible to everyone else, they not only don't have to repeat themselves, but you're scaling yourself. The challenge, I think, is that each knowledge management technology solution really requires a custom solution to achieve such efficiencies in a final form. Sure, you can throw a wiki together and that works in a one-off manner, but that doesn't scale if everyone is supposed to participate in that process and discovery starts becoming an issue or everyone has their own janky one-ff solution.

IME it is also important for management to officially recognize the need for a Wiki and provide some minimal resources and time to manage it. Otherwise it becomes just another thing for people to add to their ever growing list of things to do.

I'm in a team now with a brilliant but highly overambitious manager, and we've got lots of great knowledge locked in people's heads. So three years ago we created a nice wiki and started adding stuff into it. One year later the company reorganized and the group that owned the company wiki master site said they wouldn't pay for it anymore, and that we had to move to a new system. So we did after a lot of work. And guess what happened a year later after another reorg?

Putting something in a Wiki also requires you to put in a lot of thought so you properly address the audience that will try to make use of it. And that can range from people who are lazy and need to have their hands held through everything, to people who just needed a nudge in the right direction. With meetings you don't have to be so mindful, apart from knowing which people need to just go away.

If there is some recognition from management that a Wiki is required and it officially needs time from people, then there is consistency about what goes in there, the time required, and some escalation process if the Wiki is wrong or outdated. Otherwise it's just another thing you do that gets no recognition that could easily lead to more work.

I did that when I got sick of people bugging me about the same questions over and over.

They still kept asking me. The same people. With the same questions. Every. Single. Day.

I got yelled at for doing the internal equivalent of LMGTFY in our chat room.

Some people just don't want to learn unless they are forced to.

I have a client who calls me every few months to ask for her email password. I've considered adding an item to my next invoice that says 'password manager'. It baffles me that she thinks this is okay, but in her defense it seems to work out pretty well for her...

I think the company culture will be the determining factor.

If you have a number of people trying actively to be as knowledgeable as you are, and documentation is considered critical for everyone, a wiki will be the right approach.

If most managers think that people should have strongly separate knowledge domains ("you should be the specialist of XXXX" in our company) and/or strongly value face to face communication, a wiki won't save you from getting drowned into questions and requests.

To take the not so good example, in some companies telling your boss you're reading docs related to a library will get you a "why don't you go talk to TheKnowledgeablePerson instead, he worked with a version of it 10 years ago, he might remember things, perhaps"

In reality, this will only result in even more questions asked:

- More specific questions will arise because people will get further but lack the experience to fully understand and solve the exceptions

- More people will find you to ask questions

- People will not understand or are afraid of not understanding it correctly and will ask for clarification

- People are too lazy to read and will just ask anyway

- For some stuff, you need a lot of cognitive capability. Not everyone has this. It doesn't matter how much you explain or document, they will not be able to understand it. (This sounds arrogant but it is the same with physical limits: I can't probably be the world champion swimming because of my body characteristics. The same applies for non-physical limitations.)

The "War Room" idea promoted by Scrum Masters and Project Managers has a similar downside. War Rooms take your best people and force them to answer questions all day long posed by your least-knowledgeable people. War Rooms are one of the surest ways to reduce the morale and productivity of your best people.

However, if you require real-time visibility of project status, you want all of your people to be easily interchangeable and replaceable, and you think that knowledge concentrated in a few good people is risky, then the War Room is for you.

I didn't know people were so generous. The experience I have is that all people want to keep their knowledge for themselves. In all the companies I passed by - including Fortune 40 ones - the documentation was non existent.

In one of them, a magician who wrote a 20k lines of code Access program doing fancy things like generating stored procedures on the fly, still knew more about the program after 2 years of development than the 10 people team that was in charge of migrating it.

More recently - last week - in another company, someone told me very naturally that the requirements were in someone's head and in the database schema and that we should rely on this person's expertise and avoid spending time to lay the requirements down before starting the iteration.

The world I live in is much more political than the one that you guys seem to live in. Please give me the address.

That has been exactly my experience as well. There exist job places where "the requirements is in his head" is considered normal and in order and there is too much respect given to such "job security" selfish aes who never share things voluntarily.

As contrast, at an earlier work place there were "mentors" introducing newcomers to the domain holding introductory crash courses and doing code reviews. I understand why so many job posts here in Sweden stress the importance of knowledge sharing for common (not individual) success. Sharing knowledge means that more people can share the burden - not the other way around.

Amen.

I think the reason people are afraid of sharing is that very few people practice continuous learning. They keep using what they learned 5, 10, 20 years ago, therefore - to their mind - if they share it, they are left with nothing.

I don't mind sharing as I read like crazy, learn new things all the time, and improve my way of doings things so that I do and understand things much better than I did 5 years ago.

Most domain knowledge in one corporation has zero value outside that corporation . There's too much path dependence.

And the older the learning, generally the more general it is. There are a million ways to do everything, but a team will have Stockholm Syndrome with how it does things, generally.

There is a world of difference between service rendered and sharing knowledge voluntarily. This article specifically described the former which is precisely due to the lack of latter, whether Business Insider Research realized it or not.

Once work collaboration is viewed not as an effective means to add value but the value itself, common job security motif can drive the work place to a popularity contest. Meeting invites and social connection are some of the examples of there are more to the service demands one must draw at work place.

Business Inside only scratched the surface and jumped on a convenient conclusion.

I love your reasoning, very insightful thanks a lot for sharing. This is the kind of wisdom and out-of-the-box thinking I like to read.

I don't know. All the places I've worked for so far had close to zero useful documentation, but the reason had nothing to do with people "keeping knowledge for themselves". It was simply because there's always something more important to do than writing documentation and keeping it up to date. Everyone tells themselves and each other that someone has to do it eventually, and in the end, it never happens.

eBay did a great thing in this regard -- they offered a sabbatical every five years. It was a win for the employee because they got a nice long vacation and it was a win for the organization because it forced everyone to figure out how to get along without that employee for an extended amount of time.

I really like that!

One of the problems I see in my company is the "hero" vs. "process" mentality. We don't setup processes that any employee can handle, we just have a few "heroes" who rush in to save the day any time there is an issue. This leads to huge problems when the heroes want time off because we have no idea how they do what they do.

A sabbatical program like this would force a shift towards processes. At least I hope...

Every place I've ever worked relied on heroics to some degree. Some more so than others. Project is way behind schedule? CRUNCH TIME! Only one person knows the code base? Give him all the work! Critical bugs found close to release? All nighters until they're fixed! In all cases, what was needed was more discipline and process. But if you ask people, they'll often tell you "process is bad and project managers should go off and make their spreadsheets and let me write my code in peace!"

The other reasons why processes are not adopted is that most employees are not thinking in terms of 'processes'. Secondly typical process/BPM tools are geared towards I.T. rather than regular workers.

Both problems can be solved by gearing tools towards end-users rather than I.T. and allowing processes to emerge from lower-level constructs like (say) discussion threads that workers normally participate in. This would gently steer workers towards a process mindset.

Google did the same, until they realised everyone was leaving immediately afterwards.

Yeah eBay had that problem too. People would save up all their vacation, add it to their sabbatical and then use the time to job search.

I think they changed their rules so that you couldn't add your vacation time to it and you had to pay them back if you left within in X months.

Do you have a source for this?

My company has been looking into implementing something similar and I'd be interested in reading more. Thanks!

It worked really well for Tandem Computers.

People felt pretty happy with the company for about a year after their sabbatical, and didn't want to leave for about 2 years before their sabbatical (and miss it).

Don't know why this didn't work as well for Google.

Maybe the Google folks are more likely to apply somewhere with insane, multi-day interview processes that can stretch out over weeks, so the Tandem folks who wanted to leave didn't feel like they had to wait until they had a huge chunk of time off to look for a new job?

This is purely anecdotal, but I have a handful of friends who left google after their sabbaticals. They all explained it with some form of "I was surprised how much happier I was when I didn't have to go to work, and I didn't miss it at all." A couple of them actually chose to not work at all for a while, and one started his own company (a small lifestyle business, not a unicorn-bound startup). Using the time to interview and heading off for another full time job is not a pattern I've noticed at all...

I think Google was unique in that most of the people who were hitting their sabbatical had done very well with their stock options, and realized that they didn't need to work anymore and were quite happy not working, or working on their own stuff.

My former employer, HubSpot, just started offering a sabbatical to employees at the five year mark too. The only rule was that you had to share what you did on your sabbatical with the rest of the company on the wiki. One of the earliest employees shared a picture of the sweaters she knit, and other people shared images from the trip they took. It was really a cool experience seeing the experiences people earned from working there for five years.

I never considered it as a forcing function to make sure no one employee is a linchpin to a team though. Very interesting point.

(edit - spelling)

How long does this sabbatical last? I suspect not as long as the academic term of the same name (which is one full year for every seven years of work).

It's one month, so 30 days.

This doesn't seem all that new to me.

At the receiving line for a party, back in 2002, the executive officer on the USS Nimitz greeted my wife by saying "Thanks for supporting him, the Navy has a long tradition of riding the good horses until they break."

Seems like the problem is that people are being given more responsibility without the necessary power.

I don't know if that is exactly how I would describe the problem. It seems as though a majority of my highly skilled coworkers, management or senior engineer, are CONSTANTLY having people come into their office for advice. It's commonly known that if you have a problem or need help understanding something to go ask the resident "expert". These "experts" are bombarded with questions and visits so often it's a wonder they ever get their own work done.

Not to mention the work of the people around them in the near-ubiquitous open offices.

And yet they don't have the power to hire assistants to help with organizing disseminating their knowledge. If they are the constraint in the system, the organization should be leveraging them.

That greatest way to ensure job stability is becoming indispensable. Being indispensable entails providing a service or holding information that others cannot fully attain without relying on that individual.

Many people, especially from the newer generations are looking for more than stability from their current job. Democratizing information is great as long as the bottleneck is not an individual and their resources.

How does this compare to, say, a Q&A site where one gets positive feedback for answering random questions? Is the reason why people leave because they cannot do the work that they want (time used up in collaboration) or is it because they are not being given credit for the work they are doing?

Constantly being interrupted to answer simple questions is a thankless task that has negative consequences to your own productivity. You ultimately have to do their work and have less time for your own, which can be stressful when on projects with tight deadlines (aren't they all?). At some point I realized that being overly helpful makes you an enabler of this rude behavior - why bother spending a few minutes researching something when the guy across from you can answer it immediately? Often it's better to say no and encourage more self reliance.

My strategy is basically:

-> Politely ask colleagues to send you an IM instead of discussing in person. The context switch hit from a conversation is significantly worse than from an IM.

-> Answer questions by making/editing a wiki page then send a link. Although I find this is less helpful for one off questions or during times of super high work load.

-> If you've helped person X with a similar problem in the past then simply outsource the question to person X.

-> Worst case (especially if someone asks the same question multiple times) play dumb :)

I wonder whether there is a "soft" Dunbar number for collaboration networks?

People who know a lot and rarely have time to share knowledge will always get questions about things they haven't yet shared with others. Personally, I find it less effective to work in an environment where people don't share their knowledge since less knowledge means frequent questions...

Reply on news.ycombinator.com