The story of a first time manager and design leadership
The story of a first time manager and design leadership
The Managerial Route
( Note: I prepared a presentation Slide and this article is a text version of few pages. The slide describes real time use cases more whereas the article is heavy on process part)
I joined Fyle in 2019 as an IC & created a design system, built some complex features, and actively gave/solicited feedback to/from my teammates in my initial few months.
In the same year, the product became more customer-oriented and aimed to achieve 10x growth. This made customer satisfaction become one of the product's essential aspects.
However, this also made it clear that we needed dedicated Product Design leadership to achieve this goal.
Till that point, each designer operated individually in their initiative & our then manager left Fyle. Hence, I took this opportunity of switching my job profile when my new manager asked me to do so. During the time, designs were heavily influenced by the engineering Org.
I was very new in the managerial world and did not clearly understand where to start. I also had imposter syndrome issues initially and was afraid of not getting enough time for my craft.
I ended up going through several resources and managerial books, which seemed to be pretty overwhelming, but to some extent, I felt a shift in my mindset. 🙂
As the first step, I took care of my team's immediate needs and established design stand-ups twice a week and regular design reviews. Next, I worked with the team to standardize the presentation of wireframes & the overall design process. The entire team also shifted to the Figma environment to enhance team collaboration. Lastly, I created a wish list for all Product Design and included those in the product release cycle in each quarter.
I felt the need to have some secret base roadmap to direct the team well. I took this from a book titled "Making of a Manager." It worked well for the first 8-9 months in terms of sustaining the team.
So the very first thing I did at Fyle was "Building a right team."
Building the Team
Visioning the Team
Before I build the team, it was essential to understand the team We needed at Fyle.
I came across a great book called "First Break all the rules," which says
“People do not change, mostly. Skills can be developed, but that person should have XYZ talent. Talent cannot be taught.”
Hence, I carefully documented the skills and talent needed for the team, — Which has been instrumental when we
Write JDs for new hires
Select talent in the hiring process
Provide training or support to new hires
To learn more about Skills and Talents - First, Break All the Rules.
The selection mostly happens based on the talent that maps well concerning company culture and team core values. 🙂 As I said, we can teach skills, but not talent.
The Hiring Process
It was my first hiring experience. I was equally nervous as the candidate. 🙂 I shadowed some of the great interviewers and quickly identified few common traits of theirs. Some examples are:
Making the candidate feel comfortable
We share a doc with the candidate detailing expectations from them in every round
Digging deeper than just gracing the surface
Ask a lot of follow up questions
Looking out for specificity and capturing the things floating in the candidate's top of mind
Sourcing
The hiring process starts with Sourcing. The sourcing pipeline should always look healthy, otherwise hiring will happen in desperation. I ran into this problem after the first month of hiring, and the self-reflection helped us identify this and quickly fix it by running a fast process around it.
E.g., posting pipeline status in each stage, moving candidates faster from one stage to another, having a 15min weekly sync up twice.
An interesting analogy that my manager shared with me was, Intern and Junior post-hiring almost felt like an arranged marriage. In contrast, for a senior post-hiring, it felt more like dating apps. Entry-level posts needed more filtering, while senior-level posts needed more selling.
At Fyle, I initially took care of filling up the pipeline, but recently involved a few other team members. Moving forward, I also aim to include individual contributors to the process. This will undoubtedly enable other teammates to receive recruiting wisdom much earlier in their careers. I am currently working on a model to make it more scalable.
Here are some crazy, talented folks that I hired to build our first-ever Design Team at Fyle. I had gone through almost 100-200 plus applications per hire, conducted around 6+ hour long interviews per day sometimes. We increased our team size to nearly double during this hiring season and expect to further expand the team in the coming quarters.
It's my privilege to work with them as they bring diversity & constantly push me to think beyond; they often come up with better ideas/suggestions to build a world-class team.
The idea of building a world-class team is the equipment that keeps me moving.
As mentioned recently, I have been trying to scale up my recruiting efforts; I am building few processes around it. Before each hire, I usually share a note with the teammates regarding what we are looking out for, conduct a session on how to dig deeper with specificity & how to make candidates comfortable by giving some context around the product, business, team, and company culture.
E.g: What are we looking out for XYZ Position?
Make the candidate & yourself comfortable
At the start of the interview:
Introduce yourself
Help them understand what your product does
Business-wise where the company is at right now
Let them know the company culture
Let them know about Design Lounge hours where designers meet and talk about random things.
What the candidate is going to own in the product
Pro-tip: Always conduct interviews in bulk. This helps to close the position quickly.
Onboarding
When I joined Fyle, I struggled to get the Co-working space Wi-Fi and password. I looked around and found people were so deeply involved in their work & I felt terrible to disturb them. On opening the email, I found a couple of emails and assumed a few of them might be spam as I never experienced such a volume of emails on the very first day. I did not receive proper product training and did not know whom to reach out to.
I never wanted my new teammates to go through a similar experience. Successful onboarding is crucial for the new hire's success in the workplace and can integrate them into a productive working environment quickly.
The onboarding process for every new hire broadly involves following things spanning several weeks and starts after pre-onboarding
Company Culture intro
Intro call with the manager
Onboarding plan overview
The design team and company workflow Process
A public doc on Notion page to get access details of different tools and product
Deep product training with module experts
Team intro call
Meeting with PMs and EMs
Intro to Design Systems
Taking part in design stand-ups and shadowing review panel
Additional LnL session if the designer is new in Figma
Daily 15 min sync up calls with the manager to eliminate any blockers
By the end of two weeks, the new hire works on a new initiative (relatively a simple one & then the complexity level increases) 🙂 — all with enough context around producing excellent output.
All the new hires worked on complex projects after four weeks of joining and produced fantastic work.
What is a great design at Fyle? — The grounding principles for producing great design work
Our team was ready! But how would they know "What Great work looks like at Fyle"? How to set a higher standard of the quality of our design work?
I wanted to change the quality of the work and the visual language currently used at Fyle, and how we collaborated with other teams. Designers hardly participated in data-driven design discussions & had less product/feature context, which reduced their chances of advocating for the users in the stakeholder's meeting, resulting in a compromised solution. It happened as engineering org heavily influenced the designs in our early product design approach. The designers working here are great ones 🙂 . I only needed to take care of a few things to use their maximum potential to produce excellent output.
Partly, I tried to solve this problem by defining grounding principles around the craft and collaboration, whereas issues related to product context were solved through onboarding.
The Grounding Principles:
The principles are defined considering the loopholes in the existing design language, process, and implementation. — Few of the principles would be changed as we progress from here, and more streamlined product design principles will be in effect.
Craft Related Principles:
Collaboration related principles:
[Yet to be documented]
Listen and then speak. Also, be outspoken.
Advocate for the users.
Trust and be trustworthy.
A short framework for delight:
Delight Customers with Simplicity and Speed in a given context.
Customers should tell “Amazing things about their Experience with the Product.”
Delight users through an aesthetically pleasing Interface.
This is non-negotiable.
Gearing towards producing a great output — The Processes as a backbone
Kick-off Call
Any complex feature always starts with a kick-off call to align stakeholders, designers, and engineers. This happens much early in our product/feature release cycle.
The kick-off call is arranged to understand
Any unknowns, ambiguous information concerning processes and how to eliminate them
The scope of the feature
Processes to be carried out with respect to each org ~ pretty rough discussions! (e.g., Internal or external usability testing to be done or not)
If any data tracking needs to be done
—
A rough design checklist that we carry out in every initiative is
Understand the product context and problem statement.
Spend more time here
Feel free to question PMs on the problem statements
Feel free to discuss with PMs if the problem is not a user problem
Initiative Sync ups
After every design critique in the DRP, bring all stakeholders together and discuss ideas
This happens immediately after the designer takes care of feedback given in DRP
Nielsen’s Heuristics
Design should satisfy the heuristic criteria, should aim for scalability
Design Review:
Get designs reviewed in the Design Review Panel (DRP) before discussing this with the stakeholders.
Final HFD will go through DRP only.
User Testing
Perform Internal Testing
Perform External Testing
Data Tracking
Take the help of Engg if anything needs to be tracked in Hotjar/mix panel
Design Stand-ups
Design stand-ups happens twice a week at Fyle, whereas initiative sync ups occur almost every day.
Since the product modules are tightly coupled with each other, design stand-ups have been a great way to understand who is working on what and if there are any interdependencies we can quickly identify as most of the feature is owned by a single designer. We are working more towards forming a team around a specific persona or module in recent times.
It has also eliminated the risk of multiple people working on the same thing, saving a lot of our time. Also, this is a great way to understand our weekly progress or any other blockers.
It has been helpful with improving productivity and accountability in general within the team.
Design Review Panel (DRP)
We run daily design critique in our Design review panel and have blocked 1hr of time every working day.
The initiative designer gives context to other team members and presents their work. Our DRP is an open platform where every single member has been allowed to share relevant feedback. The facilitator notes each input shared in the panel and shares the same info on the dedicated initiative slack channel, keeping other stakeholders in the loop.
I usually stay present in every design review- — It's just natural for me to be converted to an IC profile during this role. While sometimes I give direct solutions (which I should not and have been trying to improve myself here.) My role is involved more around pushing our team members for more explorations and producing quality output through attention to detail. And this has inspired other team members to do so. It has ultimately helped us to deliver excellent work in consecutive quarters as a team.
While some of the team members did not share their feedback during the initial days, the following practices had enabled them to speak up lately.
When anyone speaks up, we acknowledge it 🙂
Actively meditate during team meetings, and respectfully invite quieter members into the discussion.
We encourage people to add offline notes if they cannot share their thoughts for XYZ reasons.
We share the agenda of the meeting early on.
Each design team member receives critical feedback at ease and is one of the talents that we carefully look out for during the hiring process.
FIGJAM Sessions
Sometimes we need to collaborate more as a team and generate ideas to solve a specific blocker in the initiative or present a few ideas to other stakeholders.
The designer arranges a Fig Jam session and invites other designers/stakeholders to participate. The designer presents the context if necessary and explains where we need to ideate/discuss more. We do not have a specifically dedicated slot for this. This session usually happens as and when required.
Sometimes we run this session in DRP directly if it is more towards getting a design solution.
Managing Design Systems
A design system is a living guide, and it needs an update as we implement features. We do not wish the design system to restrict the designer. They are free to experiment with the patterns.
For any new pattern or changes to the design, designers need to
Explain the reasons
The impacts of it at other places
Check-in with the other module owners and designers
Create a task in Click Up and assign it to design system stakeholders
We also keep track of the patterns that need updates via Click Up.
In each quarter, we have recurring initiatives to update the design systems across the platforms. We are currently working on forming a team around managing design systems.
Initiative Sync-ups
After the design critique, designers bring all initiative stakeholders to showcase the ideas or solutions to get buy-ins in each stage.
Quarterly Reflection
We do a quarterly initiative level reflection within the design team to understand
What went well
What did not go well
Learnings
This helps us do better as a team next time.
Strengthening The Relationship
Constant Check-ins via 1x1
While there are many factors associated with it, my goal is to build a strong relationship with the direct reports, which will enable them to go from the base camp to the summit.
I usually do a constant check-in in the following areas.
Offering Critical feedback:
I am conscious about not falling under ruinous empathy zone where
We tell X good things to tell Y critical comment
or vice versa
My views towards offering critical feedback have been shifted to something like
"Offering Critical feedback is nothing less than offering a gift, and this gift has compounding effect like Stocks."
My teammates have always loved it.
Conclusion
I take immense pride in myself when I think about the challenges that I faced as a first-time manager, and through all of these, I was able to build a stable team, in fact, the very first design team at Fyle ❤️.
While we improved in many areas as a team, we need to go miles from here. Our vision is to make Fyle known for delivering a great experience in the B2B Space by leveraging design as a tool.
(Old Designs)
This is how the same page looks like today.
