How to Communicate Effectively as an IC  ## Metadata - Author: [[LeadDev]] - Full Title: How to Communicate Effectively as an IC - Category: #articles - Document Note: --- tags: - #communication - #career - #engineering Author: Blanca (Moderator) with panelists Edin Gmai Heim, Arina, Jesse Rosenberger, Sha Bandare Source: YouTube Webinar — *How to communicate effectively as an IC* Reference: [Watch on YouTube](https://www.youtube.com/watch?v=TQUzV4JubB0) date created: 2025-08-22 19:05 --- # Title: Effective Communication Tips for Individual Contributors ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The webinar highlights how **senior individual contributors (ICs)** can grow by mastering communication. The panel stresses: - Adapting style to audiences across cultures and roles. - Using empathy to connect with colleagues in different domains. - Acting as facilitators rather than dominant voices in meetings. - Supporting proposals with **data and measurable impact**. - Partnering with managers to create safe spaces for strategic conversations. - Building cross-functional trust through **transparency and simplicity**. --- ## 📖 Main Content: The panel frames communication as the IC’s superpower, often more influential than raw technical skill. They argue: - **Effective ICs act like translators**: they make complex ideas accessible without oversimplifying. - **Empathy drives connection**: understanding chemists, biologists, PMs, and executives helps tailor messaging. - **Meetings aren’t about dominating**: senior ICs should ask clarifying questions and encourage participation. - **Data wins arguments**: proposals backed with quantified impact get buy-in. - **Partnership with managers matters**: honest feedback loops foster psychological safety and strategic alignment. - **Cross-functional awareness is key**: simplifying technical docs, sharing drafts early, and anticipating misinterpretations reduces risk. --- ### 🗒️ Notes - [00:14](https://www.youtube.com/watch?v=TQUzV4JubB0&t=14) Communication affects career trajectory; lack of it hinders growth. - [07:13](https://www.youtube.com/watch?v=TQUzV4JubB0&t=433) Adapt style to culture, role, and context. - [09:33](https://www.youtube.com/watch?v=TQUzV4JubB0&t=573) Use empathy to connect across disciplines. - [14:18](https://www.youtube.com/watch?v=TQUzV4JubB0&t=858) Facilitate, don’t dominate, in discussions. - [22:02](https://www.youtube.com/watch?v=TQUzV4JubB0&t=1322) Support arguments with data. - [27:35](https://www.youtube.com/watch?v=TQUzV4JubB0&t=1655) Transparency builds trust; hiding info erodes it. - [33:19](https://www.youtube.com/watch?v=TQUzV4JubB0&t=1999) Translate info for different audiences; find patterns. - [37:56](https://www.youtube.com/watch?v=TQUzV4JubB0&t=2276) Partnership with managers helps ICs level up. - [43:59](https://www.youtube.com/watch?v=TQUzV4JubB0&t=2639) Cross-functional partners need inclusive documentation. - [49:46](https://www.youtube.com/watch?v=TQUzV4JubB0&t=2986) Step out of comfort zones; build cross-lane relationships. --- ## 📖 References: - Panelist experiences (Slack, Apollo Graph, Recursion). - Concepts from communication strategy in engineering leadership. --- ## 🗣️ Paraphrase: 1. Original: *“Communication is simple: align with business needs and provide data. The hard part is creating that data.”* → Paraphrased: Communicating upward is straightforward when tied to business goals and backed with evidence, but gathering that evidence is often the challenge. 2. Original: *“Sometimes the best contribution is to ask clarifying questions instead of offering your own solution.”* → Paraphrased: An IC can create more value by facilitating understanding than by imposing their own preferred approach. --- ## 📰 Newsletter: ✉️ **This Week in WordPress & Open Source** Effective communication isn’t just for managers—it’s a career accelerator for ICs. A recent panel of senior engineers and managers shared tips: - 🎯 Adapt style to your audience (executives, PMs, or chemists need different details). - 📊 Always back proposals with data. “It’ll save money” lands better as “$10K saved per week.” - 🤝 Partner with your manager—safe spaces for feedback help sharpen communication skills. - 📄 Write docs for humans first; technical depth can come later. 👉 Lesson for WordPress contributors: communication multiplies your impact. Whether onboarding new devs, writing docs, or shaping proposals—clarity and empathy turn ideas into action. --- ## ✅ Action Items: - Frame this talk in DevRel and OSPO proposals as evidence that **effective communication is a critical IC skill**. - Develop **training modules for ICs in WordPress** on audience awareness, empathy, and facilitation. - Push for **data-backed contribution metrics** in The WPCC reports. - Emphasize communication training in **onboarding for new contributors**. --- ## 🧪 Hypotheses: - ICs who adopt facilitator roles in meetings drive higher team alignment. - Cross-cultural communication training reduces project delays. - Data-backed proposals improve IC promotion outcomes. ### 📊 Methodology: - Survey ICs on communication confidence vs. promotion history. - Run A/B tests on meeting facilitation techniques. - Case studies of cross-functional collaboration at Apollo/Slack/Recursion. ### ❓ Questions: - How can open-source contributors practice IC communication in async-first environments? - What role does documentation style play in reducing miscommunication? ### 🔮 Future Research: - Longitudinal studies on IC promotion and communication training. - Cross-community comparisons between WordPress, Kubernetes, and React. ### 💡 Implications: Findings could lead to **communication-focused mentorship programs** for open-source contributors, boosting retention and ecosystem health. --- ## 🧠 Learning Styles Assessment: - **Visual**: Limited visuals; could add diagrams and flowcharts. - **Aural**: Webinar format supports auditory learners. - **Verbal**: Rich in discussion and examples. - **Kinesthetic**: Weak; add practice exercises. - **Logical**: Present; structured cause-effect reasoning. - **Social**: Strong—panel and group discussion. - **Solitary**: Reflection points limited; add journaling prompts. - **Naturalistic**: Absent. Readability: ~12th grade level. --- ## 📊 Accessibility Assessment: - Transcript exists ✅ - Improvements: add **alt-text for visuals**, support **keyboard navigation**, and ensure **high contrast** for slides. --- ## 🌍 DEIB (Diversity, Equity, Inclusion, Belonging) Assessment: - Strengths: multiple cultural perspectives highlighted. - Weaknesses: no gender/racial inclusivity explicitly discussed. - Improvements: add multilingual examples, neurodiverse-friendly structures (chunked text), and broader representation. --- ## ✅ Logical Validity: - **Strengths**: - Deductive reasoning (communication → career growth). - Causal reasoning (data-backed proposals → buy-in). - Balanced: panelists admit mistakes and share growth. - **Weaknesses**: anecdotal over empirical in places. - **Tone**: professional, reflective, pragmatic. --- ## 🔍 DARVO Analysis: - No DARVO tactics detected. - Content is collaborative, not defensive. - Tone = supportive, growth-focused. --- ## 🔍 SEO Evaluation: - **Keywords**: “IC communication,” “engineering career growth,” “effective communication skill - Summary: The text is an introduction to a webinar discussing effective communication for individual contributors (ICs). Panelists share their experiences and insights on tailoring communication to different audiences within a company, showing empathy, and simplifying technical jargon. They emphasize the importance of understanding others' perspectives and adjusting communication styles accordingly. - URL: https://www.youtube.com/watch?v=TQUzV4JubB0 [Music] hello everyone and a huge thank you for joining us today for a discussion on how to communicate effectively as an IC the webinar will last roughly 45 minutes after which both myself and the panelist will head over to the L slack to answer some of your questions in the staff CL Channel we may also have time to answer couple of questions live so please do submit those through a Q&A feature on zoom and we'll get to them if we can towards the end so let's get started with some introductions my name is Blanca and I'll be joined today by Eden Elina Jesse Anda to share their experiences and insights I'm going to ask each of you to introduce yourselves so we're going to go in alphabetical order by name could you please answer in 60 seconds who you are and what makes you excited about being on the panel today and then would you go first yeah sure um I'm edin gmai Heim pronouns I am co-founder and CTO of thinky which is a new startup and before that I was a staff engineer at slack and I was there for around six years um yeah I'm excited to be on this panel in particular because I think communication is one of those things that everyone says you need to be good at at like work and relationships and life but there's like no real checklist um so any conversation that helps us talk more about what it's like for us or to give actionable feedback I think is awesome to put that out there in the world thank you uh and now aren hi everyone I'm Arina I'm a senior staff engineer at apoll graph I work together with Jesse who is also on this panel um I'm really happy to be here because I feel like I think a lot about community communication and I feel like I've messed up a lot of times in that way in that regard and I learned a lot from that and I'm really excited to share that that knowledge and those learnings with you um to hopefully get everyone better at this at this nuanced field of of our work thank you uh Next Top Jesse hi uh I'm Jesse Rosenberger my pronouns are he or they uh I work at Apollo as well uh I'm an engineering manager that leads the efforts building high performance graphc infrastructure and developer experienes for an Enterprise markets digital transformation needs uh when adopting the supergraph and I get to coach excellent Engineers like Arena um when I'm uh when I'm not just doing developer tools and things like that I'm certainly excited in uh the challenges that ic's face in communicating on matters like this uh certainly a thing that I that I can relate to uh places I've been before and I love getting perspective from outside of the organization um where I spend my dayto day uh that sort of learning lets me bring that information back to my team excited to be here thank you and last but not least scha hi I'm scha bandare and I'm a principal engineer at recursion recursion is a clinical stage Tech bio company that is decoding biology to industrialized drug Discovery in and in this role I I've been I've been in the engineer ing leadership team here uh that is working um to really build tools um that enable speed scientific innovation across several domains at recursion such as chemistry biology translation and workflows and so it's been it's it's a it's it's it's a fun fun place to be and definitely feel very satisfied being being in this at at recron um I as a result of being in this diverse um working with diverse people communication becomes a big part of of my job and you know not having trained being trained in this but like I've had to learn this on the job and I I I'm really excited for this uh this panel to be a part of this panel and share some some of my learnings thank you thank you sha thank you everyone we're going to take a little step back before we start and like the panel said senior individual contributors underestimate how much a lack of or bad communication can hinder the career growth our work looks obvious to us and the engineering teams we work with we have to learn to step into the shoes of others around us and tailor our explanations that they become accessible to a wider audience making things things accessible doesn't mean that we're oversimplified and on the other hand our roles as enablers uh for engineers requires us to communicate business strategy to engineers in a way that helps them understand what is most relevant for the product area they work in so today we have brought you a group of people with a breath of perspectives and roles to discuss what does effective communication look like and what to think and prepare beforeand so now let's dive into the questions uh for the first topic we're going to start to the conversation different topics but first topic we're going to be focusing on communicating effectively to different audiences and we're going to be starting with Elena what things do you think about when you are preparing to communicate with people in different teams or in different roles in the company yeah um yeah so I I work at a at a pretty technical company we are we work with developer tools and our customers are also technical because they use those developer tools and but at the same time I think I talk with a variety of different people they can be technical customers product managers managers solution Architects sometimes our executive level staff and for all of those I think it's important to really think about what's important to these people is this do they need really in-depth technical details if I'm talking with my with my teammates for example other Engineers what kind of technical detail do they need uh for example solution Architects are also really technical people but they don't need the same level of detail as for example my direct team um are they interested in timelines and that's the only thing they're interested in do they need a broad picture do they need background information of why we're making a certain decision and but overall like I think about what if I were in these shoes if I wore this hat as a product manager what it is that I would need um and at the same time you do want to communicate with a different part of the team or a different person who works at a company you kind of have to think about their background as well for example I I would probably out would frame my communication if this was like a direct chat with somebody who's from uh the US uh very differently than when somebody's from France or Ukraine for example I work with these people from different uh from different countries and they have different ways of communicating and I will sort of tell that a little bit to to their background not obviously not necessarily speaking in that language although I might speak in that language but just kind of thinking about what's important to this background of people um I also kind of think about this that if I'm speaking to somebody in a different role I think about the fact that this is a two-way street I might need something from this conversation just as much as they will need something about this conversation and kind of framing that that uh piece of document or that call is really important about what our needs are um and if I need something from this piece of communication I'll think about what it is that I need and I'll usually communicate it up front like saying I will provide you with a summary or this is the agenda for our call and again stepping in those other people's shoes is is uh is super super effective I think in a way that we can communicate with other people on the company and what this effectively means is that sometimes I'll be like a chameleon I'll change the way I write or I word certain things very differently depending on who this other person is like my immediate updates to my engineering team are going to be very very different versus like companywide updates like my language will just change and I'll change my way of speaking and um but kind of overall all of this sort of depends depends on how important is this piece of information and how well do I know the audience how official is this and then I'll adjust accordingly thank you that that is very very thoughtful Ela like the amount of the different layers of coms that you think about I think people don't realize you know how much work goes into it yeah it's a decision Matrix yeah so I'm going to bring uh Setta into into the conversation because you work very closely with biologists and chemists at your company and and I'd like you to give us an example of how do you bring them along well I think Irina said a lot of things that I wanted to say and so I think I Echo a lot of the sentiment if I were to add to what Irina said is having a lot of empathy towards the tasks and the day-to-day operations of people working in the lab and by lab you know they're working with with instruments with with uh with chemists working with chemicals and and machines and and really having empathy for the day-to-day operations of these people and I actually like to um as I as I on board on an in into a new domain for example chemistry for me this year is new and the first thing I did is try to understand what they do every day and and what does their day-to-day look like was it very different I promise you from what the day-to-day of an engineer who sits at the desk looks like and then I try to make make a diagram and then try and see the opportunities that engineering teams can help with lab maybe expedite some processing that is happening maybe in Excel spreadsheets it's might sound mundane but sometimes just that can save six hours of of a person in the lab um the other thing that I I have learned over the last two two plus years that I've been at rurin is um you got to realize the language you're speaking and by language it's not French or or German but um when if let's if I go to somebody in in a different domain and say I'm going to just give you an example is I'm going to build you a kubernetes deployment that will solve you this problem you've lost them already they're like thank you right versus if you can say I'll host an application for you at this URL and this is how you can get your results or this is where you can process your data so yes there's kubernetes happening behind that application or is hosting that application but they don't need to know that they just need to know what's the URL to go to and I'm oversimplifying here but that's the idea is you got to know what tech what tech jargon you want to bring to them and how are you going to enable them and that's the part that I I have really learned to to embrace um and then once I understand what the problems are I like to get involved with teams with engineering teams or sometimes it could be data scientists that I need to bring along and then translate those things into technical jargon and then you can use all the techie jargon you have with that group of people and then you solve the problem right and and then you you see the smile on their faces and that's just Priceless and and that's the impact you make as as um a staff plus I see and I think that's just and it's all going down to the communication and how do you how do you do how do you do it effectively um the one other thing I would like to add and I think Arena mentioned that um based on your audience you know you you probably go through four or five meetings a day pretty easily and then based on your audience you got to wear a different hat right sometimes you have one-on ones with Engineers or product or and anybody else maybe you're acting as a therapist you're just listening and you're listening to concerns and so the key part is what hat are you wearing when you enter the zoom or the room and that's the key I found in in in communication across domains thank you s i I love both of your answers already because you kind of complemented each other aren you sound very focused with technical people about this different layers different cultures and then s you have like different roles and and also kind of different rooms you're going into but but both of you are thinking about very very similar things and and I think Ena enena what you said about telling people up front what you want them from what you want from them I think it's key for knowing what hat they need to wear with you and also for you to know what hat you're going in so otherwise what how how would they know just just just just chat for a minute people are like what for I have no idea so anyway uh we'll move on next to to Eden uh you have some advice uh that might sound counterintuitive to some staff plus Engineers around talking less can you tell us of a situation where this is very important yeah I think this is especially important on your your immediate team um like a good example is if someone is presenting a design dock or an RFC I don't want to come into it with like my ideas of how to approach something or how to do something and instead kind of be like a facilitator in a way where I'm the one like asking more questions to get us on the same page because I've noticed a lot of times someone puts a dock out some people make some comments and they're like looks good and then then like three weeks later you realized not everyone was on the same page about how exactly we were going to implement this so I like instead of being like this is how we should do it I really try to listen as best as I can and be like do I really understand like how this is going to be done end to end and if I don't ask questions because other people probably don't really understand how it's going to go either so yeah facilitating a lot of questions clarifying clarifying questions so that if I took everyone on the team in that meeting and separately asked them like what is this project what is the purpose and how are we actually going to get there like that they all have the same answer that's usually my goal at the end and my input as to how to implement something is usually not the only way and I need to take myself out and be like you know what even if I think this one way might be a little bit better who cares like their way works and it's not going to cause any issues and it's you know like whatever let them do it their way just ask questions and make sure we're on the same page and if they're not doing something that'll destroy the the product then it's fine you know like stop giving your input and just like facilitate that combo um but yeah this is like especially on your immediate team especially if you're the most senior I try to stay out of like decisions or coming up with ways to do things I sense there might be a follow-up question there about why don't you make the decisions because I think that's that's another thing that sometimes people in staff plus positions can be a bit confused about so but but I I I I agree with with your approach that you Empower people with the solutions they're bring in and you know I I know Jesse does a lot of kind of herting Engineers I'd say in a way uh but also facilitating communication uh so I really like your perspective from the engineer you know managers uh kind of lensen when you are at a meeting uh how do you help your engineers shine and what do you find your role kind of is at the time well the first thing I try to recognize is that meetings cause a lot of anxiety in a lot of different ways for different people uh myself included uh it gets easier with practice is the first thing I'll say um communicating to a particular group of people takes time though to really Excel it and you need to calibrate on the level of trust an understanding of the meeting you're going into in a lot of cases um but people will do better at things like this if you give them a little bit of space and context that lets them launch themselves into the conversation uh make sure that they have a a clear expectation uh you can ask your ask your manager if you don't have these things right away uh we we try to make sure you understand things like this but it's always okay to ask um I try to make sure that there's a clear expectation of them needing to participate in a meeting and um sometimes that comes down to the the role roles that uh the different people play in the organization it it it changes depending on experience um in some meetings it's supporting on a technical matter that folks will come along uh but in a lot of cases especially at staff plus it's much more administrative uh you know try to ease off and some of the technical stuff as you move further away from like the core technical team um but going back even further uh way before the meeting actually starts uh enabling someone to shine in the meeting probably starts um way before that meeting uh it starts building Mutual trust and respect and it requires aligning and expectations for the role in a very general sense uh and then if I build up that trust ahead of time it also means that I as the manager am less likely to be surprised uh in a higher meeting because I know that folks working on it will be communicating outward uh about the challenges that they see way ahead of time if you set up that trust your team can bring problems to you for coaching uh when they need it and and you can expect that when you come to the meeting things will probably be fine start your preparedness um I I don't ask all my Engineers to show up in meetings and be alone and representing their work uh but for folks leading initiatives especially staff plus there is an expectation of that and I try to ask my team to be able to represent their work both the good parts and the bad parts um yeah that becomes a thing more and more over time uh but on day one it doesn't exist so I try to make sure I'm creating the space for them sometimes it's by being way more intentional in meetings where they're in uh but in a lot of cases it's just by saying less uh if if I just trust my team to say something um they probably will and they'll practice and they'll represent their work and I love that and I think that one of the things I try to do for is prepare for the case of if I don't show up at the meeting what are the chances of the right information getting conveyed and how do I set up the expectations so that just happened um people in my team are great uh but they're not always used to communicating to the same group of people that I do so a little bit of work here just goes along ways thank you thank you Jesse uh I think that kind of runs out very very nicely every everyone's sensors there is a lot of work behind communicating from all the roles involved and you know one one thing I you know I'd like to point out is that this applies not just to like you know synchronous meetings when you are working as syn ly as well uh through documents you can run a lot of times in kind of different understandings and you need some some sort of kind of checkpoint so this is where Eden and Jesse's answers you know would be really useful you need to make sure that everyone has gained this the same idea and it's kind of going towards the same goal so now we're going to move on to the to the second topic for our webinar which is about making information accessible while avoiding oversimplifying and I'm going to go back to you uh Eden uh because you shared before with our group how communicating up is simple but it's not easy and and what is your advice or what Frameworks uh do you use for this yeah so I think I think it's simple because all you really need to all you need to do is to understand the business needs so like what do your higher-ups want what are their KRS or goals and then you decide how do you fulfill those needs and put data behind it like that's it you just tell them hey I have a proposal that does what you want this is how long it'll take and this is the impact like you know it sounds simple enough but I think the hard part is you know finding that data or finding a proposal that's like reasonable and doesn't take too long or like being able to create the data that shows or like proves it you know it's like you can't expect people like I hear a lot of people come to me and be like hey I like I told the team that if they did this we wouldn't have any incidents or like if we just added this like we wouldn't have any issues and I'm like well how am I supposed to know that your like random proposal is right you know like I trust you as a person but where is your data how do you know that you're actually right so like I don't know say an example is that your company has an initiative to like save money and you think that getting rid of a certain log in your codebase would save a lot of money because no one's looking at it you can have that hunch but what takes it to the next level is like getting the data on how many logs there were like doing some napkin math with AWS and being like hey this is our QPS looks like it's this many cents a minute this would save us $10,000 this month if we spent you know five hours on it like that sounds way better than hey I think if we get rid of some logs like we'll save some money like okay sure versus hey if we spend a week on this thing we could save $10,000 that makes it it way easier for like back to the communication the last question it makes it way easier for that audience to understand what you're actually going to do which is save us $10,000 and it's going to take a week so it's simple and that the equation is simple but the work to get there can be kind of hard but yeah I always recommend to people if you have a proposal just buy it with their mission or their okrs and put a number behind it and they'll probably listen a lot more often thank you one one thing I i' i' add to your to your framework is giving the you know estimating the cost of not doing anything about it because sometimes it's when we kind of give a bit of like a comparison that it kind of instills action otherwise some people are just like well you know that money what is it relative to I don't really know let's just leave it there's bigger things to do or there's more features to work on uh so I I think it's a so there a bit of like kind of influencing them towards the decision you want in a way yeah that's a great Point um Jesse uh now we gonna uh ask you now um from you know from from being a manager you know and and relying on Engineers to distill what is the most important information uh for the audience you have when do you need uh to help them communicate more and when can this potentially backfire never nothing is ever backfired um no well along the lines of what I mentioned in my last bit so it's often that the folks don't have time every day to think about the audience that they're speaking to and what matters to them it's the same things um communicating information upwards to an audience requires knowledge of the things that the other attendees at the meeting really spend their days thinking about um folks who are thinking about customers folks who are thinking about their opportunities folks who are thinking about the blog post uh folks who are thinking about how your risk or that you might say might interfere with their holidays uh there's a lot of things there's a lot of things can happen nobody uh but look people don't like to come to a meeting where they're not going to get anything out of but also people don't want to be surprised by something that they do care about keep it in mind um you're all hopefully coming to the meeting to exchange information with each other and achieve the business goals um but there's also a limited amount of time there so sometimes you move really quickly through things and sometimes you you you take too long to get through things um and you don't leave time for the important discussions so you know um you want to exchange the right information in the time you have uh if you're doing like a more statusyes sort of meeting with a bunch of projects and you really want to narrow it down to a certain number of bullet points if you have more time for a particular topic you know give other people the space to ask questions because those things also surface risk um if you give people space to say things you'll find risk on the way uh and then you can actually spend time to fix it uh to prepare ahead of time uh try to understand the attendees of the meeting ask your manager again like I said earlier um and try to say something that matters to those folks it will make them first of all feel included and feel like they they they can respond um sometimes you're GNA run into a case though where you read the room and recognize that you forgot about a function and sometimes it's really just best to admit that and say hey I'm realizing now that you're interested in this topic but I haven't actually reached out to you uh is there anything on your mind right now or do you want me to reach out to you another time to chat about what's important to you um in terms of when things can backfire um if the trust exists I think that it's it's it's usually less likely uh but it does just happen sometimes especially in larger meetings uh sometimes overc communicating just results in accidental miscommunications about things that aren't really problems um if you like in an all hands meeting for example very innocent update with one unpolished detail can just set off a whole bunch of series of misunderstandings and in in those things folks just might just misinterpret what you're saying because they don't understand the problem area of where you're a subject matter expert um and that gets back to saying sort of the most important things and you know quickly framing things you've thought about in as few as words as possible and have already solved that's good builds trust with the audience um words matter fewest number of words that matter the most are the best things to go for don't hide information necessarily like I don't think that's a good strategy that that just makes things worse um that erodes trust uh but when you when you do stumble on that risk when it happens it will happen there's plenty of learning and growth opportunities folks will reach out to you and there'll be follow-up conversations there might be a retro uh there might be a series of meetings and I think all of those experiences really help people grow themselves uh certainly work for me um and I guess one of the riskiest things overall is the freshness of new information and how much that's actually been processed when you're going into something that's already scheduled uh again like I was saying it's not good to hide information but sometimes you find that information right before like a big meeting where you're like I don't know exactly what to do right now um software changes rapidly when we deliver it so uh if you've done some preparation UPF front it's on the overall project it's less likely that this new risk is going to be absolute chaos but it's still uncertainty in the near term um we try to identify doesn't work don't use it don't feel bad about it it's just a learning experience um but whenever you can uh think about how to express risk bring a plan with you if you can anything uh anything that builds trust and if in the event that you haven't had time to make a plan yet just signal that probably it's it's okay it's okay to be honest about that stuff transparency is is is pretty useful um you can say like hey I recognize this as a problem and I will come back to you with an answer some other time unless there's time to discuss it on the spot then you can you can do that but um it depends the the more you're you're sending information up sometimes there's less time to discuss it on the spot thank you it it sounds like always you know the the best tip is do the opposite of rushing yeah think things through allow others to also kind of think things through and you're probably gonna have better outcomes here great yeah thank you uh so we're gonna hear from enina now um because you work so closely with Jesse and how you know how do you learn uh what is the exact information that people want and you've already described a bit but how do you go in kind of translating this let's say in a me meeting or in a document you know how how do you go about it yeah um I think learning the information is a lot about just having a dialect with people like edin said before I think our job is to ask a lot of questions and especially as you try to figure out what your who your audience is uh for your particular bit of or meeting or a document I think the best thing to do is to get to learn to learn them I think when I sort of start up on a project uh and I don't always do this but when I do this like it's really important for me to have one-on ones with people and really figure out what they're about and what's important to them because even if there are two product managers who do product manager stuff they will have different goals uh and what they they try to achieve with their roal and so I really try to get to know that in a one1 and it's hard in the beginning I think but the more you get to know people the more you find out about them and their priorities and then it makes it easier for you to translate that information to them in a particular way and so at some point like I can tell by Body Language or the manner they speak or they write what like I don't know if it's my like level of perception is really good or just like comes with practice and eventually you get there like you'll know what what's necessary for example if Jesse writes something to me like even if doesn't say that in a sentence I'll know I'll know what means in a way but at the same time like I I think your job when you translate between different audiences is like you're you're an information compiler at this point I'm a compiler engineer so there there go the references like your your job is to once you have these conversation with different people your job is to find patterns and commonalities among these different conversations and group them together uh um and that should really help you informed help help you be informed about what groups of people want so for example you have conversations with solution Architects and your customers who are technical customers in our case I think some of that information overlaps and eventually you find patterns uh and then you group that information together and then you're able to transpile between different groups of people in a way for example like um if you're prepping an RFC and a lot of the times our rfc's are internal for like our own teams or like neighboring teams to read through and figure out what happens but they also sometimes go out to our customers and that information although technical in both ways needs to be technical in a particular way that doesn't get overwhelming to the customer because they don't need to know the internals of the tool and so you end up omitting information and making it a lot more Polished in a way and kind of also step into or work with your product managers to really also outline the feature in in the best Spotlight and that makes for two different documents at this point that you're writing kind of similar like if you're writing a preview like you're going to be previewing a feature at some point and you want to frequently FAQ uh section you will write one for your solution Architects and you'll write one for your customers again different information needs to be translated in different ways um and I think some of this like getting to know what other people want also boils down to you as as a seniors as a staff plus engineer of knowing what the business strategy is like edin was saying just a while back um it makes a lot of sense once you know what the business strategy is and then that you kind of again put that together into into your patterns and you slot that together and you figure out what what what it is that people want absolutely uh I think that the point that stood out most for me when you were speaking was you have to make sure you understand really well all of these inputs before you can actually come up with appropriate translations because if you don't understand it then have a big problem there yeah exactly yeah thank you and we're going to move on to sweater uh so you have an example about surfacing gaps that can then help uper management uh gain awareness can you describe what steps you take when sharing and how that can benefit the teams you work with you are M sha oh God it's three years since covid and I haven't gotten this down uh this this year I I have this opportunity to work across across four teams and and there's there's positives and negatives well I need to know how to manage my time but more importantly what I see this as an opportunity is really to be on the floor with the I's across several teams that the being a part of these teams on a day-to-day basis you participate you know in standups some standups some planning meetings or some pairing meetings and then you sometimes get very closer understanding um as to what's going on are you seeing some red flags is everything going going well or not right it's pretty easy to uh to to get that sense that Arena was talking like you know like you you get you get a you get a sense about it and then when that sense is not right you you give give it time and you say okay is it really happening are you imagining it you be patient and and try you know and and then you know as as one thing that um at recursion staff plus i's are leaders in the organization you know first principles here and and you can also try to say okay this is not going well what can I do first to to uh to influence a change and if you can't then you or or you now need more like leadership support which is more directors or or VPS in you start to now given that you've been patient for a few weeks you now have enough data points to say this is what I'm seeing and I'm I'm concerned about X Y and Z for example you know we we we had some reorganizations recently and I noticed that things were not going as well as they should have and I tried to influence that and at some point you have to and and you know the the key part about this is to not focus not have a complaining uh kind of uh I'm not telling on someone here it's more like okay I see this as a problem this is the gap and this is what we need to do and these are the people to bring along so we can now solve this problem and and and it's almost going to your to the to the you know directors or VPS and saying this is how I would solve it and this is the Gap that's happening um the the key aspect here is is to First be patient to make sure you're not just rushing and uh and and um yeah so I think I don't know BL kep that was uh yeah going to that was great I we have more questions around this topic a bit later on uh so yeah I think this is the perfect the perfect time to kind of end it in uh so we're we're kind of almost towards the winner we're going to try to touch on the top on topic number three and then if we have any questions left over we'll take them to slack because it's going to dive into uh a bit more in kind of communicating uh kind of risk so for the for the last topic uh for the live webinar we're going to talk about partnering with an engineering manager to elevate your communication skills and we're going to shine the line first on enina and and you describe us how has it helped you uh work on alongside just with leveling up your communication yeah definitely so Jesse and I work together for three years now so it's a it's a long it's a long time and I think we've we've had a chance to kind of really figure out how this how this manager IC relationship works and I think at this point we're in a good set of or a good combination of kind of actionable strategizing and Bird's eyee view bantering which are are two terms I made up about eight hours ago um and I I think I think the the number one thing that has been incredibly useful in our way of communicating is that well I feel Jesse might disagree is both parties are open to um feedback and both parties kind of have this honest way of communicating and so that I think really helps us have this safe space during our ways of communicating and what that really um allows us to do is to have have this Catalyst for really good ideas to come about and I think that's really useful because if you have that breathing room that Jesse was talking about before I think you come up with a lot of really interesting things and you really start to think about the gaps that you might not be thinking about whereas uh perhaps I'm bragging here a little bit about this good relationship I have with my manager not a a lot of people get that um but yeah I think it like having that really gives you the head space to really think strategically across various parts of the organization which becomes super important I think the more I am in this role um it does take time to get there and so like I appreciate that not everybody's in that position I've had not great managers to put it lightly um before but yeah I hope that at a Stuff Plus level you're at that space and obviously before that as well like you're in that space and your relationship with your manager is kind of a partnership and a collaboration because effectively that's what's that is meant to be um but I I think how this has helped me with my communication in particular is that the brainstorming and kind of like this Collective uh problem solving or looking at risk is really helping me clear out the haze that I'm might not have have been able to clear it before just because we have that space to do it and it also gives me a perspective from somebody who's in a different part of the organization because theoretically like managers and ic's are have different concerns and so like I was saying before to me it's really important to know what other parts of the organizations are thinking kind of getting this indirect gist into what somebody else uh somebody else's priorities are really gets me to think about what's important for the project and how to get it to other parts of our organization um and especially it's really helpful for like these cross functional implications that a project usually has um at least has had in the past year and a half or so and I think that's really crucial for my role and really again becomes a catalyst for good ideas and really helps to level up that communication thank you uh I I love that that example uh you shared uh I agree a lot of lot of people don't have the luxury of a good manager but I think there's a lot we can do when we hear what good kind of uh management looks like sometimes we we can just have a conversation with our manag say hey I kind of need a bit of help on on this and and I think that I kind of sometimes can move the dial uh with your conversations as well and I really love that uh thank you so Jesse uh now let you know let's hear from you I I love how we have kind of both of you kind of here in tandem um and almost kind of complimenting each other's answers so when work when you're working with with Elina and other Engineers uh in your teams how do you help them think about the wider picture and not over index and kind of the the engineer engineering details I did not know Arena came up with those two new phrases eight hours ago that's great uh we didn't get a chance to rehearse uh you know this ahead of time so I'm glad there's some some Synergy here um I appreciate the honesty uh before we go to The Wider picture I'll I'll draw a connection directly to engineering as well because different Engineers on different teams have different constituencies and different Specialties and you might be shipping a feature and you might be running it by your counterpart but then you need to go to like an Sr team Sr team and they have different things to care about about the end user experience necessarily they might be thinking about operational cost and number of nines uh and those sort of things so to some extent I just say like think about that and apply that to the different functions as well everyone has like a role to play in the organization don't get too caught up in this being uh an unknown world it's just different people different things that they come to work to think about every day um for me and my team at Apollo again we're building developer tools pretty technical um we always try to think about the end user experience um but cross functional Partners also need that consideration to do their job uh most of that information will trickle out to the end user whether you like it or not it might come as a broken experience it might come as something that doesn't make sense [Music] um you want to do the best thing for your users developer tools or not and you need to rely on your organization to do their best work so you don't you don't surprise anybody um you can work in your Silo and let them work in their Silo I guess but talk about their Specialties together um as a suggestion um something that I think about a lot uh consider making changes to how you design and deliver um I think that highly technical design documents do tend to intimidate folks and can sort of inadvertently accidentally shut down good conversation across functions early on and it's not really fair to those other folks to to force them to understand those highly technical Concepts um one thing that I think we've had better success doing is uh documentation driven development um I think that it's a it's a nice artifact or if you're going to have a blog post at some point write the blog post first um share share the blog ahead of time share the docs ahead of time uh if you if you share that you might you know leave it open for comments how people just ask questions about things that don't make sense to them and take a pulse of how many people ask the same question or we have literally renamed products because people are like I don't know what this thing says in the documentation um in the draft and it's like H well that's that's good and that's that's a learning experience so um I don't know that's that's that's one way to do it there's there's a bunch of ways to think about it but think about your peers I guess um and think about how you would want to be communicated to um and how they need to be communicated to as well thank you I believe we only have time for one more question before we wrap up so Eden uh you have the last question of today um so earlier in your career you know you what was the approach uh for communicating and participated in meetings that you changed and why yeah when I was um trying to get promoted to staff I realized um I was kind of like in my comfortable bubble of only speaking up if it was like a feature or like a part of the product that I worked on or something that I was like super comfortable with and as soon as anyone had an RFC or conversation outside of that bubble I would just not say anything and be like I probably don't know enough or there's probably someone smarter that will catch things like why do I need to say anything and and a lot of people I know now who are trying to get promoted I try to encourage them to not think of it as like oh I have to have the answers before I comment on something and instead think about like hey you have a completely different perspective from this other person like the least you could do I mean the worst thing you could do is just bring in your perspective right and you don't have to be like hey this is a better way to do it but you can just you know ask questions like if you don't understand something just ask about it and a lot of times you'll realize you asking that question will bring up a really good conversation cuz maybe the person will struggle answering it and realize hey you know maybe I don't really understand what I wrote there because I do that all the time I'll write things and be like what what was I talking about so it's like I try to get people you know if people are trying to get to the next level I'm like hey why don't you just try like baby steps this week why how about today you comment on a slack thread that is outside of the feature you're working on outside of any product you've worked on and like ask a question and it's like the nice thing about slack well at slack we use slack pretty well but I think most companies use it pretty well but like the channels are public like you I could jump into any team or any channel and no one is going to be mad if you jump in and be like hey I noticed that you like you can start with like maybe the internal tools team something you're like at least a little in familiar with and be like hey I saw you guys were adding this like how come or you know what how do you decide that you know just like just have a goal of like today where can I outside of my bubble just like ask a question and they might come to you and be like hey we don't know anything about product teams like how do you guys like prioritize stuff like you know so I think before I would stay in my bubble and be like if things don't aren't like relevant to my product I'm not going to say anything but kind of slowly worked my way up of like asking questions and just being a part of more conversations and then just doing that more often I guess is what I do now thank you Edan and I'm very gutted but we're gonna have to move the ne the remaining questions to the slack Channel and I'm going to thank all of you uh for sharing your insights today now it's time to wrap up uh We've run a bit out of time so let's quickly go around the room and summarize in a sentence what is your top tip for leveling up your communication skills your answer can be for someone who's looking to move into the staff plus Ro or someone who's been in the role for quite a while and is looking to kind of hone the skill so we're going to go in reverse alphabetical order now starting with swea um I think I learned a lot today uh about communication and effective communication but the one thing that has I'm going to apply it I think this afternoon is I think it was Jesse who said said keeping the technical um communication very simple and um try to you know don't shut people off and uh we have some architecture review happening today so I'm going to try to apply that right away so um thank you I I really enjoyed that tip thank you s uh now Jesse um learn to navigate your organization I think Edan was just sort of suggesting this like you know reach out of you know reach out of your usual Lane a little bit find something else um find some time to have some one-on-one chats uh with folks who work outside your function folks in the fringes of where you spend most of your time uh we have a thing at Apollo that's called dut chats um it's a bot that randomly assigns you to spend some time with somebody um and you can like opt in or opt out of them depending on how busy you are um but if you don't have that just pick someone you'll be surprised people are pretty interested in talking get familiar with the details I mean talk to them about who they are as a person and things like that definitely you know do those things build a relationship but also like ask them just like what's really important for you to get out of like a products delivery um it might be that it could be legal or sales or Solutions or support or marketing just ask them for feedback on your own delivery of of the things they've already heard and um when you go into your next meeting after you've had those conversations take a Peak at the attendee list and use those learnings to think about maybe catering your to who's there thank you Jesse uh andina yeah I think um I think my tip is to really figure out what hat you're wearing when you're communicating with the people try to step into their shoes see what their what their what their perspective is like ask questions and once you get those answers try to try to really gather them up and find patterns and see where that gets you because I think that's that's one of the one of the good ways that has helped me really to step up my communication thank you and finally Edan yeah I would say if I had two actionable tips one would be spend one time a day where you're going outside of your comfort zone contributing to a conversation and two I think like Adena said like having one-on ones like schedule a one-on-one with someone that you don't have one with and just ask about what they care about thank you I think for for me the big one was ask a question and just shut up and you'll be surprised you know people will tell you a lot of things um so thank you so much uh for all the good insights in today's panel we're now all going to be heading over to the lest slack in the plus Channel and please head there to continue the discussion thank you for joining and we hope to see you next time [Music] bye, How to Communicate Effectively as an IC, LeadDev, 01hq8hrhn3m2q5spzx1k9mx441.