Michael 'dnsmichi' Friedrich README (Staff Developer Advocate)

Learn more about working with Michael ‘dnsmichi’ Friedrich, Staff Developer Advocate, GitLab

This page is intended to help everyone to understand how I work, how to find me, my strengths and weaknesses, and my expertise and background. I’m intentionally vulnerable and open to feedback.

Please feel free to contribute to this page by opening a merge request.

About me

Grown up in Linz, Austria, I wanted to understand how a computer works in school. A 486 PC turbo-boost button that was not enabled by default inspired me to study Hardware/Software Systems Engineering, leading to circuit design, hardware and software programming languages, and more adventures with NFC and multimedia streaming in 2005. A student’s dorm network project in Vienna, Austria, allowed me to dive into spanning trees (and loops!) and routing, which I expanded on with DNS and monitoring at the University of Vienna, Computer Center. Maintaining an open-source monitoring project for 11 years required me to understand how the software is used in production. CVEs raised awareness about security scanning. I therefore engaged with global events and community meetups to learn and understand the roles in modern DevSecOps and cloud-native workflows. My passion for open-source communities also inspired me to move to Nuremberg, Germany, in 2012, where I live today in the countryside. In March 2020, I started my all-remote adventure at GitLab.

Outside of work, you’ll find me building LEGO models, combining embedded hardware with home automation, exploring nature, and travelling. You can learn more on my personal website: https://dnsmichi.at/about/

Biography and headshots

I have a detailed biography and CV available in different text lengths and languages, as well as professional headshot photos. You can find these resources in this public document.

My work values

I follow GitLab’s values and specifically embrace these:

I always assume positive intent. and encourage others to do the same.
I love transparency, and keeping everyone SAFE. I work in public by default, with a low level of shame. You can expect me to document my work, share updates, and engage in important discussions to help achieve company goals.
We are managers of one. I will go with a bias for action and not ask for permission to propose an idea, MR, action. If you want me to prioritize a request, please ask me directly by tagging me in an issue. You do not need to ask my manager to ask me.
Say why, not just what. Understanding the why helps me validate decisions, and make better proposals. Merge Requests without a description explaining the why can lead to questions in Slack, or otherwise back-and-forth communication. Time that could be used more efficiently.
Handbook first. Everything needs to be documented in the handbook so that everyone can learn async. If something is wrong or not documented in the handbook, it is a bug, and we need to create an issue or a merge request to fix it.
I love project management. GitLab issues, epics, labels, due dates, and overall tracking. This provides transparency and results reporting, and enables efficient collaboration. Often, I identify feature proposals through dogfooding.
I believe in “Everyone can contribute”. Technical problems/blockers/barriers, product features, handbook updates, etc. need to be broken down, and explained on everyone’s knowledge level. If you see me “testing” your knowledge in a conversation, be honest and frank and let me know if the explanation attempt is too low level, or instead needs a more in-depth deep-dive. I’m always happy to help and make it a learning coffee chat.
There is only one Single Source of Truth, and it is discoverable by all team members, async.
Slack is not a knowledge base (and messages will expire after 90 days). Every Slack thread should be summarized and broken down into actionnable issues.
I follow disagree, commit, advocate and trust that decisions can be changed.
I often step on everyone’s toes. My role requires cross-functional knowledge. Learning and discussing outside my comfort zone and expertise keeps me challenged, and requires a safe environment where short toes are the default.
I love honest and actionnable feedback. Do not feel intimidated to share feedback – use a private message, or schedule a coffee chat to help me grow.
No agenda, no attenda. If a calendar invite does not attach a Google document, or has an empty agenda, I will not attend in sync.
Inclusive communication: We are an all-remote global company. I will remind everyone to use ISO dates and time zones, and provide clear due dates.
Manual work is a bug. If you see me using quick actions, terminal commands, or writing scripts for the GitLab API, it often is because the manual work will continously consume too much time, making me less efficient. I also love challenges – Do not hesitate to ask to learn more. We can do “pair programming” coffee chats together.
Family and friends first, work second. While I am passionate about my work, I enjoy the freedom of flexible work hours and PTO, and working remotely, allowing me to put family and friends first.
Trust needs to be earned. I will work hard to earn yours.

