In which I make hiring better

In the summer of 2020, a few months into my new role, my manager said, “you get to hire someone!”

I thought, this is great news! We need some more people in this team.

Within three days of my role being posted, I had over 500 applications to review.

That is not a typo.

I noticed a few things this first time:

1. Average time-to-hire was 90ish days — and one of our hiring managers had an open role for 9 months (see number 10)

2. It was very sink-or-swim — I had to figure it out along the way, at the expense of candidates

3. Levels for hiring roles defaulted to senior designers not because we needed the design skill level but because we needed negotiators who could hold their own

4. None of the managers knew about each other’s roles or shared candidates, even locally

5. I was told to look for “rockstars” who are “visual designers first” even though the products they’d work on had issues that were about 80% UX, 20% UI — and we have a design system

6. All portfolios look exactly the same once you get to the 250th one

7. Every person I said “yes” to = another hour of prep, interview and closeout time on my calendar the following week, the fatigue from which impacted who I brought into the process

8. About 90% of applicants appeared to be white, and about 75% of those identified as men (we didn’t specifically track; this is what I was able to notice)

9. Our hiring team partners did not know how to interview or assess candidates, and as a result, they did not show up well to the interviews or the decision-making session

10. By the time I sent out an offer I was so worn out I would have happily hired my cat

I thought, this is just way too depleting alongside all the other things I’m being asked to do. I need to figure out how to make this better.

What I did

I knew none of these issues existed on purpose, more from inertia found in policy-heavy processes. I’ve been subjected to a lot of these that I had no control over before and let go of trying to improve, but this time I thought, no, this is important.

Changes like these can’t be quick fixes or band-aids — they need to be improvements people feel safe making from building trust with me over time. I start small, using each change I make and the impact of it to guide what I choose to do next.

Below is a summary of what I accomplished over the course of two years.

A number worth sharing: our average time-to-hire went from 93 days to 65 days.

---

How I did it

It turns out I have a method I use all the time.

Maybe the best word is strategic. I see where we are today and where we could be, then I create and implement a flexible plan — which is what a strategy actually is, the plan for how to get from one place to the next, better one.

Starting small, I joined the Talent Guild, our way of working on practice-wide stuff, which gave me a way to understand the landscape, make all the improvements you see above and the authority to make them official with leadership. It also gave me a way to officially partner with one of my favorite people I got to work with, our Talent Lead. Without her input and feedback, none of this would have worked out.

If you look across the top row of that table up there, you’ll see the order I addressed and changed things in: diversity of candidates and eventual new hires, shifting the hiring philosophy to something more strategic, getting the career ladder to a place where it’d be useful in more than one moment per year (reviews), and shifting the burden of the process from one person to a shared effort across the manager cohort and other team members to balance it out.

Conclusion

I came to believe that the career ladder is actually the key to many more things than I originally thought. In the interview process specifically, a well-developed ladder with an up-to-date list of specific skills the practice and business need can help you

• write job descriptions that reflect what someone in this role will actually be doing all day

• give the people who do the hiring a shared way of seeing the process

• assess applications and conduct interviews with an eye toward specific skills and the level we need to see them practiced, instead of looking for “unicorns” which still do not exist

• provide partners with the language and common definitions for good questions, and coach them with material that helps them assess answers well

• at the end of the hiring process, make a decision based on whether or not a candidate can do the job, not impress us in an interview

Design maturity FTW

It’s a pretty simple maxim — wherever I go, I try to leave things better than I found them.

I use time-tested methods of strategy and design. I typically apply it to how I set up and run teams, develop partnerships, and see impact.

Whoa! obvious Problems

When I was asked to take on a team of nearly 20 designers and managers at DocuSign after a tsunami of executive and leadership departures, I started out like I usually do: listening, watching, and talking to people.

I saw

• a set of overwhelmed managers, lead designers who felt pretty stifled, and mid-level designers craving mentorship

• three separate teams of designers who almost never spoke working on “editions” of the same SaaS enterprise product

• a sub-par user experience that designers felt they were having no impact on

