2015 Asynchrony Performance Review

This year, I was in the advocacy program at Asynchrony again.  The advocacy program is different from the traditional review process in that you solicit feedback from your coworkers on a regular basis and have an “advocate” that helps interpret the feedback and guide you in general.  In the traditional review process, employees give peer reviews to their coworkers at the end of the year and a manager summarizes the reviews.

Every employee, regardless of which program they were in, had to answer a couple questions about career aspirations as well as identifying three things that they did well and three things that they could improve upon.  Afterwards, if you were in the traditional process, your manager filled out three things that other people thought you did well and three things that other people thought you could improve on.  If you were in the advocacy program, you worked with your advocate to summarize the feedback you received all year to write the three things you did well and the three things you could improve upon (as opposed to your manager writing it).

I’m not entirely sure how I feel about it still, but it was definitely an interesting experience. It felt odd to me to ask for feedback from my peers but then input feedback in a system where the coworker could not see it, but a manager could view it.  I decided to send all of the feedback I wrote about people in an email to the people themselves as well as put it in the feedback tool.

As for getting feedback in the past year, there have definitely been ups and downs.  I solicited feedback in a Google form that asked for things that I was doing well, things that I did poorly, and things that I could improve upon.  I also solicited feedback from people face to face while there was a lull in a pairing session.  The QA team at Asynchrony seems to have a great feedback culture overall, so some of the best feedback I’ve gotten has been from QAs on my different teams.  It was very hit or miss with other developers on all of the teams that I’ve been on.  I tried to bribe people with cookies to fill out my feedback form, and that seemed to actually be the best way to get feedback.

My current team as a whole decided that it would be a good idea to try a 360 feedback session.  In a 360, a couple people are chosen to be receiving feedback from the rest of the team.  Everyone writes constructive, actionable feedback on sticky notes and then passes it to the person. The person who is getting a review will summarize the things that they think they should work on and ask any questions they have about the feedback they received.  We tried this today with just one person getting reviews, and it was awesome.  There was an intro section on what helpful vs not helpful feedback looks like which helped everyone get into the right feedback mood. I also think it was helpful to have time set aside for feedback.  Other people in the advocacy program say that giving and receiving feedback should be second nature, but come on, we live in the midwest and haven’t been socialized to give feedback to each other.  I like that my team is trying to find a way of giving and receiving feedback that works for us as a team.  Feedback in general is so inherently person that I believe that each team needs to come up with something that fits their needs and comfort level as a team.

The format of this year’s review was much shorter and structured than last year’s review.  I was on three separate teams this year.  I started the year on an iOS team.  Multiple people gave me feedback last year that I should try to learn a different technology stack.  When there was an opening on a Ruby team earlier this year, I asked to switch and got moved to a Ruby on Rails team.  At the time, I had no idea that web development was not just learning Ruby and Rails but also JavaScript, HTML, CSS, and a whole sweet of new tools including VIM (still struggling with this one!).  I spent most of the year feeling like I wasn’t learning fast enough and that I’d never get everything in my head.  In the past couple of weeks though, I’ve felt like I really got a better handle on some things and that it’s getting less overwhelming.  I still have some days where I totally suck, but it’s getting less frequent which is nice.  Anyway, in an effort of transparency, here’s my review:

Please describe your future short and long-term career aspirations:
Short Term (next 12 months):
Give a conference talk, learn to program in Swift, go back to iOS development

Long Term (within the next 5 years):
Be a team lead, teach others to not make my mistakes, and work closely with a customer. Help my community by sharing my technical skills on a wider level

Identify three areas you feel you do well:
1. Take time to help, teach, and mentor others in all aspects of our job.
2. Keep a positive attitude at all times, and help motivate my team (and the customer) to do their best work by challenging them to learn new things as well as hone areas where they already shine.
3. Keep learning and challenging myself to do new things. This year, I learned not only a new language (Ruby), but also about the world of web development.

Identify three (3) areas you feel your employee does well (written by me from feedback I received):
1. Constantly learning and challenging myself to do new things.  This year, I switched from mobile development to web development.
2. Having a positive attitude while being direct and honest with a pair to accomplish tasks.
3. Helping others whenever they need it including working with the customer and other project management tasks.

Identify three areas for improvement (business and behavioral):
1. Learn more design patterns, especially those in Ruby.
2. Learn Swift and keep up on iOS development as a whole.
3. Go through the training to become an agile coach so I can help my team become more agile as well as teach others to optimize their team dynamics.

Identify three (3) areas you feel your employee can improve (written by me from feedback I received):
1. Have a more comprehensive in-depth knowledge of the code base I am working on.
2. Take control of the pairing session more often and speak up when I don’t understand things.
3. Learn more design patterns and continue to learn about web development​.

Leave a Reply