From the author of leading snowflakes.
Q & A
Q: do you insulate devs from business objectives so they can concentrate on their task or let them understand the big picture so that they buy in?
A: Juniors need to be execution machines. KPIs filter down to the technical lead and engineering leads.
Q: How would you approach evaluations in general?
A: Need to let go of the idea that evaluations are purely objective. You want them to fit culturally and grow. If they are accomplishing these goals they should be rewarded and if not are way off, they should be fired.
Notes from discussion with Oren
Learn from your peers:
- Make a list of ppl that do things well. Pick their brain on it.
- What are must have qualites and what are deal breakers?
- What makes your tick?
- I work best when___
- It annoys me when ___
- write down a charge’s 6 month performance today
- if you really have a solid foundation of trust, share it with them
Personal preferences are based on YOUR preferences – I had misinteerpreted what they represented in the book. But why should your charges adjust to you, rather than the other way around?
The book’s perspective seems to be for teams little bit larger team than what we have (currently 7) - so I’m interested in your thoughts on goals for small teams before WE REALLY DON’T NEED A REPORTING STRUCTURE when things are pretty messy still and people have to do a lot of things (like a startup), but we still want to give inexperienced developers some structure.
- baseline expectations - which we have done and they are soft (passion, 'getting it done', making the 'right' technical decision) - so they are subjective - Personal expectations - technical risks, technical growth
This is all pretty soft and that means that performance is pretty subjective which makes it pretty hard to align goals with our future direction or OKRs.
site speed? user acquisition? We aren’t close to that.
If you could pick one and only one metric to systematically increase over time, what metric would have the greatest and most sustainable impact on you and your team’s effectiveness? But these quantitative number really can’t be all of it…
Helping others, code review, their code is breaking seem like more appropriate and directly pertinent to a dev’s day to day performance.