• a leadership team that believed design was there to execute on a vision, but the vision couldn’t be developed because of…

• dangling product strategy questions about whether or not we’d integrate with the company’s flagship product, which stalled vision and design work

I started by mapping out the process and all of the red flags I saw in it.(See below)

The Diagnosis

We had

• a product that wasn’t so much a product, more a disparate, disjointed, kinda-sorta “workflow” thing

• a process that was simply not friendly to design or designers

• product managers incentivized to ship but not focus on quality

• engineers working on an aging tech stack — minimal changes only, please and thank you

• a high percentage of churning customers who would declare on departure that “this isn’t a DocuSign product”

I drew out a huge whiteboard on Miro with the process, my goals for improvement, and a big space in between for ideas on how to get there. I filled it, then deleted half the post-its right before I talked to my team to see how they responded and what they thought. (See Below)

In the changes I decided to make first, I prioritized the team’s health and the improvements I thought would have a high impact on people feeling more motivated or better about their work, because, well, that’s where you always have to start.

Changes I made

I only had six months here — we re-organized again — but because I thought this was going to be my team for while, I got moving.

Here’s what I was able to do in the time I had:

I moved designers from a product-centric model to a core jobs to be done model so that everyone would learn about similar functionality across editions without breaking the flow of work.

I asked lead designers to be responsible for a job to be done category, supporting product quality overall by leading critique and mentoring designers, with a focus on de-duplicating and bringing better continuity to the work being done between editions, which gave them a differentiated role from senior designers.

I also asked leads to use what they learned about inconsistency in conversations with engineering leaders to start bringing the idea of streamlining the user experience and product, which helped them start seeing better impact.

Managers were moved away from managing design work to managing relationships with product so that we could mature the conversations, which helped us get more involved in up-front planning — when we could propose research and testing.

I started escalating the product strategy issues to senior leadership in product experience and in forums where I had a chance to ask questions about it, which helped surface the need for clear decision making at the executive level.

The changes started to take hold and we started moving forward in more productive ways. Had I stayed in that role, I would have kept going with my plan, evolving it as I saw impact and need.

View fullsize

Building a global design team

When I started in 2010, we had more creative directors than designers.

There were two designers in Australia, four in Buenos Aires, and regional creative directors in the US, Sweden, and Australia.

The VP who hired us made the case for incubating a creative capability after gathering data that told him 40% of their deals were lost because they didn’t have an in-house design team.

Time and time again, prospective clients asked for design to be part of the team, not an add-on with an expensive agency that didn’t understand the tech and would deliver unworkable designs.

What I did

1. Built credibility with pitch work

2. Enabled and directly supported growth from 6 to 100+

3. Supported strategic growth plans for the global practice

4. Operationalized design in the consultant force

Building credibility and growing the team

At first, we had creative directors essentially zipping all over the world trying to find work to elbow their way into. Every now and then they would score and get more involved in a pitch. I would coordinate creative explorations with designers, the Creative Directors would clean up slides, then use exploration work to do the storytelling needed. It worked — we were winning deals, much bigger deals. People started asking for them to participate.

This is when my work kicked into high gear, because I was there to help the team get organized and coordinate.

I saw the need to create a flow of information between team members that didn’t involve me personally translating everything for everyone. Complicating this effort, we worked across time zones that were not friendly to doing this easily.

I created and refined async tools so that work got done and met expectations. (Guess what we didn’t have? Slack.)

I did that just in time, because now we needed to scale to actually do the work we had proposed. I persuaded our VP to let me hire ahead of demand for the work I could show was coming to us.

Our hiring efforts went so well that we ended up with 100+ designers.

Seventy-five of them were in Buenos Aires. Everything from making sure teams had offices with places to take client conference calls, to supporting team members in gaining confidence to be on those calls, to making sure they all had the right licenses, and managing workflow globally, fell to me. It took a while, but I was able to gain the team’s trust that I would deliver improvements to their work environment and we could run a smooth shop.

Zoom In

