It’s review time again! You can read my Asynchrony review from last year here. This year, I was again in the advocacy program, which meant that I had an advocate that I met with every so often, and we’d talk about whatever feedback I had gotten. The review system was different this year from last year. Last year, if you were in the advocacy program, you somewhat had to solicit your own reviews from people, and it wasn’t the easiest to get feedback. This year, everyone got to pick people that they wanted to review them and those people were asked for three things that you did well and three things that you could improve upon. You could have a max of 12 people, and I was able to fill out all of those spots because I’ve been on so many teams this year! I was on a ruby team for half of the year, a Swift iPad app team that was half Asynchrony people/half client employees that were embedded, another Swift team that was focused on an iPad app (for only two weeks!), and now an iPhone app for our parent company WWT.
Many of the teams that I was on had 360 feedback sessions. The idea behind a 360 feedback session is that you have a subset or all of your team be the subjects of feedback for an hour. Typically, everyone writes down positive or negative useful feedback on a post it note and then gives it to the person. The person then summarizes all of the feedback that they have received and talk through it to prevent any misunderstandings and to gain clarification. That person can then decide to say that they’ll improve somehow. Every single team I was on this year except for the current one (which I’ve only been on for a little over a week) has had 360 feedback sessions. Depending on the team, they’ve been drastically different. The ruby team that I was on had the most useful feedback in the first round of 360 feedback sessions, but the usefulness dropped afterwards. The Swift team that I was on with the client employees had only one 360 when I was there, and the feedback was very surface-level as everyone was getting used to the idea of feedback. I heard that they discussed the feedback a lot afterwards, but I wasn’t there for that discussion as I was already on another team.
I think it’s pretty awesome that I have a stack of post it notes with feedback on it. During most of the 360 feedback sessions, I got useful negative feedback saying that I could improve my level of focus, try to have more time on the keyboard when pairing, lead in general more often, try to have more self-discovery instead of asking for help, question assumptions, stand up to strong personalities and don’t give in so fast, and don’t be so hangry all the time. I think I definitely grew as a developer and a person by receiving the feedback. I took to heart the not being hangry feedback and pushed back hard against any and all lunch meetings unless I had eaten or had plans to eat during the meeting.
None of that feedback shocked me at all. I was a little surprised by the feedback that I got from the annual review process. I really enjoyed that I could see who wrote what feedback so that I could have some context for it. In previous years, managers of some sort would get to read everyone’s feedback and then tell it to you through their own interpretations. I loved that I got to see all the feedback and interpret it myself with the help of my advocate. On the annual feedback report on things that I could improve upon, I was a little surprised to see that I had been acting very negatively when I wanted to be off of a particular team and that it effected team morale. In retrospect, it was stupid and immature to be complaining so much. It was one of those things where I subconsciously knew it was terrible to be constantly negative but I couldn’t stop myself from doing so. I sent an apology email to the developers on the team at the time. I also got unsurprising feedback that I was late to stand up a lot and I should be able to alter my morning routine. After I left that particular team, I haven’t been late to stand up without a good reason. Yay for some improvement! Most of the other negative feedback that I got was similar to feedback from 360 feedback sessions.
All of my positive feedback from the annual review process was along the same lines as my positive feedback from 360 reviews. In general, people liked that I had a good attitude, that I wasn’t afraid to voice my opinion, and that I contributed a lot (aka talked too much) in retros, story planning, and client meetings. There was a lot of feedback about how I was a good communicator, a good mentor, and decent at getting a conversation to get back on track. As is the norm, I always seem to get feedback on how I bake a lot and how that brings the team together. This was the first year that I got actual feedback on my technical skills! I’m not going to lie, I was super freaking excited to see people comment that I had “great technical chops” or the ability to “quickly jump into a code base and learn what is going on.” A couple people commented on how I was developing in multiple languages, too. I was also excited to see feedback on my talk at the internal Asynchrony conference on unconscious bias. There were a lot of kind words as well as suggestions to take it to the next level.
Similar to last year, I had to write three things that I could improve on and three things that I was good at before reading the reviews. Then, I had to meet with my advocate and go through my feedback and re-write the three things that I could improve upon and the three things that I excelled at with the context of other people’s feedback. I also had to write about short and long term goals. I was really excited to see that I had met all of my short term goals from last year. Here’s what I input into the review system:
Short Term (next 12 months): Give a technical conference talk, learn more about agile coaching, create a public-facing Swift app
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. Give a keynote at a conference.
Identify three areas you feel you do well:
Before feedback:
– I gave a very well-received talk on unconscious bias at the internal Asynchrony conference. After that, the talk was accepted at 3 additional conferences so far (Agile Gravy, Alterconf NYC, and McKendree University’s Idea Lab). I also created an introduction to Swift workshop that I presented at CoderGirl as well as at the StrangeLoop conference.
– I created the Google-sponsored Women Techmakers group in the St. Louis area to promote diversity in the local tech community. I am on the Leadership Task Force at Asynchrony to help come up with tangible ways to help Asynchrony grow as a company.
– I moved from a ruby team to a Swift team earlier this year. Not only did I pick up Swift, but I also helped teach the client’s developers how to program in Swift as well as how to use test-driven development.
After feedback:
– Takes initiative while talking to the customer and team members to keep the team on track, make the team work more efficiently, and drive stories forward.
– Quickly ramps up on projects and provides value on a team immediately.
– Mentors and teaches others technical skills in an inclusive way. Presents topics like unconscious bias in a way that is understandable and actionable for the audience.
Identify three areas for improvement (business and behavioral):
Before feedback:
– Increase my knowledge of how to create performant Swift apps and proactively find areas where my app may have performance issues with real data
– Learn basic visual design principles so that I can create more engaging slides for conference talks. Continue learning about effective ways to convey information to people whether it’s in meetings, while pairing, or while presenting.
– Learn more about how to become an agile coach by effectively conveying agile principles within a team as well as to a customer. After going to Agile Coach Camp and the Agile Gravy conference, I realized that I wanted to learn more about the obstacles that clients had to overcome to incorporate agile principles in their development practices. I’d like to learn techniques to help them “manage up” and restructure their teams to be more open to agile.
After feedback:
– Keep taking training on agile coaching skills
– Engage more in higher level architecture discussions
– Be more assertive & vocal about technical improvements especially hard team problems that don’t have a resolution
As you can see, I kind of lost steam on what to write after feedback. I heard that no one really reads it, and that it’s for my personal benefit. This blog post seemed more beneficial to me, so I chose to spend the time here. I also realized through all of the feedback that I wanted to learn more about agile coaching. While I like development, I really enjoy the parts of communicating with a team to work together and make an awesome product. I’ve been going to a lot of agile coaching conferences somewhat by accident, and I realized many coaches do not have the perspective of a developer at all. In the past couple of months, I been training to become a retrospective facilitator and reading a lot of books on team management. We’ll see what next year brings! Hopefully, I’ll be able to accomplish all of my short term goals again.
Special thanks to my advocate Adam Ritzel and all of the awesome people who commented on my technical skills.