Illustration by Raul Gil for this article.

Nobody warned me how challenging being the Head of Design at an early-stage startup would be. Then again, nobody warned me how much I would love the challenge.

How did I get to this point?

The journey started for me over a year ago. I had spent a small part of my earlier career managing a team and after a number of years I found myself longing to get back to that. I wanted to feel again what it’s like to not only design products but also business groups, organizations, and the processes around each.

There is no more significant design task than getting a group of people to work together toward a shared objective, growing and evolving as they go.

Additionally, I found myself wanting to be in a position much closer to the core business of the work I was doing. I wanted to not only and continue to see design's impact on customers and products, but also get close to the metal and manage how the function of design impacts and influences a business's bottom line.

What is the bridge to head of design?

As a creator, I feared moving into management would mean missing out on time spent actually designing things.

For many designers, moving into management means exactly that: the end of making. Managers tend to miss out on being close to the craft and instead must dedicate their time to helping manage and lead the team. Meetings, managing calendars, presenting work and representing the team, negotiating with executives... I wasn't sure all of that was what I wanted to do with my time as I started exploring my next career move.

Then Nick Bushak, CTO and co-founder at Gem, reached out for coffee, and through conversation with him I had a revelation. As a Head of Design I could spend a good year or two in a player-coach position before having to decide which path I'd like to take more long-term.

Being Head of Design at an early stage startup often means building and managing a design team from the ground up while also doing the work expected of a very senior individual contributor. You have to do both because both are needed at the early stage and small size of a series b company. As the company grows, the need to balance both managing and designing subsides as new members join the team, eventually pushing the Head of Design into either a senior designer role or focusing on management as a Director of Design.

Moving into the role of Head of Design meant I would be tasked with identifying headcount, hiring, defining what the team's purpose is and how we’ll operate, what parts of the product development process design is responsible for, and creating a vision for how we would grow. It also meant I'd have ample opportunities to get my hands into the work because the design team would be small early on, but the work required of us would be plentiful. I'd be not only a coach for the team but a player too.

Of course, a Head of Anything in a startup faces obstacles and issues you don't get if you are only an individual contributor or a manager.

At the bridge between both manager and individual contributor roles, you face challenges at both ends.

If you’re acting as both manager and designer, how do you know when to focus on team building and processes as opposed to focusing on the craft itself? How do you show up to lead and manage the team when you're also spending a reasonable amount of time showing up as a designer too? Where do you draw the line at being a partner to your team and their manager? Possibly most important: how do you help others on the team (the design team and the leadership team) understand what to expect of you if you're constantly doing both leading and designing?

To answer these questions I did three things immediately upon joining the team at gem:

1. Set out to define what matters most to me as a leader
2. Sought to understand what matters to the company in a leader
3. Sat down for 30 minutes with every single person in the company to learn of their perspective on design, the most pressing needs as they saw it, and what they wish design would tackle first

As part of a Stanford class on leadership, I outlined my leadership values (what my team and peers can expect from me as someone guiding a function in the company) before starting the role. I then created an outline of how I see the design team role functioning, based on early conversations with other design leaders I had developed connections with over the past few years.

Alongside guidance from my manager, Nick, I was able to identify where I should spend my time and draw lines between the tasks ahead of me as a new Head of Design. (I also found this article from McKinsey to be very helpful.)

Each of these things helped set expectations around the role for both myself and the broader company.

Crossing means expanding and refining skills

Moving across the chasm between individual contributor (or IC) design and management meant facing many skills and problem areas I never had to think really, truly, deeply about before. Things like:

• How should a design team be structured? What roles does the team need inside the company to be most effective? What's the right time to bring in specialists vs. hiring for generalists?
• How do finance and talent teams play a part in the planning of a team? How do you negotiate the importance of a role on the team?
• How do you find and source high-quality design candidates to join the team this early in its formation? (Product plug here, because Gem is making this process a little easier!)
• What work is most pressing for design, and what work can wait? What will help the business achieve its immediate goals, and how will that work be prioritized against more long-term investments in user experience?

As a result of some of these questions, I started the job at Gem by focusing my time on two core areas:

1. Capitalizing on immediate design wins

