Building a Design Team from Ground Zero
Building a multidisciplinary design team is no easy task, especially while the company is growing quickly from an early stage to maturity. My experience of building such a team at Kira Systems for the last 4 years has taught me many valuable lessons, through both my successes and mistakes. Here I want to reflect on the lessons learnt in evaluating hiring needs in a small but fast-growing organization, assessing skillsets and roles given the current and future needs, growing a team culture, and advocating for good user experience within the organization.
First things first
Some refer to the “first things” as mission, vision, and culture.
Despite my dislike of corporate jargon, I will use these terms for lack of better options.
Kira Systems started with a very ambitious goal—teaching machines to learn to read contracts fast and accurately, so legal professionals can spend their time focusing on more interesting and challenging problems. Even at an early stage, the technology was state-of-art and has impressed many big firms in the legal industry.
As the design team of Kira Systems, we wanted to contribute to helping our users work smarter and more efficiently by designing an easy-to-use and delightful product and experiences. But there is so much more to it than that.
From a design perspective, we are solving problems that very few before us have solved. There are unknowns, ambiguities, and challenges. But there are also opportunities, things to exploration, and magic.
Within the organization, I wanted the design team to be our users’ ruthless advocate. I also wanted the team to bring together the technology and the business sides of the company.
I decided very early on that I would try to foster a team that values continuous learning and open-mindedness, yet is also always critical of its own work and biases. I wanted my team to feel safe to take risks, make mistakes, and to give support to each other, while being strong and confident when advocating for the users and their needs to the rest of the organization.
Of course, I couldn’t do it all by myself. The first thing I needed to do was to hire people that buy into the mission, vision, and culture.
Advocate for the team to advocate for good design
From my first day on the job, I took on a mission to advocate for good user experience and a user-centred design approach to problem-solving within the company. The design team shouldn’t just take requirements (especially when they were not user-driven) from other teams and design something “pretty.” Designers needed to be involved very early on to work with other teams in order to understand the goal of a project, its target users, and decide on an effective approach—whether it’s designing a banner for social media or designing a new UI for the product.
This meant the people on this small design team need to share this vision and make it a foundation of the design process and culture. I valued candidates who were empathetic, passionate, dared to take risks, and challenged the status quo for the right cause. Everyone on the team was very user-centric and goal-oriented with their design approaches.
I learnt to advocate for my team so they can advocate for and educate about the right design approach when facing challenges working with other teams. It was during this time that the seed of a user-centric approach was planted in the company, and UX was starting to be treated as an integral and important part of everything within the company from product to service.
From the outside, we seemed to be a team of four outspoken women. When we were among ourselves, we talked about our concerns and defeats, and helped each other by coming up with ideas and strategies to address challenges, and collaborating on projects, as well as giving each other emotional support. I believe this team environment where we helped each other figure things out was very important during these early times, when everything was ambiguous and there were many unknowns.
As the team and the company grew, parts of the culture shifted while other parts remained. But because of the solid foundation that was established, the design organization within the company had a much easier time to transition, to the point that not only was the role of design widely recognized across the company, but even our customers reached out to us to learn about how to do user research.
Hiring for the present and the future
My first two hires on the UX team were a UX designer/developer, who was comfortable and willing to juggle both design and front-end development, and a dedicated UX researcher. I have been questioned on my decision for both hires—why did I think it was important to hire a designer who does front-end, and why hire a UX researcher when the team was so small?
In assessing the needs of the design organization within Kira Systems at the time, my planning was guided by two needs:
We needed to build a product now, not later. Needless to say, we had need of a UX designer. However, given our size and how closely design and development worked together at that point in time, it made a lot of sense to hire someone with both skills. I was also lucky enough to know that such unicorns existed in local communities such as HackerYou.
I was better at some things then others. UX research was an area that I believed we needed from very early on, but I wasn’t quite as experienced at it as I was at design and front-end at the time. To fill this gap, I decided to hire for someone who could help push our UX research practice to the next level.
As I continued to build out the team, I always looked for specific skillsets that fit either immediate or future needs of the design team, and made sense in the context of the larger organization. I also had to make sure people had general enough skills so that they wouldn’t be siloed and could start contributing as soon as they joined. However, as the team grows, it is important to help each team member develop a T-shaped skillsets so the team can truly come together and achieve something greater than the each of us can.
Building the team and building the process is one
What is right at one moment may not be right at a different moment.
One element that helps us balance the growth within and outside of the team is the design process. One simply cannot define a design organization without defining its process. I will write another post on the design process as a team, but would like to highlight what it means for building a team.
On the design team, everyone understands that the design process is not a fixed thing that we blindly follows without questioning (if anything, designers are too good at asking questions and challenging the status quo). It is, borrowing Lincoln’s quote, “of the people, by the people, and for the people.”
This means that as we continue to define and redefine our process in response to shift in the wider organization, we look for skillsets that are right given in the larger context. At a certain point, having team members that are highly specialized in given areas is beneficial to the overall effectiveness of the team.
Taking a risk
Being a lead, it is scary to admit when you don’t know something. But it is even scarier to admit this when you have to get things done, and you know your decisions will affect other peoples work and lives.
This means, sometimes you have to take risks and make a decision without as much data as you’d like. There are always risks in terms of hiring and growing the team—is this person the right fit? Is this initiative or project too much for this person to handle? Is this the right process for the team? In the end, when in doubt, someone has to make a call.
One of my personal mantras has helped in these situations—make a decision not out of fear, but out of hope. This translates to always providing growth opportunities for the team, and always believing they can achieve their goals. This doesn’t always work, but at the same time you’ll never succeed if you don’t take a first step.
If we truly believe in our mission, vision and culture, taking risks as a leader sends the message that it is ok to make mistakes and fail, as long as you know why you did that, what you learnt from it, and can grow out of it.
Contributing in a different way
There were many times I struggled with letting go of my responsibilities. In my first year I had to wear many hats including a UX/UI designer, user researcher, graphic designer, front-end developer, and product manager. I was very used to multitasking and getting things done fast. This habit made delegating difficult in the beginning.
Additionally, as a designers, our values are usually seen in our abilities to create and produce tangible results. It took me a while to change my mind from “only producing designs is work” to “enable the team to produce design is equally work.” And the enablement consists of setting directions and priorities, collaborating with partners in other teams, coaching and guiding the team, transferring complex knowledge, helping the team to make decisions about process and design.
As I witnessed how much people on my team grew when given the chance to take ownership, I started to really appreciate the importance of being the enabler.
While I still value and enjoy doing hands-on design work, I clearly see that I can contribute more by supporting and enabling others on the team. And through the experience I’ve also learnt so much from everyone on the team, and become a better designer in the process.