Case Study: Connected’s In House Kudos Generator

Estimated Reading Time: 8 minutes

A team of Connectors set out to improve one of the most cherished rituals at Connected, weekly kudos. Learn more about the research they undertook to get to the heart of the problem, the technical challenges and tradeoffs that had to be considered, and why this project was especially important to the company as we shifted to remote-first.

We celebrate each other

At Connected, we like to recognize and celebrate when our employees do something great, experience a win, or achieve a milestone. That’s why we give each other kudos via Lattice during the week, and each Thursday at our company-wide demos we spend the last 10 minutes reading out these kudos and celebrate the Connectors who received them. To many Connectors, it is their favourite part of the week.

This beloved kudos tradition has been a huge part of our seven-year history, and has both withstood the test of time and the transition to our remote-first environment. For the first little bit this ritual was done manually. Each individual nominated to read out these kudos would do so directly from Lattice or the Lattice integration in Slack. But we realized this wasn’t a great experience for the reader, and since it was something we did every week decided to make this better (Another popular Connected ritual, more on that in a future post!). So, with all this in mind, a small (but mighty) team of Connectors set out to address this challenge during some of their unallocated time. If you’re interested, you can have a look at another unallocated project by Connectors here.

Jobs, Pains, and Gains

To figure out how to make the kudos readout experience better, we first had to learn what was and wasn’t working. To do that, we had to do research with our users, Connectors. We documented what we learned in a simplified overview of the customer-profile canvas in Figure 1. If you’re interested in the customer-profile canvas, we recommend that you take a look at this book on Value Proposition Design.

Challenges

During development, there were numerous challenges that we had to tackle, most of them related to handling sensitive data. One such challenge was extracting the kudos, author, and recipient information without compromising the rest of the sensitive user data that could be extracted from our HR and People Management systems. To mitigate the risk of accidental access of sensitive user data, we decided to use the #kudos Slack channel to get the information we needed instead by adding our own Kudos Listener bot (have a look here for how to create a Slack bot) and saving the information in GCP from the Slack API.

Another challenge was to select which kudos should be presented each week, without repetition of data from the previous week, and with minimum effort from the user. Our first approach was to have a date picker which would allow users to select and capture kudos from the previous week. However, this would be a bit tedious as the Connector presenting kudos would actually need to remember the last date the kudos were presented, which can be problemsome when weeks were skipped due to holidays or other reasons. Therefore, this was not a very reliable method, so an archive feature was added, which allowed users to “archive” the kudos once they have finished presenting. These “archived” kudos would not show up in subsequent kudos presentations, whenever it might be, next week or two weeks after. These are some of the examples of the technical challenges that were mitigated by the team during development via research and discovery which were very helpful in building out the perfect usable product.

Technical Tradeoffs

Developing an application also means making some difficult decisions and some technical tradeoffs which are essential in shaping out the final product. One of the major decisions is the selection of database, platform, frameworks, etc. In this case, choosing the database needed technical discovery, weighing upon different options based on pros and cons, before making a final choice. Based on the need for the database to be scalable, fast, and easily integratable with Google Cloud Platform, it was decided to use Google Firestore. Since it was a Google product, it would provide the speed, scale, and ease we were looking for from integration and beyond.

To understand the architecture of the product, have a look at the simplified UML diagram in Figure 2.

Another major decision was choosing the frontend framework and backend technology for the application. Due to its popularity, community support and easy usage, ReactJs was the deserving candidate for the frontend, along with ReduxJs toolkit for State Management. The styling library chosen was Material UI. We liked its ease of usage, seamless integration with React, and icons, buttons and different components were easily available and required minimal alterations before usage. Every decision made was backed up by discussions, technical discovery, and weighing pros and cons, before landing on a team decision. Approaching it this way resulted in a final product that was easy to build, easy to maintain, and, most importantly, easy to use.

Approach

We decided to mimic a client-facing project as much as possible, and because of that we employed rituals such as daily stand up, weekly IPM, and bi-weekly retro. To stay accountable to our user base, we decided to do monthly demos to the full Connected company as well.

To break down the work we used Asana. We could assign pieces of work (tickets/stories) to our engineers, and easily understand responsibilities, deadlines and how they fit into a greater whole. We also used Miro to build a User Story Map, which can be seen in Figure 3. Miro integrates with Asana so it made it easy and convenient to port user stories back and forth between the two tools. The User Story Map was a useful tool to understand all the underpinning tickets that fit into different sections of the product, and that way we could understand which parts were simple, which parts were complex, and which parts needed the most support. We could also better align on which features were essential to an MVP/first launch and which ones we could punt to a later release.

So, how did it go?

We launched our MVP and our colleagues at Connected loved it! We received so much positive feedback, everyone told us that it was much better than the previous solution. Here’s a statement from our very first user:

“It was a good experience to have this tool. I liked that I had something visual to present and that I didn’t need to take extra time to prepare that. The fact that it only takes a few clicks to generate is appreciated and the onboarding was super straightforward” 

– Connected Employee

It was a great 10 weeks of collaboration, and we’re excited to have Connectors use the generator to continue to praise, recognize, and celebrate efforts to chase impact for our clients, Connectors, and communities!

Kudos to the team contributors of Project Kudos Generator: Ashna Raman, Cathy Qiu, Katie Zhan, Matt Deluco, Matthew Dent, Mikkel Lunding, Navdeep Dhindsa, Olwasoji Sanyaolu