Imagine walking into a room where your team is debating the merits of Snowflake & Kafka, or whether a data transformation layer needs dbt (Data Build Tool) to ensure consistency. As a project manager (PM) with a non-technical background, this might feel like stepping onto another planet. But here’s the secret: You don’t need to code to lead technical projects. You just need to bridge the gap between what you know and what your team does.

This is the story of how non-technical PMs can thrive in data engineering by embracing curiosity, asking the right questions, and building a foundation of understanding. Let’s dive into the first steps of this journey.

Transition into data engineering project management always begins with a mix of excitement and panic. As a non-tech PM you might have successfully managed marketing and operations teams, but data engineering? Terms like “ELT,” “data modelling,” and “orchestration” felt like a foreign language. Early on, you have to make a critical decision: I wouldn’t become an expert, but I would become fluent enough to earn my team’s trust.

‍

Understanding Data Engineering Basics (Without Coding)

You don’t need to write SQL to grasp data engineering fundamentals. Start with these analogies:

1. Snowflake = A Library with Superpowers
   Think of Snowflake as a digital library where data is stored (like books on shelves) and analyzed (like librarians fetching specific books). Its “superpower” is scaling compute resources independently from storage—imagine hiring extra librarians during a rush without building a bigger library.
2. dbt: The Blueprint for Transformations
   dbt (Data Build Tool) is like a recipe book for transforming raw data into analysis-ready tables. Instead of writing custom scripts every time, engineers use dbt to create reusable SQL “models” (recipes) that standardize how data is cleaned, aggregated, and tested.
3. Data Orchestration = Air Traffic Control
   Tools like Airflow or Prefect act as air traffic controllers for data pipelines. They schedule tasks (e.g., “run this dbt model after Snowflake finishes ingesting data”) and ensure workflows don’t collide.

Overcoming the Knowledge Gap: How to Learn (Without Drowning)

As a non-technical PM, your goal isn’t to master DBT’s Jinja templating—it’s to speak the language of your team. Here’s how you can close the gap:

1. Learn by Osmosis
   
   • Shadow Engineers: Ask your teammate to walk you through a dBT project. Seeing how models were organized (staging, intermediate, mart layers) demystified the transformation process.
   • Watch Explainers: YouTube channels like Dbt Labs or Snowflake’s “Powered By” series broke down concepts in plain English.
   • Play with Tools (Sort Of):  Explored Snowflake’s UI to grasp concepts like “virtual warehouses” (compute clusters) and cloned demo dashboards to see how queries worked.
2. Ask, “Why?” Relentlessly,
   When a developer says, “We need to refactor this DBT model,” You should be asked:
   
   • “What’s the business impact of this change?”
   • “How will this affect downstream dashboards?”
   • “Can we automate testing here?”
3. Leverage Visual Tools
   Tools like dbt’s Lineage Graphs should become your best friend. Use & understand diagrams of how raw data morphed into final tables, making it easier to explain dependencies to stakeholders.
4. Embrace the Glossary
   . keep a running list of terms like:
   
   • ELT (Extract, Load, Transform): Snowflake’s approach: load raw data first and transform it later (vs. traditional ETL).
   • Data Vault: A modelling methodology sometimes used with DBT.
   • Time Travel: Snowflake’s feature to query historical data.

‍

Challenges Faced By Non-Technical PMs (And How to Overcome Them)

Even after grasping the data engineering basics, you'll encounter certain challenges. Here's what might trip you up - and how to overcome them.

‍

1: Feeling Lost in Conversations

When engineers debate technical concepts behind the product, it's easy to feel like an outsider. This knowledge gap can lead to misaligned priorities and unrealistic expectations.

Solution: Ask questions – lots of them. Sketch diagrams of what you understand and use them to explain your POV in discussions. Your goal shouldn't be to sound technical but to bridge business needs with engineering efforts.

‍

2: Underestimating Data Complexity 

Not all data is clean or ready for reporting. Issues like missing data, schema mismatches, or duplicate records can screw the insights. That "sudden revenue drop" might be just bad data, not an actual sales decline.

Solution: Prioritize data validation using tools like dbt tests . Always review sample datasets before launch, track data freshness, and push for well-documented metrics.

‍

3: Letting Tech Debt Become a Bottleneck

Stakeholders always want new features. To satisfy them, you might ignore slow-running queries (aka tech debt), but it will eventually hurt scalability.