I bring my authentic-self to work every day – can you spot all easter eggs in my remote workspace?

Strengths and weaknesses

Strengths

I’m a fast learner. I’m always eager to expand my knowledge and skills, whether it’s learning a new programming language, framework, or technology. I enjoy tackling challenges and finding creative solutions.
I’m adaptable. I’m comfortable working in various environments and can quickly adjust to changing priorities or requirements. I’m able to pivot and find new ways to contribute when needed.
I document everything. Depending on the scope, a handbook merge request or GitLab issue is never far away. You can help me with your bias for action, and also assign handbook merge requests for review.
I love connecting everyone. I’m not shy to engage in important discussions to help achieve company goals or contribute to cross-functional work, often in key Slack channels, epics, working groups, cross-functional initiatives, or monthly field syncs.
I’m a team player and prioritize helping others achieve their results. I take the time to unblock processes and results (content reviews, feature and setup debugging, etc.) or contribute ideas to iterate faster.
I have a broad knowledge base. My career has touched on many different technical topics and open-source collaboration. I’m here to share my knowledge and help you advance your knowledge, goals and career.

Weaknesses

I’m passionate about my work, and sometimes push my opinion. When I think that my solution has the most impact for the business, I push for it, even though I am not the DRI (Directly Responsible Individual). I can also be direct, which can come across as overbearing at times. I am working on being more mindful of this and balancing my passion with consideration for others’ perspectives.
I say yes too often. I’m constantly challenged with many requests and my own ideas, and I sometimes overload myself with tasks and need to reprioritize. The printed Eisenhower Matrix on my desk helps me do, schedule, delegate, or delete tasks. I might forget about requests that are not tracked in an issue with a due date and a to-do assignment (Google Docs, Slack, Email). Please be proactive and create Developer Advocacy requests and assign them to me.
My native language is German, not English, sometimes leading to misunderstandings. I have a vocabulary weakness for day-to-day items (e.g., kitchen and food). I’m learning through coffee chats, social conversations, and using Grammarly to improve my English. For example, when I share a tip to make you more efficient, it does not mean that you are not efficient. Instead, I am always looking for ways to help others benefit from my discovered efficiency tips, and need to word it differently.
I’m not good at email communication. If I should follow up on an external email conversation, you might have to remind me to do so, or create a tracking issue.
I occasionally fall into old habits and aim for perfection and completeness. Minimal valuable changes, boring solutions, and iteration are challenging sometimes. If you see me writing a long tutorial blog post or a capture-everything issue, please jump in and remind me to break down the tasks.

Working with me

I prefer asynchronous written communication over synchronous calls.
- GitLab issues, merge requests, and forum topics are preferred over Slack or Discord.
- I love low-context communication, providing all necessary context so that everyone can continue when I’m offline or focused on other tasks.
- Avoid live screen sharing presentations in meetings. Instead, record a walkthrough video, upload it to GitLab Unfiltered on YouTube, and share the resources in advance for the synchronous meeting.
Ask questions in public Slack channels, so that everyone can contribute.
- This helps loop in more team members, subject matter experts, and those responsible for specific areas (DRIs).
- Please avoid direct messages (DMs) unless it’s private feedback or confidential information. I’ll respond to DMs with lower priority than public requests.
I enjoy helping in public, and sometimes work evening hours to assist with incidents or timezone aligned tasks (after 10 AM PT, which is 7 PM CET).
- If I need to leave during a planned task, I will communicate the sign-off time and provide a handover summary.
My calendar invites are editable by guests.
- Feel free to adjust the time to fit everyone’s schedule.
- No worries about short-notice reschedules. I always have a task or project to work on, or appreciate the short break.
- My default Zoom URL has a waiting room set up for external guests. If I don’t show up in Zoom on time and let you in, ping me on Slack.
If you think a repeating coffee chat or a topic-specific 1:1 would be beneficial for efficient collaboration, propose a new calendar event and include an agenda document.
My work hours cover mostly AMER and EMEA time zones.
- Meetings can be scheduled in my afternoon (5 AM to 10 AM PT, 2 PM CET to 7 PM CET). My mornings are reserved for focused work or personal time (shopping, extended lunch with friends).
- Ask when scheduling during my focus time blocks (customer calls, EMEA syncs, etc.).
Team members can always schedule a coffee chat with me. I’d love to learn about you, your background, life stories, experiences, and interests.
- Wider community members can ask for my Calendly link.

