Marin Jankovski's README

Purpose

Inspired by the CEO page, this page is a readme for the Marin Jankovski.

Team(s)

Over the course of my tenure at GitLab, I’ve bootstrapped and onboarded a number of teams. Currently serving in the role of a Director of Platform Infrastructure.

I was a team lead and an engineering manager for Distribution team, Delivery team, and Scalability team

I was the first engineer working on tasks related to GitLab installation and as GitLab grew, so did the need to impact wider scope increase.

As I build a team, the first task I tackle is to ensure that my teams have a clear mission and vision. The handbook page for each team is the single source of truth for that team, and if the information is not discoverable on the team page, it can be considered as not important.

Time allocation

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.

To ensure that I can stay on top of my tasks, I use bullet journaling combined with my Remarkable2 tablet. I finish each day by writing the list of tasks that need to be completed the next day. I start each work day by cross checking my weekly and monthly plan with the daily list I created the day before to prioritise the order of tasks I am aiming to complete on that day. This ensures that I do the highest priority items on the short term, while aligning with the mid to long term set of tasks. This approach also allows me to question whether the long term plan is good for the current state of affairs.

1-1s

I hold weekly 1-1s with all my direct reports, and monthly 1-1s with all my indirect 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, or when the calls are far apart).

The structure consists of:

• Every meeting has the Google Doc accessible to the direct report and myself only
• The doc has a suggested topics template at the top that the report can use if they want to
• The doc is filled by the report 1 working day before the meeting
• The doc can be used as a place to write down all the thoughts, positive and negative
• In case of an item that requires attention prior to the scheduled call, the report can mention me or raise it up in direct message in Slack

My Availability

• My calendar is generally blocked during the early morning/evening. I usually do not accept meetings during this period
• I have a work only laptop which contains only one non-work related account: music streaming application. If I am responding during my off hours, that usually means that I am traveling or I have a pretty big behaviour regression
• I do not have Slack or work email setup on my phone so I will not respond to pings unless I am at my work laptop

Communication

• I have a very direct communication style, sometimes mistaken with being upset at people. If you encounter that, please ask whether that is the case.
• English is not my native language which can affect how I express myself. I tend to mix words like frustrated and upset and sometimes oversimplify sentences. I will also say I don't understand often when I am having trouble translating what is being said. Please ask for clarification if you encounter this.
• I have been at GitLab since the start and have a strong sense of ownership. Due to this, I sometimes tend to be overprotective if I think that something won’t benefit GitLab. If you explain how an item will help GitLab in general and not individual/team I will look into ways of helping if I agree.
• I do not like inefficiency and will look for any way to improve that. This is also the case in group conversations where bike-shedding is making me uncomfortable and I tend to speak up very directly regardless of the list of participants. If this makes you feel uncomfortable, please schedule a call with me and provide me feedback.
• I am not an optimist person by nature so I tend to see everything as glass half empty. There is always room for improvement and I always stress the improvement part. In recent times I’ve been learning on how to provide feedback that is positive in nature, and I’ve asked people to help me with that by asking for that type of feedback specifically. If I am not able to provide it on the spot, give me time to think as that takes an extra effort from my side.

Trust

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 tends to be 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.

View page source - Edit this page - please contribute.