Right way to note down necessary information during online meetings ?

[Satyaprakash Joshii]

During online meetings, when someone explains details about work on how some work needs to be done , I note down any necessary information (which I would require to refer while working )using pen on a copy.This has to be done rapidly becuase of the speed at which someone would be speaking. Sometimes I cannot note down so fast and sometimes to write so fast ,the handwriting becomes so bad that even I cannot understand later that what had I written. Another way I note sometimes is, by typing on a small notepad window.(notepad++ opens up on full size window so notepad is more useful here ). But again one had to be very fast. What is the right way for noting information which one would have to refer later on to ensure that it is noted somewhere and one doesn't miss it ?

[fred rosenberger]

Is it possible to record the meetings, so you can go back later and review what was said?  There may be legal issues to consider as well as technical ones, so check your company policies.

[Junilu Lacar]

What's wrong with saying "I'm taking some notes and I want to make sure I captured some of these thoughts correctly. So you said ... " then read back what you think your notes say and ask "Did I capture that correctly? Did I miss anything?"

Communication is a two-way street. If you feel like you have to get everything down the first time someone says it and focus on writing down what they're saying as they say it, then you've probably already lost some of the signal. Pausing the conversation to reflect what you received to sure you understood correctly is the only sensible thing to do, in my opinion.

[Campbell Ritchie]

If anybody is producing so much information, ask them for a copy of their notes. They should actually circulate such notes in advance.

[Paul Clapham]

Agreed. If there's so much key information that you can't keep up with writing it down, you should ask the speaker to provide a written version.

[Tim Holloway]

Fast or slow, my writing is pretty much unreadable. Although I did have some success back in my Palm Pilot days using Grafitti - I could actually Grafitti faster than I can type.

So I tend to use things like sticky-notes apps (Gnote/Tombody Notes) which are great for small snippets in tiny windows (and can be collected, organized and hyperlinked).

More serious stuff I keep in Joplin, which is similar to Evernote. I have my own DAV server so notes sync between desk, phone and tablet and I don't have to entrust them to an alien Cloud database. I also keep my grocery list then and use my Android Share feature on my mobile devices to grab URLs from interesting websites that pop up in my newsfeeds.

You might also consider making audio recordings, although audio can be hard to "read" too - plus some places may have restrictions on audio recording. Then again, depending on the conferencing software, there might even be a built-in text transcription service available from it.

But, As was said earlier, a well-planned meeting would hopefully include handouts, even as an in-person meeting would. And/or a designated secretary to be the recorder of the meeting and the contact point for questions about the meeting.

[Satyaprakash Joshii]

fred rosenberger wrote:Is it possible to record the meetings, so you can go back later and review what was said?  .

Yes for some important meeting.But not practical for each and every meeting. And some may be just adhoc online one to one meeting to discuss on work.

[Satyaprakash Joshii]

Junilu Lacar wrote:What's wrong with saying "I'm taking some notes and I want to make sure I captured some of these thoughts correctly. So you said ... " then read back what you think your notes say and ask "Did I capture that correctly? Did I miss anything?"

Good idea.I will try and implement.This has to happen at a rapid pace.

[Satyaprakash Joshii]

Junilu Lacar wrote:Pausing the conversation to reflect what you received to sure you understood correctly is the only sensible thing to do, in my opinion.

Very good point. And the way to pause is "so what I understood is ....Is that correct "..correct ?

[Satyaprakash Joshii]

Campbell Ritchie wrote: They should actually circulate such notes in advance.

Sometimes adhoc one to one meeting to discuss something on work.

[Les Morgan]

I type into Word.
If the presenter is going too fast, I make them wait and slow down.
I have recorded on occasions where that feature is reliable.
for anything written on a White Board etc... take a picture, it is full detail and much better to read later.

I have 30 years as a programmer... this works, people will slow down to make sure things are accurate.  Don't be afraid to ask questions if you miss something.

[Campbell Ritchie]

Junilu Lacar wrote:. . . "I'm taking some notes . . ." then read back what you think your notes say . . . .

