How can I get new colleagues to learn and understand business processes and technical details faster?

Question

I'm working on a project that's very stressful and has high attrition rates. One of my client's main pain points is that the people working with them don't know their requirements and proprietary details to the level they'd like. In essence they don't understand the client's business processes or some the technical details of their set-up. It's important that they internalize business processes and documentation so that they can hold their own in process discussions. They should also do this quickly and efficiently so the more experienced people don't have to answer the same questions over and over again.

How can I get new colleagues to commit more details and processes to memory while minimising impact on experienced staff? Should I ask them to write stuff down and review their notes instead of consulting colleagues? How can I get them to take away more from meetings and training sessions than they are now? I'm considering also out-of-the-box suggestions such as making a set of flashcards and keeping it in the office to use like trivia.

Answer 1

It's simple really.

Put a process in place that demands that projects are only worked on if there's a signed off requirements document. Whoever adds to that document during the project initiation phase also makes sure that whatever they put into it doesn't conflict with anything else.

Anyone working on the project after sign-off then tags each work item with the requirement step number.

Just working from memory and ad-hoc meetings is just going to end in chaos.

You really need some decent project management processes, but starting and sticking with a requirements/design document is a decent first base.

Answer 2

I would look at this from a slightly different angle:

It is rare (and a somewhat unrealistic expectation) to be able to drop new people into a complex project and have them be really productive in less then 6 months or so. Depending on your staff burnout rate you may do very much better to address the turnover issue rather then (or in addition to) the training one.

Why are you burning people out? Fix the attrition and most of this pain will go away.

High attrition is usually some combination of unrealistic expectations, hiring the wrong people, poor pay and benefits (Actually this is the least common driver), or poor project management and leadership. There is a certain truth that people join companies but leave bosses.

Now training, you need to get your subject matter experts to write documentation, and to explain why not just what when it comes to process issues. FAQs, some sort of intranet site for the documentation (Make it searchable and have an index!), do departmental (and interdepartmental) "Lunch and learn" sessions (We order in pizza, but whatever works).

Answer 3

First thing we do is establish a wiki for all the process details. Anytime someone puts in their notice, they have to to make sure the wiki is completely up-to-date on all of their responsibilities and to train someone currently in the office on those things before they leave. That person trains the replacement when he or she is hired and handles the responsibilities until the hire takes place. Now the new people have a place to go to understand the processes. They have a place to go review before a meeting, to be sure they understand what this area is about.

One of the biggest problems we used to have is that new software developers (especially contractors) didn't understand the business processes or why they were important. So we set up a training session specifically for that. We also ask them about the business processes in their current job when hiring to help identify people who are used to understanding the the meaning behind what they do. These people are more likely to care about getting up-to-speed on such things.

I have a training sessions specifically on data meaning that shows them why it is important to understand what the business is using the data for and why it is critical to understand the complexities of our database as it relates to the business. After they work through a few examples, they are much better prepared to understand that you can't just know how to use an ORM or a write SQL code, you have to understand what the results of queries mean. After all I can write a ton of different queries on the same set of tables and have the business meaning be totally different.

You can also ask the client to spell out specifically which things they feel that new people need to know to come up to speed quickly. Their list may be very different from what you would do for initial training. It could also help to have the business users of the software, produce a video where they go through different sections of the application and talk about what they do in that section and why they do it. We did a session like that shortly after I was hired and it made so many things and programming choices much more clear to me.

A key part of this is having your own management care about processes, requirements and business rules and modeling that behavior by explaining them as they go with new people, by asking them questions about those things when planning a new module, etc. You get what you expect and if you don't expect people to learn the business as well as the technical programming side, they won't. Every meeting that does not contain the client should also talk about these things. New people need to understand that they are important. In technical meetings, you should be looking for holes in requirements and then passing those questions up to the client to resolve (not make assumptions about what they want!!!!!) Any organization that cares about business rules and requirements pushes a very large portion of initial requirements back for clarification. If QA and the dev disagree about what a requirement says, it gets pushed back up for clarification, if the dev has a question about what to do in this situation not covered (requirements often only cover one decision side of a decision tree), then it gets pushed back. Devs will be less likely to pretend they are clear on the requirements when they see senior people pushing them back for clarification.

Code reviews should also look at requirements to see if the code meets the requirements. QA should base their tests on the requirements.

Answer 4

Snow's answer is great - and he's right on the money about getting a robust process in place around establishing requirements being really key.

I'd like to add however that in the more general sense of getting people to record the contents of meetings I think a good approach would be to get your colleagues to see this as something that causes a problem for them, point out that simply remembering the events and discussions of a meeting not only isn't working but also leaves them wide open to some "convenient" reinterpretation of memories and events by a client. Say your client swears blind that one of the team promised they could have Really-Time-Consuming-Feature A and they could have it yesterday - how would they prove otherwise? That sort of thing.

Once you have them seeing this as a problem that will benefit them to solve you'll probably find that they get a lot more proactive and enthusiastic about finding those solutions and implementing them.

Speaking of which here's some suggestions:

1. Nominate someone to take notes

There is a reason that meeting minutes are such a cliche - they really do work. Having someone take brief notes on everything of import that was discussed in the meeting gives you a clear record. This not being the 1950s (thank god!) where everyone could just get someone from the secretarial pool to sit there and scribble away means that generally this falls to one of the meeting participants to do. The responsibility can be rotated around the various team members from meeting to meeting to ensure that no-one feels unfairly burdened.

2. Record the meeting

Most smartphones will either have a built in recording app or one can easily be obtained from the relevant app store. While not as convenient as written notes a recording ensures that nothing gets missed and other than hitting a couple of buttons to start and stop the recording at the beginning and end of the meeting it places no additional work load on anyone during the meeting. Obviously depending upon your jurisdiction you may have to meet certain consent thresholds in order to be able to record a conversation but that's outside the scope of what Workplace SE can cover.

Answer 5

Several answers have suggested writing up some documentation, which is a good idea, but I'd like to propose a slight twist to that. Next time you have a new developer¹ (or group of relatively new developers) come in to the project, have them write the documentation with regular reviews from those who well understand the business processes, technical details, and so on. This will both greatly speed the learning of those particular new developers (a good way to learn something is to try to teach it) and ideally also generate documentation better suited for new developers because those developers will have recent, personal understanding of exactly what they had to learn.

I've found that in general, writing up and organising my own notes on something I'm learning helps a lot, so long as I'm putting the notes in my own words, rather than just copying from somewhere. This is something you might be able to encourage in your new developers, though good note-taking is not a skill that everybody has.

For those people who are more visual (and sometimes even for those who are not), diagrams are also helpful. I expect anybody who's been in my team for a little while to be able to walk up to a whiteboard and draw an overall diagram of whatever system (business or technical) that we're working on, showing what's connected to what, where the information flows, and so on. Having newer developers do the drawing at your internal meetings (with the more experienced developers correcting them) would probably also be helpful.

---

_{¹ I use the term "developers" here for whomever is working on the project; they need not be technical people. Someone developing business processes for a business would be considered a "developer" too, in this context.}