As you get used to a new team, a new product, and maybe some new tools, it is useful to get your bearings from time to time. Check-ins are a way for Spiff to know what is important to you and for you to know what is important to Spiff. Check-ins are a one-on-one meeting between you and your manager that happen at least once per month. If you forget, your manager will remind you. If your manager forgets, you should remind them.
During a check-in all topics are fair game, but a few topics should always be addressed.
- How do you feel about the team, company, product and manager? Are you noticing any systemic problems or things that should be course-corrected?
- How does your manager feel about your performance on the team? Are you getting projects done? Are you helping others on the team?
There are a few general metrics that might be considered while assessing your performance such as numbers of PRs and github activity (including feedback on issues and other peoples' PRs). These metrics are like a smoke test. As long as the metrics are roughly in-line with the rest of your team, they probably won't get discussed much.
The more important metrics are the ones you bring to the discussion. Share the things you want to measure about your own performance (see Setting Your Course). Do you both agree that these are worthwhile? If you agree on the value of your goals, spend some time discussing what will be measured, how you will measure it and how you plan to impact those metrics.
Product and Engineering should always have a collaborative relationship. A check-in is a great time to ask yourself or the person you are checking in with what kind of collaboration they have had.
- Have you initiated any ideas that have made it into production code?
- Are you feeling like a "code monkey"? Transforming issues into PRs?
- Do you feel frustrated that you don't have time to make project improvements?
Some engineers will want to provide product feedback as part of reviewing issues or stories. You might suggest delivering the pieces of a project in a certain order, or removing parts of a story that will take a long time or that could be confusing to users. Engineers can also propose new stories and work with the product team to get them prioritized. These stories could involve re-structuring part of a feature to make it easier to extend in the future, or to provide tools for internal Spiff users to be able to manage features. However you like to collaborate with the Product team, you should keep a few things in mind:
- If you see a chance to make something significantly better, and it will take you less than a day, just go do it. You don't need to ask for permission to spend the time.
- If there is an improvement that you think would be valuable, but it will take more than a day, talk to some other people in your pod about it. See if that idea has been tried before, or if there are other ways of solving that particular problem. If you feel confident that a change would make things better, write up a story outlining your idea and meet with your product manager. Get that change prioritized.