Being back in the job market again, I’ve noticed that there’s a bit of a change happening in job descriptions for Engineering Managers. Most notably, many of them specify that the successful candidate should be doing some/all of:

• Coding
• Code reviews
• Driving sprints/being a scrum master
• Breaking down work into tickets for the team
• Architecting solutions
• And many more tech-focused functions

Ваша работа как программиста — не писать код, а решать проблемы. Лучший способ решить проблему — писать как можно меньше кода.

Управлять производительностью (людей) так же безнадежно, как и приказывать растениям расти.
Вы можете посеять семена и удобрить почву, но вы не сможете заставить цветок вырасти, дергая его. И вы же не выкапываете его раз в месяц, чтобы проверить, как он растёт.

1. Measure the time engineers are spending. This doesn’t need to be super-precise, nor does it necessarily have to be wall-clock time (you can use story points, or ticket counts, or probably a dozen other things).

2. Split that time into “buckets” that map to the kinds of activities that influence output. I start with three buckets: features (time spent developing new things), debt (time spent fixing old problems), and toil (time spent on routine tasks).

3. Agree on the appropriate ratios for each bucket, and then adjust over time to influence the outputs you care about.

Smart people don’t learn… because they have too much invested in proving what they know and avoiding being seen as not knowing