L8Conf 2025 Summary
A Journey Through Staff Engineering Excellence
Last week, I went to L8Conf in Warsaw, Poland, a two-day conference about staff engineering and technical leadership. The event was on March 17-18, 2025, and brought together smart people to share ideas and advice for engineers who want to make a bigger impact at work. This conference filled a gap in Poland's tech conference scene.
The name L8Conf refers to Layer 8 of the OSI model—the human layer above the seven technical layers. It might also mean "Late Conf" for the later parts of a tech career. Throughout the event, speakers emphasized that senior engineers need more than just technical skills—they also need good communication, influence, strategic thinking, and experience.
What made this conference great was the quality of the talks. All presentations were highly rated (at least 4.5/5), but some were truly outstanding, getting perfect scores or better. These talks gave me insights that will change how I approach engineering leadership. Below, I've summarized the best talks that impressed me the most.
Creative Engineering: The Subtle Art of Cutting Corners - Wojciech Pituła
Wojciech Pituła gave one of the most surprising yet useful talks at the conference. His talk on "Creative Engineering" challenged the common belief that cutting corners is always bad. Instead, he showed it as a smart way to learn more and deliver value with less work—which is what agile development is all about.
What made this talk, so good was Wojciech's willingness to question what everyone thinks is true. He took apart common beliefs like "sending code over the wire is not a good idea," "you need proper ETL," and "SQL views are slow." For each one, he showed real examples where breaking these rules led to simpler, better solutions.
The talk was great because it was practical. Instead of talking about perfect solutions, Wojciech shared creative fixes from his own work that balanced how well something works, how reliable it is, and how complex it is. His approach showed that sometimes the best solution breaks the rules.
His final message—"If you don't see any other way, challenge standards"—reminds us that new ideas often come from questioning what everyone does. This talk highlights to me that I need to push others to think more creatively about technical problems and to better weigh the pros and cons of different approaches.
From Side Hustle to Full-Time Open-Source Gig - Jarek Potiuk
Jarek Potiuk gave a helpful talk about switching between technical and management jobs. From his own experience, he showed that you don't have to become a manager to advance your career.
He was honest about the mental stress of working in jobs that don't fit you well. Jarek talked about times when he realized management roles weren't right for him, which helped others think about their own situations.
The talk showed that moving from management back to technical work is a smart choice, not a failure. As someone who works on Apache Airflow and contributes to the Apache Software Foundation, Jarek shared practical advice about working full-time in open source.
His simple advice—"If management doesn't feel right, or you're unhappy at your company, just step back!"—cut through the pressure to climb the corporate ladder. Jarek explained how to make money while working independently on open-source projects, showing senior engineers they can have good careers outside traditional companies.
Many people thinking about their next career move found this different view really helpful.
How to Sell a Big Refactor or Rewrite to the Business? - Ivett Ördög
Ivett Ördög gave a great talk about how tech leaders can convince business people to fund big code cleanup projects. Her talk was refreshing because she didn't just say "never rewrite code" like many engineers do, but she also didn't say "always rewrite" either.
The best part was how she showed different investment patterns with pictures. She showed that good design pays off more over time, while bad design gives fewer benefits as projects get older. Her graphs showed how taking risks early affects whether a product succeeds long-term. She warned startups that starting fast but needing rewrites later can kill their business because losing momentum during rebuilding often ends promising ideas.
She warned that "Usually, rewriting software is lost time and money!" but explained when rewrites might make sense. Ivett stressed the need to explain technical debt using business terms and to present options with clear trade-offs instead of pushing just one solution.
What made this talk, so good was how it balanced tech and business views. Ivett gave a way to discuss technical debt that makes sense to non-technical people, with specific communication tips engineers can use right away in their companies.
Overcoming Bottlenecks of Platform Teams - Candost Dagdeviren
Candost Dagdeviren's talk on "Overcoming Bottlenecks of Platform Teams" shared useful ideas about a problem many companies face when using Team Topologies. As an Engineering Manager at SumUp, he brought real-world experience to this topic.
The talk showed the difference between how platform teams should work in theory versus reality. Platform teams are supposed to make work easier for other teams by providing reusable tools and infrastructure, but they often end up slowing things down instead. Candost showed this using pictures comparing the ideal "Platform Magic" with the messy reality.
What made this talk really helpful was Candost's honest take that "Platform Engineering is always a kind of compromise." This showed that there's no perfect answer—just careful trade-offs that need ongoing attention.
The most useful part was his explanation of how platforms must serve many needs across products, reports, rules, and analytics while keeping everything working together. His diagrams showing how platform parts connect provided a clear picture of platform design.
For engineers working on or with platform teams, this talk offered both big-picture thinking about platform design and practical ways to spot and fix bottlenecks before they slow down the whole company.
Using metrics to foster change - Krystian Cybulski
Krystian Cybulski's talk was simple but powerful. While other speakers elaborated on complex leadership ideas, Krystian showed that sometimes the best tool for staff engineers is just making things visible with basic numbers.
What made his talk great was that it focused on real-world use, not just theory. He showed how simple metrics can reveal problems that stay hidden even in well-run organizations. His examples showed how struggling teams found clarity once they could see key metrics.
One example I remember was about a team stuck debating architecture for weeks. By tracking just three basic things—how often they deployed, error rates, and how long features took—Krystian helped them see their real bottleneck wasn't what anyone thought. This immediately changed their discussions from theory to actual improvements.
"Numbers tell stories that opinions cannot," Krystian said, showing how simple dashboards changed how teams worked together. What stood out was his point that good metrics don't need to fancy tools or data science—they just need thoughtful picking of what matters most in your situation.
For staff engineers trying to drive change, this talk reminded us that sometimes the best approach isn't creating new solutions but making existing problems visible through carefully chosen metrics. As Krystian put it, "You can't improve what you can't see, and you can't convince others to change what they don't believe exists."
"I'm Not Cleaning Up Their Mess!" Let's Discuss Legacy Systems - Artur Skowroński
Artur Skowroński's talk about old computer systems offered a fresh take on the common "just rebuild everything" idea. From his work with big systems at large companies, Artur showed how making smart, targeted changes can work better than complete rewrites.
What made this talk really useful was Artur's practical approach. Having worked with similar systems in banking and telecom companies, I thought, "I'm not alone in this experience". He shared a story about his team facing a huge, all-in-one system with important business rules buried inside and few tests—something many people in the room knew all too well. Instead of suggesting they start over, Artur explained how they found key connection points and made strategic changes that changed how other teams worked with the system.
"We don't need perfect architecture," Artur said, "but we need to allow growth and new ideas while accepting what we already have." This idea backs up what Ivett said earlier about how big rewrites usually end badly.
Artur's method focused on what we might call "interface-first evolution"—caring more about how systems talk to each, besides what's happening inside them. By building clean, well-documented APIs that hide the mess inside the old parts, his team helped other groups build modern features without waiting for the whole core system to be updated.
The best part of the talk was seeing the before-and-after picture showing how development speed improved across many teams after these targeted changes. Without changing 90% of the old code, they unlocked major improvements through smart architectural thinking.
For engineers dealing with complex old systems, Artur showed a good middle path between doing nothing and changing everything—showing how careful, step-by-step changes to system interfaces can bring big value while lowering risk.
Decision-Making for High-Performing Work Environments - Sebastian Gębski
Unlike most talks about decision-making that are too abstract, Sebastian gave practical advice you can use right away. He showed how good decision processes improve how teams work together and what they deliver in real engineering organizations.
Sebastian Gębski's talk on decision frameworks really connected with me, since I've been writing about RAPID-based modernization and finding the right decision makers in complex tech environments.
"Better decisions lead to better results," Sebastian said, "but a better decision-making process makes those results last." This difference between single decisions and having a good system for making decisions matches what I've seen when leading modernization projects.
The most useful part was Sebastian's "pick your battles" idea—a practical approach recognizing that not all decisions need the same process. He shared a simple framework for sorting decisions based on how easily they can be changed, who they affect, and their risk level, showing that different decisions require different approaches.
Sebastian's best point, which I entirely agree with, was that "we are all sellers." Having pushed for customer-focused selling for years, I strongly agree that tech leaders need to know how to sell their ideas. As we might say, "The best technical solution that nobody uses is worthless."
This selling mindset isn't about manipulation—it's about understanding what stakeholders need and presenting solutions in ways that matter to them.
For staff engineers wanting to make real change, Sebastian's framework provided practical tools for handling the people side of technical decisions—showing how to balance including everyone while still being efficient, and how to create decision processes that build trust across the organization.
Driving Change and Making an Impact as Staff Engineer - Michał Franc
Michał Franc's opening talk really set the stage for the conference by talking about the main challenge for staff engineers: making important changes across different parts of an organization. Using his 16 years of experience at companies like JustGiving, JustEat, Form3, and Affirm, Michał showed how the staff engineer job has become about more than just technical skills. I think it was the best talk of the whole conference.
What I liked most was his idea of the "Modern Engineer" who has both broad skills and in-depth knowledge in specific areas. He showed this with a helpful picture that explained how junior engineers mostly focus on coding, while staff+ engineers work on architecture, testing, understanding the business, and infrastructure—while still being able to connect all these pieces in a smart way.
His point that "Senior Engineering Roles are about people, not about Coding and Technology" made everyone think differently about their value. His reminder that modern IT exists to create business value, not just to play with cool technologies, was something many people in the audience needed to hear.
Michał showed how staff engineers connect technical work with business goals. His slide translated business problems into specific tech actions. This helps engineers understand how to turn business concerns into real technical solutions, which is key for making a big impact.
Michał's talk provided a transformative perspective on staff engineering through two powerful metaphors. As "glue engineers," senior technical leaders connect disparate parts of the organization—bridging teams, departments, and domains while identifying and fixing systemic disconnects. Meanwhile, as "water engineers," they demonstrate crucial adaptability, knowing when to stand firm on principles and when to flow around obstacles to deliver business value. This dual capability allows staff engineers to translate business metrics into technical initiatives while navigating organizational complexities. His framework challenged the audience to evolve beyond technical purism toward a more holistic approach that balances technical excellence with practical business outcomes—ultimately showing that true engineering leadership requires both technical depth and organizational fluidity.
Key Takeaways from L8Conf 2025
The conference delivered exceptional value through its laser focus on the human aspects of technical leadership. Several themes emerged across the various talks:
Technical expertise alone isn't enough - The most effective staff engineers combine deep technical knowledge with strong interpersonal skills
Business impact matters most - Understanding how technical decisions affect business outcomes separates good engineers from great ones
Communication bridges worlds - The ability to translate between technical and business domains is perhaps the most valuable skill a staff engineer can develop
Adaptability is non-negotiable - The metaphor of "water engineering" resonated with many attendees, who recognized the need to be both principled and flexible
Community is crucial - The connections formed at L8Conf demonstrated that staff engineering can be a lonely role, and having peers to share experiences with is invaluable
What struck me most was how the conference created a space where technical leaders could openly discuss challenges that are rarely addressed in typical engineering forums. The honesty with which speakers shared their failures alongside their successes created an atmosphere of authentic learning rather than simple knowledge transfer. I hope to see a good community develop around the L8 Conf Discord channel, and I'd love to give a talk at the next edition in 2026.