alexander-sosna

README.md



Where I come from

I'm Alexander Sosna - Alex for short - and I love to know how "thinks" work, so I can alter improve them.
On my quest to understand computers, electronics and technology in general, I discovered Open Source Software sometime in the late 1990s, and for the first time I truly felt that I was not only standing on the shoulders of giants, but could also look over them to understand and build upon their creations.
Motivation, or why this README exists

I want it to be easy, enjoyable and productive for everyone to 🤝 collaborate ⏱️ efficiently with me to achieve great 📈 results for our customers.
This document is a small 👣 Iteration in the process.
It helps me to reflect on myself, as well as giving inside about me to others.
I'm as honest and 👁️ transparent
as I can.
Everything at GitLab should be public by default, and I start with myself.
This is my way to show that I assume good intentions and to build trust.
I want to foster an environment where everyone can thrive and feel a strong sense of 🌐 Diversity, Inclusion & Belonging.
I hope YOU feel safe to approach me with whatever question, idea or thought that you think I could help you with!
Why I work at GitLab

I love that when I or my team solve problems we are not just solving them for ourselves, but for everyone else who is willing to learn from us.
That is the power of Open Source and I hope that our work inspires others to do the same, so more people can watch over the shoulder of giants and advance the digital world we live in.
Therefore, 👁️ Transparency is my favorite among GitLab's values.
This is also why one of the things I enjoy is to think about the work I have done in the resent past, asses what subset of it is valuable for others and then talk about it at suitable conferences.
With that being said I could work for many Open Source / Open Core companies, but GitLab is special.
Our lived values and handbook fist approach, make all the difference.
I feel a strong sense of ownership of our critical database infrastructure and enjoy working with an incredible team, from the place I want to be and the way it works best for me.
How I like to work

I have a strong bias for action.
But 'action' does not (always) mean rushing headlong into any direction.
When approaching a challenge it can be fun to just start coding / solving right away, because it promises the fastest results and ensures a quick dopamine rush.
I had the pleasure to maintain code, infrastructure, documentation and processes I build for prolonged periods of time.
My lesson learned is that starting by understanding the problem and circumstances, assessing the requirements and defining the expected results is worth the effort.
Especially when an 'obvious' solution is presented with the problem, it still makes sense to investigate if there might be a simpler, more idiomatic and more boring solution.
How much time I invest to understand the task and circumstances ahead depends on the involved risk.
When I brew a batch of beer and the worst case scenario is to lose 25 EUR worth of ingredients and 8h of my time, my affinity to just try it out is different from changing a component in our database infrastructure.
Communication style

I'm quite very direct, and sometimes can't keep my opinion to myself.
Also, I'm bad at hiding my feelings, including disappointment and frustration.
From many long-term colleagues I got the feedback that they like my directness and openness, for it removes otherwise necessary guesswork.
But, I also noticed that some people may see me as unpolite, especially if they had the majority of their work experience outside of Europe.
I have the feeling that I improved significantly here since I joined GitLab, but should you have the feeling that I'm impolite or do not value your input enough, please point it out to give me a chance to iterate and improve. 🙇
I personally appreciate directness!
Feel free to talk to me freely, no sugar-coating necessary, actually the opposite is appreciated.
If you bury important data, like negative feedback too deeply or hide it in subordinate clauses, there is a reasonable chance that I will not recognize it fully and will not be able to act on it.
It is unfortunate to run in the wrong direction.
But it is unnecessary and avoidable to continue to do so, if your peers already noticed, just because they do not feel comfortable to speak up.
Therefor always feel encouraged to deliver constructive feedback. This is paramount to build trust, strong relationships and high performing teams.
Focus and distraction

I can focus on 'interesting' problems for prolonged periods of time.
But sometimes I get too easily distracted, examples:


YOU DM me on Slack, I start writing a comprehensive answer, get distracted by incident.io and never write back to you.

YOU you explain a complex situation too me, halfway through, my brain fills in the blanks, and I just start talking.

YOU talk to me about topic x, mid-conversation I get a random thought and switch to topic y mid-sentence.

When you notice something similar, assume good intent, please point it out and be aware that I did not want to show any lack of interest in you or the topic on your mind. 🙇
Problem-solving

I like solving problem!
If YOU explain a problem to me, I assume that you want my help to solve it.
And chances are high that I want to do so and start to offer potential solutions.
It is totally fine to just vent to me.
Maybe explaining your problem to me gives you a better understanding about it yourself.
If YOU don't want my input, or you don't want it immediately, please openly say so.
If not I assume you are interested in my two cents.
Should you describe a problematic situation to me that involves people, I might assume that there is the possibility that you:

did not fully understand the other persons intentions / assumptions / world view
made wrong assumptions about x

said the right thing, but the other person did understand y instead

In order to help you I might play the role of the devil's advocate, taking the opposing position, without necessarily agreeing with it.
This one of my method for finding an explanation of the other person's behavior, while assuming good intentions, giving you potentially viable input to better understand and then solve the situation.
If that is not what you want, please openly say so.
Affinity for risk

In general, I'm a positive optimist.
If you don't try and allow for the possibility of failure you will not be able to achieve much.
However, in certain roles you have to ensure scalability and high availability of critical infrastructure.

Risk = { Likelihood \times Impact}


Risk is the likelihood of a failure multiplied with it's cost.
So even if the likelihood of a failure is quite small, as long as the potential impact is catastrophic, it makes sense to minimize it even further.
For GitLab.com we currently use one monolithic database infrastructure, so all customers are effected at once.
It's hard to estimate the actual failure impact and most of the time I check against only two scenarios.

Availability: ALL SaaS customers experience x hours of downtime

Data Corruption: We need to restore a backup and ALL SaaS customers loose y days of work


So should I appear too pessimistic it might be that my intention is to ensure we can continue to deliver great 📈 results for our customers, by protecting the SaaS's availability.
But sometimes I'm too cautious and apply unreasonable high values for Impact, if you spot or suspect this, please speak up and let us asses the risk together.
Contact me

Feel free to reach out in Slack or just schedule a Coffee Chat in my calendar, I will move or decline if it is not possible for me!
You can also reach out via my personal accounts if you prefer.

Personal website: sosna.de

Signal: phone number in Slack profile
LinkedIn: alexander-sosna


Emergencies

Given our established on-call schedule, there is unlikely to be a need for additional emergency communication channels.
Should you still need to reach me, my personal phone number is in my Slack profile.
If GitLab.com is down and there’s anything I can do to help, please don’t hesitate to call me anytime.