Back to Homepage

Vulnerable

Great software engineers are vulnerable, creating psychologically safe places for failure, honesty, and learning. Psychological safety is the idea that a teammate doesn't fear harm to their identity, their job, or their career if they were to share their genuine thoughts about the team and it's work. This safety empowers teammates to provide genuine (perhaps critical) feedback that can help move a project forward.

What does this mean in practice and what does safety have to do with vulnerability? Imagine you've spent the least week working hard on an implementation of a set of requirements. You show it to your team. If you're intentionally vulnerable, you'll make it clear to your teammates that any critique they provide of your work will not harm you as an individual. If you're intentionally vulnerable, you might proactively disclose how you feel about your work, showing them that you want and need their further critique and help. Vulnerability is a way of showing that there's room for honesty. This is particularly important if you're in a leadership position on your team.

Now, imagine you're not intentionally vulnerable, but you're defensive. Will anyone feel safe sharing negative feedback on your work? Probably not. Will you ask for criticism? Probably not. Will ask for help if you're stuck on something? Probably not. This lack of space for sharing will prevent you from learning and from your software improving.

Practicing vulnerability

You've just started your sprint. You've probably encountered some difficulties or have some work to show your teammates. Now is your chance to practice being vulnerable, opening up to your teammates about your progress.

For each teammate:

• Express one thing you need help with, however small or big.
• Express one thing you want feedback on.
• Express one thing you fear about the project.

Review your process document

Your team previously define a custom process for Homework 5. Review that process now. Have you been following the process you previously defined? Does following this process still make sense? Why or why not?

Synthesize a plan

You've probably learned a few things about the status of your project by being vulnerable and reviewing your process document. What are you going to do about them, to ensure the success of your release?

Share with the class

To learn from other teams, each team will share with the class their findings:

• What new information did your team learn?
• What is your new/updated plan?
• How did you make this plan?