Five Ways To Make Your Thinking Visible In Engineering Collaboration

Hi, everybody. I'm so happy to see you all here. Also, hi to those of you who are joining me online. My name is Karen Lee. I'm a software engineer currently working for GitHub and today I will be sharing with you five ways to make your thinking visible in engineering collaboration.

Before we get started, let me quickly introduce myself so you know where my perspective is coming from. I have been an engineer for four and a half years and previously I worked for two education technology companies. Before becoming an engineer, I was a fifth grade teacher who taught reading, math, science, and social studies. And a fun fact about myself is that I was a pianist. I've been playing with keyboards all my life. I started off with the black and white ones and now I'm playing with the computer ones.

So let's get back to our topic for today. Ways to make our thinking visible in engineering collaboration. Why do we need that? Let's think for a second. But while you're thinking, I'm going to share with you where did I get this inspiration from? When I was teaching in the classroom, I had to implement a lot of thinking strategies to get my students to think and ask questions. And when I became an engineer, I realized that some of these strategies are also applicable in the engineering workplace as long as I make some tweaks to them. So I decided to create this presentation to share all of them with you.

Back to our question. Why do we need to make our thinking visible? We need to make our thinking visible because thinking is an internal process. It happens in our brains and others cannot see it. But when we are collaborating with others, we want to see those ideas so that we can share and generate even more great ideas. That's why we want to make our thinking visible. The number one thing I learned from teaching on how to do that is to ask facilitative questions. Facilitative questions are the kinds of questions where when you ask somebody, you're showing them that you're not only interested in how and in their answer, but also how they get to it. And this will in turn, encourage them to explain their thinking process. How does that question look like? Well, a very easy way to do it is to start your question with what makes you dot, dot, dot. The three dots represents the action that you wanted to learn more about. So say if you wanted to know why somebody said something, you can ask them what makes you say that. Or if you're reviewing PR and somebody adds a timeout somewhere, you can ask what makes you add a timeout here, etc. Facilitative questions are very helpful when you want to know more about someone's thinking process.

You can use them when you're reviewing PRs, when you want to get clarification on someone's action, or even when you're trying to help other solve problems, you can ask this kind of questions.

Now, what if somebody asks you a facilitative question? How can you make sure that your answer, your thinking is visible in your answer? Introducing the second strategy, include what you see and know. What you see and what you know are invisible to others unless you explicitly mention them. Since thinking is an internal process, we are constantly drawing from this invisible knowledge. If you really want someone to follow your thinking process, they need to see what we see and know what we know in order for that to happen.

Now, how does that look like? Let's look at a scenario. Let's say we are a team that is trying to select a feature flagging provider. There's an engineer in charge that is tasked with researching two companies, company A and company B. This person needs to give a recommendation on which one is better. The engineer in charge says, I'm recommending company A over B for our feature flagging tool. Some team member asks, what made you choose A over B? Notice that's a facilitative question right there. How can engineer A answer this question to review their thinking? Now let me give you a bad example. A is just better. Now, can you really tell why they decided that A is better? Not really, right? So let's try again. We can do better. How about this? I see that A has most of the features we need and a much lower cost. There's also a workaround for the one missing use case. Therefore, I chose A over B. The fact that A has most of the features we need and a lower cost and the fact that also we have a workaround are all the internal knowledge that the engineer is drawing from to get to this conclusion. Others might not be aware of this. That's why when you're explaining a thinking process, you need to include these things that you know and you see. The strategy of including what you see and know is very useful in many situations. Whether or not you're answering questions, you're explaining your thought process, or even if you're giving feedback to others, you can use this strategy.

Now before we move on to the next one, I want to show you a way that we can combine the two strategies that we just learned to supercharge a facilitative question. Now, sometimes if we ask someone a facilitative question, they will explain their thought process, but they may not always include what they saw or knew that led them down a specific path. Instead of asking, what made you do that, we can ask, what did you see, or what did you know that made you do that? By combining the two strategies, we can prompt the other person to include their internal knowledge when they are explaining their thought process. That way, not only do we understand how did they get their answer, but also we learn about the cues that they refer to when they get to that answer. Do we have any junior engineers in the room here? If you're a junior engineer, this is a great question to ask your senior engineers, or really anybody on your team. Because folks on your team who are more advanced have a lot of these cues in their toolbox. They have experience and exposure in the system that they just recognize these patterns.

When you ask these questions, you're not only learning how they get to the answer, but you're also learning the cues that your senior engineers are using. Now we just talked about these two strategies. They work in many different settings, but particularly well when we have one-on-one collaboration.