Immediate wins for the company were easy enough to tackle as a former IC designer. I spent a few weeks up-front auditing the entire product, talking with every member of the company, and working directly with customers to understand what design work needed to be done right away. I asked: what could help demonstrate the value of design to the company while getting me familiar with the product, customers, and culture? Within a few weeks, I had shipped minor but readily apparent changes to the product and begun shaping processes around the role of design as a function.

2. Preparing design to scale and create business influence

Scaling a design team was a new space for me to work in. I never had to think about building and scaling a design team as an IC. As such, I relied on external resources and help from other design leaders in the industry to spotlight the skills I would either need to improve in or learn for the firs time. Amongst the skills I identified:

• Business strategy: How does our product solve real needs in the market, how are we growing our presence in the industry, what are our strengths and areas of opportunity as a business? How do we establish ourselves as leaders and convert that presence to dollars? What is design's responsibility for each of these things?
• Organization building: How do we get the most benefit from a team of people? How do we align business objectives with team structure and career planning for individuals? How do you hire designers for a rapidly growing company?
• Communication, negotiation and product strategy: Three skills not only belonging to managers, but skills I hadn't needed to become truly an expert in previously (as my peers in engineering, product management, and design leadership could fill in my gaps for me as an IC).

Most helpful for me during this time of identifying skill gaps was having a personal "board of directors" I could reach out to. Whenever I encountered a challenging situation or whenever I'm unclear about something as it relates to my role, having this close group of people I can seek guidance from has been rewarding.

Being in a Head role can be overwhelming and leave you feeling like you're on the verge of failing at any moment. There’s so much to be done and only one you. Having a small group of peers who have done the role successfully before can be all the support and inspiration you need to stay afloat.

First brought up for me during the DesignX State of Leadership panel. The idea is simple enough:

• Find people in the industry who have successfully done what you're doing now
• Build a close connection with them
• Regularly meet with them to glean insights from their experience

Surprisingly, not a single design leader I have reached out to over the past year has declined time to chat. Many of those conversations have grown into regularly recurring catch-up calls.

Without this personal board of directors, I'm not sure I could survive the dynamic world of a fast-paced startup, let alone the role of attempting to cross between management with designing at the same time.

What it means to grow a design practice

As many of the people the design team works with at Gem haven't worked with a product designer one-on-one before, I found it essential to live our company value of transparency and make the design process as straightforward and clear as possible to everyone in the company. This emphasis on working transparently is great because it aligns with my personal values as a creator and leader.

Early on at the company I started hosting weekly, hour long, Design Reviews on Fridays, inviting everyone in the company to attend and see a bit of my work process. The company at this stage was very interested in the topic, and I found upwards of 90% of the company would regularly attend these virtual meetings to see what this new “design” function was all about.

Over time as the design team has grown, I've pushed for us to continue this practice of transparency in other ways.

As a design team, we share work daily in Slack. We host Design Reviews each month for discussion with anyone in the company who wants to attend. We also host weekly Open Office Hours for anyone in the company to ask questions and work with us collaboratively—in real-time—on problems. These things have helped connect design to the business and demonstrate how our function does much more than just turn an ugly screen into something pretty.

Scaling the team and lessons learned thus far

One of the biggest focus areas in my role is thinking about how the design team will scale inside the company.

Kristin Skinner and Peter Merholz wrote a book on designing the design organization in a company, in which they outline a time-tested process for building and scaling a team.

The book, aptly titled Org Design for Design Orgs, is an excellent reference and helpful guide for any organizational leader who needs to understand how design might scale in their company. Though the book is a good reference, it's also relatively generic and requires deep thinking into what your specific company might need as it scales. For Gem, this meant looking at the company size, product-market fit, and investment in the product itself.

As I thought about building the team, I landed on hiring strong design generalists first, then scaling to include specialists (across design functions like writing, research, motion, and interaction design) later. By focusing on generalists out of the gate, our small team could work in a scrappy way to accomplish whatever needs to get done quickly. The outputs of this small group’s work may not be ideal or perfect, but when it comes to a startup, done really is better than perfect. If you’re not moving quickly—producing work, snuffing out fires, and focusing on scaling—the competition is always there in the wings waiting for their chance in the spotlight. Design generalists are exceptional at moving quickly, no matter the task.

