Small Asks for Simple Feedback

Shipping new features to users is a thrill that every engineer I’ve known chases; recently in my work with Robinhood I’ve been lucky enough to have that experience with the Recurring Investments team: we created and delivered recurring investments for cryptocurrencies, a feature that we designed to expand the user base of the recurring feature while providing our existing users with more options for diversifying their investment. From being involved since the outset of this effort I learned so much: I was exposed to new tools, technologies, and design patterns. I was challenged to understand new concepts, consider an entirely new classification of users, and question assumptions that I had made about the type of people who were engaging with my domain. Each day spent in service of creating this product alongside some of the most passionate and skilled engineers that I know was a joy; looking back now and seeing our accomplishments fills me with pride.

As great as the experience was and as fond as I am of the product that we produced, I’m not allowing myself to be blind to the idea that my team and I can always do better: each project can and should teach us something. As is commonplace in the software industry my team has completed a series of retrospectives to identify the lessons that we collectively want to take from this work; there are technical improvements that we’ll make as well as process improvements that we’ll implement so that the next phase of projects that we take on will be executed even more efficiently. All this team development and learning inspired me to take action to be sure that I was not only learning alongside the team but also growing individually. I have kept track of what I got out of the work that I did technically, the new patterns and practices that I have become comfortable with thanks to being hands-on with them in the course of building and refining will inform my work going forward. Beyond this technical growth I know that it is equally important to make sure that I am reflecting on how I can improve in my individual contribution to my team’s success: I was interested in gathering my peer’s thoughts on my performance over the course of this project in order that I can integrate their thoughts and ideas into my work going forward.

Since everyone on my team is always very busy I knew that it would be important to optimize the means by which I asked for feedback. With Robinhood making heavy use of the GSuite office system I made a short Google Form and sent it individually to the people that I knew I wanted feedback from. I think that the simplicity of the request was key to the great response rate that I got: the form contained only three questions, each optional. This meant that anyone could provide as much or as little information as they desired and had time to give, reducing the chance that someone would procrastinate writing down their thoughts.

If you are going to try something like this in the future I’d like to point out one detail that I believe was integral to my process: I requested feedback individually from each person that I sent my form to. I didn’t post a mass request in one of my team’s many Slack channels (although I was tempted!), instead I opted to personalize my ask for each person. I figured that it was the least that I could do if I was asking for their valuable time. In each request I included why I was specifically seeking feedback from that person, what their contribution would mean to me. I know that I’d be much more inclined to prioritize completing a request for feedback if someone else asked me for my time with a personal touch, I sought to do the same in making my request.

It took just a few days for me to achieve a 100% response rate to my requests, and the feedback that my colleagues took the time to write to me will be invaluable for my continued improvement. I’m so thankful to my coworkers for taking a few minutes to provide me with their thoughts. A few themes that I pulled out from the collection of feedback that I got was that my flexibility in working across multiple platforms and domains for the project was useful to everyone, and that having an openness to learning and trying out new means of making a technical impact was equally valued. I was reminded that I should continue to focus on testing and reviewing my own work before sending it for review (this is consistent with past feedback and is an area of constant growth for me). One new piece of feedback that I’m going to focus on for the remainder of the year is in the way that I approach new ideas coming up in team meetings: I frequently frame my ideas as a question: “I wonder if we should do thing?” or “Would we benefit from another idea?”. My justification for this framing was always to be humble and avoid dominating a meeting with my proposal, it was suggested to me that a stronger leadership-oriented means of doing the same thing would be to make a suggestion (“I think we should do _my cool idea_”), get confirmation from others that the idea has merit, and then see if someone else on the team would like to own the implementation of that idea. In implementing this process instead of the question method I give someone else the opportunity to own a portion of the idea as well, thereby also taking some of the burden off of me.

While I found this method successful I know that it, like everything, can also be improved. If in reading this you have developed ideas for improvement to my system I’d be glad to hear them! (Yes, I’m even seeking feedback on my feedback process!)