Prototype, influence, build skills and deliver value
Four things that have helped me make a greater impact
I’ve learned that being a well-rounded data engineer goes beyond technical skills. It’s about how you approach problems, communicate with teams, and deliver outcomes. Here are four ideas that have helped me work better and make a greater impact, with some examples.
TL;DR
Build small prototypes for early feedback and team alignment.
Use demos and clear communication to gain influence and trust.
Develop T-shaped skills by combining deep expertise with broad knowledge.
Focus on solving problems instead of chasing tools or certifications.
Build small, share quickly
When you’re tackling complex projects, it’s tempting to try and plan every detail upfront. Starting with a prototype creates momentum and gives everyone something to discuss.
It lets you fail quicker and refine ideas before significant effort is spent on detailed plans. Design documents have their place in serving the wider team, but the best design emerges out of hacking first.
For example, this works well when working on a new data pipeline. Start with a high-level API representing the desired workflow, with placeholder functions where details are needed. Sharing this prototype can help clarify what to build and divide future tasks.
Here’s how I approach prototyping:
Start simple: Focus on the main functionality, leaving out non-critical details for now.
Use placeholders: Don’t wait for all inputs or data to be ready and use mocked data if needed.
Share early: The sooner your team can react to something tangible, the faster you’ll identify gaps or better ideas.
The goal is to get early feedback and alignment from others. This lets you try multiple approaches before settling on a final solution.
Influence without authority
The best way to influence is by showcasing your work through demos and over-communicating. This means announcing things in daily standups, team channels and anywhere else where people working with you would benefit from knowing about your work.
Since data engineers rarely have the final say on strategic decisions, influencing without authority becomes an important skill to ensure your ideas are heard.
While working on a migration project from Jenkins to GitLab, I had a chance to suggest a better way to structure our build pipelines. I wanted to use standardised YAML templates to create our Lambda functions and Python utility packages.
I started with something simple and shared it with the team. We learned more about the features of GitLab, which worked well with extensibility and reusing components.
My initial demos were not perfect, but it was enough to demonstrate the idea, and they made the benefits clear to everyone. Sharing these ideas across the business helped engage with other teams as they also migrated.
To build influence without formal authority:
Demonstrate your ideas: Use demos and proof-of-concepts to make your ideas tangible.
Document clearly: Good documentation like README's, wiki's and diagrams builds trust and helps others understand your thinking.
Bridge silos: Take time to explain technical concepts in simple terms, especially to non-technical stakeholders.
When others see the value you bring, they’ll be more open to your ideas, and you'll build trust, regardless of your seniority.
Balance technical depth with breadth
The best data engineers I’ve worked with were T-shaped as they often wore multiple hats. T-shaped data engineers have deep expertise in one area but also know enough about adjacent topics to collaborate and solve problems across domains.
This versatility has been a huge advantage in my work as I have mostly worked in small data engineering teams where we managed our cloud infrastructure and deployed our tools.
One of my previous managers encouraged this by giving me different opportunities, which helped me learn new skills and eventually boosted my performance rating.
Learning Terraform has been a huge plus for me in my current role, and I’ve picked up enough networking basics to troubleshoot issues when services fail due to VPC misconfigurations, for example.
To develop T-shaped skills:
Go deep in your core area: Be the go-to person for at least one technical domain, whether it’s data pipelines, deployment, unit testing or data quality checking.
Explore related fields: Pick up foundational skills in areas like pipeline monitoring, CICD or orchestration frameworks. Even a basic understanding can help you bridge gaps and communicate with others who may be assisting you.
Having a broad base of knowledge makes you more adaptable, enables you to contribute to a wider range of problems and may future-proof your career.
Focus on value, not tools
As I took on my first data engineering role, I got caught up in certifications, and I thought being “AWS Certified” or mastering a specific platform was the key to success. I spent months aiming to get certified on GCP, only to switch to AWS when I changed roles.
As I worked on more projects and moved companies for different learning opportunities, I realised that the tools constantly change, but the fundamentals remain similar. The real measure of success became whether I was solving new problems and creating value.
What mattered more than the platform was understanding concepts like event-driven architecture, microservices, and efficient pipeline design.
Here’s what I’ve learned:
Prioritise fundamentals: Focus on concepts that are not tied to a single platform, like SQL optimisation, data modelling, design patterns and ETL.
Learn versatile tools: Open-source technologies like Airflow or Iceberg since they’re widely used and often have managed vendor services.
Stay adaptable: Tools will always change, but my ability to learn and apply them to solve problems is what matters.
By focusing on skills that transcend tools, you stay relevant no matter what the latest trend or technology is.
What’s worked for me as a data engineer is keeping things simple: start small, communicate clearly, and focus on solving real problems. They’re habits that have helped me deliver better results and be recognised for my work.
Thanks for reading,
Elias