Maybe you should be more assertive and send them the notes by email immediately after the meeting.

You've got so much to say I have to take notes and I shall send you them afterwareds to check I haven't missed anything.

Persuade everybody it is quicker to send notes out beforehand.

[Junilu Lacar]

Campbell Ritchie wrote:Maybe you should be more assertive and send them the notes by email immediately after the meeting.

I don't see how assertiveness has anything to do with this vs asking for feedback in the moment. If anything, sending notes after the meeting to get feedback is more passive because you've delayed the feedback rather than asked for it in the moment. What's passive about asking to pause the conversation for a second to make sure you've understood a point correctly? This is also in line with the agile value/principle of fast feedback and face-to-face communication and collaboration.

Persuade everybody it is quicker to send notes out beforehand.

This is not always possible nor is it necessarily quicker or more efficient. When you're discussing a complex topic, things can come up during the discussion that you just can't predict beforehand. Again, in a conversation, you have at least two sides: the sender and the receiver. If you have multiple receivers, then each one of them could potentially add more texture and flavor to the conversation as it progresses. When you delay feedback and make it asynchronous rather than in the moment, you tend to lose some of the context and that's where miscommunication and misunderstanding can creep in.

This is why in Behavior-Driven Development you have requirements workshops or example mapping sessions that require the Three Amigos to be present. In TDD, you have the Driver and Navigator. You can't go into a BDD or TDD session with pre-written notes and expect those to cover everything that's going to be discussed. At best, the notes will serve as a framework for the conversation. Then as new things come up, you write them down. This is sometimes referred to as "Talk and Doc" and having somebody read back what has been noted down to ensure important details have been correctly captured is part of that.

[Satyaprakash Joshii]

Les Morgan wrote:
If the presenter is going too fast, I make them wait and slow down.
I have recorded on occasions where that feature is reliable.
for anything written on a White Board etc... take a picture, it is full detail and much better to read later.

I used notepad ++ often for this and if in online meeting if someone is showing something which I will have to refer later for sure, I take screeshot, paste into mspaint and save.

[Satyaprakash Joshii]

Les Morgan wrote: people will slow down to make sure things are accurate.  Don't be afraid to ask questions if you miss something.

Good advice.

[Satyaprakash Joshii]

