Podcast thumbnail for Data Gibberish

Data Gibberish

Claim This Podcast

by Yordan Ivanov

11 episodes
Updated Daily
Accepts GuestsHas Sponsors

Podcast Overview

Data Gibberish helps experienced data engineers and data leads handle stakeholder requests, scope pressure, and decision-making with scripts, checklists, and playbooks you can use immediately. <br/><br/><a href="https://www.datagibberish.com?utm_medium=podcast">www.datagibberish.com</a>

Language

🇺🇲

Publishing Since

1/20/2026

1 verified contact email on file for Data Gibberish

Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.

Recent Episodes

Episode thumbnail for 👷 You're Not Stuck Because You're Not Good Enough

July 3, 2026

👷 You're Not Stuck Because You're Not Good Enough

<p>You are stuck because you are optimizing for the wrong thing.</p><p>Most data professionals I talk to work incredibly hard at their craft. They go deep on Python, on dbt, on Spark, on whatever the stack is.</p><p>They take courses, they build side projects, they read documentation on weekends. And then they watch someone else get promoted. Someone who, honestly, is probably less technically sharp than them.</p><p>Introducing David Langer</p><p>Dave Langer has been in technology for almost 30 years. He started on the help desk, wrote COBOL on a mainframe at an insurance company, moved into software engineering, and lived through the dot-com crash in the early 2000s.</p><p>The last 15 of those years have been in analytics, starting with traditional BI and data warehousing, Kimball star schemas, the whole thing, and then moving into more advanced analytics.</p><p>Dave worked at Microsoft leading a data and analytics team, then at a startup called Schedulicity as VP of Analytics, and at Data Science Dojo. He is a Microsoft Excel MVP, not for writing formulas, but for evangelizing Python inside Excel, which he got early NDA access to in 2023.</p><p>David wrote a book on Python and Excel published this year, and his second book on SQL for Excel users is coming in 2027.</p><p>These days Dave is an independent consultant and trainer. He runs a Substack called The DIY Data Scientist, which is exactly what it says: practical tutorials on data analysis for professionals who want to use data better, regardless of their background.</p><p>We had a live conversation, and this is everything worth taking from it.</p><p>The Value Ladder Is Not What You Think It Is</p><p>Every organization has a value ladder. A rough hierarchy of what it perceives as worth paying for, promoting people for, and building strategy around.</p><p>The problem is that your version of the value ladder and your organization’s version are often completely different things.</p><p>When you are early in your career, this does not matter much. You are rewarded for technical output:</p><p>* Write good code.</p><p>* Ship clean pipelines.</p><p>* Produce accurate models.</p><p>That is the ladder, and being technically excellent gets you up it.</p><p>But at some point the ladder changes. And nobody tells you.</p><p>What the organization starts rewarding is perceived strategic value.</p><p>That could mean designing systems instead of building them. It could mean being able to translate between the data team and the C-suite. It could mean understanding enough about the business to push back on a requirement intelligently, not just implement it.</p><p>If you keep climbing the old ladder while the organization has already moved to a new one, you plateau. Only because you are solving for the wrong problem.</p><p>The Outsourcing Lesson</p><p>Think about what happened to a lot of senior engineers in the early 2000s. They had gone deep on C++ (Qt will stay in my heart forever), and read all the right books, so they could architect complex object-oriented systems.</p><p>And then globalization happened, and suddenly all of that specialized knowledge became a commodity. You could hire it for a fraction of the cost from an outsourcing firm.</p><p>The people who survived that shift asked: what is the value ladder actually rewarding right now? And the answer was architecture, system design, coordination, the things that required judgment and organizational context. Not just technical execution.</p><p>The same question applies to you today. Not “how do I get better at this tool?“ but “what is my organization actually paying for?“</p><p>If you want a concrete way to map where you actually sit on your organization’s value ladder, that is exactly what the <a target="_blank" href="https://open.substack.com/pub/datagibberish/p/building-a-techincal-job-level-matrix?r=odlo3&#38;utm_campaign=post-expanded-share&#38;utm_medium=web">Career Progression Matrix</a> in the premium library does. Paid subscribers get access to it on day one. <a target="_blank" href="https://www.datagibberish.com/subscribe">Upgrade here.</a></p><p>Data Problems Are Not Technology Problems</p><p>Here is what nobody told me early in my career:</p><p>The hardest part of working in data is not the data itself, but people</p><p>If you’ve been in data long enough, you’ve probably been in meetings about the definition of a customer for way too longs. And all of that, just because four departments each had a different answer, and each answer made a different executive look better or worse.</p><p>This is what senior data professionals figure out. And it is what a lot of talented junior and mid-level people never fully internalize.</p><p>If your goal is to do technically excellent work in a well-scoped problem, you can stay in your lane and deliver. That is a legitimate career.</p><p>But if you want to actually drive decisions, if you want your work to change how an organization operates, you are going to spend a significant amount of your time as a mediator.</p><p>* Between engineering and business.</p><p>* Between what the data says and what someone wants the data to say.</p><p>* Between this year’s urgent request and the foundational investment that would make next year’s requests 10x easier to answer.</p><p>The people who succeed in that space are not always the most technically gifted. But they are always the ones who learned to sit in an uncomfortable call, name the real disagreement out loud, and not flinch when someone gets defensive.</p><p>Why Teaching Is a Career Asset</p><p>One of the underrated ways to build this skill is to teach.</p><p>Not necessarily a course or YouTube tutorial. Just the act of explaining complex technical concepts to someone who does not share your context.</p><p>It forces you to leave your own head and think from the other person’s perspective. You cannot fall back on jargon. You have to find the analogy that lands for this specific person, not the definition that would satisfy a technical reviewer.</p><p>That skill transfers directly to stakeholder work. Every time you explain a data model to a VP, every time you scope a request with a product manager who is not sure what they are asking for, every time you push back on a dashboard request by asking “what decision are you trying to make?“ you are doing the same cognitive work.</p><p>Data professionals who build that muscle early tend to accelerate later. The ones who skip it hit a ceiling.</p><p><a target="_blank" href="https://www.datagibberish.com/t/playlist-show-and-tell">Show & Tell</a> is where I work through exactly this kind of thing live. One paid subscriber brings a real situation, and we work through it together in front of the group. Every session is recorded, and included in a paid subscription. <a target="_blank" href="https://www.datagibberish.com/subscribe">Join here.</a></p><p>Executives Are Running the Same Hype Cycle Again</p><p>A few years ago, the mandate was “we need to be data-driven“. Companies hired data teams, built dashboards, set up data warehouses. Most of them never actually became data-driven. But “data-driven“ was the thing, so they built it anyway.</p><p>Now the mandate is “we need to be AI-first“.</p><p>The structure is identical:</p><p>* An executive reads something.</p><p>* The pressure cascades down.</p><p>* Someone, often the data team, gets handed the brief: implement AI.</p><p>The business problem that AI is supposed to solve is treated as secondary. Sometimes it is not even identified.</p><p>I have seen a company run a churn model comparison: a basic logistic regression built by a data scientist, versus an LLM-based approach. The logistic regression hit 80% accuracy. The LLM hit 50%, which is coin-flip territory. The traditional model also cost a fraction as much to build and run.</p><p>And that is before you account for what happens when AI pricing moves from flat subscription to usage-based. When your CFO is looking at a bill where the token cost exceeds the salary of the team that could have built a simpler model, the conversation changes fast.</p><p>Most organizations are not thinking about this right now. They are still in the “we need an AI use case“ phase. The ROI calculation comes later, usually painfully.</p><p>The Hadoop Lesson Is Already Written</p><p>During the Hadoop hype cycle, an executive asked Dave whether the company could move their SQL Server databases to run on top of Hadoop instead of fast disks. Because Hadoop storage was cheaper. The executive had read about it in a trade magazine.</p><p>The answer was no. Obviously. But the fact that the question was asked at all tells you something about how technology hype filters through organizations.</p><p>It’s all about the anxiety of not being part of the trend.</p><p>* MongoDB was supposed to kill relational databases.</p><p>* Excel has been declared dead every year for 20 years.</p><p>* SQL was going to be replaced by query builders.</p><p>None of that happened.</p><p>Some things change. Programming languages come and go. Platforms rise and fall. But the underlying problems stay the same: organizations need to make better decisions using data.</p><p>The data needs to be clean, structured, and understandable. The people consuming it need context.</p><p>The Two Questions Worth Asking</p><p>Here is what I would take from all of this.</p><p>First, <strong>be honest about your organization’s value ladder</strong>. Not the one you wish existed, but the one that actually exists.</p><p>* What gets people promoted here?</p><p>* What gets people noticed by leadership?</p><p>* Is it technical depth, or is it business impact, or is it visibility, or is it the ability to manage up</p><p>Because the answer changes your strategy.</p><p>Second, <strong>ask whether that ladder aligns with what you are actually trying to build</strong>. If it does, optimize hard for it. If it does not, that is useful information too. The organization where the ladder aligns with your goals exists. Sometimes you have to find it.</p><p>The data professionals who stall out tend to do one of two things: they optimize for a ladder that their organization does not value, or they assume the ladder they are on right now is the one they will always be on.</p><p>Neither is true.</p><p>Find More From Dave</p><p>Dave’s Substack is <a target="_blank" href="https://thediydatascientist.substack.com/?r=odlo3&#38;utm_campaign=pub&#38;utm_medium=web">The DIY Data Scientist</a>. Every issue is a hands-on tutorial with workbooks, code, and data included, free. If you work with data in any capacity and want to actually understand what you are doing with it, it is worth subscribing.</p><p>He is also active on <a target="_blank" href="https://www.linkedin.com/in/davelanger/">LinkedIn</a>, where his content leans more toward the enterprise and organizational side of analytics.</p><p>His book, Python for Excel, is available on <a target="_blank" href="https://www.daveondata.com/">Amazon</a> and in <a target="_blank" href="https://www.barnesandnoble.com/w/python-in-excel-step-by-step-david-langer/1147563942?ean=9781394340767">Barnes & Noble</a> stores.</p><p>—</p><p>Until next time,</p><p>Yordan</p><p><strong>PS:</strong> Paid subscribers get the Career Progression Matrix, the full Show & Tell archive, and the entire premium resource library. <a target="_blank" href="https://www.datagibberish.com/subscribe">Upgrade here.</a></p><p><strong>PPS:</strong> The next Show & Tell session is coming up. A paid subscriber and I will be working on a long on a long therm-career plan. <a target="_blank" href="https://www.datagibberish.com/subscribe">Join here.</a></p><p>Let’s Connect</p><p><strong>Connect on LinkedIn:</strong> <a target="_blank" href="https://www.linkedin.com/in/ivanovyordan">https://www.linkedin.com/in/ivanovyordan</a></p><p><strong>Work with me:</strong> <a target="_blank" href="https://www.ivanovyordan.com/coaching">https://www.ivanovyordan.com/coaching</a></p><p><strong>Start journaling:</strong> <a target="_blank" href="https://www.dearself.ai">https://www.dearself.ai</a></p><p>More on the Topic</p><p>* <a target="_blank" href="https://www.datagibberish.com/p/the-other-side-of-the-job">The Other Half Of The Job</a></p><p>* <a target="_blank" href="https://www.datagibberish.com/p/the-senior-data-engineer-paradox">Why Senior Data Engineers Lose Their Velocity (Even When Their Skills Improve)</a></p><p>* <a target="_blank" href="https://www.datagibberish.com/p/you-describe-your-best-work-wrong">Your Best Work Is Invisible Because You Describe It Wrong</a></p> <br/><br/>This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://www.datagibberish.com/subscribe?utm_medium=podcast&#38;utm_campaign=CTA_2">www.datagibberish.com/subscribe</a>

