Data Gibberish

👷 What Olympians, CEOs, and Lords Have in Common

Presenting Peter Mukherjee 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. I’ve known Peter Mukherjee [https://substack.com/profile/105005627-peter-mukherjee] for about an year now, and he’s one of the wisest people I’ve ever talked to. The whole time he was talking during our conversation, I kept hearing the same diagnosis for why most senior engineers hit a ceiling. You are managing your career like an employee. 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. Forced Pivots Surface The Rest Of You 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. 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. 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. 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. 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. 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. The Old Leadership Model Is Finished 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. 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. 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. 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. Where Leaders Lose People 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. 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. Humility Is The Hardest Lesson 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. 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. The relationships survive the second version. The same principle runs through every other team interaction. Make people feel included, valued, recognised. 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. The 51/100 Rule 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. 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. 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. 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. 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. 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. Stop collecting advice. Start operating differently. 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. Curiosity Is The Response To Uncertainty 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. 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. The AI Entropy Warning 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. 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. 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. Load The Dice Yourself 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. 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. 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. 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. 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. Sir Clive Woodward, the England rugby head coach who won the 2003 World Cup, put it this way: The worst thing that happens in life is getting older and looking back thinking “I wish I’d taken a chance on that“ Treat Yourself As A Business Inside The Organisation 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. The language change shows it: Saying “I am an admin manager, I have been doing this for seven years“ tells the listener nothing. 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. That is how you communicate inside the organisation. That is how you describe yourself outside it. 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. 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. I built the resource library I wish existed when I was 25 years old. Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks. Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing. Final Thoughts 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. 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. 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. None of it requires a certification. All of it requires the mindset shift most senior engineers never make. Where To Find Peter Peter writes A Few Wise Words [https://open.substack.com/pub/afewwisewords] on Substack. The book is available in hardback, paperback, Kindle, and audiobook, the audiobook [https://afewwisewords.com/landing-page/] read with 12 different voices, one per contributor. — Yordan This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe [https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2]

The Identity Shift Nobody Warns You About When You Become a Team of One

Presenting Yuki Kakegawa Yuki is a Staff Data Engineer, author of the Polars Cookbook, and the founder of Orem Data. He writes about data tools and independent consulting on Substack and LinkedIn. I asked Yuki [https://substack.com/profile/89127157-yuki], Staff Data Engineer and author of the Polars Cookbook, what the biggest adjustment was when he became a team of one. He skipped tooling. He skipped workload. He said this: It’s a shift in mindset. You’re not a data engineer anymore. You’re a data person helping the business with data and analytics That sentence landed harder than I expected, because most people assume the challenge is the technical breadth: wearing all the hats, being the analyst, the engineer, and the data scientist rolled into one. That part is visible. What nobody talks about is the identity part. You Were Hired as a Data Engineer. That Is the Problem. At a large company, your identity is your scope. You do pipeline work, pass it to the analyst, the analyst makes the report, the report goes to the business. You are one node in a chain, and that chain insulates you from the messiness of what the business needs. When you’re a team of one, that chain is you. Yuki described his current day-to-day: * talking to the business to understand what they care about * translating that into projects * building the pipelines * building the models, * building the reporting layer * delivering insights directly to stakeholders He skips the handoff entirely. That scope describes a different job, built around a different identity. The Selfishness That Kills You He used a word that surprised me: selfish. When I was first getting started, I wanted to work on pipelines and I didn’t want to work on reporting. That selfishness kills you in this role. You have to be flexible and you have to care about the business first. Most data engineers have strong opinions about which work is worth doing. Pipelines are interesting. Reporting is boring. Data modeling is craft. Dashboards are noise. Those opinions are how you survive in a large org where you can negotiate your scope. A team of one has no scope to negotiate. The business has no interest in which part of the stack you find meaningful. The work that needs doing is the work you do, and if you have not made peace with that before taking the role, the first six months will feel like a slow grind against a situation you agreed to. What Is Broken at Every Startup You Walk Into I asked Yuki what he finds broken almost every time he walks into a young company. Tooling is rarely the issue. It’s the processes around the processes that produce the data used for reporting and analytics downstream. And the alignment on what’s important, the definition of metrics, what we want to build. Two things. The upstream processes that generate data, and whether the business has agreed on what the numbers mean. The stack is almost never the problem. The Metric Definition Problem This is the one that is hardest to fix and most commonly ignored. Yuki described the ideal state: every metric the business cares about is written down, defined, and agreed on before the data team touches a model. When that is true, the data team’s job is implementation. The hard part is already done for you. The real state at most companies is three departments with three definitions of the same number. If you use one team’s definition, you put another team in a bad spot. If you try to reconcile them, you are suddenly in a political conversation nobody hired you to have. I’ve been in that position. That’s the part I hated the most. Defining core metrics early, before the company grows, before each department builds its own reporting layer, before everyone has opinions baked into their own numbers, is more valuable than any pipeline you will build. If you’re walking into a company where this work is undone, do it first. How to Handle the Stakeholder Who Thinks Your Work Takes Two Weeks Yuki described a pattern that every team-of-one data person will recognise. A stakeholder requests a report, thinks it can be done in two weeks, and the data behind it is messy enough that you know it will take four. I can try, but I can’t promise, because I think these things will be bottlenecks. Two things are happening in that exchange. Setting expectations is the obvious one. Making the complexity visible is the one that changes the relationship long-term. When you’re the only data person, the rest of the company defaults to assuming data work is fast. Pull the numbers, build the report, done. They genuinely have no frame of reference for what it takes to model messy source data into something accurate enough to make decisions with. Your job is to narrate the work before you do it, and skip the explanation after you miss the deadline. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. The Transparency Stack Yuki added something that makes the whole prioritisation problem easier: making your priority stack visible to the entire business. Being transparent about what you’re working on and what the priorities are is important. Because if one stakeholder thinks his project is the top priority, but I’m working on a priority item requested by the CEO, then that stakeholder will understand that his project is not at the top. This works because it shifts who does the priority negotiation. When everyone can see the queue, the conversation moves from “why isn’t my thing done“ to “is my thing in the right place in the queue“. The second conversation is faster and involves fewer emotions. Accuracy vs. Speed Is a Trade-Off to Name, Not a Choice to Make Alone I pushed Yuki on a question that sounds simple: accuracy or speed? Definitely accuracy. But that’s where your skill comes in. How do you deliver projects fast while ensuring accuracy? The real answer lives in the communication around the trade-off, not the trade-off itself. If you can deliver in one week at 80% data quality, or in two weeks at 100%, the stakeholder should make that call. They can only make it if you put the options in front of them explicitly. If you wait two weeks, I can ensure 100% accuracy. If you want it in one week, there might be things that still need to be pinned down. Yuki’s underlying point is worth sitting with: making decisions on low-quality data defeats the entire point of data-driven decision making. Speed that produces bad numbers is a liability that takes three times longer to fix than the shortcut saved. On Using AI When You Have Nobody to Think With One thing Yuki said is worth pulling out directly, because it is the most honest framing of AI use I have heard from anyone working in the data space: I use AI especially when I want to bounce ideas around. I use it because I don’t have anybody else to talk to, because I’m the only data person. AI as a rubber duck rather than a replacement for judgment. At a startup where you’re the only data person, you have no peer to sanity check your modeling approach, your architecture choices, or whether your prioritisation call makes sense. AI fills a small part of that gap. But Yuki also admitted he is not sure AI is making him faster overall. The time he used to spend building the solution, he now spends validating what the AI built. The total may net to zero, with the shape of the work changed and the volume unchanged. That matches what I have seen. AI handles narrowly scoped, well-defined tasks well: understanding what a table column means by parsing the codebase, generating boilerplate inside a framework you have already defined, drafting initial SQL that you then refactor. For architectural decisions and anything that requires sustained judgment, the model is an input, and the judgment stays with you. Connect With Yuki Yuki is very active online. Here are some of the best ways to connect with Yuki: * Substack profile [https://substack.com/@yuki1] * The Data Toolbox [https://thedatatoolbox.substack.com/?utm_campaign=pub&utm_medium=web] * The Independent Insight [https://theindependentinsight.substack.com/?utm_campaign=pub&utm_medium=web] * LinkedIn profile [https://www.linkedin.com/in/yukikakegawa/] * The Polars Cookbook [https://www.amazon.com/Polars-Cookbook-practical-transform-manipulate/dp/1805121154] * Consultancy website [https://www.oremdata.com/] — Yordan Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe [https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2]

How to Transition from Managing Pipelines to Managing People like Prajakta

Presenting Prajakta Yerpude Prajakta spent a decade climbing every rung of the data engineering ladder, intern, engineer, senior, lead, manager, and somewhere along the way realized her biggest impact was no longer in the code she wrote but in the people she unblocked. Getting promoted into management felt like winning. I had the title, the 1:1s, the org chart with my name at the top. What nobody told me was that everything I had spent years getting good at had just become irrelevant. The skills that got me the promotion were the wrong ones for the job. Speed, ownership, technical control, those are IC superpowers. In management, they become liabilities. Prajakta figured this out the hard way too, after a decade climbing every rung of the data engineering ladder. What she learned on the other side is clearer than anything I've read on the topic, and it maps almost exactly to where most senior data engineers quietly stall You Are Already a Manager Before the Title Most people wait for the promotion to start operating differently. That is the wrong order. The data professionals who get promoted into leadership are not the ones who wanted the title. They are the ones who were already doing the work before anyone gave it to them. Clarifying requirements with stakeholders when nobody asked. Helping teammates get unblocked when they had their own deliverables to ship. Asking the why behind the problem instead of just solving the what. The Week Your Code Sits Untouched There is a specific moment that signals the shift. You get to the end of a week and realize you made almost no progress on your own work — but the team moved forward because of the conversations you had. That discomfort is the job changing underneath you. If you wait until the title to start operating at the next level, you are asking your manager to take a bet on future behavior. That is a harder sell than showing them behavior that is already there. Speaking Up Is a Skill Early in any leadership journey, the most uncomfortable moment is the same for almost everyone: being in a room of more experienced people, knowing something is wrong, and deciding whether to say it. The imposter syndrome is real. The difference is learning not to let it make the decision for you. Facts Remove the Politics In data, you have a specific advantage: you can ground a challenge in numbers and evidence. When you do that, you shift the conversation from opinion to information. The most experienced person in the room does not win by default anymore. Leadership is about stepping up when something needs to be said. That is available to you at any level. An intern can flag a bad assumption. A senior IC can challenge a decision made three levels above them. The cost of staying quiet is harder to measure than the cost of speaking up. But it compounds over time. Empathy Is Leverage. As engineers, we are trained to solve technical problems. The higher you go, the more you realize the hardest problems are people problems. Misalignment. Stress. Lack of clarity. Someone having an off day. These do not have a clean solution. Some of them do not need a solution at all. Instead, they need listening. The Problem-Solver Trap The instinct to fix things immediately is exactly what gets senior ICs into leadership. It is also the thing that makes early management hard. Not every situation calls for a solution. Sometimes the person in front of you just needs to feel heard. When you learn to read that distinction — when you can tell the difference between a problem that needs solving and a person who needs to know you are paying attention — the team responds differently. People who feel understood and supported perform better without you pushing harder. You do not manufacture that with a process or a framework. It is built through consistent, genuine attention to what is actually going on beneath the surface. Technical skills get you to the role. Empathy and emotional intelligence determine how far you go inside it. Your Impact Becomes Invisible. That Is the Whole Point. As an IC, your output is visible. Code you wrote. Pipelines you fixed. A cost number you moved. You can point to it directly. As a manager, your impact shows up through other people. Better decisions. Stronger execution. A team delivering consistently and growing in the process. None of that has your name on it. Unlearning the Need to Own the Outcome The hardest thing to unlearn is tying your personal value to what you directly produce. Andy Grove put it clearly in High Output Management: your output as a manager is your team’s output. That is the measure. You do not have a separate output anymore. The team speaks on your behalf. That means impact can look like: * Creating the right direction when things are ambiguous * Removing friction before it slows the team down * Helping someone succeed in a way they would not have without your support * Building the environment in which good work happens consistently You stop building systems. You start building the conditions in which good systems get built. That is more scalable than anything you could ship yourself. The Myth That Needs to Die The most persistent management myth: a good manager always has to be in control of everything. New managers fall into it. Experienced managers fall into it. They believe that effectiveness means knowing every detail, monitoring closely, and constantly stepping in. What that actually creates is dependency. It slows people down. It makes you a single point of failure. The Real Measure The actual measure of good leadership is when your team can collaborate, problem-solve, and resolve issues without you needing to be in the room. When something gets fixed before you even know it happened. That is the job done well. High standards work better when trust already exists. When people know you genuinely support them, they are more open to feedback, more willing to stretch, more willing to take on work that makes them uncomfortable. You can be kind and still be clear. You can be supportive and still hold people accountable. The balance is a more effective version of both. Final Thoughts The move from IC to manager is a step sideways into a completely different job that happens to sit inside the same organization. The data professionals who stall at senior are almost always technically strong. They can build. What they have not yet built is the capacity to make others better at building. If you are waiting until you feel ready to step into that, here is the honest version: you will never feel fully ready. Growth happens because you stepped forward before you did. — Yordan More on the Topic These are some of the articles Prajakta mentioned in our chat: * The Operating System Every Data Engineering Leader Needs [https://open.substack.com/pub/datagibberish/p/the-data-engineering-manager-operating-system?utm_campaign=post-expanded-share&utm_medium=web] * Business value mapping playbook: How to translate data work into executive language [https://open.substack.com/pub/datagibberish/p/translate-data-work-into-executive-language?utm_campaign=post-expanded-share&utm_medium=web] * How To Stop Waiting For Permission To Lead Data Engineering [https://open.substack.com/pub/datagibberish/p/how-to-stop-waiting-for-permission-to-lead-data-engineering?utm_campaign=post-expanded-share&utm_medium=web] * Why Senior Data Engineers Lose Their Velocity (Even When Their Skills Improve) [https://open.substack.com/pub/datagibberish/p/the-senior-data-engineer-paradox?utm_campaign=post-expanded-share&utm_medium=web] This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe [https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2]

University Doesn't Teach Data Engineering. Here's What You're Missing.

I had a chat with Mihail [https://www.linkedin.com/in/mihail-petrov/], a software engineering lead who also lectures at Plovdiv University. He teaches data engineering as an elective because the core CS curriculum has zero room for it. That tells you everything about the state of data education. Universities produce graduates who know SQL syntax, basic normalization, and enough theory to pass an exam. Then those graduates walk into jobs where the theory is the easy part. The pipelines, the warehouses, the cloud platforms, the stakeholder conversations, the ambiguity of real problems. None of that shows up in a lecture hall. I got my databases grade in university and it was mediocre. I didn’t care because the course felt abstract and disconnected from anything real. Most students feel the same way. And the system does nothing to change that. The gap between what university teaches and what the job demands keeps growing. But the fix is simpler than most people think, and it starts long before graduation day. The Curriculum Stops at SQL University data education peaks at a single databases course in your second year. You learn what SQL is, what a database does, and some theory about normalization and data storage. The course is abstract. Students treat databases like glorified Excel files because nobody shows them why the syntactical overhead matters. Until you work on large-scale projects, the difference between a spreadsheet and a relational database feels like a bureaucratic formality. And that databases course is the baseline for everything data-related in the entire degree. Everything Beyond SQL Is “Too Specialized” From that point, data science branches into math and statistics. Data engineering branches into pipelines, warehouses, cloud platforms, ETL, governance. The university follows neither branch with any depth. The reason is structural. Introducing a new subject into a CS curriculum takes years of bureaucratic and administrative effort. Universities teach foundations because foundations are stable. Specific technologies move too fast for a system designed to change slowly. * SQL is foundational enough to make the cut * Snowflake, Databricks, dbt, Airflow are all “too specialized” * Anything resembling a real data engineering stack gets classified as professional training, outside the university’s scope Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. The 10-Year Lag Is Built Into the System Mihail put it bluntly. Universities are roughly a decade behind the industry. By the time a discipline earns a permanent spot in the curriculum, the profession has already moved on to the next generation of tooling. The workaround at Plovdiv University is elective courses. Mihail and his colleagues created an entire data engineering track outside the required curriculum. Students who are dedicated sign up semester after semester and piece together the big picture on their own initiative. A full data engineering discipline exists in the master’s program, but only because individual lecturers pushed for it. The core curriculum still treats data engineering as a niche profession. The students who figure out it matters do so despite the system, not because of it. Hard Skills Used to Be Enough. They Aren’t Anymore. A few years ago, knowing one programming language and one framework got you hired. The COVID-era hiring boom rewarded narrow skill sets. Companies needed seats filled. They needed people who could write code in a specific technology and ship tickets. Thousands of junior developers entered the industry every month on the back of a single concentrated skill. No curiosity required and no product understanding expected. Know React, get a job. That worked because the economics supported it. The Market Shifted and the Craftsmen Got Stuck The economics changed. Companies stopped hiring for volume. AI tools absorbed the foundational knowledge work. People who built their entire career around one framework or one language found themselves competing with a chatbot that explains object-oriented programming better than most university courses. Information is everywhere now. What separates a valuable engineer from a replaceable one is everything around the information. * Understanding the product and the customer * Adapting when the tooling changes underneath you * Operating with judgment in ambiguous situations * Communicating with stakeholders who speak a different language than you do Universities Still Train for the Old Game The university teaches you how to use tools. The job requires you to understand why you’re using them and what problem they solve for the business. Mihail made a sharp distinction. Universities produce IT people, not developers. The degree gives you logic, math, and a surface-level tour of programming concepts. But the industry needs people who solve problems related to communication, technology, and economics. Those are three different skill sets, and a CS curriculum addresses one of them on a good day. The people who stall are the ones who treat graduation as the finish line. The ones who keep going treat it as a starting point for a much longer education that happens inside the business, inside the community, and inside the messy reality of real projects. Your Network Is Your Actual Career Engine The cliche says your network is your net worth. It holds true even when you look for a job. Blasting CVs across LinkedIn is the path of least resistance. It feels productive because you’re doing something. But it’s a low-leverage move that puts you in a pile with hundreds of other applicants who look identical on paper. Mihail’s company has never posted a single job offer on a popular platform. They hand-pick students directly from the university. Every hire comes through relationships built during lectures, projects, and community events. That pattern repeats across the industry more often than people realize. Show Up Where the Decisions Happen Conferences and user groups are where project leads, hiring managers, and senior engineers gather to talk about the work they care about. These people are approachable in that setting. They want to talk shop. The move is to ask about their problems, not their openings. * What kind of scaling challenges are you dealing with? * Where does delivery break down on your projects? * What does your data stack look like and where does it hurt? These questions signal curiosity and understanding. “Do you have any open positions?“ signals desperation. One leads to a conversation. The other leads to a polite nod and a business card that goes nowhere. Make Yourself Visible Before You Need a Job If you’re early in your career and don’t have deep experience to share, you still have options. A GitHub project, a blog post about a technology you’re learning, a short tutorial, a LinkedIn thread documenting what you figured out this week. None of these need to be brilliant. They need to exist. Visibility compounds. The people who run conferences and user groups see the same faces year after year. They remember your questions, and when a role opens up on their team, they think of the person they’ve been talking to for the last six months before they think of the 200 CVs sitting in their inbox. I found my current company through conferences. Several people I’ve worked with came from user groups and community events. This is how the industry works when you look past the job boards. Find Misho Here’s how you can find more about Mihail and his initiatives for data newcomers. Everything he does at this point is in Bulgarian, but Mihail promised to start building educational content in English, too. * LinkedIn profile [https://www.linkedin.com/in/mihail-petrov/] * Snowflake user group [https://usergroups.snowflake.com/bulgaria/] * Free Snowflake course [https://discord.com/invite/hXzqRgBZ] Closing Words The university gives you a starting line. Logic, math, a community of confused peers who share your ambition. That matters more than the cynics admit. But the finish line is somewhere else entirely. The skills that make data engineers valuable are built in the space between academia and industry. Pipelines, product thinking, stakeholder conversations, judgment under ambiguity. No curriculum covers this. No lecture hall prepares you for the moment a stakeholder asks you to scope something that has never been done before and expects an answer by Thursday. The people who figure this out early have an unfair advantage. They show up at conferences while still in their second year. They build side projects that prove curiosity, not mastery. They surround themselves with people who are ahead of them and ask questions until the vocabulary clicks. The people who wait for a curriculum to teach them what the job demands graduate with a degree and a gap where their career momentum should be. University is a foundation. Treat it as one. Build everything else yourself. — Yordan More on the Topic * The Surprising Trait That Beats Experience [https://open.substack.com/pub/datagibberish/p/hiring-curious-data-engineers?utm_campaign=post-expanded-share&utm_medium=web] * Level-up Data Engineering [https://www.datagibberish.com/t/playlist-level-up-data-engineering] * Why the Hard Skills Obsession Is Misleading Every Aspiring Data Engineer [https://open.substack.com/pub/datagibberish/p/hard-data-engineering-skills-obsession-mistake?utm_campaign=post-expanded-share&utm_medium=web] This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe [https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2]

She Runs a $10k/Month Business Using Data and AI (and Her Title Says Marketing)

I invited Yana G.Y. [https://substack.com/profile/136431837-yana-gy] to a live conversation because she does something rare. She has a director title and a Substack generating between $5K and $10K a month on the side of her full-time banking job. And she runs it entirely on data. Data-driven the way subscription businesses actually operate it. Numbers connected to decisions, decisions connected to outcomes. Below are the ideas she shared. The full conversation is in the video above. Stakeholders Make Emotional Decisions First (and They Have Good Reason To) The standard data professional complaint is that stakeholders ignore data and run on gut. Yana flips that framing. Her view: Most people are wired to make emotional decisions first and look for data that confirms them second. From her background in neurolinguistic programming, she puts the share of people who genuinely process the world through numbers at around 15%. Everyone else needs a different approach. Showing up with a dashboard and expecting it to land is wishful thinking. Data needs a story around it. A number without context gets interpreted differently by every person in the room. One sees growth, another sees underperformance, a third questions whether the metric tracks the right thing at all. Yana learned this early. Every conversation with engineering teams felt like friction. She was asking questions they thought she should already know. They were building things that missed what she actually needed. The gap cost both sides time. What closed it was her decision to learn enough about how systems work to ask better questions. To stop being helpless in technical conversations. The One Move That Ends Arguments in Any Meeting Yana has one technique she uses across every organization. It works in telecom. It works in banking. She has a perfect record with it. Before any contentious conversation, find the data that links your ask to what the organization actually cares about. Customers, revenue, profit. Those three. Then add competitive benchmarks if you can find them. In her current bank, she came in and asked how many successful app registrations they were getting. She pulled the internal rate, found competitor data, and discovered some competitors were achieving double or triple the registration conversion rate. She put that in front of the team. The conversation changed. People stop defending their position when the data shows the position is costing them. Go into the meeting with the numbers already pulled. Link them to something the people in the room care about. Then let the data do the work. This applies directly to data teams. When a project needs prioritization, funding, or unblocking, skip the technical justification. Show the business number it connects to, then show where a competitor is already ahead. Data Gibberish is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. What Yana Actually Tracks on Substack Substack’s native analytics fall short. Yana built her own spreadsheet and tracks the following every month: * Total subscribers * New subscribers * Total paid subscribers * New paid subscribers * Churned paid subscribers * New revenue * Average revenue per subscriber per month * Average revenue per subscriber per year * Free-to-paid conversion rate * Net Promoter Score The benchmark Yana uses for revenue per subscriber is the email marketing industry average, ranging roughly from $1 to $12 per subscriber per year depending on niche. Above average means the business is healthy. Below average means something needs auditing. The NPS tracking is the piece most Substackers skip. She uses Substack’s survey feature to ask paid subscribers one question: on a scale from 1 to 10, how likely are you to recommend this publication to someone you know. That one question, run through the standard NPS formula, tells her whether her paid tier delivers real value. Her target is above 70. Yana’s reasoning: NPS is the only reliable signal for whether paid subscribers are satisfied or are simply on their way out. How She Runs a $10K/Month Business in the Hours Left Over From a Full-Time Job Yana works five days a week, eight hours a day, in an office. She can answer Substack comments during lunch or late after work. That’s the window she operates in. AI handles everything operational. Formatting, research, scheduling, the mechanical parts. For writing, she trained a system on her own content. She extracted all her published articles into a database, connected it to an MCP server, and built what she calls a second brain. She can query it for content gaps, understand what paid subscribers want more of, and run analysis on her own business data. She writes in her voice, informed by her own data, with AI executing the work that requires no judgment. Her warning about AI: It pulls you into rabbit holes when you let it. Every answer suggests the next step, and the next step, and an hour later you have built something with no clear business purpose. Use it to execute a decision. Know exactly what you want before you open it. Yana also made the point that the 9-to-5 built the Substack. The telecom career gave her subscription business knowledge, customer journey expertise, conversion rate benchmarks, and an understanding of which metrics actually predict business health. All of it went directly into how she runs the newsletter. The side business grew because of the day job. Final Thoughts Yana has 15 years of subscription business experience, a disciplined tracking system, and a clear rule: link your ask to numbers that matter, then find the benchmark that shows where you stand. That’s the part worth sitting with. Data professionals spend time arguing that stakeholders ignore data. Yana learned enough about systems to have real conversations with engineers. She built her own analytics because the platform’s fell short. She tracks NPS because her industry background taught her it mattered. The gap between business and data closes when people on both sides decide to move. Yana moved. The engineers still telling business people to figure it out on their own are the ones falling behind. Interested into growing your Substack? Subscribe to Yana’s publication [https://www.yana-g-y.com/]. This newsletter is funded by paid subscriptions from readers like yourself. If you aren’t already, consider becoming a paid subscriber to receive the full experience! See what people say about working with me. [https://www.datagibberish.com/p/become-a-member] You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.datagibberish.com/subscribe [https://www.datagibberish.com/subscribe?utm_medium=podcast&utm_campaign=CTA_2]