Feeder and feedee: project onboarding

I've recently switched from being the longest standing person on one project to being the newest on another project.

Thusly I've witnessed  both blank stares from people trying to take in a way to large information dump on them. And I've participated in estimation rounds where I was staring blankly into the void for not getting anything being discussed.

The problem

The thing rarely spoken is of course the huge knowledge gap between newcomers and old-timers. Umpteen years of domain knowledge will play out in estimation sessions (and pretty much any other session).

This is what Fred Brooks talked about in the mythical man month. Newcomers will slow down the project. But having been on both sides I think that there are more effective ways of onboarding someone.

Map and feeder analogies

A new person(s) arrives to the project. From hereon named the onboardee since i like words with to ee:s in them. If  we assume that the onboardee fills all requirements: knows the lanugage and techniques du jour, speaks agile, lean and kanban - the map of the application and domain would look something like when starting out in an RPG (think old warcraft):

The onboarder and the onbardees job is to as efficiently try to both heighten the contrast of the map and also create well chosen new spots of clear sight.

These are fine and quite obvious words, but how do you actually do that whilst keeping the onboarder and the onboardee as productive as possible? Because we need the onboardee getting more and more of the big picture to both keep the onboarder actually producing things and also not inadvertently screw things up.

Well in order to get fat on that knowledge you need a feeder and a feedee (2 ee:s, ermaghaad!). If you are going to get big and chubby fast someone needs to direct the feeding and someone needs to eat - and feedback. ee.

It's going to take time

The boring disclaimer: there is no silver bullet. No-one gets fat overnight. No one gets ripped overnight (or in X weeks despite the PT:s hating).

Your brain needs time, sleep and doing dishes (letting your mind wander) to physically store and build memory traces. There is no way around this and in fact - all of the methods below are designed explicitly to let the brain absorb a reasonable amount of information and build memory traces of that information. 

With that upper bound there are still better or worse ways on how to utilize those memory traces given at each day. Memory and understanding builds much faster if you can relate things to already known things.

Or in essence: chunking a subject with help.

Onboarder: the tourist tour

The most serious mistake both parties is akin to trying to go off the deep end - dive into too much details. At the outset we need to go from general to carefully selected detailed knowledge. Going the other direction the details will just confuse and possibly contradict unless the whole map is known.

Enter the tourist tour.

It's a 10-15 minute long session done once or twice per week by the feeder for the feedee(s) where the feeder shows the tourist attractions = main landmarks of the application. How would a typical user interact with the application? It there a main flow? What problem does it solve? Akin to how you would present a user manual for a new prospect.

Make this session very very informal. No meeting rooms, no booked agendas - simply gather around someones screen. This will dampen the stupid "stupid questions factor" where the onboardee will act like they understand because of fear of looking dumb.

Also: try to make the session interactive by asking queststions to the onboardee. Did you get that? What did this do? Have the onboardee repeat back in their own words what you just said. Sweet memory-traces here we come!!

The key is to feed more general knowledge about the domain the application lives in and the application itself that the onboardee can then latch onto the detailed small islands where the work must begin.

The onboarder is responsible for trying to serve knowledge in the most useful and efficient way. This means thinking through what are irrelevant details (for now) and what are the general gist of a domain and application. Things have to make sense with only the knowledge presented and up till now known.

It's good if the onboarder has some self-insight (or can spend some moments self ransacking) trying to think back on what themselves did not know coming to the project.

Dreyfus model

If you've read the fabulous book Refactoring your wetware by Andy Hunt of pragmatic programmer fame you are probably familiar with the Dreyfus model. If  not - it basically states that you as you progress from novice to expert you progress from relying heavily on guidance and rigid rules to a more holistic and intuitive approach. The key asset for progressing is deep knowledge and understanding of whatever you're working in.

This model will dictate how an onboardee can most efficiently can contribute to the project. And what you need to do to get from novice to the next stage.

The onboardees work will be with very isolated small tasks that require minimal overall knowledge and can be rigidly specified. Think of them as small isolated islands in your overall map. Uncovering an area is very costly at first so if an area has been uncovered the payoff is naturally highest if the task is centered there (and only there) in that area.

The problem is that it's very easy to get stuck in this mode and never achieve general knowledge. It's also comfortable for the onboarder as they get to not waste time on the onboardee.

On top of that it's the place where self-deception lives. The onboarder thinks the onboardee gets it (forgetting the years of implicit knowledge acquired themselves). The onboardee is just happy to be contributing and will smile and nod when details fly all around - because the onboardee thinks that it will probably make sense sometime later. Or plain just zones out because there is too much to take in.

Onboardee: world building sessions

Now, these skills won't accumulate by themselves. Or rather - they will. But it can be sped up dramatically if the onboardee is willing to put some effort into it.

Between the onboarding sessions the onboardee must take regular breaks (2 or 3 times a day at first) and spend some minutes actively connecting whatever you are working on with the rest of the world.

Recall from memory what was said at the last onboarding session and write down questions for the next session. Accumulate feedback for the onboarder to act upon - the onboarder cannot after the initial sessions keep track of what the onboardee do and do not know.

Feedback that information so that the onboarder can make calls on wether explaining a new area will pay off right now - or if it's irrelevant to the big picture understanding.

Estimates and planning

I include estimates since they happen in the epicenter of the knowledge gap. Often touted as knowledge transfer sessions but since this requires stern discipline from all parties involved. If they are too long and too detailed they will just end up being sheep dunking. You are working against how the brain builds memory traces - via useful relevant information in small pieces with plenty of time for repentition.

The key to effectiveness is to give the onboardee a reasonable chance to contribute. Two points (and one addendum) needs to be considered.
  1. Notice is given what areas that will be estimated.
  2. The areas of estimation are located close enough to the onboardees current knowledge.
But wait! This sounds like a job for.... the tourist tour! For each area that is up for estimation, schedule a tourist tour of that area and allow at least a day (preferably more) for the information to stick before entering estimation rounds.

The addendum is: Keep estimation rounds short and schedule more if needed.

A wall of information will cause even the most keen brain to discard information. If a thing is going to stick, it has to be favored over something else. Akin to starting to speak a a second language - the pure fatigue of trying to understand will make the estimation session fruitless after a short period.

Playfüllness für alle

The last thing you want do to is corporatize the onboarding sessions. I thoroughly believe that the best learning happens when the stakes are low and there is ample room for any type of questions. I won't say dumb questions because that's the point.

After a while - mix up the sessions to relieve some pressure from the onboarder. Have the onboardee show off what areas are known at the screen. Or let a new person try to accomplish something during these sessions without giving hints as to how first.

There is ample room for variation - as long as an eye is kept on what we're trying to achieve - a full uncovered map with no blank spots starting with the most obvious landmarks and ending with small obscure details.

Liked this post? No? Then share and rant why: