It’s appraisal season again. I’ve experienced this moment from both sides, first as someone preparing for reviews, trying to decode expectations, and now as someone responsible for defining them for a team. Most of what I’ve built comes from lived friction. The uncertainty, the last-minute surprises, the feeling that performance was being judged on criteria that was never clearly stated.
When I joined Pocket FM, I wanted to build a system that removes as much of that Lack of clarity factor as possible. Not perfectly, but meaningfully. The core idea was simple: no one on the team should be guessing what is expected out of them. That meant shifting performance conversations from being event-based to being continuous.
I started with structured 1:1s. Initially they were monthly, later moving to a cadence of once every two months. The goal wasn’t just tracking work, it was creating space for reflection.
Two things happen when this is done well: First, people become more aware of their own contributions. They start connecting their work to outcomes, not just outputs. Second, feedback becomes less confrontational. It doesn’t eliminate difficult conversations; those will always exist, but it reduces the shock. Nothing in the final appraisal should feel completely new.
Alongside this cadence, I started formalising the systems around performance. Because clarity does not emerge from conversations alone. It needs structure. What I saw across many organisations was a lack of explicitness. Expectations existed, but they were often implicit, inconsistent, or dependent on the manager. So I built a set of frameworks to make things more visible, more discussable, and more actionable.
These include:
- Product design group levels: roles and expectations, Levels make growth tangible.
- Performance evaluation guidelines: evaluation guidelines define how performance is assessed.
- Core team principles: principles anchor how we behave as a team.
- Design critique guidelines: critique guidelines shape how work is discussed.
- Understanding team dynamics: it help us understand how individuals operate within a larger system.
Each of these solves a different layer of the same problem. Together, they create a shared language. Not just for managers, but for the entire team. This is important. Because performance should not feel like something that is “done to you”. It should feel like a system you can navigate, question, and use to grow.
I’m sharing these frameworks openly.
These are shaped by my experiences across teams and organisations, by leaders I’ve learned from, and by existing open frameworks that I’ve adapted to fit context. If you’re building a team, these might give you a good starting point. If you’re part of a team, they might help you ask for better systems. Either way, the goal is the same.
Make expectations visible.
Make feedback continuous.
Make growth intentional.
Full Github repository with all docs is available here.