Solution: Balance new feature requests with tech debt fixes. If asked for a new request, ask: 

• "Will this still be relevant in 6 months?"
• "Will ignoring tech debt now make future work harder?"

‍

4: Vague Problem Statements = Wasted Engineering Time

Saying "we need a faster dashboard" without defining "slow" forces engineers to guess the issue. This leads to wasted efforts and frustration.

Solution: Before bringing a request to engineers, clearly define what problem you're solving. Define speed in measurable terms (e.g., load time should be <5s). Work with stakeholders to document clear use cases.

‍

5: Ignoring Data Governance & Compliance 

Collecting every bit of data might seem smart, but without governance, it's a legal time bomb waiting to explode. There's always a possibility of exposing sensitive data. Also, privacy laws like GDPR, CCPA & internal governance policies restrict how long you can keep data, so ignoring them will only force painful rework.

Solution: Loop in compliance teams early to define data retention & masking policies even before data is ingested.

‍

As a PM, you aren't just an advisor; you’ll work with engineers, designers, marketing, data science, & customer success teams. So, you shouldn't worry too much about the lack of technical skills as they’re just a small part of the full roster of skills you need for this job.

‍

Best Practices for Non-Technical PMs in Data Engineering

1. Build a Shared Vocabulary
   While you don’t need to code, you do need to understand what your team is talking about. Maintain a glossary of key terms and regularly update it as you learn. This ensures you can follow discussions without getting lost.
2. Prioritize Clear Communication
   The biggest challenge in any data engineering project isn’t technology—it’s alignment. Ensure everyone, from engineers to stakeholders, understands objectives, timelines, and constraints.
3. Stay Curious & Keep Learning
   Technology evolves quickly, and data engineering is no exception. Set aside time each week to read industry blogs, watch explainer videos, or attend webinars on emerging trends.
4. Use Visual Aids to Bridge Gaps
   Flowcharts, lineage graphs, and dashboard mockups help non-technical and technical teams stay aligned. These tools make complex data architectures easier to grasp.
5. Make Data Governance a Priority
   Work closely with compliance teams to establish clear policies on data retention, access controls, and security. Address these early to avoid legal or operational challenges later.
6. Balance Tech Debt & New Features
   Don’t let stakeholder demands dictate unsustainable development. Advocate for regular tech debt cleanup to ensure long-term project scalability and efficiency.
7. Master Stakeholder Management
   Engineers want clarity, executives want results, and customers want seamless experiences. Learn to tailor your communication style to each group while ensuring alignment across the board.

‍

Key Takeaways for Non-Technical PMs in Data Engineering

• You don’t need to code, but you must understand data engineering concepts well enough to facilitate informed discussions.
• Asking the right questions is more valuable than pretending to know the answers.
• Data projects are only successful if business and technical teams work in sync—be the bridge between them.
• Managing expectations is just as important as managing sprints and deadlines.
• Data quality issues can derail entire projects—advocate for strong validation and testing processes.
• Build strong relationships with your technical team. Trust and open communication are your greatest assets.

Advice for Aspiring Project Managers in Data Engineering

1. Embrace the Beginner’s Mindset
   It’s okay to start with zero knowledge. The key is to be willing to learn, ask questions, and refine your understanding over time.
2. Find a Mentor in Data Engineering
   Partnering with a data engineer or senior PM can accelerate your learning curve. Don’t be afraid to seek guidance.
3. Develop a Business-Centric Mindset
   Understanding how data solutions impact business decisions will make you an invaluable asset. Learn how data-driven insights improve operations and strategy.
4. Get Comfortable with Uncertainty
   Data projects often involve ambiguous requirements, shifting priorities, and unforeseen technical hurdles. Adaptability and problem-solving skills are crucial.
5. Leverage No-Code & Low-Code Tools
   Tools like dbt, Fivetran, and Airbyte provide user-friendly interfaces for data transformation and integration. Exploring them will deepen your understanding without needing to code.
6. Practice Translating Technical to Non-Technical
   Being able to explain technical concepts in simple, business-friendly terms is one of the most valuable skills you can develop as a PM.
7. Celebrate Small Wins
   Data projects can be long and complex. Acknowledge milestones, even small ones, to keep morale high and momentum going.

By following these best practices, takeaways, and advice, you’ll not only survive but thrive as a non-technical PM in the data engineering space.

‍