During the first few months at the company, I also learned just how difficult hiring can be.

I've participated in interviews before, but have never been responsible for defining an open role, writing the job post, creating a rubric for evaluating designers, and putting together an interview guide.

When it comes to hiring, that's not all: during the first few months of looking to hire designers, I had to actively reach out to potentially strong candidates and show them why joining a small, early team like Gem design was a good move, even though externally it can seem very risky as a career move. It’s a hard sell for many designers who cherish stability and certainty over the potential reward of being an early leader at a growing company.

General wisdom when it comes to hiring is to go with who you know. Close connections—the people you have worked with before—are easier to hire for and more reliable in the long-term but also introduce a ton of bias. I knew from the start I wanted to build a diverse team of designers from many different backgrounds and expertise areas, not just from my network of former colleagues at big tech companies like Facebook and Lyft.

So, after countless months of talking with designers, reviewing portfolios, calibrating the hiring team, making offers only to have them declined for various reasons, we landed two incredible designers within my first eight months on the job. Melinda Kilner and Wandi Liu joined the team, and each has contributed heavily to the overall makeup of how we work and what it means to be a team. I could not be more thrilled with both of these designers and the work we’re doing together to build the foundations of what will inevitably be a truly world-class design team.

If you’re hiring designers you can’t be afraid to hire from smaller companies than the big FAANG ones. You should look for designers with strong processes, adaptability, creativity, and grit. You may be surprised what you find when you give a conversation a chance.

Of course, having such great designers on the team has meant my perspective of leading them has evolved as we continue working together and scaling the team.

When we say "head" of the team, I now view that as helping to gently nudge decisions, demonstrate practices and processes, and provoking meaningful discourse and debate for both the team and individuals on it.

I've learned an incredible amount in this role already. I've learned about startups and how to both show up and not show up as a leader (those messages you send on Slack intended to be witty and humorous, for example, tend to have a different punch when you’re a leader). I've learned about the way design can subtly influence decisions inside and outside the company (a vision workshop can be helpful for driving vision, but only if it’s regularly referenced).

More than anything: I've learned I made the right decision bridging the gap between IC and manager. Because in this role, I've discovered my passion for getting to know the individuals I work with so closely daily. I've uncovered just how incredible (and incredibly hard) it can be to get people aligned and doing great work. I’ve learned from my team, and I’ve seen the mistakes I’ve made in the past as an IC designer. I’ve grown a lot, partially out of ambition but probably more so out of necessity.

I now wake up every day both excited and anxious for what the day holds for me in this role. Where will I fall short? What new obstacle will I uncover and have to maneuver around? Am I making the right decisions for my team and the company? Am I contributing in a way that is helping move the bottom line? Is this road going to be one I want to stay on for a long while? Only time will tell.

For now, I'm loving it all. The challenges and opportunities.

Illustration by Molly Magnell for this article.

The value of a good one-on-one meeting is nearly immeasurable.

It's a time to sync on things in a format you can't get any other time or in any other medium. You don't have an audience waiting in the wing to jump into the conversation, nor distractions to pull your attention away from the other person. I believe a great one-on-one is where your best work often gets done.

To make your one-on-one's more effective:

• Define and agree upon their purpose together
• Be clear about the schedule
• Use the time to sync on anything you can't anywhere else
• Work to keep things casual

Define and agree upon the purpose up-front

First-and-foremost, you'll want to set a clear plan or purpose for your one-on-one meetings.

The plan can be high-level (e.g. "Catch up on everything that happened over the last week in our lives.") or focused (e.g. "Discuss a decision I need to make tomorrow around Project X."). The key is to have a clear purpose or agenda both parties understand before the meeting. Whether you're meeting for the first or hundredth time: get aligned on the purpose and plan of the time.

What do you each want to get out of the time? What would a successful sync look like for both people? What is most valuable to the relationship? Even if you spend time catching up, that's an important use of time for teammates to have.

Be clear about the time and recurrence

It's not enough to agree on the purpose of your one-on-ones. Both people should know in advance just how much time will be dedicated to the meeting and how often they will occur.