Episode thumbnail for 👷 How to Use AI Like This World Class CDO

June 17, 2026

👷 How to Use AI Like This World Class CDO

<p>I had a great chat with <a target="_blank" href="https://substack.com/profile/170793541-nick-valiotti">Nick Valiotti</a>. Nick built his fractional CDO practice around one bet: <strong>growing companies need senior data leadership long before most of them can afford it full time</strong>.</p><p>He wrote the playbook down in his book Your Fractional CDO, after watching the same failure pattern repeat across years of client work.</p><p>A data team builds perfectly modeled tables, clean naming conventions, a finished warehouse, and still fails at the one job that matters.</p><p>The failure starts in the hiring order, months before anyone touches SQL.</p><p>The Pattern Behind Almost Every Broken Data Team</p><p>A company grows, raises money or bootstraps itself, and builds product and marketing first. Data waits. By the time anyone notices, the gaps have already turned into blind spots in real decisions.</p><p>The fix usually starts with a data analyst, hired to both analyze the data and build the warehouse underneath it. He patches things together with whatever is closest: ad hoc imports from spreadsheets, quick pipelines wired through whatever tool is available. It works until it doesn’t.</p><p>So the company hires a data engineer to rebuild the plumbing properly. Pipelines get rebuilt, structure improves, the technical layer finally looks right.</p><p>It still doesn’t work. Nobody ever agreed on what the numbers mean.</p><p>A clean warehouse built on an unresolved disagreement only makes the disagreement faster.</p><p>This is the gap a fractional Chief Data Officer gets hired to close. The job is the translation layer between what the business is trying to decide and what the data team is building. Head of Data, VP of Data, Chief Data Officer, the title changes. The job underneath stays the same: turn business priorities into a data roadmap, then close the distance between the two.</p><p>Three People, Three Numbers, One Metric</p><p>When the role gets done right, the first move rarely touches the warehouse.</p><p>On one project, the opening round of conversations with C-level stakeholders surfaced a single metric, active subscriber, calculated three different ways by three different executives. Each one trusted their own version. Nobody had flagged it as a problem, because nobody had compared notes.</p><p>The fix starts with a written catalog of every metric that matters: what it counts, what it excludes, who owns the definition. It lives somewhere simple, a Notion page, an Obsidian vault, plain markdown files, and every stakeholder signs off on a definition before a single pipeline gets touched.</p><p>Skip that step and the technical work inherits the argument anyway. A warehouse with perfect naming conventions and a properly modeled transformation layer still produces three different numbers for active subscriber, because the disagreement never lived in the tables. It lived in the room full of people who never sat down to agree on what the word meant.</p><p><p><strong>Your career is not stuck because you lack technical skills.</strong></p><p></p><p>It is stuck because nobody taught you how to operate. Stakeholder management. Business translation. Career positioning. I write about all of it every week</p><p></p></p><p>What AI Changed</p><p>The Audit That Used To Take A Month</p><p>When Nick onboarded onto a new client’s stack, he inherited a Metabase instance holding around 2,000 saved questions, each one a SQL query sitting on top of the warehouse. Reading through that by hand to figure out which tables and metrics mattered used to eat him three to four weeks.</p><p>He connected an LLM to Metabase’s API and turned the same task into a question-asking exercise: which tables get used most, which metrics get calculated more than one way. The 2,000 saved queries referenced around 90 tables in the warehouse. Only 12 of them turned out to matter.</p><p>The same pass produced a first list of conflicting metric definitions, the kind of list that used to take weeks of stakeholder interviews to assemble by hand. It became the opening line of the metric catalog conversation. The conversation with stakeholders still had to happen.</p><p>A Personal Operating System</p><p>Outside of any single audit, Nick’s daily workflow runs through a stack of connected tools: email, Slack, Telegram, WhatsApp, Jira, Google Calendar, a meeting note-taker, a task planner, a personal fitness tracker. Each one is wired in through its own API, feeding into folders organized by client, by teammate, by personal project, written up as markdown files an AI assistant reads for context.</p><p>A new lead from the website used to mean reading an email and booking a call. Research on the prospect now happens automatically, the call transcript gets analyzed for next steps, and a draft proposal and CRM update follow without him typing either one by hand.</p><p>He still types every prompt himself. Roughly 90 percent of his working day still happens inside an editor, reading something, asking a question about it, deciding what happens next.</p><p>The Rules That Don’t Bend</p><p>Speed doesn’t extend to trust. A short list of rules stays fixed regardless of how good the tools get:</p><p>* Every SQL statement an AI writes gets verified by a human before it touches anything live or anything tied to budget.</p><p>* Raw client data never goes into a public AI tool. Only metadata about the data does, table names and query structure, never the rows underneath.</p><p>* Sensitive processing happens through local models inside the client’s own environment instead of commercial platforms.</p><p>Delivery got faster. The job grew, because speed opens room to take on more work.</p><p>Judgment Became The Scarce Skill</p><p>As AI absorbs more of the execution, headcount on this kind of team is shrinking on purpose, driven by a bet: enable each remaining data analyst and engineer with AI rather than hiring more people to do routine work that AI now does faster, the documentation nobody wanted to write, the boilerplate code, the first draft of a pipeline.</p><p>Not everyone takes that bet. Some experienced data engineers distrust the output outright or keep working the old way out of habit.</p><p>That resistance is becoming the dividing line. Once anyone is able to write a working SQL query or stand up a dashboard with AI’s help, calculation stops being the skill that earns a senior title. Reasoning about why a stakeholder cares about a specific number takes its place. The valuable hire thinks strategically about the business and catches the cases where the fast answer is the wrong one.</p><p><p><strong>I built the resource library I wish existed when I was 25 years old.</strong></p><p></p><p>Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks.</p><p></p><p>Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing.</p><p></p></p><p>Reporting Lines Decide Whether The Job Works</p><p>Where this role sits on the org chart changes what it’s able to do, regardless of the title on the business card.</p><p>Put the data function inside engineering and it drifts toward whatever a chief technical officer recognizes as good work: pipelines, infrastructure, technical correctness, thinly connected to what the business is trying to decide.</p><p>Put it inside finance and a different bias shows up. Finance’s own questions get solved first simply because of who the team reports to, while marketing or product priorities wait their turn even when they matter more to the business right now.</p><p>Neither placement is wrong on paper. Both pick a winner without saying so.</p><p>The function works best as a peer to product, marketing, and finance rather than a report inside any one of them, sitting at whatever level makes the final call on what the company builds next: a CEO in most structures, whoever arbitrates between general managers in flatter ones. The job stays the same either way. Listen across every department, then build the data foundation that unblocks all of them instead of only the one holding the budget.</p><p>None of this requires the word “Chief” in the title. It requires someone willing to do the unglamorous work of getting people to agree on what a number means before anyone touches a pipeline, and the discipline to use AI as a way to do that work faster rather than as a reason to skip it.</p><p>Find Nick Online</p><p>You can find Nick on a number of places. I strongly recommend following Nick on LinkedIn and subscribing to his Substack.</p><p>* <a target="_blank" href="https://valiotti.com/">Valiotti Data</a>, the agency Nick runs as a fractional CDO for growing companies.</p><p>* <a target="_blank" href="https://www.linkedin.com/in/valiotti/">LinkedIn</a>, where most of this thinking shows up first.</p><p>* <a target="_blank" href="https://nickvaliotti.substack.com/">Substack</a>, where Nick writes long-form content.</p><p>* <a target="_blank" href="https://www.amazon.com/Your-Fractional-CDO-Nick-Valiotti-ebook/dp/B0G3954N5S">Your Fractional CDO</a>, the book written for executives building a data function for the first time.</p><p>—</p><p>Yordan</p><p>More on the Topic</p><p>* <a target="_blank" href="https://open.substack.com/pub/datagibberish/p/where-your-data-team-needs-to-sit?r=odlo3&#38;utm_campaign=post-expanded-share&#38;utm_medium=web">Where Your Data Team Sits Is a Strategic Decision</a></p><p>* <a target="_blank" href="https://open.substack.com/pub/datagibberish/p/data-platforms-exist-to-enforce-consistency?r=odlo3&#38;utm_campaign=post-expanded-share&#38;utm_medium=web">Data Platforms Exist to Enforce Consistency, Not Enable Insight</a></p><p>* <a target="_blank" href="https://open.substack.com/pub/datagibberish/p/the-data-engineering-manager-operating-system?r=odlo3&#38;utm_campaign=post-expanded-share&#38;utm_medium=web">The Operating System Every Data Engineering Leader Needs</a></p><p><p>Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.</p></p> <br/><br/>This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://www.datagibberish.com/subscribe?utm_medium=podcast&#38;utm_campaign=CTA_2">www.datagibberish.com/subscribe</a>

