One of my previous employers is of the large variety. While working there, it was evident that every developer became a knowledge silo because that...
For further actions, you may consider blocking this person and/or reporting abuse
Admittedly, all the teams I've worked on share the same struggle.
We all seem to have our core strength, but we're all in a place where if Fred, for example, left the team, the team would be able to continue on..even if limping along.
Here's a few of the things that get us along-
Use a team wiki (i.e.: Confluence)
Whenever we are learning something new - we put instructions/guides/user names/passwords/urls all on a shared site. It's up to us to maintain it, but the team lead will remind us whenever something comes up that "that should be on confluence". Or when we're looking for something late and find it's not there, we'll be sure to ask the developer to get it on there.
Lunch n learns
These can definitely be inconvenient if too frequent, but even 1 a month is an improvement. If the company is able to provide lunch, that's a incentive for people to show up. We've done sessions on unit testing, a demo on something we felt was really cool, a demo on a framework, or product, or x is all fair game. Keeping it casual is also key. Building powerpoints takes a lot of time.. but having your key points laid out and demonstrating them is a lot more interesting and interactive.
Open working area
Everyone has their own space, but I can easily turn around and ask someone, in person, to clarify x, y, z. This has enabled the lines of communication. If we're stuck, we'll sit at each others desks until we're both understanding, etc.
I've always liked the idea of a team wiki that functioned at a higher level than one particular project. For example, perhaps I could write an article that breaks down a common pitfall we always run into or tips for improving productivity while using a particular tool. I remember pitching Confluence at one point, too.
The open working area concept isn't my cup of tea. I understand the appeal of that for some, but I enjoy the relative privacy of my cube fort. Personally, I feel that our team manages to communicate freely enough despite the chest-high walls which separate us.
One thing we are trying to strive for more of is the interactive demo like you mentioned in point two. Since our sprints most often don't end with a code deployment, we hope that instead of a deliverable product we can present our accomplished work. Not only do we get to feel like we're "delivering" something but everyone on the team or involved in the project can see the progress we're making.
We have a team wiki that we could be better about being updated. We've do internal presentations that everyone benefits from. But I don't think people are always psyched about carving the time to prepare these.
I'd love to get into mob programming a bit. It's like pair programming, but the code is projected and the whole room drives.
I'd be interested in trying it, but my anxiety would die if I had to code in front of a room of people judging me while in front of a giant screen. 😶😶
Well the idea is that the person typing does not drive, mostly takes instructions, and everyone else collaborates on the solution. Still would be a bit nerve-racking but mostly on a "do I know all the proper keyboard shortcuts" kind of way.
...So I'm not alone in this struggle after all?!
I too work in an enterprise where development and operational staff live in tall silos of their particular area of expertise/oversight.
I've tried email lists, MS Teams groups, sharing interesting articles (many from Dev.to), promoting collaboration among teams/individuals, begging folks to use version control... Crickets!
We do a monthly developers' lunch to get everyone away from their desks for some casual socialization, but even that is attended by less than half the team and it's most often the same individuals who choose to go or skip lunch.
I can see the benefit of sharing our day-to-day activities and mitigating the risk of a "hit by a bus" knowledge disaster, yet I can't fathom why others don't see it as an obvious benefit to working as a team.
// end short rant of self-defeat
Suffice to say that I'll be watching replies to this thread closely. :)
This is a challenge I face as a CTO, given that I strongly believe in Maker's schedule and manager's schedule. So this is what we have implemented at where I am now. Not perfect, but I'm sharing what is working for us.
We continue to review each of these aspects and tweak to experiment. So far this has helped us to be a learning organization.
Amazing, I am a junior dev at my company. I know all the developers have vast amount of knowledge in different domains. We are however a new team, figuring out a lot about the product we are building. I want to help make knowledge sharing a painless and effective process. These points are really helpful in making my plan. Thank you.
We practice pair programming about 70 to 80% of the time. That's our main way to share knowledge and by far the most effective one. Besides that, we do show and tells twice a week, where everyone can share whatever interesting thing they stumbled upon.
Thanks for sharing your struggles Joe. I think many organizations and teams have the same issues, even the one I am on. Like you I am trying to encourage continuous learning and improvement on my team. Over the past year and half I have concluded that the most important factor for sharing information is team culture and the willingness of the individuals on the team to want to learn. You may have the best implementation of a knowledge sharing program, but if the people you are trying to teach don't want to learn there's not much you can really do.
If it is within your power or your manager's power, hire people who share similar values regarding learning and education. That's how you really fix the problem, but alas, it's probably something we can't do...
I am fortunate enough to have a few principal engineers take time to set up sessions to teach the team some of the fundamental systems and team history but they don't go beyond the team's project technology.
If you going at it alone, I would suggest you find at least one or two other individuals on your team that share this passion and start doing lunch and learns together. It's easier to sustain when you have a consistent group of members willing to see it through together.
For me, I try to do weekly lunch and learn videos. I take some of my favorite videos from conferences such as NDC, Goto, @Scale, GDC, WWDC, Build, F8, I/O, etc... and show them on a weekly basis. I try to leave an extra 30 minutes after the video for discussion. This is not always successful, as most of the team doesn't show up, but I have my core group of members who do. As I sustain this, I am hoping others will join us when they are ready.
Another immediate way of sharing random tidbits of knowledge is to send emails occasionally, like a newsletter of coding/design tips, tricks and advice. Don't do it too frequently that people will start ignoring you. A cadence of once every two weeks would be a good start. As an example, I was able to get the Android team to be aware of a new framework that I learned from F8 just by sharing it through email.
I hope this helps just a little bit but you are definitely fighting a hard, but worthwhile, battle.
I'm in a startup and we have a dev team of 3 so it's maybe a bit different here, but we're doing a mixture of things because it's especially important for us to be able to help each other out.
Informal Team Code Reviews - We're not doing code reviews in the true sense because one of us write the back end in .Net/C#, one of us writes the front end in Aurelia/TypeScript and one of us writes the mobile apps in React Native/Javascript. Instead we try and get together fairly regularly to show each other anything interesting we've been working on recently. It's not really a prepared session beyond deciding what we want to show each other. If nothing else, it gives us a chance to look at each others code and get a basic understanding for how it all hangs together.
Half a day a week of "training" time - To start off we were using this half a day for watching courses, reading books / blogs etc. We found that got a bit boring doing it every week after a while though. This is still an option, but I've also set up weekly "labs". We've got a few fun ideas for things we'd like to build that would involve us learning about certain things. The aim is to keep the tech stack similar to what we're using but also not limiting ourselves to this and still going for what we think is the best solution for the problem. We also don't want to limit ourselves to sticking with what we know. For example, I write the .Net/C# code but I'm pretty good with JS/TS too so I want to pick up some stuff on the web / mobile parts of our labs as that's how I'll learn to better support those parts of our own system. I personally think this is my favourite. It's fun for a start! For example we have table tennis in the office, so one of our labs is a system to keep score. We've even bought an Echo Dot so we could potentially write a skill to get Alexa to update the score for us. Another idea is to mount buttons under the table that we can hit to update. So yeah, fun and educational with a useful outcome :)
I'm not currently part of a professional team, but it seems that StackOverflow Channels will be a great fit for this. It's a private Q&A space for teams. It's free while in Early Access, and they've stated on the StackOverflow podcast that they intend to keep it free for teams upto a certain size.
Depending on what kind of position you're in (e.g. ops, dev) this situation from my workplace might give you a hint on how information exchange should happen:
At work we are dealing with a lot of technologies, systems, applications, each with their own quirks.
None of us can be a jack of all trades there.
So we are asking each other.
You ask others who might be the best to ask for a certain task.
If you express your willingness to learn to others you will likely end up in a "I'll show you one instance of how to do this so you can do the rest" situation.
This is for our business stuff, like "how to rollout an SSH key" or "how to install a webserver certificate".
One thing that is very useful in our job, as GNU/Linux server administrators is to be able to use the shell effectively.
This is something you do every day, at almost all times.
It is something that not everybody is more than 80% comfortable with.
Often the problem with programs you use at all times is that you find "your way" to do things, even if there's an unobvious but way faster or "better" way.
It can help for someone experienced with the usage of your $tool to sit beneath you for a few minutes while you are using it.
This might not be possible in all cases.
15 Minutes.
Every week we have one presentation taking about 15 Minutes.
This need not be anything that is interesting for everyone but a sufficiently large group.
It's a presentation that just sums up a small topic.
Examples include "hey, I found this awesome framework for writing CLI tools in python" or "How I use $tool".
It's also good to make these presentations accessible to everyone, not just those who need it at work.
Onboarding.
You wouldn't believe how important that is.
Write certain things down.
As others already suggested, there's lots of Wikis or Wiki-like things to put information into.
Document known processes.
Things which work good
It sounds trivial, but a very good way for knowledge transfer is asking questions; personally or via a chat tool. This checklist feels useful to me: catb.org/esr/faqs/smart-questions....
Also code reviews lead to knowledge transfer. When colleagues see a better way for doing things they will state this as a comment on GitHub and explain things if necessary. All of our production code goes through this process.
Pair-programming is another a very effective way for knowledge transfer. Knowledge gaps become obvious a can be filled. Little productivity hacks transfer kind of automatically to the pairing partner.
Further, we have a set of presentations for the most important topics for the on-boarding of new colleagues, e.g. Spring, Lombok and RabbitMQ. They consist of diagrams, bullet points and examples.
Things which are nice to have
There is also a public developer blog where I sometimes learn some bits about our internally used technology: developer.epages.com/blog/
We have a community of practice meeting every two weeks where volunteers presents the usage of new architectural pattern, lessons learned from conferences, etc.
I am storing lots of snippets in my personal blog of our company's Confluence instance. Occasionally I share links to them to help solving a particular problem.
I am connected with some of my colleagues on Twitter. I am taking notice of their findings and eventually they are occasionally reading some of the pearls of programming knowledge I am re-tweeting.
Things I am experimenting with
I am also keeping my personal notes on a public website. But even the ones which are kind of cleaned up seem not to resonate with people, e.g. this one notes.experimental-software.com/So... The challenge here is to extract the information and then make it digestible for others. The Infodecks from Martin Fowler seem to be a good example: martinfowler.com/articles/workflow...
Further I have started to record videos about software development but I am still in search of a process for creating good videos without spending too much effort on it. youtube.com/channel/UCcZGbEeAuBJXi...
I think the method question misses the mark.
You probably know next to nothing about something: cars, plumbing, electrical wiring, surgery, dentistry.
When you need those services, you pay a premium for someone else's expertise.
Specialization increases my value to the organization. When it comes time for a raise, promotion, or bonus I have an expectation that I will be compensated for it.
If anyone can do what I can do, then the organization needs me less. My value decreases, and it's possible the security of my job becomes threatened.
This is why avoiding silos is hard -- self interest (preservation?) will almost always win out over what's good for the business. Challenging people to go against their basic need for security is never going to work.
If you can find a way to elevate the value of sharing/education so that the value of the individual to the organization is increased by doing it, then the method will matter less. When motivated people will find a way to accomplish the goal.
Avoiding silos is hard, yes, and not everyone will see specialization as a bad thing. I can't force people to learn if they aren't motivated just I was unable to absorb information while having peer knowledge transfer presentations forced upon me at regular intervals.
I would challenge the idea that "specialization" is a value to an organization. I'm not against the notion of subject matter experts on a team, but just because I know more about one kind of technology doesn't mean I want the burden of having ALL tasks related to that technology assigned to me. What is more valuable to an organization, one specialist or a team of capable developers armed with the same knowledge that an expert shared with them? When resources and time are tight, having many capable developers is always better than one person.
Specialists are ok, but why stop at any one subject? If an expert imparts their knowledge to others, it frees them to become proficient in another area.
I'm sort of in the same boat as you here, one of the places i work at uses slack for communication, we have dedicated channels for the staff team to learn places, for example learn how to use our custom made client, how to use slack and general questions about staff. A few things we're starting to use and working on are:
1.
Knowledge base: We're currently building an entire knowledge base for every bit of information our community will need to know when contacting the support team.
2.
Guides: a lot of the information we're required to use can be quiet heavy and thankfully after some tinkering around with google documents we've been able to create guides that have all the information required
3.
Good communication: We like to see the staff team not just colleagues we like to see each other as a family, there's many that have been here longer than others that are assigned to helping out the newer people coming in.
In my current job, I shout the info when I enter the room.
Is this that "MEAN" framework I keep hearing about everywhere?