Please note that this document is a draft. It has only been in progress for a few weeks, so there might be mistakes and areas that should / will be revised in the future.

This document is a “live” one, which means that it can and most likely will change in the future.

Author: Sergey Korsakov. Last update: January 18, 2023

You can also check My Readme page

Intro

If you read this document, it means that whether I report to you, you report to me, or we work in the same team.

How to work with this document

I created this cheatsheet in order to structure my thoughts about what falls into my scope and what doesn't.

The main goal is to ensure that I'm aware of everything I will be focusing on. Being able to push people back saying "this is no my responsibility" is not a goal. Hence, if we work together, feel free to let me know if you think there is something I missed :)

[IN PROGRESS] My Responsibilities / A "Blame" table

Thinking about my responsibilities as an engineering manager, I decided that it might be a good idea to use the "Blame” framework. The idea is to write down all things I can blame myself for in the future and devise actions I need to take to prevent myself from being in such situations.

Note that I use two different levels of responsibility: being responsible and being accountable. While both of these levels assume that I can/will be taking actions, "being accountable" means that I take personal accountability for the result, while being responsible means that someone else is accountable for this.

People:

I can blame myself for: A/R This is what I do to ensure this won't happen:
My reports do not grow professionally A * I create and manage development plans;
My teams don't see the value of the things they have in their roadmap R * I work close with PMs to ensure we have clearly defined long-term vision/roadmaps for all products we look after;
New employees leave the company in an unreasonably short time after joining A * I make sure have an established hiring processes, so that we hire highly motivated people who have relevant expertise;
I wasn't aware of the fact that some of the people from my teams are not happy to work in our company / department A * I organise quarterly team health checks and make sure we have action items as an output. I keep in touch with everyone who's owning these tasks to transform the output into outcome;
I can blame myself for: A/R This is what I do to ensure this won't happen:
Being not aware enough of technical details in order to represent a teem on meetings, identify risks and A * I review and contribute (when needed) to RFCs related to my domains;

Domain:

I can blame myself for: This is what I do to ensure this won't happen:
Being not aware enough of technical details in order to represent a teem on meetings, identify risks and
Some of the components

Development Plan

Find more hints in the "Empowered” book

  1. Define the types of expertise you want to use to evaluate your direct reports, i.e.: Designing Complex Solutions, Data Analysis Techniques, Stakeholder Management skills, etc.;