I am the primary engineering manager for Delivery team.
Prior to this team, I was the Engineering Manager for Distribution team. I was the first engineer working on tasks related to GitLab installation and as GitLab grew, I ended up building up the Distribution team
My teams have a clear mission and vision, and if you read Distribution and Delivery's mission side by side you'll notice some similarities. Namely, Distribution team is focused on easing GitLab installation as a whole to our customers and users and Delivery team focuses on enabling engineering teams within GitLab to get their work ready for shipping and running on GitLab.com.
In other words, Delivery team primary focus is on tasks prior to releasing GitLab to public and Distribution on tasks for easing customer/user consumption of GitLab.
Between enabling every team member to do their jobs the best they can, engineering tasks and hiring, my work day is a stream of context switching.
The work week can however be roughly divided as:
I hold weekly 1-1s with all my direct reports. Most common call duration is 30 minutes but this vastly depends on the individual report. In all cases, I find it acceptable when the meetings are both shorter and longer but I dislike skipping these calls.
I've found that important information gets lost when 1-1s are skipped because the smallest, most insignificant looking "btw" often can save a lot of time and effort down the line. I don't often quote other people so I won't do that now too, but I'll just say that High Output Management - Andrew Grove is very often right in my opinion.
My 1-1s do have some structure, but only as a guideline in case people are not inspired (which can often be the case when you have the same type of call every week).
The structure consists of:
My tasks in the Distribution team in interim are related to hiring, working with the Distribution Interim Engineering Manager on helping them plan and schedule tasks. I will also hold on-demand 1-1s with my old reports to help them with navigating their careers at GitLab.
Day to day technical decisions are made by each team member. My technical tasks are limited to providing advice, providing higher level guidance and periodically help with making a decision.
Delivery team is inward facing so majority of my work is looking into engineering processes and driving a change that helps us deliver faster. Large chunk of this is working on direction blueprints that not only allows engineers to work more efficiently, but also changes in the way we deploy our code into GitLab.com environments.
upsetand sometimes oversimplify sentences. I will also say
I don't understandoften when I am having trouble translating what is being said. Please ask for clarification if you encounter this.
My default position is to trust everyone, be it work related or not. To some people I come off as too open and free as I expect people to say when they don't want to share some information or are not in agreement.
At work, I will trust that intentions are good by default. I will often provide feedback if I see something that I find is not beneficial to the company whether that is my job or not. I will provide direct feedback to individuals of all ranks if I observe this type of behaviour.
If I feel that I am repeating my feedback or that my feedback is being misused without raising this directly with me, I tend to react by withdrawing the trust completely. From then on, earning back my trust is a lot of work.
For this reason I ask people working with me to always provide me direct feedback in time, and to react to my feedback timely without holding back.