Some people use 1:1s as a way of getting updated on work. Others use it as a chance to chat and get to know the other person casually. In either case, the amount of time required will play a part. Discuss and agree on how much time you'll need to fulfill the sync's purpose and how often you should be meeting.

Consider how close your relationship is to the person: weekly is the right cadence if you work very closely. If more casually, as far out as once a month can suffice. It will vary for every person you meet with and the purpose. Staying in-sync on personal goals can be less regular than meeting to stay connected about the work.

Use the time to discuss things you can't elsewhere

Email, group posts, Slack chats, and more are all excellent ways to stay up-to-date with your peers about ongoing work, in asynchronous methods more often than not. You may not have the ability to sync on more personal or pressing matters with a level of emotion or nuance to them in these methods, however. One-on-ones are for things you can't say in the other means or something that may not be suited for those channels.

Focus on the individual, the working relationship, or things that may impact others but need to be figured-out in-person, in advance. Consider the value of any one-on-one as being able to discuss these crucial subjects on a micro level, without interference or the ears and eyes of a larger audience.

Ask yourself (and the other person): "What conversations are we not having elsewhere?" Those are what your one-on-ones are for more often than not.

Keep it casual and human

It's worth noting: one of the best aspects of one-on-ones is you have them in real-time, usually face-to-face, with one other person. Meaning: you can see the person, you can better understand what they're saying or how they're listening, how they're responding to what's being said (in real-time), and you can interject the conversation with questions or ideas on-the-fly as necessary.

The work we do as teams ultimately comes down to the work we do as individual human beings. Often when we get buried in project scope documents, design mocks, and customer feedback requests, it can be hard to remember we're all people functioning together.

Keeping one-on-one conversations as casual and friendly builds the working relationship and enables you (as a team) to better tackle work subjects.

One-on-ones can be awkward or time you wish you were spending doing work, but ultimately the investment made in a good conversation with one other team member can pay immense dividends. A good one-on-one is any one-on-one where both people understand the purpose of the time, where they have agreed on how long and how often the time should be spent, and where each person uses the time to connect at a human, casual level.

Illustration by Bonnie Kate Wolf for this article.

To effectively navigate product complexity as a designer, think of the narrative around the product.

The story we tell ourselves, our peers, and our customers about the product and how it works is ultimately the resulting work we put out into the world.

To design effective experiences it’s not enough to think of our work in terms of features, patterns, or libraries, but rather experiences that play out in a narrative arc, wherein the user is the star. This narrative is always one that encompasses much more than what we can control and yet is the space within which we must play, experiment, and create.

This is unfortunately not how many designers are taught to think about the work they do.

Designers will often think of only features or feature areas as they work: "This is the profile part of the product" or "This is the billing or settings part, this is a list of controls for this particular thing." Understandably, it can be both challenging and/or exhausting to think more holistically.

Having a micro perspective of a design task is important for focused ideation and execution, but each of these things—features and feature areas—are always part of a larger whole, and if we forget that fact we often end up designing something that doesn’t really do it’s job; what the late Clayton Christensen defined as "Job to be done."

Jim Kalbach, in his book The Jobs to Be Done Playbook, breaks down the five elements of any job to be done:

1. Job performer: The executor of the main job, the ultimate end user
2. Jobs: The aim of the performer, what they want to accomplish
3. Process: The procedure of how the job will get done
4. Needs: Why the performer acts in a certain way while executing the job, or their requirements or intended outcomes during the job process
5. Circumstances: The contextual factors that frame job execution

When considering a design experience we tend to emphasize our attention on job performer and their jobs, only occasionally pulling in the process of how a job will get done via interaction design patterns we create.

But, as with any good story, we also need to understand motivations and context—the circumstances and needs around the job performer and their job—to develop a complete picture of what it is we’re solving through our designs. This is the product narrative designers need to understand and develop in order to do their best work and grapple with the complexities of large-scale product design.

Even if the scope of work a designer is responsible for is feature-level, understanding the larger product narrative helps ensure the feature work aligns with the bigger "job to be done" of the end user. No user comes into a designed experience with a completely fresh and empty mind, ready to partake in whatever experience has been designed for them. No! Everyone comes into an experience with a lot more than we can intuit: are they having a stressful day, do they want to race through the experience or take their time, are they casually browsing or actively seeking solutions?

