Wiki

Communication

How DataTalks.Club podcast guests treat communication as a core data and ML skill: stakeholder translation, interviews, writing, consulting, portfolio narratives, and business context.

Communication in data and ML work means translating technical work into a decision someone else can trust. Across the DataTalks.Club archive, guests do not treat communication as polish added after modeling or SQL work. They apply the same rule to dashboards and infrastructure. Data professionals define the business question, explain assumptions, show ownership, and make evidence usable.

For role context, use career transitions in data, job search, and data product management. Also use the data scientist role, the data engineer manager article, and open-source portfolio evidence. Those pages cover the roles and artifacts. Here, the focus is the communication work that makes those roles and artifacts clear.

Start with these interviews:

Shared Definition

Across the archive, a data professional communicates well when another person can understand the decision and trust the evidence. That person may be a hiring manager, product manager, executive, or client. It may also be a teammate, open-source maintainer, or future reader of a README.

Nick Singh makes the hiring version explicit. Behavioral interviews test more than whether a candidate has done technical work. At 8:58 and 13:20 in Ace Data Interviews, he frames behavioral prep around what interviewers seek and how candidates plan STAR stories. At 25:13, 27:50, and 31:06, project walkthroughs move from ownership to impact and business context. The candidate has to make the work easy to evaluate.

Oleg Novikov gives the same rule for applications. At 18:28 in Data Science Interview Guide, he treats the CV as a landing page. At 25:51, he asks candidates to highlight personal contribution and remove noise. At 32:03, case-study preparation starts from business goals and evaluation metrics. Technical skill matters, but the candidate still has to guide the reader or interviewer toward the signal.

In day-to-day work, Loris Marini gives the stakeholder version. At 12:19 in Business Skills for Data Professionals in SaaS, he starts with shared meanings for terms such as customer. At 18:00, he adds cross-functional context. At 21:46, he connects data storytelling to memorable communication. At 25:53, active listening and business literacy become trust work, not soft extras.

Guest Differences

Guests value different communication surfaces because they speak from different work settings.

Nick Singh and Oleg Novikov focus on hiring. They care about concise stories and clear CVs, along with defensible project claims, case-interview structure, and outreach. Nick’s advice at 27:50 and 33:59 in Ace Data Interviews pushes candidates to lead with impact and control pacing. Oleg’s advice at 29:32 and 39:10 in Data Science Interview Guide pushes candidates to prepare past-project narratives and respond to rejection without burning relationships.

Eugene Yan focuses on writing as reusable communication. At 51:00 and 54:00 in Technical Writing for Data Scientists, he connects writing at work to working-backwards documents and design docs. He also covers decision logs, rationales, and team memory. His portfolio advice at 56:30 makes a README part of the project. Future readers need a quick start and a repo tour before they can judge the work.

Loris Marini focuses on organizational translation. In Business Skills for Data Professionals in SaaS, he spends time on metric semantics and stakeholder mapping. He also covers meeting immersion and note systems. At 27:55, 35:20, and 37:51, the data professional learns the business by mapping stakeholders. They also record roles and context, then join meetings where teams use their own language.

Aleksander Kruszelnicki focuses on client communication. In Data Consulting Business, he treats user interviews and positioning as communication about value. Outreach and pricing belong to the same work. At 12:53 and 15:55, he covers interview questions and note-taking. At 37:03 and 45:19, he moves into service messaging and value-based pricing.

Marijn Markus focuses on differentiation and influence. In Data Science Career Playbook, he connects communication to domain knowledge and constructive pushback. He also connects it to sensitive findings and personal presence. At 19:12 and 23:25, he discusses explaining risky insights and challenging hierarchy with data-driven arguments. At 53:34, communication and presence become part of how a data scientist stands out.

Stakeholder Translation

Stakeholder communication starts before a model or dashboard exists. The data professional has to learn what words mean inside the business, which decisions matter, and which stakeholders can change the outcome.

Loris Marini gives the clearest operating model. In Business Skills for Data Professionals in SaaS, he treats shared semantics as the first problem. At 12:19, teams have to define customer and core metrics before analytics can guide action. At 15:46, lead indicators and churn require causal thinking.

At 25:53, active listening and business literacy build trust. At 45:13 and 47:10, project prioritization depends on stakeholder impact and high-connectivity opportunities.

That makes communication central to data product management. A data product manager has to discover the user problem, define the success metric, and keep adoption in view. The same skill matters for the data scientist role, where the scientist turns a product or operational question into evidence that changes a decision.

Communication also changes as people move into management. The data engineer manager article frames the manager’s work around team outcomes, roadmaps, hiring, and stakeholder demand. That management version isn’t separate from technical judgment. The manager still has to explain why a platform request, data reliability fix, or self-service investment matters to the business.

Interviews and Hiring

In hiring, communication turns private experience into public evidence. Candidates have to explain what they did, why it mattered, what tradeoffs they made, and how they would reason through a new problem.

