Back to Home

Beyond building processes

A considerable amount of time in 'Year 1' of being a manager has been about setting up artifacts and processes. I was lucky to be part of an organization that had a documentation culture in its DNA. This was partly because we had Program Managers embedded within each team. This meant that Jira, Confluence and Asana were setup and maintained religiously, with weekly feature spec reviews [FSR] and ProdTech meetings to keep these upto date.

Setting up Documentation spaces

I find design documentation to be critical part of the design process. I recommend every designer takes the time to document the project because apart from being a design artifact, that serves as a single point of truth, it also helps them when they have to write their performance reviews, promotion proposals and build their portfolio.

I do not like Google Docs for documentation. Documentation spaces need to be a searchable wiki and ironically Google Docs is poor at providing this. At Practo, we already had Atlassian’s Confluence setup when I joined, and at Gojek, Maji setup our Confluence spaces in 2019 and then the two of us started structuring and documenting our knowledge about the product and its processes. I created a design documentation template based on the product feature spec template and advocated for it.

As for project management, the org moved to using Asana. Adding them here felt forced and an unnecessary addition to our workload. However as our product roadmap was moved into Asana, I devised a process to make design tasks a visible part of the product development process by adding them as subtasks and duplicating them to our design boards for effective tracking. Post every prioritization meeting, I added tasks into the todo list and tagged designers so that they were aware of what’s coming up.

However, we faced a problem with adoption of these processes. We lacked a program manager dedicated to design and not all designers in the team were able to keep their boards updated. We were able to setup a biweekly cadence with the program management VP, Gifika, to discuss our problems and understand how we can get better at solving them. And what we learned is two things.

1. Add more meetings in the calendar
2. Be a bad cop

More meetings in the calendar

When your calendar is already full of meetings, you feel like staying away from setting up any more that will take away whatever little 'time for focus work' that is left in it. But given our problem, this seemed to be the most effective way to get things working. Our team was a 3 level hierarchy so each lead now had to setup two additional cadences into their calendar. One was a common stream leads cadence where each stream lead would come prepared to the biweeekly meeting with a progress update (which would be posted biweekly to the Asana board) Maji worked on a template for this.

The other meeting was with their stream where each of their reports could come with a similarly formatted update. This meeting helped stream leads prepare them for the stream leads meeting. You can also make these meetings async if everyone is diligent. The updates were a small part of the biweekly leads meeting.

Be a Bad Cop

Not all designers like following process. They may see it as additional work with low ROI or they may just not have enough time. You should take the time to communicate the problems that the process is going to solve and ask them for feedback on the process. Make it feel like they co-own the process. But if this fails, then you should be okay with being "bad cop". This would mean that you would need to set Slack reminders, add calendar invites and send DMs if everything fails. This is the way.