But obviously, engineering collaboration can also happen in groups. So let's talk about some group-specific strategies. I have two of them for you. The first one is called SAIL, the SAIL framework, which stands for Share, Ask, Ideas, and Learn. And this is how it works. It starts off with the presenter sharing their plan. Then the group can ask questions about the plan. Then the group offers ideas on how to improve. And finally, the presenter will conclude what they've learned and what they might do moving forward.

Now let's look at an example. Say you have a team, an engineer is in charge of a POC. They did the work, and they wanted to share with the team and get some discussions going. The leader will share their findings in a Google Doc, and the team can ask questions about the doc. They might leave some of those questions in the comments, and some discussions can start there. Then the team finds the time to get together and talk about the plan, talk about ideas to improve. And finally, the leader will conclude the meeting with some of the things that they might do moving forward. Now depending on the responses as well as the complexity of your project, this process might have to happen multiple times. You might have to repeat some of the steps, and that is okay. The goal is to make sure that there's some sort of a structure that allows everybody to share their ideas.

When we're implementing the SAIL framework, the first step in the framework is very important. That is because it introduces everyone to the topic so that they can participate in the remaining steps. And most of the time, a plan will be shared in writing. So let's talk about some writing-specific considerations that will set you and everyone on your team for success. When we communicate through writing, we are relying on the reader's reading comprehension ability to interpret our text. Their interpretation of the text comes from making connection between the text and their prior knowledge on the topic. And since everyone's prior knowledge on the topic can differ, their interpretation can also differ. So if we want to make sure that people interpret the text exactly the way we want, we need to think about these three things.

First of all, who's the audience? Knowing who your audience is will help you to decide what words to use. Also, we need to know what topics do you expect the readers to know already before reading your content? And if your document will be read by people from different backgrounds, say in different departments, you might want to include some definitions of key concepts or keywords to make sure that everybody has the same background knowledge and understanding.

Finally, what is the goal and non-goal of the document? The reason why this is important is because readers make connections between the text and what they know on the topic, and their exposure to the topic could come from a variety of experience. When you share with them what your goal and non-goal is, it helps them to set some boundaries around what type of prior knowledge should they be making a connection with the text that you wrote, which will help them to come up with a more accurate understanding of the text.

By sharing the plan in a well-written document in step one, it sets a good foundation for everyone in the group, and this will enable every member to share and engage in the discussions. This framework is useful whenever you have a leader in a group. Discussing POCs is one of them. If you have project management groups, cross-functional collaboration, those are all scenarios where you can use this framework. Sometimes, when we have discussions, we have a leader, but other times we might have discussions where there is no leader. It's kind of like this, where everybody just goes in the same direction, but no leader. How can we make sure that even when we have such a loose process, we can still make everybody's thinking visible?

Introducing the fourth strategy, the leaderless discussion. In a leaderless discussion, we use the team members' questions to guide the discussion. We start off with the team agreeing on a topic, then everyone brings one or two questions into the discussion, and then the team will just go through each of the questions. Sounds very simple. But there are some things to consider. First of all, we want to make sure that everybody gets their chance to ask the question. If you have a big group, you might want to set a time limit on each person's question so that everybody has their chance. Or, if you meet online, some people can post their questions in the chats and have those answered there, so that everyone will still have the opportunity to ask the questions. The second thing to consider is that the kinds of questions you can ask are largely dependent on what is your prior knowledge on the topic.

So, if you're a junior engineer, you might be asking more factual questions because you don't know much about the topic, whereas if you're a senior engineer, you might be asking something about the pros and cons of two solutions. If we want to make sure that everyone can engage in the deeper discussions, consider these modifications. First of all, have everybody pre-submit their questions to the document. Then at the start of the meeting, go through all the questions together and identify the ones that provide background information and get those answered first. When we do that, it helps to get everybody on the same page on the topic, and then when we get to the deeper discussions, it encourages everybody in the group to participate.

The steps in the leaderless discussion gives us some guidelines to follow so that even if you don't have a leader leading the process, everybody still has their opportunity to share. Obviously, we can use it in brainstorming, or even if you're working on, say, open source projects or hackathon where everybody just bands together and works on something, you can try this strategy as well.

