Writing Your Own Performance Review

I’m not the type to boast. I wasn’t born and raised to properly receive complements (queue awkward silence when someone says my hair looks great today) and unfortunately, I think that also makes it difficult for me to give them as much as I would like.

So imagine when HR tells the organization individuals are required to write their performance appraisals.

My blood pressure spiked. I know I have a bad habit of underselling myself (as I am told), but I feel disgusting saying and writing prideful things. It feels icky.

Vitals
Vitals. Photo by @pixabay

Where’s the in-between?

What do I say?

Why is this so hard?

I blame my mum!

Jokes aside, I figured it would help future me and other folks out there if I shared what I ended up scrimmaging together.

Note: The review period was for January 1 2018 – February 15, 2019

Accomplishments

Please list the highlights of your performance this past year. Accomplished goals, professional development. List how your success impacted the business/others

  • Investigated and improved live receipt webview loading from 6+ seconds to ~2 seconds on the 3G mobile network (my working baseline for measuring our main metric was on slow mobile connections). Also refactored webview to be testable and improved developer productivity.
  • Led efforts and implemented next-gen RWD to better improve UX and developer productivity, making it easier to add in tests, new features requests from product, and other modifications to the UI.
  • Improved partner integration with the SDK by minimizing custom initialization params. It makes the onboarding process more streamlined and less confusing for both partners and the onboarding team.
  • Architected, planned, built, and currently maintain entire lifecycle + iterations of the component library (and playbook).
Thumbs up
Great job, continue your thing! Photo by @donaldtong94

Strengths

Please list your top three strengths, and after each, give a specific example of an instance where this strength was exemplified.

I am extremely flexible with sprint loads. Working on the SDK, webview LR, and RWD means exposure to users (both internal and external). If bugs come in, I need to be flexible enough to work on high priority issues and push them through. On top of that, I also work through my load quick enough to grab more tickets from the next sprint.

I strive to improve poor processes around tooling and documentation, primarily anything related to developer productivity. It not only helps me but the team. A huge weakness with webview and RWD was the lack of tooling and testing, and I have since improved those to be streamlined.

I have strong UI/UX knacks (and work great with the Design team). I know the ins-and-outs of the design system not only because I was there to help it be conceived, but also because my working design knowledge makes sense of the decisions made. I rarely need to involve Design with my projects, unless it’s non-trivial or involves product. It saves them time to work on other things.

Opportunities for Improvement

Please list three areas where you could improve and develop performance

A better understanding of backend services. Sometimes I get thrown into a story/epic without a proper working knowledge of what’s expected to be done on the UI side, but I don’t have enough information in my arsenal to hold backend accountable for their delivery of various API/data/data models.

Books pile
Time to learn. Photo by @pixabay

Along the same lines above, I need to speak out more/sooner when things are unclear so I can establish a better understanding of what needs to be done/how it can be done. I tend to figure things out on my own, but if someone else has a better working knowledge of something, I should reach out sooner and take advantage of that.

User empathy. More specifically, RWD users. Since refactoring it, I haven’t had the chance to consider how people want to use the store (eg: probably more like a normal store). I need to ask people what is useful, and then get those stories written. For example, people probably want to be able to select what size dress to add to the cart. Testing that data is important too!

Conclusion

I feel vulnerable posting this, but I can only benefit from it! I hope it was helpful for you and inspires you to not be afraid to give yourself a great pat on the back.

Mee in a rainbow
Putting myself in the rainbow spotlight. Taken at Odaiba, Tokyo, Japan teamLAB Borderless installation, 2019.

Tags:work

Written by Mee Cha who is probably twiddling her thumbs wondering what's next on the menu. Github | LinkedIn | Instagram

© 2021. Built and maintained by Mee.