Management Decisions with Git. How it Works
Hi everyone! My name is Alexander Machulin, and I’m a co-founder of Gramax.
In this article, I’ll explain why we moved our management decisions to GitHub and how it helped us become more effective.
How it was and what we didn’t like
Like all progressive companies, we implement agile, handle massive amounts of data (big data), use machine learning, etc.
But in internal founder meetings, we started facing a problem — basic information about management decisions was scattered across different platforms and communication channels.
Because of this, it was impossible to understand: which decision was ultimately made, why it was made, and what led to it.
Here’s how it used to work.
We used 4 channels for sharing information:
2 messengers (recently switched from MS Teams).
Email.
Task tracker.
Notion / Paper / Google Docs — whichever was convenient.
We could post information in each channel on topics like:
Organization development concepts for 1–3 years ahead.
Decisions to start new products or directions.
Options for delineating authority and responsibilities within the company.
Rules for spinning off independent units into separate legal entities.
This resulted in a large number of “topic/channel” combinations, making it hard to find information — something that needed fixing.
Where we started
We started with a list of criteria for the future system. No, of course we didn’t. Who really does that?
We just discussed orally what everyone wanted. But looking back, these “wants” actually became the criteria. Key ones:
Limited access to information. Access should be restricted but reasonably stable, so it’s important that:
Links cannot be easily generated for someone outside the management circle.
Company admins cannot view these materials. Currently, they have unrestricted access to everything.
Control over change history. This is rarely used, but if we ever need it, having a full history is invaluable.
Offline mode. Good ideas often come where there’s no internet — for example, on the way to our another office on a plane, during vacation, etc.
Selection phase
The simplest solution would have been to agree to use only one channel. But we couldn’t agree.
Below are the points that didn’t work:
Messenger or email. Clear: chances of finding something after six months are close to zero.
Task tracker (YouTrack). Tried organizing management tasks as epics and user stories. Didn’t work — everyone was too lazy. Plus, task trackers aren’t ideal for quickly retrieving knowledge.
Internal knowledge base. Would require a layer over our admins so they couldn’t see this particular knowledge base, and someone had to maintain it technically. No one wanted to do this.
Paper (Dropbox). Popular for info exchange in our company, but:
Lacks convenient navigation and catalog structure.
Sharing links is easy, and there’s no centralized control over who has access.
Lately, their cloud has been unreliable.
Notion.
Simply disliked by one of the co-founders.
There was a contradiction — unclear whether to store info in our cloud or someone else’s.
Someone else’s cloud is risky and stressful: could be temporarily unavailable, data could be lost, or access restricted.
Our own cloud requires building admin layers — not desirable either.
What we ended up with
We solved the storage contradiction using Git — a distributed storage system.
Content exists simultaneously on my laptop, phone, partners’ devices, and on the GitHub server.
If something happens to GitHub, content remains on our devices.
For convenience, we added a few more tools.
Ultimately, it looked like this:
GitHub + Markdown + VSCode + Static Site Generator.
If you’re thinking of using this in your workflow — go ahead! Any part of the equation can be swapped for a preferred tool.
Later, we replaced Markdown and VSCode with a visual editor with Git support, and abandoned the static site generator for this repository entirely. I’ll cover that in another article.
Pros
Harder to share a link with “just anyone.”
Full control over change history with all the benefits of Git.
Offline mode.
Review mechanism.
Cons
Git, Markdown, and VSCode have a learning curve.
Separate authentication. Other systems use SSO.
No mobile version for offline work — but laptops are always with us.
Conclusion
The experiment was successful. We plan to roll out this approach to other areas in the company.
Planned steps:
Implement similar processes in HR to store grades, salary ranges, and candidate assessments for managers.
Move the repository to our GitLab with client-side encryption or corporate cloud disk to reduce the number of systems and authentication steps.