Now, I have one more strategy to share with you. That has to do with giving and receiving feedback. This can be a little bit sensitive, especially if the person receiving the feedback feels attacked. So how can we make sure that the feedback receiver does not feel that way and can truly benefit from what you're sharing with them? Introducing the ladder of feedback. The ladder of feedback is a five-step process developed by the researchers at Harvard Graduate School of Education, and this is how it works. We start with step one, clarify. You make an effort to understand the work and ask clarifying questions if needed. Step two, value. You acknowledge the good things you see in their work, and you call them out. Step three, questions and concerns. You raise questions and concerns you have about their work. Step four, suggest. This is the last step for the feedback provider. You give suggestion to the feedback partner to let them know how they can improve. And finally, step five, think. As the feedback receiver, you showed gratitude to the feedback provider and share what you have learned. Let's look at an example. Let's say an engineer comes to you and wants you to review their PR. You may want to ask them for clarification on something they did. You can say something like I see that you're using a regic string to validate the input. What made you choose this option? You may notice that I used two strategies at this clarify part. Include what you see and know. That's the first part.

And a facilitative question is the second part. Then once you get the clarification you need, you can offer them, you can complete the remaining steps, value, questions, concerns, and suggest. It may sound like this. I tested your solution and it works. That's a value. We might need to reuse this regic somewhere else. That's a concern. Can you move the regics to a shared file? That's a suggestion. Then the feedback receiver will acknowledge your feedback and thank you. They might say something like thanks for the feedback, that's a good callout. I'll fix that right away. Then they fix it, you can give them approval, and we can all move on. The ladder of feedback is useful whenever you need to give feedback to people. PR comments is one of them. But also it's performance review season for a lot of us. So that's also a time that we can leverage this strategy. Or even when you're just giving feedback to others on their day-to-day work. You can use this strategy so that they do not feel attacked and they can truly benefit from what you have to say.

Now, we just went over five strategies on how to make our thinking visible in engineering collaboration. These strategies can work in many different situations, such as one-on-one or group settings. When you can make your thinking visible, others can follow your thought process better, which can lead to greater understanding. And this facilitates more collaboration. And in addition, the more we can make our thinking visible, the easier it will be for others, especially junior members, to learn from each other. And this will help everyone on the team to grow. So I hope you and your team will get to try out some of these strategies soon.

And this brings us to the end of my presentation for today. This is my first time speaking at a tech conference and I'm very excited. I'm also nervous, but I'm so happy that I got to share this with all of you. If you would like to connect with me, you can find me on LinkedIn. My profile name is Karen Lee.

Thank you so much for joining me today at JS Nation. I do have a bunch of questions I'm going to start with. And I'm just trying to figure out which one I should address. Should I go with the sort of like lightning rod question first? Maybe I will. So I do love the idea of having these sort of discussions to make sure everything is clear and whatnot. How would you go about having these kind of discussions in a current climate right now where there's a lot of it done online, so in a Zoom call, and versus an in-room, in-person, sort of like collaborative kind of discussion? Because I do, you know, I've had both and I remember the last time we did it, I'm like, man, I'm so glad we're all together in this room with this whiteboard kind of kicking it. So how do you feel about that?

That is a great question. And I actually think those strategies work regardless of if it is in person or if it is remote. I have been an engineer for four and a half years. My entire engineering career has been remote. And so I had the experience of implementing some of these strategies in the classroom in person with students, but actually implementing most of them online when I'm interacting with my teammates on Slack and even in Zoom. And what I've noticed is that even though I introduced these strategies very much from an educational perspective, I noticed some of my colleagues who had no background in teaching actually use them when they were communicating with me. And the way I would see it is that their PR comments, for example, would be very clear. They will tell me, oh, I see that you're doing this here. I think maybe you should try this instead. So maybe they're not as structured as the way I listed out just now, but I see the same idea being implemented. And so in that case, I think these strategies can be implemented in all settings. The idea is regardless of which mode of collaboration you're using, ultimately, we all want to make our thinking visible to others so that we can all collaborate better. Okay, thank you.

Here's a question I like. I like them all, by the way. Do you have any advice for encouraging everyone's participation in collaborative settings, especially, specifically for uplifting quieter voices? So someone who's shy or whatnot.

So I think off the top of my head right now, I don't have a very good suggestion other than document, document, document. But I think what I found to make documents helpful is that instead of structuring your documents in like long paragraphs, sometimes it is helpful to structure your documents by questions. So just think about if somebody were to go back to this topic a year later, what do they want to know? What are the five questions that they want to know? And can your document answer those five questions? You could just list those five questions from the get go and organize your thought that way. Or if you don't, you can just make sure that whatever you put in your document includes that information. And I think that would be one of my suggestions if we want to organize our thoughts so that we look back to it and we're not like, oh, what did I do here? Thank you.

