Starting from zero
When I joined Helsing, there was no design team. No design system. No established process for how design contributed to product decisions. This is not a criticism — it is the reality of most deep-tech companies. Engineering and research come first. Design comes when someone realizes the interface is a problem.
I have now built the design function here from the ground up. These are the lessons I wish someone had told me.
Lesson 1: Earn trust before you change things
The biggest mistake a new design leader can make in a technical organization is to arrive with a manifesto. Engineers and researchers have been shipping without you. They have built things that work. Respect that.
My first months were spent listening. Sitting in on engineering reviews. Watching operators use the software. Understanding what the team valued and where they felt friction. Only after I could articulate the existing culture did I start proposing changes.
You cannot redesign a process you do not understand.
Lesson 2: Ship something small and undeniable
Grand visions for design transformation do not persuade skeptics. Results do.
I identified a single, painful interface problem that affected a real user. I fixed it — quickly, collaboratively, with minimal disruption. When the operator feedback came back positive, the team noticed. That one small win created more organizational buy-in than any deck ever could.
Lesson 3: Hire for adaptability, not pedigree
The designers who thrive in environments like this are not the ones with the most polished portfolios. They are the ones who:
- Can work with extreme ambiguity
- Are comfortable in deeply technical conversations
- Do not need a "design-friendly" culture to do good work — they create it
- Ship imperfect work and iterate, rather than polishing in isolation
I have learned to interview for resilience and curiosity above all else.
Lesson 4: Build the system while you build the product
It is tempting to defer the design system, the component library, the documentation. You are moving fast, the team is small, you will do it later. You will not.
I started codifying patterns from day one. Not a comprehensive system — just the decisions we were making, written down, with rationale. This compounding investment pays for itself within months.
Lesson 5: Make design legible to non-designers
In a company where design is new, your colleagues do not know what you do. This is your problem to solve, not theirs. I learned to:
- Present design work in terms of user outcomes and business impact, not craft
- Invite engineers into the design process early and often
- Make critique sessions open to anyone
Building a design team is not a design problem. It is a change management problem.
The tools and processes matter far less than the relationships. Start there.