Finding me

I go by dnsmichi everywhere: Slack, GitLab.com profile, GitLab forum, social media, and my personal website. However, for email and calendar, you need to find my full name Michael Friedrich or the short form mfriedrich. I love coffee chats, so please schedule one without asking for permission. :-)

I enjoy connecting with team members on LinkedIn, and amplifying your voice into my network (hiring, product/engineering insights, marketing, etc.). Tips for social media messaging are documented in the Developer Advocacy on Social Media handbook. I’m active on social media, but I have push notifications disabled on my mobile devices. I’m not good at responding to many private messages or connection requests, so using a different channel is more efficient. I uninstall social media apps during vacations to relax and maintain my mental health.

My private contact details are available internally to team members. Please do not share them with anyone, as I don’t want to receive spam calls or phishing attempts. If a web form asks for a phone number, use the company phone number instead. You can connect with me through WhatsApp, Telegram, or Signal, which is more reliable for location sharing, dinner coordination, and private pictures.

I do not have Slack installed on my mobile unless I am traveling for events. If an incident becomes urgent, text me on my private mobile.

Experience and engagements

In my career, I studied hardware/software engineering, debugged networks, hardware packet filters and DNS, and learned how services behave differently on Linux, Unix and Windows. I enjoy debugging and troubleshooting in production - therefore I run cloud VMs, containers, Kubernetes, Raspberry Pi, Arduino boards to keep me in practice, learning and building in public. Depending on the audience, I create GitLab blog posts or write about it on my personal blog.

I love creating tutorials, workshops, and trainings about GitLab use cases and new technologies - the 5-minute success moment is key for me. At my previous company, I authored their GitLab and Git training from scratch, and continued building workshops in my role as Developer Advocate at GitLab.

I usually try to understand the big picture and always want to look behind the curtain. I am interested in many cloud-native and DevSecOps technologies, but often reduce my scope after understanding the basics, blockers, and challenges. For example, I was fascinated by Chaos Engineering and WebAssembly in FY23 but found it hard to build a business case for it, after creating talks and workshops, for example at KubeCon EU 2022. I also invested in learning eBPF in FY24 and created workshops for GitLab Summit 2024 to share the knowledge with team members, but did not identify an immediate business impact for the Observability group, and paused the efforts.

GitLab Duo and AI required me to learn everything from scratch again. Finding a strategy to learn and scheduling coffee chats with product and engineering team members allowed me to expand my expertise. This also led to the GitLab Duo Coffee Chat on YouTube, a boring solution to help customers with real-world scenarios. Researching GitLab Duo with embedded use cases and GitLab Duo prompts and challenges took priority in FY25, and excite me every day in close collaboration with customers.

I thrive in areas where I am not an expert, and someone has asked for help, providing a real use case. For example, GitLab Duo adoption in a customer environment requires me to learn Java Spring Boot. My knowledge about GitLab features continuously sources from helping users on the GitLab Community Forum. I also help maintain the GitLab handbook backend and engage in CI/CD components initiatives.

My role as Developer Advocate enables me to take different hats: provide product feedback from different user personas’ views, evaluate marketing messaging, or generally brainstorm about product feature ideas and architecture. Feel free to loop me into UX workflows, architecture proposals, product roadmaps, or website design for different target personas. Recent examples of my cross-functional engagements are the SaaS Free User Efficiency initiative, the CI Use Case Adoption WG, and Developer Relations initiatives to drive company goals with GitLab Duo Adoption and CI/CD, Security Adoption.

I’m a leader within GitLab, and I’m happy to share my knowledge, expertise, and connections with everyone. I’m active in the Global Voices TMRG, and I’m an ally, for example, by supporting underrepresented groups in my mentoring and coaching activities.

Resources

All-remote experience

Thanks for reading

I hope you’ve learned a lot about me in this README. If you want to know more, or peek into my remote workspace background, schedule a coffee chat.

Last modified August 19, 2024: Personal README: MVC update, move bio doc to top (ade2ef3f)

View page source - Edit this page - please contribute.