If you want to create more cohesive experiences across a large system or platform, think not only in terms of feature areas, but of the narrative behind the system itself. That story is what ensures the work will… well, work.

A product narrative will come as a result of many diverse forms of conceptualization: a static user experience map, a low-fidelity prototype of a complete product experience, a series of recorded phone or video calls of customers describing their day-to-day process, or a set of storyboards highlighting the core experience of the product.

These artifacts are not necessarily "the product narrative" but rather elements that inform the narrative. Teams need these artifacts in order to start the dialog around what the narrative will be. The product narrative itself is how the team and users talk about the product.

If the team you work with isn’t telling the same story, you’re going to create features that don’t align with one another or you’ll run into differences of opinion or principles as you work that create unnecessary roadblocks. Your team needs to make story telling a team initiative.

If you have product managers, this is often a fundamental part of their job: creating and disseminating an initial version of the product narrative. Designers and product managers should work closely together (with customer success leaders, sales members, executives, and others) to ensure there’s a narrative about the product that is internally shared and agreed-upon.

A simple narrative written out can have lasting effects, particularly when considering the additional "chapters" to the story that influence new features or areas of work. Asking "How does this new area of work play a role in the existing product narrative" is one of the most effective ways at ensuring work the team does is aligned to a larger initiative that pairs well with company trajectory.

To learn more about creating a strong product narrative as a team, listen to this episode of the Inside Intercom podcast with James Buckhouse who says:

"You start with personas, and you map out the personas. Those personas are the character in your movie….Each one of those characters is important, and each one of those characters is going through an arc… At the very beginning of a design project, I would find the engineering lead, and the product lead, and the design lead – or if I was the design lead I would be there. We’d have a sheet of paper and we’d talk about the problem in the world. I would take out a pencil and I would make the smallest mark I could on the page, like a circle, and I’d say, ‘This is the user.’ I’d hand the pencil to the engineer, and ask, "‘What are we trying to do?’ As soon as you can get the engineer to draw on the paper with you, and you can literally draw together to make a solution, everyone’s invested in co-creating this thing."

There’s much more to creating a product narrative than what I’ve teased here, but that’s a story for another day. For now, know that if you’re designing anything it’s part of a much, much larger story, and if you want your work to be effective it’s important to be in-tune with that narrative.

So much of design work comes down to the story we tell ourselves about the experience we want *others* to have. If we don’t know the full story, it’s hard to know what small piece our work can play in it.

Illustration by Simina Popescu for this article.

How do you approach a problem that has no definition, not even a hypothesis?

How do you walk into a room of talented and experienced cross-functional peers—engineers, product managers, customer success managers—and guide them through problem identification and solution brainstorming… when you yourself have no idea of what’s to come?

As product designers grow in their careers we are tasked with taking on more complexity and ambiguous problems. We find ourselves in situations where our job is to help others envision and explore a complex and often poorly defined landscape.

If you’re just starting out in your career as a designer, you will likely be tasked with feature-level or already clearly defined problems: improving the information hierarchy of a screen or finding a way to grow interactions on a particular button.

As you progress in your design career—improving skills and understanding of how design plays a part in digital products getting made as well as how they become successful—you may be tasked with more ambitious and ambiguous challenges: researching and synthesizing ideas around expanding the business, leading a organization-wide usability effort, or dramatically improving the usability of several broad feature areas of the product (or the entire product itself).

At some point a senior designer may decide to continue and work on the product side of things or they might decide to transition to a new type of problem: managing and leading a team. Team problems are very much like ambiguous, multi-faceted product problems: in that they consist of many moving parts that you, as a leader, need to figure out how to help work effectively together.

In either case, the challenges ahead will be fraught with ambiguity and uncertainty. Others on the team will be looking to you, as the designer, to help lead them forward.

Progressing to a point in your career where you have the trust and skills necessary to be held accountable for, know how to approach, and successfully navigate, very large, ambiguous problems (team or product related) can be stressful and often frightening. Particularly if you’ve never done that type of work before.

I’ve talked with quite a few designers over the course of my career who find the challenge of growing through ambiguous problems almost overwhelming.

How do you approach ambiguous problems?

You start. With what you have now, however you can.

