WHERE ENGINEERING LEADERS CONNECT.

Let’s be real: building amazing tech isn’t just about writing great code; it’s about having a team that works well together. As a freelancer, I’ve faced some of the same issues popping up repeatedly in different teams or companies. I will share the most common struggles tech teams face daily. Whether you’re a developer, a manager, or just someone who wants to improve the workplace, you’ll leave with practical tips to help your team work better together, stay motivated, and hit your goals!

As mobile orgs grow, bottlenecks like slow builds, flaky CI, duplicated code, inconsistent architecture can cripple delivery speed and developer productivity. In this talk, I’ll share how our mobile platform team turned things around: cutting build times, automating releases, building shared component libraries, adopting Compose Multiplatform, and more. Whether you already have a platform team or forming one, you’ll leave with fresh ideas, proven patterns, and an appreciation for teams that power great mobile engineering.

A strong engineering culture is crucial for mobile teams to scale efficiently, retain top talent, and drive innovation. This roundtable will explore strategies for fostering an adaptive, inclusive, and high-performing engineering culture across remote, hybrid, and in-person teams. > What are the most effective ways to document, spread, and reinforce engineering culture in mobile teams? > What common pitfalls can erode engineering culture, and how can leaders prevent them? > What metrics or signals indicate a thriving vs. struggling engineering culture? > What strategies to use for reducing knowledge silos? > How to set stretch goals and maintain a healthy balance of context switching to keep the team members engaged and motivated? > Why is the skill/will matrix important when delegating tasks?

For anyone who moved from being an Individual Contributor (IC) into Engineering Management, systems design interviews are a staple, effectively replacing the live-coding interview. However, there are an increasing number of interview processes where ICs find themselves faced with a full-stack systems design interview. If you’ve been a mobile developer all your career, being suddenly asked to outline the intricacies of individual microservices or to explain why you’d use a certain database paradigm over another can be an entirely new world. This is not a talk for people who hate systems design, but who find the vast potential scope and deeply varying expectations in systems design interviews difficult to overcome. If you thought coding challenges were subjective, wait until you’re doodling diagrams and outlining schemas on an online whiteboard. You can be rejected by one company for going into too much detail, and by another for being too high-level. One interviewer might be impressed with your attempt to delve into an area you don’t understand, whereas the next considers it a cardinal sin and expects you to simply say you don’t know. What you’ll (hopefully) take away from this talk: - How to prepare and which resources are especially useful for doing so. How to decide what to focus on in your preparation based on the role, the company and its product. - What to ask prior to the interview in terms of gleaning the expectations of your interviewer, and how to do it without worrying you sound like you’re asking for the answers. - How to ask the right questions and say the right things during the interview to ensure you’re not drifting astray from the interviewer’s expectations. - A short look into the minimum set of principals you should know that are common to most systems design interviews*. - Some concrete examples of traps Chris fell into, what he learned from them, and how you can avoid them. *NB. Please be aware that this won’t be a deep-dive into the intricacies of systems design itself - there simply wouldn’t be time for that - but we will go through some of the very common basic concepts that come up regularly. There are plenty of excellent resources out there that will help you deep-dive into those concepts, and they’ll be highlighted in the talk.

Every seasoned engineer knows the tension between what the codebase needs and what the product demands. As systems evolve, legacy decisions accumulate, and the codebase becomes more complex, and more difficult to maintain. That's when the urge to refactor, or start from scratch comes in. This roundtable invites experienced engineers to discuss around the real-world complexity of refactoring at scale: when to do it, how to argue for it, and what to do when it’s simply too expensive. When does “ugly but stable” code become a real liability? What are the hidden costs of keeping legacy systems alive? What’s the right balance between incremental improvement and “big bang” rewrites? How do you justify refactoring work when it doesn’t align with roadmap goals? What does a “refactoring culture” look like in a truly high-performing engineering organization?

I can guess a few things you might be thinking now. Either I am lying, or I just don't know what technical debt is. Or maybe I am just bad at my job and these opinions will blow up in my face a year from now. Maybe the last one is true, time will tell! But I think a lot of technical debt is a mindset about your codebase. But over the last two years, we have taken our Android app, used by millions of Norwegians, from a place where you could see its legacy as an SDK to a codebase where we can make changes and add features so quickly it can be inconvenient. I think the way we got here is pretty simple: take ownership of your codebase. In this talk, I will explain what that loaded statement means, and how you too can be tech debt free in no time!