Junilu Lacar wrote:[What's passive about asking to pause the conversation for a second to make sure you've understood a point correctly? This is also in line with the agile value/principle of fast feedback and face-to-face communication and collaboration..

I will read about this agile principle of fast feedback and face to face communication and collaboration.

[Tim Holloway]

You know, a one-on-one meeting shouldn't(Your Mileage May Vary)  have some of these issues.

In a multi-member meeting, asking people to slow down or asking questions can bog down a meeting. But one-one-one, that's not really an issue.

There are a couple of exceptions, of course. When the other one is a "busy person" and cannot be persuaded to let you stop and capture the details. Best case is to get them to promise to send details later. Worst case is you're being railroaded and at that point, it's probably time to dust off the old CV.

Or you could be one of those people who simply "asks too many questions". Sometimes its worthwhile to simply capture what you can and go back for clarifications rather than attempt to get a perfect picture on the spot (which is counter to Agile's adaptive convepts anyway). Often, once the other person has outlined what they want, they'll realize details of their own after explaining, which can be passed on next time.

[Junilu Lacar]

This is the context that framed OP's question:

Satyaprakash Joshii wrote:During online meetings, when someone explains details about work on how some work needs to be done

Here are the assumptions I made based on that framing:

1. This is complex work that can't just be written down as a procedure to be followed. If it could be written down as a procedure to follow, then why have a meeting about it?

2. The "someone" who explains the details of the complex work is a subject matter expert (SME) and the listener taking notes is a developer, presumably OP. There might be other listeners who are coming from other perspectives, like a tester maybe or someone from operations. Each different perspective will take something different away from the meeting. In other words, because it's complex work, it's also a complex conversation.

3. This is a "discovery" type meeting where the listeners are trying to explore the requirements of the work. They will have some questions come up as they learn new things. These are questions they wouldn't have known to ask before getting into the conversation in the first place.

To Tim's point, I have seen these kinds discussions get bogged down, too, and the thing you want to do there is to have a facilitator for the conversation and clear goals for what you want to get out of the meeting. If you can't or don't have someone to facilitate, then you have to self-facilitate and clearly define the level of detail for the conversation that you want so you can stay focused on achieving the meeting goal(s). Any time you start digging deeper than the agreed-upon level of detail, you should catch yourself and make a quick note to delve into that later, perhaps with the same SME or someone else with whom it is more appropriate to discuss at that level of detail.

Alistair Cockburn uses an altitude metaphor to define three levels of detail for use cases, which can also be applied to this type of conversation: High-level summary detail (represented by a kite); sea-level functional detail (waves), and subtask detail (fish). The functional, sea-level detail is where you describe work at the level of detail of tasks you'd expect to complete before intentionally stopping to do something else. Things like brush your teeth or eat breakfast or take a shower. The kite or high-level framing for these tasks might be something like Get ready for work. The sub-task or fish level of detail might be put toothpaste on toothbrush, brush front of teeth, brush back of teeth, rinse, gargle with mouthwash.

Just as we write code and try to keep methods at a single level of abstraction, you would also want to follow a similar principle for your conversations with SMEs.

[Junilu Lacar]

Tim Holloway wrote:When the other one is a "busy person" and cannot be persuaded to let you stop and capture the details. Best case is to get them to promise to send details later. Worst case is you're being railroaded and at that point, it's probably time to dust off the old CV.

This is a whole 'nother spin on the original question. The assumption I'm making is that the people in the meeting have come with positive intent to communicate and get on the same page about some piece of complex work that they're trying to understand well enough to be able to start writing software related to that work.

[Junilu Lacar]

This thread itself is a good example of the kind of rabbit holes that you can start falling into when having a non-facilitated and non-focused conversation.

To keep things on track, you have to frame the conversation to define what's in and what's out of context. What I did in the last two replies I posted was define that framing and called out something that fell outside of those boundaries.

[Tim Holloway]

Junilu Lacar wrote:

Tim Holloway wrote:When the other one is a "busy person" and cannot be persuaded to let you stop and capture the details. Best case is to get them to promise to send details later. Worst case is you're being railroaded and at that point, it's probably time to dust off the old CV.

This is a whole 'nother spin on the original question. The assumption I'm making is that the people in the meeting have come with positive intent to communicate and get on the same page about some piece of complex work that they're trying to understand well enough to be able to start writing software related to that work.

Satyaprakash Joshii wrote:And some may be just adhoc online one to one meeting to discuss on work.

I.e., the equivalent of meeting in the hallway.

The original question does give the feel of a multi-person meeting, yes, but based on Satyaprakash's later comments, I had to wonder if that was the main case truly in question.

[Satyaprakash Joshii]

Junilu Lacar wrote:can't just be written down as a procedure to be followed. If it could be written down as a procedure to follow, then why have a meeting about it?

Procedure can be written down but on high level. It would not have some specific detail required during implementation.

I am talking more about adhoc one to one meetings.E.g just pinging on chat and calling for a random discussion on work on skype  or adding third person dynamically in the meeting for few minutes for some discussion , than the meetings fixed in advance.

[Satyaprakash Joshii]

Junilu Lacar wrote:
Just as we write code and try to keep methods at a single level of abstraction, you would also want to follow a similar principle for your conversations with SMEs.

What does keeping methods at single level of abstraction mean ?

[Junilu Lacar]

Here are some examples of refactoring a method so it has a single level of abstraction:
https://industriallogic.com/papers/ComposeMethod.pdf
https://www.informit.com/articles/article.aspx?p=1398607

And more about SLAP (single level of abstraction principle) from Bob Martin: https://8thlight.com/blog/javier-garc%C3%ADa/2019/06/11/refactoring-levels-of-abstraction.html

Essentially, getting a single level of abstraction makes the code focused on intent rather than implementation. With respect to the conversations you're having with an SME, you want to make sure you're clear on intent first (high-level summary and functional levels) before delving into subtask details (the fish-eye view). This is how you can iteratively refine your understanding of the work.

It's not necessarily a top-down approach because sometimes you have to go into details and talk about specific examples before you can start seeing patterns that allow you to generalize the "rules" for behavior in the application. Starting with a good high-level picture does help frame the context for lower-level detail discussions so that's where I generally like to start and then once you get the ball rolling, be fine with going back and forth between top-down and bottom-up.

[Junilu Lacar]

There are multiple ways you can capture reminders for conversations you have with SMEs. Sometimes you want to draw out pictures and flow charts. Sometimes sticky notes on a wall are a good way to capture ideas not only as text but also show temporal/sequential relationships as well as other kinds of relationships like maybe architectural or functional relationships.

There are a number of online tools like Miro and Mural that you can use to facilitate conversations with SMEs so you can add other dimensions to whatever it is you're trying to capture.

Look into the practices of BDD example mapping and User Story Mapping for ideas on how you can enrich and capture important ideas coming out of your conversations.

[Junilu Lacar]

Satyaprakash Joshii wrote:I am talking more about adhoc one to one meetings.E.g just pinging on chat and calling for a random discussion on work on skype  or adding third person dynamically in the meeting for few minutes for some discussion , than the meetings fixed in advance.

Thanks for that clarification.

So everything I've shared so far still applies:
1. Be sure you're clear on what your goal is for the conversation and frame it up front: level of detail you need, what is in context and what is out of context.
2. Keep the conversation within the agreed-upon context. Note down anything outside of that context for follow-up discussions.
3. Don't be afraid to pause conversation to restate your understanding so far to make sure you've understood it correctly and didn't miss or misinterpret any detail.
4. Use whatever tools are available that can facilitate capturing and clarifying the information you need. Anything that helps you visualize the ideas and represent other dimensions like sequencing, grouping, dependencies, etc. is good. Purely textual forms of documentation can limit the richness and depth of understanding that you can capture from a conversation.

[Junilu Lacar]

To the point of being "too busy" to pause and reflect on the understanding so far, I think that's a very short-sighted view of efficiency. When you develop software, the more solid your understanding is of the requirements, the less likely you are to introduce bugs into the code/design. The fewer bugs you have and the higher the quality of the code/design, the less time you're likely to spend later on chasing down defects and dealing with problems in production.

So whenever someone says "We don't have time for that" where "that" is making sure we have a good understanding of the work to be done, it makes me think "Ok, but you have all the time later to wake up in the middle of the night and spend your weekends doing production support?" Because that's usually what happens when you don't pay attention to details when you're doing development.

[Satyaprakash Joshii]

Junilu Lacar wrote:The "someone" who explains the details of the complex work is a subject matter expert (SME) and the listener taking notes is a developer, .

I am talking about the adhoc meeting usually between developer and his team leader.

[Satyaprakash Joshii]

Junilu Lacar wrote:
Essentially, getting a single level of abstraction makes the code focused on intent rather than implementation. With respect to the conversations you're having with an SME, you want to make sure you're clear on intent first (high-level summary and functional levels) before delving into subtask details (the fish-eye view). This is how you can iteratively refine your understanding of the work.

Is the disadvantage of not maintaining single level of abstraction in coding or communication that it would lead to confusions ?

[Satyaprakash Joshii]

If during such meetings, at rapid pace one understands and remembers then one may not even have to write. I write sometimes thinking that I can understand this after analyzing slowly later on, and not at pace of the meeting , so write down now and analyze later slowly.

[Campbell Ritchie]

Does that mean you are risking writing an inaccurate version of what was said? That is going to do more harm than good. And as Junilu told you, that can mean very much harm.

[Junilu Lacar]

Satyaprakash Joshii wrote:If during such meetings, at rapid pace one understands and remembers then one may not even have to write. I write sometimes thinking that I can understand this after analyzing slowly later on, and not at pace of the meeting , so write down now and analyze later slowly.

Maybe it's just me but I get a distinct sense of some kind of fear in your line thinking: a fear of looking inattentive or worse, stupid. There's absolutely NOTHING wrong with asking the other person to check your understanding. Even if you let them talk it all through first, then ask them to listen to what you are taking away, it's still better than looking like you got everything and then it turns out you didn't because you missed something or misunderstood it and that shows up in the work that you did. You look far more inattentive or stupid when that happens. Don't be afraid to ask for feedback in the moment!

[Junilu Lacar]

Satyaprakash Joshii wrote:Is the disadvantage of not maintaining single level of abstraction in coding or communication that it would lead to confusions ?

In code, yes. Mixing levels of abstraction in one method adds to its cognitive weight, the amount of mental effort it takes to understand the code's intent. Same principle applies to conversations because of the shifting context. If you keep your conversation at a single level of detail, your brain can stay more focused at that single level of detail. Conversations tend to be more fluid though and can quickly move back and forth through different levels of detail. Imagine a conversation about what happens when a person is getting ready for work and the description goes something like this:

Well, first I get out of bed, put my slippers on, I fluff the pillow, smooth out the bedsheet, fold the blanket, put it on top of the pillow, then I walk to the bathroom, I pick up the toothbrush, put toothpaste on it, turn on the faucet, wet the toothbrush, put the toothbrush in my mouth, move my hand up and down, then I brush the front teeth, then the left side, then the right side, then I brush the back of my front teeth, the back of my left side, the back of my right side, then I spit in the sink, turn on the water, then I pick up the glass, fill it with water, ..., then I have breakfast, take a shower, get dressed, get in the car, put the key in the engine, turn the key, put the car in reverse, back out of the garage, click the button on the garage door remote, wait until the garage door is fully closed, back out into the street, then I drive to work.

This an an extreme (and silly) example of bouncing around between different levels of detail. It's easy to see where that shift happens in the above example but in real-world conversations about work, it isn't as easy to discern when things are shifting into a different level of detail because you're unfamiliar with the work. We're all familiar with the process of getting ready for work in the morning which is why we can discern when the example is getting into too much detail when trying to answer the question "How do you get ready for work in the morning?"

[Junilu Lacar]

Junilu Lacar wrote:

Satyaprakash Joshii wrote:Is the disadvantage of not maintaining single level of abstraction in coding or communication that it would lead to confusions ?

Well, first I get out of bed, put my slippers on, I fluff the pillow, smooth out the bedsheet, fold the blanket, put it on top of the pillow, then I walk to the bathroom, I pick up the toothbrush, put toothpaste on it, turn on the faucet, wet the toothbrush, put the toothbrush in my mouth, move my hand up and down, then I brush the front teeth, then the left side, then the right side, then I brush the back of my front teeth, the back of my left side, the back of my right side, then I spit in the sink, turn on the water, then I pick up the glass, fill it with water, ..., then I have breakfast, take a shower, get dressed, get in the car, put the key in the engine, turn the key, put the car in reverse, back out of the garage, click the button on the garage door remote, wait until the garage door is fully closed, back out into the street, then I drive to work.

... when trying to answer the question "How do you get ready for work in the morning?"

A single (sane) level of detail for the above example description would be:

I make my bed, have breakfast, brush my teeth, shave, take a shower, get dressed, gather up my stuff, and head on out.

The steps are all given at the sea-level or functional level of detail. If you want to dig into some particular task, you'd ask questions that frame the context and set the level of detail you're looking for, like "How do you usually get dressed, do you put your pants on first or your shirt?" or "How do you put your trousers on, left leg first or right leg? Or both legs at the same time?" This is what Cockburn calls the "fish level" or subtask level of detail.

Do you see how it helps keep you more focused?

[Satyaprakash Joshii]

Junilu Lacar wrote:
Do you see how it helps keep you more focused?

Yes. Maintaning single level of abstraction is simpler and the right approach. Switching level of abstractions makes it difficult to understand.

[Satyaprakash Joshii]

Junilu Lacar wrote: Don't be afraid to ask for feedback in the moment!

Sometimes, what happens is when something is explained during a meeting and is very simple , I understand it at the moment itself.

Often, what happens is when something is explained during a meeting and it not very simple, it requires me more time to rethink and analyze to understand it.I do happen to understand it but later on when I can give it more time then doing it quickly during the meeting itself.

E.g one can't say during the meeting that what you explained now let me think and analyze for 5-10 minutes meanwhile you pause.

That's what is frequently happening. I can be more attentive, ask more questions to understand, confirm my understanding but often things for me take 5-10 minute of analysis to understand than at the moment itself.

[Satyaprakash Joshii]

Junilu Lacar wrote:[ There's absolutely NOTHING wrong with asking the other person to check your understanding. Even if you let them talk it all through first, then ask them to listen to what you are taking away, it's still better than looking like you got everything and then it turns out you didn't because you missed something or misunderstood it and that shows up in the work that you did. You look far more inattentive or stupid when that happens.

That is absolutely correct.I will try and follow this.

Just that one problem is that mostly it takes me few minutes of time to analyse and build some understanding (out of what someone explains) which I can use to confirm with the other person.

During the meeting building some understanding and telling it to the other person that this is my understanding , this has to be reasonably quick (because the other person would not pause for 5 minutes to let me think analyse and build some understanding then tell my understanding to him to confirm)

[Junilu Lacar]

Satyaprakash Joshii wrote:During the meeting building some understanding and telling it to the other person that this is my understanding , this has to be reasonably quick (because the other person would not pause for 5 minutes to let me think analyse and build some understanding then tell my understanding to him to confirm)

I think you're just creating problems for yourself in your head. Yes, it would be silly for you to say "Give me a few minutes while I analyze and digest this, can you wait so I can get feedback?" I don't know who would ever do this, on either side of the conversation.

Again, to me, it sounds like you're afraid of looking stupid. There's nothing wrong with not getting it right the first time or even the second time someone explains something complex to you. The whole point of getting feedback is to make sure you don't walk away with any wrong ideas. If, in the course of explaining what you understood, the other person says, "No, that's not right," you should be happy, not embarrassed. That means the feedback process is working and that you identified something you didn't fully understand before it could work its way into code as a bug!

So, you have this:

Other person: "blah, blah, blah, blah"

You: "Ok, this what I understood... explain in your own words what you think the other person said"

Other person: "No, that's not right... explains again"

NO -- You: (embarrassed and feel stupid)
YES -- You: "Great! Thank you for that clarification."

NO -- You: goes away as if you got everything
YES -- You: Thanks again for your input. This was a lot to take in so I might have to get your input again on other details. Can I ping you once I've fully digested and analyzed the implications of this new information? I want to make sure I understand this correctly.

The latter parts (the parts marked with YES) demonstrate emotional intelligence rather than an admission of incompetence or stupidity. Sometimes to avoid looking stupid, you have to risk being honest and less than perfect (because none of us are perfect, of course).

[Junilu Lacar]

I wrote:
You: "Ok, this what I understood... explain in your own words what you think the other person said"

If you skip this part because you're pressed for time or the other person has to run, the last part is definitely something you should say.

YES -- You: Thanks again for your input. This was a lot to take in so I might have to ask for your input again later on about some of these details. Can I ping you once I've fully digested and analyzed this new information? I want to make sure I get it right.

The one thing I would do is write executable tests (doing TDD) and some skeleton code that reflects my understanding and could be demonstrated for feedback purposes. That way you don't get into a long analysis paralysis but are actually using working software to get feedback and make adjustments as you iterate and build out your application.

[Satyaprakash Joshii]

Junilu Lacar wrote:You: Thanks again for your input. This was a lot to take in so I might have to get your input again on other details. Can I ping you once I've fully digested and analyzed the implications of this new information? I want to make sure I understand this correctly.

This one seems the most important step for me. I will focus and start doing this.