phixiuz
Interested to join our mission? Need more info about the job description? Go to https://ziggu.io/full-stack-engineer/
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.
Interested to join our mission? Need more info about the job description? Go to https://ziggu.io/full-stack-engineer/
Interested to join our mission? Need more info about the job description? Go to https://ziggu.io/full-stack-engineer/ :)
Interested about our culture? Find out here https://ziggu.io/the-ziggu-way/
With Ziggu, you will be part of a highly ambitious team where ideas, creativity, learning, autonomy and ownership are highly valued.
Interested to join our mission? Need more info about the job description? Go to https://ziggu.io/full-stack-engineer/ :)
Interested about our culture? Find out here https://ziggu.io/the-ziggu-way/
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.
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.
(fyi, not affiliated with them in any way, just really happy with their product, they deserve a shout-out!)