2025: What a year as an engineering lead
Prolog:Link to this section
In February 2023, I started as team lead for the Composable Frontends team at shopware AG. A few months later, I was also put in charge of the Storefront team. Basically, everything the customer could see in an online store was my responsibility.
We had great discussions about the future of the storefront. Should Composable Frontends be the future? Was the old Twig no longer needed? We fought for two parallel solutions targeting different use cases, developers, and tech stacks.
Towards the end of 2024, I was asked if I wanted to lead the framework team. Why not? What could go wrong?
Turns out, a lot could go wrong. And a lot did. But we also learned, grew, and achieved more than I expected. This is the story of 2025, written from my very subjective point of view.
How it startedLink to this section
So what’s the challenge? The new Framework Team was created from four different teams: Composable Frontends, Storefront, Core, and Administration. The idea sounds easy: reduce communication overhead between the teams, make it easier to work together, and make it easier to scale. But the start of 2025 was not as smooth as expected. We had a lot of side quests going on that hit us hard. We moved development from GitLab to GitHub and also needed to migrate all our pipelines to GitHub Actions. As an open-source company, we wanted to move away from closed issues in Jira to transparent issues on GitHub to work closer with the community. Besides these challenges, we needed to release the next major version 6.7, which included features like cache rework, library updates, accessibility improvements, Webpack to Vite migration, and more.
How to surviveLink to this section
With the old Storefront Team and the Composable Frontends Team, we always did the planning on our own. Brainstorming, asking the community, getting customer or project feedback, and so on. At the beginning of 2025, some people from Project Management and Product Management joined the team. The idea was to make the transition from GitLab and Jira to GitHub and GitHub Issues easier. It worked out to some extent, but we hit a lot of road bumps. My biggest mistake was that I waited to work on a roadmap together with project and product management. The idea was simple: let’s do this together so everybody is on board. But the plan for after the major release was not really done by the team. The result was that the team questioned the roadmap a lot; some epics were not in good shape, and some epics had blockers from the start. So the team didn’t really want to follow the epics (aka roadmap). The team focused on the most important issues and maintenance. There was a mismatch between how the team saw itself and how it was being measured and organized.
And what happens if people do not feel connected to the software they are building? Yes, mid-2025 two people left the team for different reasons. At that point, I still had two open positions in the team, and now I had to fill four positions for our framework team. So we jumped into the hiring process. It took a lot of time, and during this time I missed a lot because, on the other hand, the team was not formed. We lacked our identity and our goals. By the way, at that time I took one month for parental leave.
I needed that month so much. My little girl did very good planning and gave me a break from this storm.
How to form a teamLink to this section
After my parental leave, I came back to the team, and you know, sometimes it just needs time. The situation was different: the major release was done, the GitHub transition was complete, but we still didn’t feel like a team. So we did a kind of restart with an on-site workshop. The first half of the year was not like it should have been. We lacked our identity, mission, and goals. So we met in person for three days (one fun day and two workshop days) and talked about what our purpose is, what our mission is, and what our goals are. This on-site workshop was so much needed; it gave us a lot of positive energy and we created connections inside the team.
Just to be clear, project and product management did their best to support us. They joined at a time when the team was not ready and lacked its own identity. It was a timing issue, not a people issue. I myself certainly also made a lot of mistakes, and I needed to find my way into this Engineering Lead role. It was described as a bit like coding and a bit of management.
But you know what? Coding is the simplest part, and management was totally underrated.
We also changed this during the year and defined the role differently.
At the end of 2025, I did a lot of interviews and filled all open positions in the team. The team, including me, is fourteen people now. I know this is generally too big for one leader. But I manage with a lot of trust and shared responsibilities. Most of the people on that team are at a senior level, so they know what to do and how to do it. I learn a lot from them and try to help with communication and collaboration with other teams in the company.
Things we achieved in 2025Link to this section
Despite all the challenges we faced, the framework team accomplished a lot in 2025.
The list in the image is not complete and represents just a subset of what we accomplished together in 2025.
How we will start into 2026Link to this section
After the on-site workshop, we had defined our identity. Late in 2025, I transformed that identity and goals into a mission document for the next three years to come. The first year is very detailed, and the third year is more of a vision of what we want to achieve. That document has five sections that contain different technical goals that I created with the team. Every section is connected to company goals, and every epic inside that section contributes to that goal. We also changed our meeting cycle. Basically, we have a weekly meeting where we focus twice on technical topics, once we do retrospectives, and once we do planning. After the on-site workshop, we already started planning the next on-site event to regularly meet in person. At the end of 2025, we also collected our achievements from the year 2025 to celebrate and share inside the company.
Sometimes you need to be bold so others understand the value of your work.
LearningsLink to this section
Here are the key lessons I learned from this challenging but rewarding year:
Find your identity before you planLink to this section
Before you define a plan, find your identity and your goals. If the main reason your team exists is to create the underlying framework for the e-commerce system, it’s probably a bad idea to rate the team by the features it delivers. Framework teams need different metrics and different ways of measuring success.
Own your roadmapLink to this section
Never, really never, wait for anyone to create the plan for you. It was a nice thought to collaborate on the roadmap, but it’s also not rude to have a plan and combine it with external parties, whatever kind of party that is. Everyone has different expectations of how a team should work, but at the end of the day, the team is the one that needs to deliver. If that team delivers, it’s not really important how big the backlog is or how many KPIs are met.
Be a scout, not just a builderLink to this section
If you know your community and your software problems, just be a scout and improve it over time. Sure, this work is not always sexy, and maybe you cannot write about it on LinkedIn, but it is very valuable for your customers, users, developers, and the company.
The unglamorous work of fixing bugs, improving performance, and maintaining code quality often has more impact than flashy new features.
Build for the futureLink to this section
Always teach others. Always protect the base. Always create guardrails for the future. Adapt to the new AI era (also when it creates slop), improve your tools to not create slop, and have fun building great software.
The best engineering leadership is about enabling others, maintaining quality, and setting up systems that will serve the team long after you’re gone.