Ziggu | Full-Stack Engineer (Ruby & Javascript) | Remote (Europe based) | Full-time | https://ziggu.io
When you order a $15 pizza with a food delivery app like UberEats or Deliveroo, you’re able to track that pizza better than when you buy a $350.000 apartment. This doesn’t make any sense in a world of awesome customer experiences we all know and come across in our daily lives. That’s where Ziggu comes in. Ziggu helps real estate companies better understand, inform, and engage their customers – homebuyers – by offering a centralized platform – before, during, and after construction. With Ziggu, you will be part of a highly ambitious team where ideas, creativity, learning, autonomy and ownership are highly valued.
When you order a $15 pizza with a food delivery app like UberEats or Deliveroo, you’re able to track that pizza better than when you buy a $350.000 apartment. This doesn’t make any sense in a world of awesome customer experiences we all know and come across in our daily lives. That’s where Ziggu comes in. Ziggu helps real estate companies better understand, inform, and engage their customers – homebuyers – by offering a centralized platform – before, during, and after construction. With Ziggu, you will be part of a highly ambitious team where ideas, creativity, learning, autonomy and ownership are highly valued.
Ziggu | Full-stack Engineer | Rails/Vue.js | Remote (Europe based) | Full-time | Headquarters: Ghent, Belgium | ziggu.io When you order a $15 pizza with a food delivery app like UberEats or Deliveroo, you’re able to track that pizza better than when you buy a $350.000 apartment. This doesn’t make any sense in a world of awesome customer experiences we all know and come across in our daily lives. That’s where Ziggu comes in. Ziggu helps real estate companies better understand, inform, and engage their customers – homebuyers – by offering an online customer portal – before, during, and after construction.
With Ziggu, you will be part of a highly ambitious team where ideas, creativity, learning, autonomy and ownership are highly valued.
Ziggu | Full-stack Engineer | Rails/Vue.js | Remote (Europe based) | Full-time | Headquarters: Ghent, Belgium | ziggu.io
When you order a $15 pizza with a food delivery app like UberEats or Deliveroo, you’re able to track that pizza better than when you buy a $350.000 apartment. This doesn’t make any sense in a world of awesome customer experiences we all know and come across in our daily lives. That’s where Ziggu comes in. Ziggu helps real estate companies better understand, inform, and engage their customers – homebuyers – by offering an online customer portal – before, during, and after construction.
With Ziggu, you will be part of a highly ambitious team where ideas, creativity, learning, autonomy and ownership are highly valued.
Afaik, Gitlab's wiki/knowledge base is also a separate repository and content is added/updated via regular MR flow. Our knowledge base is still part of the main codebase due to practical reasons (CI/CD related), but we'll eventually also migrate this to a separate repository as well, to avoid the unintentional gatekeeper aspect as you mention ;).
> There are plenty of things that happen on any company that have no relation to the code
Some more details about our approach that addresses your concerns:
(1) for content changes unrelated to code, anyone (tech or non-tech) is able to open a new MR, and after approval it automatically gets merged into our reference branch and deployed
(2) for content changes related to new (unreleased) code, the input from non-tech people (e.g. customer support) is usually requested via an already existing merge request (via a mention), they can then add their input/content via gitlab's interface straight into the markdown files (and see a live preview), this way we ensure this sort of content goes live along with the code and requires no extra coordination
> I am not telling you that what you are doing is wrong, but scalable it is not.
I hope with my clarification above it makes more sense.
> when you say "our use case": are you speaking on behalf on the whole company or just the tech team?
On behalf of the whole company: we have a single product/platform that is continuously increasing in complexity, and it really helps to have a single process in order to maintain a knowledge base that covers as many aspects as possible (tech and non-tech). We believe this approach will also minimize replication of content across departments (facilitates cross-linking), and we're intending to also create an aggregated search (next to the individual search) across all categories of our knowledge base (product/engineering/support/sales/..), in order to more easily retrieve relevant content.
> Beware the usage of the Royal We when you say "our use case"
I am not implying this is set in stone, we (as a whole team) thought long about this flow, and for now it seems to work great, and I hope (responsible for maintaining this technically) that it scales up to some point far enough in the future. I'd say we were mostly inspired by Gitlab, they seem to adopt a similar approach, and that seems to be scaling quite okay over there :). We've noticed ourselves that the general "documentation mindset" has definitely grown among the team because of this specific process and the ease of adding content, updating content and retrieving content.
Granted, we're still a fairly small organization (+- 10), but our business and customer support people are also using Gitlab to maintain our knowledge base: once you properly guide them on how to use it, they are definitely able to handle this. All the actual git operations happen under the hood of the web interface. So we do strongly believe this is scalable, at least for our use case. This has been working fine in fact for long-lived information across multiple departments (not only technical docs, but also e.g. sales/customer support guidelines). For short-lived information we use Google Docs (e.g. meeting summaries).
Also have similar experience with Confluence, as an alternative: we adopted a VuePress static site that we host internally (behind proxy), which basically just renders a bunch of markdown files. For easy discoverability of content we use Algolia's documentation search on top of it. For updating content we either use git locally for technical people, non-technical people can also directly update the content on remote git via gitlab interface. This has been working really well for us once setup, the main challenge we still have now is how to effectively communicate changes to the relevant people at the most appropriate time.
Your knowledge system keeping in sync with your version control is also a major plus, this is the primary reason why I don't like tools like Confluence, because it's easy for them to get out of sync with the actual system, and this can require too much coordination.
Twist was a true game changer for our remote team, been using it for over a year now after 3 years of slack. Before, with slack, we also experienced the typical frustrations of it being very distracting, and the synchronous communication could often lead to unneeded tensions within the team. Since adopting Twist, our workplace is now much calmer and more productive! They also dogfood their own product, and their team has been remote from the start AFAIK.
(fyi, not affiliated with them in any way, just really happy with their product, they deserve a shout-out!)
Interested to join our mission? Need more info about the job description? Go to https://ziggu.io/full-stack-engineer/