A small example of the things I worked on: licensing software. Early on, when we had about 15 designers on the Buenos Aires team, there was an unexplained slowdown in velocity. When I asked about it I found out that they were all sharing a Photoshop license. I was incredulous. No one can work that way! (Also: No Sketch or Figma yet.)

So I went to our VP… who asked if Photoshop was really necessary because it was expensive, and wanted me to investigate if the team could “just use MS Paint.” Aha! Now I knew why license requests had not been made.

A second operational effort I took care of was career ladders, because hiring was continually on the struggle bus without it. Our job titles were for developers and we didn’t have a way to talk about career planning with our teams or candidates.

So I found the right person, got a crash course in career ladders from HR, and built out a career track for information architecture, visual design and user experience.

Third, I had to sort out our engagement model.

With our teams working in remote locations, and the way creative work happened in bursts followed by a lot of waiting, the “butt-in-seat” model of tying a name to a contract and location wasn’t going to work for us.

We needed work to flow around the studio so that one person wasn’t over-allocated while others sat around and waited for something to do.

I had to make the case that we could not attach names to deals or project plans in estimates or contracts, which was the typical practice, and the project team would start out working through me to move the work to design teams.

This was not scalable, as you can imagine, so I had to delegate pretty quickly once the pitches were won and deals signed.

Finally, we had skill bias issues show up. I was doing a regular check-in on how projects were going when a designer told me about the 6-hour phone calls he had been on for the last month to support developers rebuilding something he already delivered.

SharePoint sites at the time ran off of something called a “master page” which was really just UI display styles. Developers across multiple projects were not using the ones we were delivering.

(Honestly, they were glorified style sheets. I still don’t see why it had to be so hard.)

It turned out they didn’t believe a design team from Argentina could do that work.

While I would have loved to declare “you’re biased” and have that fix it, I had to demonstrate the efficiency and budget hits project teams were taking because of this behavior. It was pretty easy.

Strategic growth and operationalization

Now that we were popular and growing, it was time to start looking at moving through the last incubation gate and becoming a “real team.” In 2011 the leaders got together in person to come up with how we would do just that.

Two items in our plan fell to me — revenue recognition for deals we helped sell and getting estimates automatically included so we didn’t have to negotiate scope twice for each project.

The thing about working remotely for a 10,000-person organization is that you have to know how to find people. I had to figure out who had all the sales tracking spreadsheets, and then I had to find the person who owned our estimating model. That took about a month.

For sales support, first I had to get us included at all in the documentation for sales, which took about three months. Then, to get a number that didn’t look like double-dipping on claimed revenue, I had to make a case for what our share should be. I was able to figure that out and persuade the Keeper of the Spreadsheets to have a column for XD added. This got us on the way to being a profit center of our own, so that once we moved out of incubation, we could continue to hire ahead of demand based on revenue we generated for deals that would become projects.

Then there was the estimating model, a gargantuan spreadsheet. Once I found the right guy somewhere in Australia, I had to explain that our work could not be back-figured based on a percentage of engineering, and that we needed both exploration and production time in our estimates, so no, 4 hours for a complete set of wireframes and 8 hours for detailed design was not going to cut it.

Two months later, our estimates were included in every deal we helped pitch and win, all over the world. This grew our footprint and our revenue.

Summary of what I learned

Do you ever look at a piece like this after you’re done writing it and think, “Wow. I did a lot of things”? That’s what I think about this one.

If you read the whole thing, you probably noticed that I spent a lot of time anticipating needs and saw the phrase “make a case” quite a bit, and that’s really my point in telling this story.

Most of scaling a team and getting it to a self-sustaining, growing profit center in this context is about seeing what’s coming and being able to build a case for what the team will need soon (but preferably not right now).

I had to learn how to make a business case for everything from decent office space to flexible workflows for a completely new organizational function. It took quite a bit more groundwork and storytelling than, say, arguing for a new developer certification.

And while I definitely had support and guidance from our VP, our creative directors were much too busy to manage anything I was doing. It was not the first or last time someone who had not worked in design would be my direct manager.

Being able to do what I did for this team takes good instincts for building a business and strong creative problem-solving muscles I still use today.