Episode thumbnail for 👷 What Olympians, CEOs, and Lords Have in Common

May 15, 2026

👷 What Olympians, CEOs, and Lords Have in Common

<p><p><strong>Presenting Peter Mukherjee</strong></p><p></p><p>Peter built a London business from scratch in 1992, grew it into an international franchise network with a public listing, and lost most of it to the 2008 crash. He reinvented himself as a professional architectural photographer and worked at it for fifteen years before retiring in 2023 to write full-time.</p><p></p></p><p>I’ve known <a target="_blank" href="https://substack.com/profile/105005627-peter-mukherjee">Peter Mukherjee</a> for about an year now, and he’s one of the wisest people I’ve ever talked to.</p><p>The whole time he was talking during our conversation, I kept hearing the same diagnosis for why most senior engineers hit a ceiling.</p><p>You are managing your career like an employee.</p><p>The people who break through manage it like a business. They use a different vocabulary, run a different operating system, and make different decisions. None of it requires another certification, and all of it requires a mindset shift most senior engineers never make.</p><p>Forced Pivots Surface The Rest Of You</p><p>The default for a generation was 30-40 years at one employer, a stable pension, and a CV that looked sensible. The world does not work that way anymore. Multiple careers across one working life is now the norm.</p><p>The hardest version is the forced pivot. Income stops, status stops, and everything you built is on hold while you scramble to establish something new.</p><p>Getting through it requires confidence in your own abilities, because most people are more capable than they give themselves credit for, and the work is digging deep, finding the talents you have, and pulling yourself through.</p><p>Resilience is built mostly through failure. There is no shortcut. You learn the most during the times you fail, because failure forces you to dig in and recover. The worst response is going negative, looking backwards, sliding into “what have I done“. That posture stops the recovery before it starts.</p><p>The deeper insight is that most people never find out what their real talents are. They pick the first thing they think they are good at and develop only that.</p><p>There might be tens of thousands of people with that level of athletic talent who never find out they run, because they never explored their full range. When things go wrong, you are forced to ask “what else am I good at?“ That question, under pressure, surfaces the talents the comfortable version of you never bothered to look for.</p><p>The Old Leadership Model Is Finished</p><p>The safe pair of hands is done. Steady the ship, grow dividends 5-8% a year, stay around for ten years. That mindset takes the business backwards now, because the world moves too fast for it. Standing still is moving backwards.</p><p>The replacement is the transformational leader. Transformation involves risk-taking, which only works if the culture supports it, which means giving your people permission to take risks too, without making them fear for their jobs when they get something wrong.</p><p>Apple and Google run open plans where managers sit among their people. Senior managers might have an office, but it is glass-sided so people see them and they see their people. Any transformational leader has to be able to carry their people through change, and you only carry them properly if you are visibly involved with them.</p><p>A successful US business leader who talked about being vulnerable in front of her people in the 90s was told “that’s because you’re a woman“. Now every leadership conversation centres on empathy and vulnerability. COVID accelerated it and AI will accelerate it further.</p><p>Where Leaders Lose People</p><p>The biggest source of failure is arrogance and ego, and the biggest organisational consequence is losing the people you invested time and money into developing. You will always be outbid on salary. There is always someone offering more money.</p><p>But the one thing people put ahead of the bigger paycheque is enjoying where they work. The manager who is arrogant, ego-driven, and disconnected from their team creates an environment people are eager to leave, and that manager loses good people on a clock.</p><p>Humility Is The Hardest Lesson</p><p>The kind of humility forced on you by having to let go of people who built the business with you. Telling someone who has been with you for 15 years that the business is closing is one of the hardest things a leader does.</p><p>There are two ways to handle it. The first is matter-of-fact, because that is what organisations do. The second is to treat the moment with the weight it carries for the person on the other side of the desk, with empathy and active care for what happens to them next, including helping them frame what they learned.</p><p>The relationships survive the second version.</p><p>The same principle runs through every other team interaction. Make people feel included, valued, recognised.</p><p>A specific mechanic that works: team-level bonuses where the team itself decides who the top contributors are. Everyone shares in the reward, but the team picks the largest pieces. It does not have to be financial. A day out, a big dinner, share options. The point is structuring recognition so it incentivises working together instead of competing.</p><p>The 51/100 Rule</p><p>The mythology of the successful CEO making lots of right decisions is wrong. Every CEO is making decisions every day, and some they get wrong, sometimes catastrophically.</p><p>The batting average, from Ursula Burns (former CEO of Xerox, started as an intern): out of every 100 decisions, you make 51 good ones and 49 bad ones. The job is making sure the 49 bad ones are not too bad.</p><p>You afford one or two howlers, but the rest need to be recoverable. If you have an immaculate record of getting everything right, you are not taking enough risk, and your career is moving backwards while you congratulate yourself for being right.</p><p>The mechanic underneath is reversibility. Good risk-taking is calculated, not suicidal. Sort every decision into reversible and irreversible. The reversible ones get volume. The irreversible ones get contingency planning.</p><p>The downside in the reversible bucket is embarrassment and a week of recovery. The downside in the irreversible bucket is structural and measured in years.</p><p>Most senior engineers treat every decision as if it were in the irreversible bucket. They spend two weeks deciding whether to submit a conference talk. They draft a LinkedIn post and never publish it. They workshop an internal proposal until the moment to make it has passed. The cost is invisible because nothing went wrong. Nothing happened at all.</p><p><p><strong>Stop collecting advice. Start operating differently.</strong></p><p></p><p>I share the exact playbooks that helped me become Head of Data, negotiate a 40% raise, and survive 4 M&A transactions. Paid subscribers use them to get promoted.</p><p></p></p><p>Curiosity Is The Response To Uncertainty</p><p>For individuals, the best response to uncertainty is curiosity. Nobody becomes successful without it. Learning does not stop when you finish university. Curious people are the ones who do something big.</p><p>Invest in emotional skills. Degrees matter less. The capability to communicate, manage people, be visionary, be inspirational, and bring creativity is what employers will look for. Those are the skills that differentiate you in three years’ time, and they are the ones currently at risk from the AI-as-co-pilot trap.</p><p>The AI Entropy Warning</p><p>Entropy is a real thing. Systems decay toward their lowest energy state when nothing pushes back. Brains are a system. The muscle you stop using is the one that atrophies. People who used their brains for the work are now using AI for the work. The output looks fine. The brain underneath is going to sleep.</p><p>The fix is using the tools while keeping the thinking. Let AI draft, then edit by hand, let it summarise, then read the source or let it suggest options, then make the decision yourself and write down why.</p><p>The skills that cannot be outsourced are the ones the technical job market will pay for in three years, and right now the industry is volunteering for neglect.</p><p>Load The Dice Yourself</p><p>Every successful person credits luck. A specific phone call, a meeting, a door that opened at the right moment. A single phone call was the pivot for a multi-billion-dollar career, where the answer was 50-50 right up until it was given. The mistake is to hear that and conclude luck is random.</p><p>Luck is a numbers game with a rigged distribution. Go to one networking event a year and talk to three people you already know, you have three lottery tickets. Go to five events and talk to ten new people each, you have fifty. Same person, same skills, sixteen times the surface area for a lucky break.</p><p>For data engineers, the equivalent is volume of visible work. Internal documents that travel. Brown bags and lightning talks. External writing. Conference submissions. Every one of them is in the reversible bucket. The hit rate on any individual piece does not matter. The volume across all of them does.</p><p>The wider pattern shows up in every successful career: luck plus passion. Everyone talks about their passion for what they do, and there is a direct correlation between success and finding it. “Follow your passion” only works if you have one. If you have not found one, the work is exploration. Keep looking until you find the thing you love. Until then, every step is a stepping stone.</p><p>The cost of getting this wrong is what makes the rest of it urgent. The greatest risk is that you never find success and fulfilment because you stuck with something you did not love.</p><p>Sir Clive Woodward, the England rugby head coach who won the 2003 World Cup, put it this way:</p><p>The worst thing that happens in life is getting older and looking back thinking “I wish I’d taken a chance on that“</p><p>Treat Yourself As A Business Inside The Organisation</p><p>Change your perception of your role. You are no longer “the programming manager.” Look at yourself like a one-person business inside the organisation you work for. Promote yourself. Acquire the skills. Develop yourself the way a business develops.</p><p>The language change shows it:</p><p>Saying “I am an admin manager, I have been doing this for seven years“ tells the listener nothing.</p><p>Saying “in the last seven years I have organised X, I have done Y, these are the successes, these are my strengths, this is where I add value, these are the things I will carry forward to help your organisation“ is a different conversation.</p><p>That is how you communicate inside the organisation. That is how you describe yourself outside it.</p><p>Life is like snakes and ladders. You roll the dice, you move forward. Lucky, you climb a ladder. Unlucky, you slide down a snake. The mistake is to think your future is dependent on the roll of the dice. Most people are more in control of their destiny than they think.</p><p>Too many expect someone else to design their career. The alternative is to go out, meet people, decide your own projects, decide your own career.</p><p><p><strong>I built the resource library I wish existed when I was 25 years old.</strong></p><p></p><p>Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks.</p><p></p><p>Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing.</p><p></p></p><p>Final Thoughts</p><p>The senior engineer ceiling is not built out of skill gaps. It is built out of an operating model imported from the codebase: optimise for being right, ration the decisions, stay invisible until you are sure. That model breaks the moment the job stops being primarily technical, which is the moment the ceiling appears.</p><p>The people on the other side run a different model. They aim for 51 out of 100, sort decisions before they spend time on them, and surround themselves with people better than they are.</p><p>They take humility seriously and ego personally. They keep their brains on while the industry switches theirs off. They describe themselves like a business that knows what it sells.</p><p>None of it requires a certification. All of it requires the mindset shift most senior engineers never make.</p><p>Where To Find Peter</p><p>Peter writes <a target="_blank" href="https://open.substack.com/pub/afewwisewords">A Few Wise Words</a> on Substack. The book is available in <a target="_blank" href="https://afewwisewords.com/landing-page/">hardback, paperback, Kindle, and audiobook, the audiobook</a> read with 12 different voices, one per contributor.</p><p>—</p><p>Yordan</p><p></p> <br/><br/>This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit <a href="https://www.datagibberish.com/subscribe?utm_medium=podcast&#38;utm_campaign=CTA_2">www.datagibberish.com/subscribe</a>

11 total episodes available

Deep-dive analytics for Data Gibberish

Frequently asked questions

Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.

What is Data Gibberish?

Data Gibberish helps experienced data engineers and data leads handle stakeholder requests, scope pressure, and decision-making with scripts, checklists, and playbooks you can use immediately. <br/><br/><a href="https://www.datagibberish.com?utm_medium=podcast">www.datagibberish.com</a>

How often does this podcast release new episodes?

This podcast updates daily.

Where can I listen to this podcast?

This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.

Does this podcast accept guests?

Information about guest appearances is not available.

Legal Disclaimer

Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.

All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.

We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.

While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.

By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.