Nick Singh’s behavioral-interview advice in Ace Data Interviews starts with intent. At 8:58, the interviewer looks for signals beyond tool knowledge. At 13:20, grid planning and STAR stories help candidates prepare without improvising every answer. At 18:47, practiced delivery matters because the answer still has to sound natural. At 33:59, candidates have to avoid rambling and burying the lead.

Case interviews test the same translation skill, and Nick recommends clarifying goals before proposing solutions at 44:27. At 45:30, product-sense interviews require metrics, assumptions, and brainstorming. Oleg Novikov’s case-study section in Data Science Interview Guide starts from business goals and evaluation metrics at 32:03, then moves toward technical assessments at 36:38. The communication failure is to jump to a model before the interviewer understands the goal.

This connects communication to job search and career transitions in data. Career changers need to translate previous work into the target role’s language. Oleg’s CV advice at 18:28 and 25:51 makes that translation visible on the page. Nick’s project walkthrough advice at 25:13, 27:50, and 31:06 makes it visible in conversation.

Writing and Documentation

Writing is the archive’s most reusable communication skill. It helps a data professional teach, clarify their own thinking, help a team remember decisions, and make a project easier to look at.

Eugene Yan’s Technical Writing for Data Scientists episode separates several writing jobs. At 9:30, writing helps people share, learn, and become discoverable. At 14:00, the writer chooses readers, peers, and future teammates as the audience. At 16:30 and 20:00, he treats articles as products that ship on a weekly cadence. At 25:00, the outline-first method turns memory and rough ideas into a structure.

For teams, Eugene’s advice becomes documentation discipline. At 51:00, writing at work includes working-backwards documents and design docs. At 54:00, technical documentation includes decision logs, rationales, and team memory. At 56:30, a portfolio project needs a clear README, quick start, and repo tour. Those details connect directly to open-source portfolio evidence, where public work is stronger when readers can reproduce, review, and understand the contribution.

Admond Lee Kin Lim adds the public-audience version in Personal Brand for Data Professionals. At 6:00, he defines personal brand through purpose and positioning. At 13:00, he discusses publishing on Medium and LinkedIn. At 31:00, conference speaking adds preparation, submission, and delivery.

At 42:00 and 44:30, he ties content to personal values and authenticity. He also discusses frequency and quality. His focus is less on team documentation and more on how a data professional becomes known for a clear point of view.

Consulting and Client Conversations

Consulting communication has a different test: the client has to believe the consultant understands the problem well enough to price and deliver useful work. A technically correct answer can still fail if the consultant hasn’t validated the buyer, the pain, or the value.

Aleksander Kruszelnicki’s Data Consulting Business episode starts with customer validation. At 9:08, he discusses validation techniques before a product exists. At 12:53, user interviews become a way to collect evidence instead of guesses. At 15:55, pair roles and note-taking make the conversation more reliable.

Later in the episode, Aleksander turns discovery into a commercial message. At 27:59, client acquisition begins with network-first outreach. At 30:17 and 37:03, positioning depends on target customers, timing, and offers such as revenue or marketing optimization. At 45:19, value-based benchmarking shapes pricing. At 52:38, day rates and project pricing create different incentives.

This consulting path belongs with career transitions in data because the proof changes. A consultant still needs technical credibility. They also need discovery, scoping, pricing, and relationship language. The portfolio isn’t only a repository or notebook. It can also be a clear offer, repeatable service, client result, or well-scoped diagnostic.

Portfolio Narratives

Portfolio work only helps when the viewer can understand what the project proves. The archive repeatedly warns against treating a project as self-explanatory.

Nick Singh’s portfolio guidance in Ace Data Interviews asks candidates to show ownership at 25:13 and lead with impact at 27:50. At 31:06, he asks them to connect technical work to product value. At 37:18, they should present only technical claims they can defend. At 39:42, he discusses how to quantify impact for non-enterprise projects. The candidate doesn’t need a famous production system, but they do need a credible story about why the work mattered.

Oleg Novikov gives the application version. In Data Science Interview Guide, he opens with a project built to show skills at 2:42. At 27:51, he treats take-home projects as a time-investment and return-on-investment decision. At 29:32, behavioral stories should make past-project impact clear.

Marijn Markus adds the differentiation focus in Data Science Career Playbook. At 37:49, he argues for unique projects instead of only doing Kaggle. His examples at 30:47 and 31:18 use home automation and plant sensors. At 34:31 and 36:21, data pipelines and a coffee-machine time series make curiosity visible. At 43:08, domain experts and cross-disciplinary skills become part of the portfolio story.

Open-source work follows the same rule. Open-source portfolio evidence is strongest when readers can look at the issue or pull request. Documentation, tests, demos, and maintainer feedback matter too. Communication turns the public artifact into an interview story. The story should name who needed it, what changed, which constraints applied, and what the contributor learned.

Use these pages for adjacent role, hiring, transition, and portfolio context.