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.

  • 1
    Can you be more clear on exactly what knowledge is expected and why it's missing? Are they literally referring to "requirements" in an official sense (ie, referencing a requirements document that was signed on the beginning of the project)? Do they mean literal "requirements" but there never was an official document? Or is the expectation that staff would be more aware of the overall culture and foundations of the project - knowledge of business processes, responsibilities of different parties, who owns things, etc.?
    – dwizum
    Commented Mar 22, 2018 at 13:55
  • 1
    So would it be fair to re-phrase your question as, "how do I get my colleagues to learn business processes" instead of, "how do I get my colleagues to write stuff down?" Important distinction - people learn in different ways, writing things down isn't always a good way for people to actually understand or learn something.
    – dwizum
    Commented Mar 26, 2018 at 13:21
  • 2
    Ok - so really you're asking, "How do I onboard new technical staff and get them up to speed on business processes and technical details?" With a footnote of, "the few experienced people I do have are sick of explaining this over and over!"
    – dwizum
    Commented Mar 26, 2018 at 14:30
  • 1
    @Lilienthal The first option. I'd like them to internalize business processes and documentation so that they can hold their own in process discussions. Commented Apr 2, 2018 at 4:21
  • 1
    @HardWorker Thanks for the feedback. I've updated your question significantly to focus on that first option and used some of the language from both your and others' comments to identify the core question. Please edit it further if I missed anything or changed too much. Despite the difficult subject I also think it makes sense to get a more canonical answer here so since your bounty auto-expired I've started one myself.
    – Lilienthal
    Commented Apr 2, 2018 at 12:36

5 Answers 5


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.

  • 2
    It sounds like you also need a project manager. These are not a bad thing and often are necessary as projects become larger and more complex. They will be the person that meets with the client and knows their requirements. They should have the authority to set schedules and priorities for the development team as well. In agile this role is known as the product owner. Commented Mar 23, 2018 at 15:15
  • Agreed. But starting with a requirements/technical design document is at least a start.
    – user44108
    Commented Mar 23, 2018 at 15:18
  • I see the point of there being a product owner for this project. Sadly we've no such one person and it maybe makes sense to spread the knowledge among more people, given our attrition rates. There are technical documents but because they're split into modules the interdependencies are not obvious and are hard to understand. Commented Mar 25, 2018 at 14:33
  • 1
    So why can't you document the dependencies as a section of your requirements/technical documentation and then collate these dependencies into a "dependencies" document as and when they're documented?
    – user44108
    Commented Mar 26, 2018 at 10:26
  • 1
    @Snow Good suggestion! We're actually doing that as of a few days ago :) Commented Mar 26, 2018 at 14:08

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).

  • "and have them be really productive in less then 6 months or so" That applies more to new hires joining a company rather than a client/project team who need to generate value almost immediately. I assume the OP is talking about onboarding time for client-specific info and not about new hires. Though I'm not actually sure so I'll leave a comment up above as well.
    – Lilienthal
    Commented Apr 2, 2018 at 20:30
  • 1
    @Lilienthal I have yet to be convinced that it generally makes more then about a factor of two or three difference which sort of "onboarding" (Dreadful abuse of English!) you are doing. What does help is trying very hard to find people with task domain knowledge going in, task domain knowledge trumps an intimate knowledge of particular tools and frameworks nearly every time (There are a few exceptions to this, but that is the way to bet). But I still say the real (and frankly the humane) answer is to fix the burnout problem.
    – Dan Mills
    Commented Apr 2, 2018 at 21:41
  • Well "onboarding" is now a commonly accepted word and a rather important one in a consulting environment, which the OP is in. Quickly adopting clients terminology, processes and standards is an essential skill for client-facing consultants who constantly move between clients. Improving retention will help but won't solve the problem of getting people up to speed with a new client environment.
    – Lilienthal
    Commented Apr 3, 2018 at 10:41

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.


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.

  1. 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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .