We reinvented our working culture…
…by refurbishing the way we communicate!
I’m someone who’s always looking forward, and if something does not work as it should anymore, I don’t hesitate to change or discuss it with my team. Over the last year, my team and I recognized that we are creepingly running into troubles with the communication channels customers and colleagues can use to contact my team and me for working tasks. And, three weeks ago we started to turn the wheel around, immediately!
The starting situation
As written in my story about communication and IT, today there are many ways to communicate. At work, we use the following tools and channels regularly. They range from classic to new ones.
- Landline (telephone)
- Microsoft Teams (chat, groups, online meetings)
- Calendars (mostly to schedule meetings)
- Ticket system (for ITIL)
- Issue system (GitLab internally)
The problem is not the number of channels, but the quality and quantity of information which is transmitted over these channels. Every channel has benefits and drawbacks in communication. None of them is bad or worse and none of them is the sole hero. After much reading and discussion, I think that three important categories have emerged into which the different communication channels could fit, at least for me.
- Quality of information
- Type of interruption
- Asynchronous or synchronous work (adopted from GitLab)
These three categories are connected to each other and to visualize it better, I made a diagram of it. The colour code means that green would be the best way to communicate in combination with the work-load handling, at least for me.
Red communication: Low-quality information means, that the probability is high that there is no contextual or factual information in what you receive. For example, a chat that starts which just “Hello!” (and nothing more) has an information density of zero! It does not transport any information but, it interrupts you the hard way if it comes as a chat that pops up surprisingly, therefore we flag this type of communication red. There’s a website about this “no hello” problem which explains the topic very well! Furthermore, every information which is stored inside a chat is not visible to other team members, until you take care of and pull the information out of the chat, into another system.
…every information which is stored inside a chat is not visible to other team members, until you take care of and pull the information out of the chat, into another system.
Green communication: High-quality information means, that the probability is high that you will receive data that contains context, factual information, or at least a question or statement. Well, most of the time this is the case if you get an email or if someone raises a ticket or an issue. Furthermore, this does not interrupt you the hard way, you can check your inbox every hour or so — we flag this type of communication green.
Now you might say, that the quality of tickets or issues is often low. You’re correct, that's obviously true! So wheres the difference? Well, besides the quality of information and the interrupt type, there’s also the asynchronous and synchronous category of work. The asynchronous work category means that information is written down, without exception and therefore it can be processed later. This is inherent in the system because you must write an email and you must write a ticket/issue. Even if the information density is low, there are still benefits: you still now when, how and by whom an issue was written. 😏
Yellow communication: Of course, a meeting means synchronous work, so why is it in the asynchronous work lane too? If a meeting is well prepared, has an agenda, has a Live Doc and is scheduled as soon as possible, everyone who is meant to attend the meeting can prepare for the meeting before the meeting starts. But often, these aspects are missing. And then, meetings can be really time-consuming and pointless, especially if no one writes anything down. Therefore, please, if you schedule a meeting, take care to submit as much information before the meeting as possible! This type of communication is flagged yellow for these reasons.
Blue communication: So, what about the blue communication channel? If you call someone on the phone, the one you called will be interrupted the hard way. Think about if it’s really needed to call someone before you do it. If you like to ask something that is only needed in a couple of days, write an email! If you need something to be done for you, open an issue! The benefit of a telephone call is, that you can ask back if needed. The drawback is, that no one in your team knows about what you have bespoken with the caller if it is not written down.
Sure, these communication categories are often blurry and are interacting which each other, but in the end, you have to handle it.
The challenge
As written above, we are using different communication channels — no problem — but we take care of how we are using these channels and which information we are transmitting over which channel. Inside the team, we are mostly using MS-Teams for our internal communication especially if we are working from our home offices. But our problem was, that we have to handle the communication form outside of our team. This communication can happen in every way, there’s no rule for it. We were really struggling to get the communication into a proper and coordinated way, and one of the problems was a technical one.
We are heavily using GitLab for our daily work. We’re trying to automate as much as we can, wherever it’s appropriate. And yes, we are using GitLab also for our issue management. We’ve adopted a lot of workflows from GitLab and other sources. Of course, we are using a Kanban board too and, this year alone, we closed more than 1000 issues until the end of November 2020. With only four colleagues including myself!
But, we had some handicaps to handle with GitLab and therefore, we built some tooling around to be able to canalize the communication anyway. One problem is, that if you use GitLab Community Edition(CE), you can have as many users as you like. But this is not true if you use one of the on-premises enterprise licensing model as we do. There is currently no way to split up licenses, for example, you cannot buy 200 premium licenses and 100 starter licenses. 🙄 That’s bad. The same is true for guest users. Guest users are only possible if you are buying ultimate GitLab licenses. But, the price difference between a premium and an ultimate is 80 Euros per user per month! But hey, GitLab offers a really good API and therefore nothing gonna stop us here, just write some tooling.😋 If you would like to change this, please upvote the official GitLab issue about this topic here.
The problem solution
As written before, we would like to adopt the GitLab way of asynchronous work wherever possible. And therefore we created a self-made platform to solve the licensing problem stated above. The tool was written by my colleague Stefan and everyone in my team brought in some tips and wishes. To be honest, some of the ideas which we implemented were directly derived from GitLab and Hugo, for example, the management of static content. But let go step by step. 😊
Step 1: Issue templates for everyone who’s authenticated
The first and foremost goal we had was, to enable everyone who is authenticatable to be able to commit an issue into our GitLab Kanban project. We’ve several thousand users in our enterprise and as you now know, GitLab does not offer a guest based model für premium customers. Therefore we decided to write a custom frontend for GitLab, to make use of the GitLab issue template system for every user! 😍 At first, we’ve used the API to access the GitLab issue templates, but then we switched to a Git-based clone/pull method because this enables us to implement a more Kubernetes like (sidecar) approach. Stefan used Markdown renderer to render the GitLab templates into an output which the user is able to handle. And well, here's how it looks like!
If the user clicks the edit link, the Markdown view opens (in place) and the user can edit the issue request. Simple and useful.
Step 2: Integrate the handbooks
If you are working with customers who are in the need to issue requests to get their stuff done, it is very useful to have some kind of handbooks where the user is able to look up what’s needed. At work, we are using Confluence (by Atlassian) as a collaboration platform. But as with GitLab, not everyone has a license for it. Therefore, as a second step, we moved over our handbooks from Confluence into the same GitLab repository where our Kanban/Issue resides and converted them to Markdown. Due to the same Build process for the container of our ops dashboard, we are now able to provide the handbook information to everyone who is in the need of it. Here we go 😎:
Step 3: Integrating operation statistics
As a next step, Stefan integrated our operation statistics. Due to this step, everyone who’s authenticated can see our statistics, for example, how many containers are we running currently, how many domains are SSL checked, and so on. We think that it is always a good move to also share metadata about the work we do. How does it look like? See:
Conclusion
At first, many thanks to Martin, Stefan and Bernhard (my team) for supporting this idea and the progress we made so far! I think we are now in the situation to be able to manage the communication much better. The quick wins that we got were:
- A centralized point of contact for all our customers regardless if they have a GitLab or Confluence license or not
- A centralized place for our handbooks
- A centralized place for our statistics
- A secured authentication with OAuth/SAML for all our colleagues
- We can now add even more statistics about the GitLab usage
- We will have an RSS feed for the latest and upcoming news from the operations
- We will provide a newsletter (double opt-in) for the operations, like AWS or GPC
- We are now able to extend the issue templates on the fly for everyone (same is true for the handbooks)
What was the investment so far? Stefan (did the programming) and Martin (OAuth2/SAML) invested 10 days until now. That’s nothing compared to the benefits we now have!
Thank you for reading and if you have any further questions, let me know!
Last edited on 22nd November 2020
