Once upon a time, I had lunch with a very, very smart person. My director at the time kindly asked her to bear with me and my questions for a couple of hours, and she graciously agreed in spite of being an extremely busy person.
That was one of the most growth intense meals I ever had. I took home a few life changing lessons from that event. Here’s one I keep getting back to.
You can always summarize a job role into two bullet points.
That’s it. There will be more nuance and complexity, but when uncertainty strikes, you can always refer back to those two points.
Here are some examples:
- Software Engineer:
- Deliver value to customers
- Don’t let the system degrade
- Program Manager:
- Make sure nobody is ever surprised
- Have the whole technical picture together
- Engineering Manager:
- Deliver value to customers through the team’s work
- Take care of your team and each person in it
- Product Manager:
- Build what customers actually need
- Make sure engineering can build it and maintain it efficiently
Note that the points are ordered by importance. If you have to make a choice between the two, typically the first point carries more weight.
For example, value delivery generally wins over operational stability, in most software engineering scenarios, at least temporarily: it’s usually ok to deliver a valuable feature and work out operational support as a fast follow up (with some common sense boundaries, of course).
Similarly, sometimes a manager will need to ask people to stay late so that the team can meet some critical deadline or solve an urgent issue, even though that’s temporarily less caring to the people in the team. The manager should then absolutely make that balance right again short after the team achievement.
Common Mistakes
I’ve seen people struggle with this exercise, and there are a few patterns:
Too vague: “Be a good team player” or “Do quality work” doesn’t help when you’re making hard choices. Your two points need to be specific enough to guide decisions.
Too tactical: “Attend all meetings” or “Respond to emails within 24 hours” are tasks, not priorities. Your two points should be about outcomes, not activities.
Too balanced: Sometimes people try to make their two points equal in importance. That defeats the purpose. One needs to win when they conflict. If you can’t choose, you should think harder about what really matters.
Too many: “But my role is complex! I need at least five points!” Yeah, yeah I know. You’re special. Spoilers: you’re not. I know it’s hard to distill it down to the two essential points, but that’s kind of the whole point.
Using This With Your Team
This framework is powerful when you use it with the people you manage.
In your next 1:1, ask your team member: “What do you think are the two most important things about your role?” Then share what you think their two points are.
The gap between their answer and yours is a way to see what’s the misalignment. If they think their job is primarily about writing clean code, but you think it’s primarily about delivering customer value, that explains something.
It also helps with delegation. When you hand off a project, they can use those points to make decisions. Now they have a framework, albeit basic, not just a task list.
Your Turn
What’s your job? Can you distill it down to two points?
Try this: write down your official job title, then list the two most important things you do. Not the full job description - just the two things that, if you nail them consistently, mean you’re succeeding.
If you’re struggling, ask yourself: “When I’m uncertain about a decision, what two principles should guide me?” That’s usually where your two points live.
Once you have them, keep them visible. Write them down. When you’re overwhelmed or unclear about priorities, come back to these two points. They’re your north star.