🏫
Obvious University
Website
  • 👋Welcome to Obvious University!
  • Strategy
    • Sprints
      • 1️⃣Map
      • 2️⃣Sketch
      • 3️⃣Decide
      • 4️⃣Prototype
      • 5️⃣Test
    • Benchmarking
    • Research
      • 1️⃣Research guide
      • 2️⃣How to recruit users
      • 3️⃣How to conduct an interview well
      • 4️⃣How to take notes
      • 5️⃣How to prep for remote research
      • 6️⃣How to throw a watch party
      • 7️⃣How to create artefacts
  • Working with Features
    • Building with AI
      • 1️⃣Understand the tech
      • 2️⃣Map your product
      • 3️⃣Build a proof of concept
      • 4️⃣LLM Inputs
      • 5️⃣LLM Responses
    • Building Help and Support
      • 1️⃣How to scope a support experience
      • 2️⃣How to design discovery for support
      • 3️⃣How to design a support centre
      • 4️⃣How to write good support articles
  • Product Design
    • Microcopy
      • 1️⃣How to write well
      • 2️⃣How to write phrases
      • 3️⃣How to write messages
      • 4️⃣How to create a voice
    • Typography
      • 1️⃣How to compose type
      • 2️⃣How to create a type scale
      • 3️⃣How to pick typefaces
      • 4️⃣How to pair typefaces
    • Design System
      • 1️⃣Introduction to design systems
      • 2️⃣How to audit a design system
      • 3️⃣How to run a design system pilot
      • 4️⃣How to set up a design foundation
      • 5️⃣How to build components
      • 6️⃣How to document a design system
      • 7️⃣How to enable adoption and govern a design system
    • Mobile Engineering
      • 1️⃣Trunk based development
      • 2️⃣Agile development terminology
      • 3️⃣Git commit messages
      • 4️⃣Code review and pull requests
      • 5️⃣Readings
  • Delivery
    • Project Management
    • Collaboration
  • Hiring and Growth
    • Growth
      • 1️⃣Design growth framework
      • 2️⃣How to give ongoing feedback
      • 3️⃣How to check-in every quarter
      • 4️⃣How to address underperformance
      • 5️⃣FAQs
    • Hiring and careers
      • 1️⃣The Hiring Process
      • 2️⃣Diverse and Inclusive Hiring
  • PEOPLE EXPERIENCE
    • Benefits and Perks
      • 1️⃣Paid time off
      • 2️⃣Insurance and healthcare
      • 3️⃣Continuing education
      • 4️⃣Speaking at conferences
    • Starting at Obvious
      • 1️⃣Introducing Obvious
      • 2️⃣Set up your workspace
      • 3️⃣Onboarding
      • 4️⃣Finances
      • 5️⃣Code of Conduct
    • Employment policies
      • 1️⃣Equal opportunity employment
      • 2️⃣At-will employment
      • 3️⃣Employee records and privacy
      • 4️⃣Prevention of sexual harassment
      • 5️⃣Drugs and alcohol
      • 6️⃣Fraternisation
      • 7️⃣Non-compete and non-solicitation
      • 8️⃣Non-disclosure
Powered by GitBook
On this page
  • 👋 Introduction
  • 1️⃣ How to write a win
  • Sample of a Win
  • 2️⃣ How to write Feedback
  • Sample of Feedback
  1. Hiring and Growth
  2. Growth

How to give ongoing feedback

PreviousDesign growth frameworkNextHow to check-in every quarter

Last updated 1 year ago

👋 Introduction

Proactively record Feedback as and when relevant, because they feed into check-ins and main assessments. .

This way, we ensure that everyone is aware of their achievements and scope for improvement, and have all the evidence they require at their Check-ins.

We use the Wins feature on Progression to give and receive positive feedback and notes of appreciation.

From whom
When
About what
How

Wins from Mentor and peers

Spontaneously

Skill-based positive feedback

Choose Wins based on relevant skills and levels, as the goal is to help assessment become easier.

Feedback from Mentor

Spontaneously

Skill-based critique

Click on “Give Feedback” on the relevant colleague’s profile page, and tag it with the relevant skills.

1️⃣ How to write a win

A good win captures two parts - the challenge and the contribution:

  • Describe the challenge. Set the context and give as much detail as you can about the problem. Call out the potential downside of not having solved it.

  • Describe the contribution. Explain what you are appreciating about the person. Call out the relation to a skill area. Consider adding a line or two about the impact of the mentee’s effort on the overall project.

Sample of a Win

Challenge: During our field study, we saw that internet connectivity was poor in rural areas. We realised that we will have to find a solution that would enable phone number masking without relying on a strong internet connection, but none of us had a solution in mind. In fact, it seemed impossible to achieve.

Contribution: When I returned to work on Monday after the field study, I saw Saket tinkering with DTMF tones, which is a system of number signalling used on older phones. His DTMF solution could help nurses make masked calls to patients without an internet connection using a service like Twillio. If this works, it will be a big win for us. Great work, Saket!

2️⃣ How to write Feedback

Start with the SBI structure to gracefully provide the one receiving the feedback with concrete information that allows them to change their behaviour in the future.

  • Situation: define the where and when of the situation you’ll be referring to, along with any other contextual details that might help place the feedback in the right setting.

  • Behaviour: describe the specific behaviours that you want to deal with. When doing this, ensure that you observed them directly and you’re not making assumptions or judgements about why those behaviours happened.

  • Impact: describe how the other person’s action has affected you, others, or the project.

Suggest a Necessary Change i.e. well-explained ways to change this behaviour in the future to avoid similar situations.

👉 When giving feedback, it might be nicer to do the feedback conversation in-person before adding it to Progression. So it’s gentler, and reduces misinterpretation. Add it to Progression to merely document the conversation that’s already had.

Sample of Feedback

  • Situation:When we met on Friday, we had decided that you would make a presentation before the clients about the pros and cons of building a Design System in code. We agreed on having this happen on Wednesday and that you would reach out as early as possible if stuck anywhere. However on Wednesday morning, the presentation wasn’t complete because you said you had unresolved questions.

  • Behaviour:Your questions could’ve been resolved earlier on but they weren’t brought up to me in time. And so, I and a few others from the team had to drop a few high-priority tasks to get this deck past the finish line.

  • Impact: The presentation ended up being subpar because we rushed through it, and that left a poor impression on the client. As a result, we might not get a chance to develop the Design System, something that’s necessary for the long-term success of the project.

  • Necessary Change: The miss here isn’t that you couldn’t resolve questions on your own, but that you didn’t seek help as soon as you realised you were stuck. As we saw with the presentation, folks are ready to help if you ask for it. In the future, I would love to see you actively ask for help and push information to me without expecting me to pull it from you.

2️⃣
Praise in public and criticise in private