When faced with uncertainty and ambiguity, starting is a powerful way of creating definition. A step in any direction is a step forward. Even if you come to learn the direction you’re heading in is the wrong one, you’ll have learned something tangible. That learning is far more valuable than not moving and not learning.

As Lewis Carroll famously wrote in Alice’s Adventures in Wonderland: "If you don't know where you are going, any road will get you there."

Of course, the alternative is to wait, to research, to plan before you start off in a direction. That’s a direction worth considering, often worth taking. But the way to even do that is to first set off in a direction, to take a chance on some question, some idea, some hypothesis. Movement is what matters most at the start of any endeavor.

Often we fear that if we make a wrong choice—if we ask the wrong questions or head off in the wrong direction—we’ll be viewed as a failure. But most decisions can be turned around. Most directions can be informative, even when they turn out to be wrong.

As designers, we’re often best suited for rapid adaptation, keen awareness of user needs and problems, and ideating through solutions. When others around us are paralyzed by uncertainty, we can take it on ourselves to take that first step, wrong or right, and help guide our team forward.

Define a list of what you know and what you don’t know, create a document of questions and hypotheses, audit competitors, start a conversation with any customers who will make time for you, drawing out low-fidelity maps of existing experiences...

When faced with an ambiguous design problem, the best thing you can do is anything. There is no right or best way to move forward, there is only action and inaction.

Illustration by Ollie Silvester for this article.

In Nobody told me UX would be like this, product designer Chris Kiess explains how getting things wrong is a core part of being a designer:

When you evaluate design as an activity, you'll realize that you spend the majority of your time getting it wrong, getting rejecting and getting it wrong again. A very small amount of your time will be spent getting it right. That's what we do as designers.

Chris' words struck as a universal truth that is not often spoken out loud, certainly not in the history of my own career. I wish someone had told me this earlier in my life: the work isn't about trying to prove yourself right, it's about being wrong so you can better inform what is right.

It feels good to be right, and seeking right ideas is more comfortable than seeking wrong ones. But regularly trying to be right (to validate our ideas) only shuts us off from what's actually right and best. The role of designers—and, in some sense, product teams—is that we should work not to get things right but to get things wrong. To make mistakes and find broken ideas. Because if we constantly seek to be right we're missing out on possibilities. If we're trying to prove something right, we're limiting our ability to learn and understand.

Author and mathematical statistician Nassim Nicholas Taleb talks about this from the lens of statistics in his book The Black Swan. Nassim explains that once we encounter something that seems right we easily "concoct an explanation that makes it appear less random, and more predictable, than it was." This limits our learning. From the book overview:

We concentrate on things we already know and time and time again fail to take into consideration what we don't know. We are, therefore, unable to truly estimate opportunities, too vulnerable to the impulse to simplify, narrate, and categorize, and not open enough to rewarding those who can imagine the 'impossible.'

Nassim explains that "we can get closer to the truth by negative instances, not by verification" and that a thousand bit of "right" information can't really prove anything because there will always be something outside the information we're being exposed to.

We can't accurately say "All swans are white" if all we've ever seen are white swans (right information). But we can say "Not all swans are white" the moment we encounter a black one (wrong information). One wrong idea can be more true than a handful of right ones.

If we want to uncover truly good ideas, if we want to make sure we're solving the right problems in the best possible way, or that we're learning and leveling-up not only ourselves but our teams, we should seek to not be right, but wrong. Do not seek validation, seek evaluation. Try to see where your ideas and work break, not where they can stand up against all scrutiny.

There is an important distinction between being wrong and doing bad work, of course.

We shouldn't buck convention just to "be wrong" or purposefully pursue bad ideas in order to learn something. We should still conduct ourselves in pursuit of doing honest work, but when it comes time to evaluate the work (with our team, customers, or others) our emphasis shouldn't be on demonstrating our right-ness but rather: actively seeking to uncover what we've done wrong. This is why it's important to share work early and often, even (or especially) when it hasn't been "fully thought through."

That's where the best work comes from as designers: when we discover we're wrong. When we're wrong, we can course-correct and, as a result, the work we do becomes stronger, not weaker. When we think we're right through validation, we stop trying to improve, we become blind to how wrong we might actually be.