I am currently the primary engineering manager for two teams, Distribution and Delivery. The history behind why I am leading these two teams is a bit long and digs into GitLab and my career development path at GitLab so I'll skip detailing it for now.
The two teams have a clear mission and vision, and if you read them side by side you'll notice some similarities. Namely, Distribution team is focused on shipping GitLab 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 customer/user consumption.
Between enabling every team member of both teams 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 are related to hiring, working with the Distribution Product Manager on planning and scheduling features and working together with the team on optimising team processes.
Day to day technical decisions are made by each team member. My technical tasks are limited to providing advice, providing higher level guidance and help with making a decision.
Periodically I will help with Merge Request review in cases where change impact is large.
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.