Ask HN: How do you transfer domain knowledge to new starters?
7 comments
Everyone's talking about sharing how your own business operates (as OP asked). I think of that as onboarding. I work in B2B, and the question I was hoping to get answered is how to share how your customers' businesses operate. In my case domain knowledge means things like: What are the differences in how an OEM vs a Job Shop operates. What departments does a manufacturing organization of different sizes typically have? How is our product perceived as providing value in each of these scenarios? How does our product actually provide value in these scenarios? Who gets extra work in the company because of our product? What's the benefit to them? Knowing these things is what allows us to bring value to different kinds of customers. This is really hard knowledge to transfer though, because you aren't living it every day. That's the kind of knowledge that's going to make a developer (, or service staff, or sales person) highly effective though.
I worked in a completely different world my entire career but I see something familiar with your questions. (I was a policy and budget wonk, a child advocate, basically a lobbyist on local government issues in DC.)
I successfully brought on one new staffer by having her shadow me (in formal and informal meetings with decision makers, community meetings, telephone calls, document prep) for a month and do a TON of grunt work, things like making lists of the various organizations working on a particular issue, what their viewpoint was, identifying DC Council staffers working on the issue, identifying their interests and learning styles.
I know the staffer felt somewhat constrained on the leash, but she ended up being so much more successful than other policy staff who did not go through this and do the grunt work. Though, thinking back, success may have had much more to do with my having conveyed a specific approach to the work, goals for the work, etc.
I successfully brought on one new staffer by having her shadow me (in formal and informal meetings with decision makers, community meetings, telephone calls, document prep) for a month and do a TON of grunt work, things like making lists of the various organizations working on a particular issue, what their viewpoint was, identifying DC Council staffers working on the issue, identifying their interests and learning styles.
I know the staffer felt somewhat constrained on the leash, but she ended up being so much more successful than other policy staff who did not go through this and do the grunt work. Though, thinking back, success may have had much more to do with my having conveyed a specific approach to the work, goals for the work, etc.
I try to keep extensive documentation for our standards and processes, and I've recently also started a weekly internal blog describing challenges, updates and tasks. Handing over this whole thing along with a few face to face sessions has seemed to work with new joinees.
It is probably a bit dependent on what exactly you do. I am mostly an embedded dev and I often begin to show the tool chain we use from requirements analysis to firmware. And also the tooling around that for generally organizing your work. A certain phase for orientation should always be given an and some team members need to put in effort to train new developers.
But you can also take advantage of that if you task new members to maybe evaluate these tools or a specific one. That way they have a task beyond familiarizing themselves, which is often a blurry goal. The task also requires to get to know the tools employed to be able to compare them to alternatives.
That way you can also leverage the fact that someone new maybe doesn't have the same blinders yet and it can take work off you to keep up with developments in the field.
It takes a bit of time though, since newcomers are also a bit reluctant to tell you that the tools you use are suboptimal. You maybe need to encourage them to speak their mind.
As I said, it is a bit dependent on the field. Perhaps this approach is terrible for web devs, because the amount of alternatives is staggering and a lot of it comes down to opinion and personal preferences. So maybe this is terrible advice here.
But you can also take advantage of that if you task new members to maybe evaluate these tools or a specific one. That way they have a task beyond familiarizing themselves, which is often a blurry goal. The task also requires to get to know the tools employed to be able to compare them to alternatives.
That way you can also leverage the fact that someone new maybe doesn't have the same blinders yet and it can take work off you to keep up with developments in the field.
It takes a bit of time though, since newcomers are also a bit reluctant to tell you that the tools you use are suboptimal. You maybe need to encourage them to speak their mind.
As I said, it is a bit dependent on the field. Perhaps this approach is terrible for web devs, because the amount of alternatives is staggering and a lot of it comes down to opinion and personal preferences. So maybe this is terrible advice here.
i recorded all the sessions of my knowledge transfer sessions and put them on a web page. I also created a new employee forum to ask questions. Now i just point new joinees to go through these sessions and ask questions in the forum. Every quarter i review if new session needs to be added based on past answers in forum or some previous session needs to be removed due to outdated knowledge. It is working fine since last 4-5 years. I have now left the company however the system is still in place and other teams have adopted this practice as well.
At my last employer I set up a simple internal wiki for which I used Cherry Tree.
The idea was to to collect the best solutions and strategies for recurring problems or edge cases, background knowledge for new and seasoned employees to understand the reasoning behind specific processes, a link database, form templates and general IT self-help advice.
It was somewhat helpful when the most-experienced co-worker was missing for months due to illness.
Unfortunately the idea never truly got off the ground and was abandoned after I quit.
The idea was to to collect the best solutions and strategies for recurring problems or edge cases, background knowledge for new and seasoned employees to understand the reasoning behind specific processes, a link database, form templates and general IT self-help advice.
It was somewhat helpful when the most-experienced co-worker was missing for months due to illness.
Unfortunately the idea never truly got off the ground and was abandoned after I quit.
Create internal blogs and videos. Keep them for internal use. Upload content on Youtube but keep it private or on your own server. This way you will have both depth and breath of your teams knowledge put in one place. Google does this.
Any tips/advice welcome