So when we have a situation like this, I think this reminds me a very classic teacher move, which is you call on some people. The problem with doing that in a workplace is sometimes people feel like they are singled out. So I think this doesn't mean that you shouldn't do it. But the way to do it instead is to frame it in a way to make sure that everybody like if you notice multiple people on your team didn't say something, as a leader, you might want to just acknowledge every single person in the room or in the call and make sure that they had the chance to speak. So that's one way. The other thing that I would consider is if you are the person leading the meeting or if you know that your colleague is working on something not too long ago that is related to the topic that you're discussing and you want to get them to collaborate more, call that out. Because from my experience, I would consider still a junior engineer, junior mid-engineer, sometimes what I notice is that the things that I was thinking about is actually what seniors are thinking about. But I was too scared to talk about it because I thought, oh, maybe like everybody would know this already. And if I share it, it's not contributing. But it turns out it actually is relevant. And I think if somebody else who has worked with me would have maybe called it out, I would feel a lot more comfortable sharing it. And I think that can also help encourage some of the quieter folks in the team to speak up. And just kind of following up on something you just said, I would imagine as well sort of, you know, being a bit more involved might also indicate maybe to some seniors or intermediates in a room that you're, you know, hey, you're constantly thinking, like, you know, kind of thinking out loud and sharing ideas. I would imagine that's positive as well. Yeah. Modeling is a big part of it as well.

Oh, that's a good question. So my first question is going to be, is there anything that person does that you think they should keep doing? Because even if you have nothing good about what they do, let's say, like, they have a lot of mistakes in their changes, they don't document, they don't communicate well, is there anything that they do that you think brings value to the team? Because sometimes some of those values might be a little more, I want to say subtle, but it's just not obvious. Perhaps they are a unique thinker. The way they think, the way they approach a problem or they just, they do things very quickly because they have a set of commands that they are used to using and it's just in their toolbox, they use it so much that they use it without thinking.

Another question here that's been getting a lot of love. How do you give feedback if you feel you only have bad things to say? Oh, that's a good question. So my first question is going to be, is there anything that person does that you think they should keep doing? Because even if you have nothing good about what they do, let's say, like, they have a lot of mistakes in their changes, they don't document, they don't communicate well, is there anything that they do that you think brings value to the team? Because sometimes some of those values might be a little more, I want to say subtle, but it's just not obvious. Perhaps they are a unique thinker. The way they think, the way they approach a problem or they just, they do things very quickly because they have a set of commands that they are used to using and it's just in their toolbox, they use it so much that they use it without thinking. And that's a good thing. It's just not good because it's almost like they did everything in this black box and nobody knows what happened. And so when we can acknowledge some of those things that it is good in a sense, but it could be better if it is, say, shared with other people or explained a little more, then I think there is at least some room for us to figure out what we can learn, what we can acknowledge or give positive feedback. Because I think ultimately, no matter which team you're working on, there's always something that we can learn from people, even though it's not the obvious, oh, this person codes very fast, or this person comes up with very good quality code, whatever it is, there are things that we can learn and I think it will take a little bit of time to notice those things.

So I have a personal question here I want to ask before I get to the next one. How do you feel your education background brought sort of like, you know, some skills to this position and specifically this talk that you have? That's a very broad question that I feel like I can talk about it for hours. But I think the number one thing I learned from education and how I think it translates to my work today is that when I was an educator, I care a lot about really fulfilling everybody's potential, helping every single student to fulfill their potential. And I think because I had no coding experience when I was teaching, software development felt like just a black box. I was thinking how, how do I do this? I studied piano performance in college. Like my last math class was in high school. How could I even do this? But then as I continued on my journey in software development, I've noticed that software is this tool that allows people to create things and to fulfill their potential just in a different way. Instead of just learning things, you're building things. And so I think that is very similar and it motivates me.

Now this will be the last question. And it's the following, when using the sales strategy, what things should we consider to make sure everyone reviews the document? So depending on your team, if you are on Slack, linking it in Slack, I think when I think about my team as an example, if I want to make sure somebody will read my document, I will actually DM them and I will remind them to leave comments. I understand the challenge because it can be and we have so many of them. So depending on how your team organizes your documents as well, I would encourage people to include the link of the document in multiple places. Because one of the experiences I had before is I wrote a document about an issue. I thought everybody read it, but they didn't. It was in the issue and somebody went into the meeting asking questions that you're just like, yeah, you did not read it at all. And so when that happens, it frustrates me a little, but I also think that maybe sometimes, especially if you work with people who are outside of your team, if you have cross collaboration, it might help to just tell them exactly where the link is because they might not be used to where things are. So overall, maybe a little bit more reminders would be my suggestion. Awesome. Thank you very much for your time. There were a lot of questions, so I would suggest that I'm assuming because you shared your information, if you do want to ask some additional questions to Karen, I guess hit you on LinkedIn. Is that correct? Yes. And that being said, once again, I do want to thank you for your time. Congratulations on your first talk. Did she do well or what?