High-documentation, low-meeting work culture

Designers to design, draughtspeople to draught, archivists to archive.

Engineering entails a lot of secretarial work that has been "streamlined" by expecting engineers to do it themselves rather than employing professional secretaries to do so. The end result is that it is often left un-done.

The "enforcers" you talk about are basically secretaries, no? Trained individuals with enough understanding of the work at hand to record and file it in a context-aware manner.

Reminds me of the "surgical team" model from The Mythical Man Month [1] wherein there is a suite of people provided to every engineer to minimise their work outside of design and implementation. (At least that's how I remember it, it's a few years since I read it)

[1]: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

GitLab team member here.

Sharing a personal insight - I'm currently moving flats in the Nuremberg area in Germany which is a little hectic because forced out by the new house flat owner. Async work enables me to take calls and go shopping to organize the move, whilst shifting work hours into the evening or early morning. I am also able to take paid time off (PTO) when needed to prepare the move early December. In my previous office job, I would have needed to reserve a lot of vacation days for this, and ask for permission to start later than 10am, or leave earlier than 4pm. Here at GitLab, I am my own manager [0] and take care about my working hours - it is a personal freedom, and I appreciate these less stressful times a lot. In return, I can take time to focus on private life, and come back refreshed to produce great results (blog posts, talks, helpful replies here and other community channels, etc.).

What I learned in the past 2 years and 9 months at GitLab, is to provide as much context as needed so that someone else in a different timezone can continue async, and is not blocked by anything (low context communication [1]). Also, short toes [2] enable everyone to add their thoughts and opinions, and work with the directly individual responsible (DRI) for the best outcome.

The Slack retention period of 90 days is a great reminder (and also enforcement) to document everything in the handbook. Example from today: I learned that Google docs supports the colon for emoji live-search. Thought of sharing in Slack, but then went with editing the handbook and sending a MR [3] to help everyone find this little efficiency tip in the future - that said, Slack is not a knowledge base. The GitLab handbook is.

Thinking about the past year with a public discussion about speaker diversity at events, I admire our teams to take action to ensure events align with our diversity, inclusion and belonging values. We have updated our event requirements for speakers (MR [4], handbook page [5]), and are working with event organizers and the wider community to help with mentoring and coaching to inspire future speakers.

Last but not least, transparency [6]. Internal and external, I can read and learn async at my own pace. Most of my meetings are optional, and the meeting notes/recording are detailed, with follow-up actions. You'll never recap old meeting notes the next time but reference actioned issues and merge requests. Many issues/epics are public - if you'd like to learn more about my thought leadership strategy for Observability, and all content created and planned, you can follow this epic [7] or my profile activity [8] for example.

I haven't met everyone in-person yet, because of the pandemic, and travel only for some events (KubeCon EU/NA, PromCon EU [9] [10]), but I am looking forward to meet and value these moments. Hard to describe, I feel incredibly connected to my teams albeit living far far away. :-)

Happy to share more thoughts and insights - my role is on the community relations/developer evangelism team, I'm the stable counterpart for the product teams, and collaborate in cross-functional initiatives often. [11] My first [12] and second [13] year blog posts share more experiences too :-)

[0] https://about.gitlab.com/handbook/leadership/#managers-of-on...

[1] https://about.gitlab.com/handbook/communication/#effective-c...

[2] https://about.gitlab.com/handbook/values/#short-toes

[3] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

[4] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

[5] https://about.gitlab.com/handbook/marketing/corporate-market...

[6] https://about.gitlab.com/handbook/values/#transparency

[7] https://gitlab.com/groups/gitlab-com/marketing/-/epics/2593

[8] https://gitlab.com/dnsmichi

[9] https://dnsmichi.at/2022/06/13/my-kubecon-eu-experience-firs...

[10] https://opsindev.news/archive/2022-11-23/#promcon-eu

[11] https://about.gitlab.com/handbook/marketing/community-relati...

[12] https://dnsmichi.at/2021/03/02/my-1st-year-all-remote-at-git...

[13] https://dnsmichi.at/2022/03/02/2-years-all-remote-and-2022-v...

Yes, this is literally the case from grade school all the way into college level technical writing courses. The first paragraph, or first section depending on the length of the work, should essentially be a high level summary of the entire work. I remember in middle school we were also taught to write our paragraphs this way, that is, the first sentence should be a gestalt of the entire paragraph. The conclusion of each paragraph, and also the conclusory paragraph itself, is also supposed to have this behavior to some extent.

It took me quite a few years to realize how dry, boring, and repetitive this makes your writing, and I now choose to write as I talk. Might make for worse documentation, but it's far better for conversing with other people either in real time or in back-and-forths via email.

Say what you're going to say (briefly)

Say it (at length)

Say what you've said (briefly)

Is how you successfully present things in the US