The journey towards Tech Blog

Many mature companies publish their own technical blog. But have you ever wondered how to launch such an initiative as your company grows, when to do it, and how to make it real? This post describes how we spawned our first blog at Pigment and the various challenges and questions we addressed to reach that goal.

Blog or no blog?

Technical blogs and articles are often a way for companies to communicate on the technical challenges they had and have to overcome. They tend to materialize for external developers what the company is doing from a technical point-of-view on a daily basis. While it can be considered as a powerful asset to better advertise on the strengths of the teams, it tends to require a bunch of time and energy. Indeed, a blog does not live by itself as it needs new content and thus time. It also needs people that like to share what they learnt, discovered, or faced.

When you are in a start-up with 4 developers, setting up a blog is definitely not your first target. You and your team are aiming to make the difference with competing products. This is especially true when your product does not target a developer audience, as a blog may not seem like a viable option for encouraging adoption and spreading the word about your tool. As such the priority starts low but at some point, it may become a clear will that you as a company or as an individual want to share on what you achieved and how you overcame part of these challenges. Question being to find this point in time.

Fostering a sharing culture

A blog is mostly about sharing. It is also about getting advice, suggestions, or questions from the external world, on simple to complex challenges.

At Pigment, sharing across R&D has always been one of our key principles. From the start, our development process has integrated the concept of Request For Comments (RFC). This practice is guiding us before we begin any new feature. RFCs enable us to closely plan each feature. We consider the technical requirements, product impacts, and design aspects. This approach ensures a well-rounded development process.

These documents in addition to being the backbone for any new feature to succeed, are a way to share knowledge into our R&D. For instance, if someone wants to understand why we did something in a given way, there is a document explaining the pros and cons of the alternatives we thought about in the past. Documents have always been written to ensure accessibility for everyone, including remote workers, who have been a significant part of our team from day one. They have also always been shared internally to ensure consensus and address any remaining blockers.

We also quickly fostered sharing extending outside of the R&D for new features to be demo-ed and we encouraged technical exchanges among developers, allowing them to showcase new discoveries on various technical topics.

But we wanted to push it further with an external communication layer made of a technical blog, this blog.

Tech stack

As our culture of sharing and openness took root, it became clear that we needed a blog able to reflect these values. Our next challenge was to choose the right technical stack for it. Indeed, there are many ways to publish a blog: from on-premise well-known blogging platforms to home-made options.

At Pigment, our blog serves two main purposes. First, it acts as a window, offering the external world a glimpse into our daily work. Second, it mirrors our core principles and objectives. We aim for our blog to embody the values and goals that guide us. As such our blog must be a way to show:

• live demos of components,
• designs we worked on,
• code snippets,
• playgrounds…

We decided to put aside external platforms, in order to keep those capabilities. We embraced a JavaScript and React based option making us able to share and customize more easily our content. Our choice went for Docusaurus. As a blog is also about publishing it, we wanted to make the publication workflow as simple as possible. For our blog's deployment, we chose an automated process. This process uses GitHub Actions, a tool for automation. With GitHub Actions, our content gets automatically published to GitHub Pages.