AI coding assistants have been hyped as game-changers for software engineering, but how effective are they in practice? This session provides a reality check on current AI coding tools, analyzing what works, what doesn’t, and how these tools impact software development workflows. You'll get a chance to discuss best practices, challenges, and the future trajectory of GenAI in software development with your peers and examine: > What is the current state of AI coding assistants? >How are AI coding assistants improving developer productivity? > What AI tools are effective for software development today, which ones are disappointing? > What are the future trends and implications of AI-driven software development? > What are the implications for cross-platform development?

The Challenge: Your best Individual Contributors (ICs) might be technical wizards, but their career trajectory—and your team's efficiency—is often hampered by ineffective communication. Time lost to unclear requirements, redundant meetings, and misaligned priorities is a direct tax on your engineering output and their potential. The Focus: This talk provides engineering managers, CTOs, and tech leads with a practical framework for actively coaching and guiding ICs to become better, more strategic communicators. We'll move beyond generic advice to explore hands-on, actionable strategies that leaders can implement immediately. You Will Learn How To: Establish Cross-Functional Clarity: Equip ICs with the tools and language to interface effectively with Product Managers, UI/UX, and QA. Learn how to leverage existing developer tooling and AI to create communication bridges that reduce friction and cycle time. Optimize Meeting ROI: Shift the team culture from passive attendance to active, outcome-driven engagement. Discover leadership techniques to define, enforce, and facilitate meetings that consistently achieve their goal, minimizing wasted time for your high-value developers. Maximize Professional Development (and ROI): Guide ICs to be proactive, high-impact representatives of the team—whether in an internal meeting or at an industry conference. Learn how to coach them to build meaningful connections, ask strategic questions, and translate external learnings directly back into team value. Outcome: By embedding a culture of high-impact communication, leaders can unlock the next level of performance in their ICs, accelerate career development, and significantly boost overall team productivity.

Owning and delivering a feature might seem like a standard responsibility for senior engineers and tech leads—but doing it exceptionally well is rarer than you'd think. This roundtable brings together seasoned leaders from Android and Flutter teams to discuss the often-overlooked mistakes that can derail feature development, even for experienced ICs and EMs. From poor documentation and unclear communication to lack of collaboration and hidden decision-making, we'll explore what not to do—and how to do better. Together, we’ll share stories, surface patterns, and identify habits that lead to smoother execution, stronger team dynamics, and better outcomes. What’s one misstep you've seen (or made) when leading a feature that created avoidable friction or confusion? How do you balance speed with documenting decisions and trade-offs—especially when timelines are tight? Have you ever seen (or experienced) communication breakdowns because too much happened in DMs or side chats? How do you promote visibility without slowing down progress? How do you encourage engineers to challenge each other’s solutions without creating tension or hierarchy in the team? What strategies have worked for you to keep large features on track without micromanaging every detail?

Building effective development teams hinges on prioritizing the developer experience. Poor tooling and inadequate support lead to cumbersome builds and inefficient workflows, creating friction that slows engineers and hinders their ability to deliver value. Join this peer discussion to share and discover practical strategies for boosting developer velocity and satisfaction. > How can we effectively measure the developer experience to pinpoint specific friction points that negatively impact team velocity and satisfaction? > What tools or strategies effectively boost knowledge transfer, reduce cognitive load, and accelerate onboarding? > What are your team's biggest DX pain points with builds, IDE, or CI, and what proven leadership tactics address them? > Where does your team experience the most friction day-to-day (e.g., with builds, IDEs, CI/CD, inefficient workflows)? What practical leadership tactics or tooling improvements have successfully addressed these pain points? > How can engineering leaders effectively quantify the impact of DX improvements on velocity, satisfaction, or overall value delivery to justify necessary investments to stakeholders?

Building and leading effective development teams hinges on prioritizing the developer experience. But how do you know what to focus on and how do you measure what is working? What tools and strategies can eliminate friction that slows engineers and hinders their ability to deliver value? What role is AI playing in DevEx? Join us for a peer-level discussion as we talk about: What are your team’s biggest DX pain points with builds, IDE, or CI, and what proven leadership tactics address them How can engineering leaders effectively quantify the impact of DX improvements on velocity, satisfaction, or overall value? What practical leadership tactics or tooling improvements have successfully addressed these pain points? How can we effectively measure the developer experience to pinpoint friction points that negatively impact team velocity and satisfaction?