Leading a design team through Moladin's pivot

Role and team

The work spans two roles at the same company. As Associate Design Lead at the peak of the Dealer Financing and Platform Tribe, I led 5 designers and 3 copywriters, owning delivery strategy, design review and stakeholder alignment. As Design Lead I now lead a 4-person design team across 4 business verticals.

One number tells this story and it only went down: 15 designers in 2023, 10 by the end of 2023, 4 by August 2024. The team kept delivering the same scope with roughly a quarter of the people it started with.

The problem

Since I joined, a gap had opened between designers, product managers and business operations. Designers were never exposed to the real problem: we never had a seat when the business and product people discussed the operational problems, the business opportunities we wanted to explore, or the improvements we wanted to make. Designers were only brought in after the solution and the decisions had already been made.

It became even more problematic when designers started challenging the solution, because more often than not we only had half the story. The process had to restart, which often meant long discussions, long waits when a decision needed management approval, and timelines that ran longer than expected.

Constraints

• Headcount only went down. Every change had to work with a decreasing number of people.
• The scope did not shrink with the team. Dealer financing, Tuwaga, the Moladin web transformation and the Moladin Finance SME platform all had to keep moving.
• Nothing could be paused to reorganise. There was no quiet quarter to rebuild ways of working in, so it had to happen inside delivery.
• Limited publication. Most of what this team built is internal or commercially sensitive, which is why this is a written case study: only screenshots that are publicly available are publishable.

What I did

I started by finding a PM who shared the concern, and worked on trust first. The gap had bred a quiet distrust between some designers and PMs: on projects that needed only simple design, PMs would design it themselves rather than assign it to the design team.

Once I had that trust, I proposed a change as a pilot project: on one project, a designer would join the requirement-gathering process, listen and observe first, then continue with our usual process — design kickoff, designing, alignment, adjusting the design based on feedback, then the final checkpoint and delivery.

The pilot worked well. Communication between PMs, designers and the business team improved a lot, the friction between designers and PMs was gone, and projects of that type now took two weeks where designers used to need four.

So we expanded the pilot until we proposed the whole change to the C-level, which gave it the go-ahead.

From that point on, designers stopped being handed a ready-made specification and started being in the room where the specification was written: the PM and business ops conversations, and the commercial reasoning behind a feature. The first question in a review moved from "does this look right" to "what is this supposed to change for the business, and what did we learn that supports it".

We are down to four people now, and this is still how the team designs.

Changing how the team worked

Deciding on the new proposal took one meeting. Making it real took most of a quarter, and almost none of that work was design work.

How the change was made

1. 01 Find an ally A lead who was worried about the same thing I was, so the case had two voices from the start.
2. 02 Plan it together We shaped the change as a shared proposal, so it arrived as a plan rather than one team's complaint.
3. 03 Earn trust outside design I met people across product and business teams. The message was the same each time: design wants to work with you and can help. That took weeks.
4. 04 Bring the designers with me It asked more of them — listening to business problems instead of receiving the solution on a plate — and it came with questions, so I explained what the change was for. Some were convinced in one conversation. Others needed several one-to-ones, and a few needed to see it working first.
5. 05 Pilot it, then report back We ran it on one project for a few weeks, then I reported what had actually changed to the whole team. The feedback from other departments was strong enough that the case made itself after that.

Three things made the model work once it was in place:

• Listen to the problem. Assuming things is easy, but it often leads to generalising, so the crucial step is listening: to the problem the business faces, the constraints we have, and what has already been tried.
• Trust and respect each other's expertise. We may think our idea is the best, only to find it is very challenging to implement operationally; the best idea might come from the business, ops or product team.
• Context sharing. Having one person with deeper knowledge of a project can be optimal, but relying on it gets a lot harder when priorities change constantly. Several people with broader, shallower knowledge can actually be very helpful in finding a proper solution.

Key decisions and trade-offs

A change in our ways of working was pivotal. More and more teams wanted to work with us, and it exposed us to a lot more varying projects: AppSheet builds, landing pages, pitch decks and marketing projects. It also made the team very efficient, with the trade-offs spelled out below.

The ways of working were fitted to four people. Arguing for more designers was the obvious move and the least useful one. The company was pivoting and the constraint was real, so I fitted our ways of working to the team we had and was honest with stakeholders about what four people could carry.

Business context was distributed, not specialised. At four people, a research team was never going to be resourced. Instead, business context was distributed to every designer, so judgement about the business lived across the team rather than in one specialist. The trade-off: no single owner of a product, in exchange for a pool where any designer can pick up any vertical's work.

The design library was kept small on purpose. We rebuilt the previously very detailed design library into a leaner one, focused on shared components and universal use, so we could use it to create new products faster and iterate faster. When we need a new component we create it locally, and when we find it being reused several times we add it to the universal design system.

Proximity instead of a new process. A heavier process mid-pivot would have added coordination cost without context. The fix had to be proximity, not paperwork.

Outcome

The team got smaller and the scope did not. The existing verticals kept running the whole way through, among them dealer financing, consumer financing and the platform project. On top of that, the same team helped the company open four new initiatives.

• Tuwaga went from 0 to 1,000+ potential leads.
• The Moladin web transformation moved revenue from hundreds of thousands to hundreds of millions of rupiah per month.
• The Moladin Finance SME platform manages hundreds of leads and loan submissions, and its companion agent app generates 100+ leads per month.
• The team also took on a new AI-based platform initiative, which was not on the roadmap when the year started.

Dealer financing itself went from 0 to 5,000+ users while the design team was losing most of its people.

The gap closed as well. Designers and PMs stopped working in silos and stopped blindly questioning each other, and began working together, with shared visibility into what the business faced. I would not claim a causal line from the ways-of-working change to any single number. What I would claim is that the same team kept delivering while it lost most of its people, and that the silo problem stopped being what slowed decisions down.