惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
WordPress大学
WordPress大学
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
V
Visual Studio Blog
S
Securelist
P
Palo Alto Networks Blog
A
Arctic Wolf
T
Tor Project blog
P
Proofpoint News Feed
I
InfoQ
博客园 - 三生石上(FineUI控件)
T
Threat Research - Cisco Blogs
G
GRAHAM CLULEY
M
MIT News - Artificial intelligence
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Microsoft Security Blog
Microsoft Security Blog
MongoDB | Blog
MongoDB | Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
Apple Machine Learning Research
Apple Machine Learning Research
S
Secure Thoughts
Cyberwarzone
Cyberwarzone
Blog — PlanetScale
Blog — PlanetScale
Simon Willison's Weblog
Simon Willison's Weblog
博客园 - 【当耐特】
大猫的无限游戏
大猫的无限游戏
腾讯CDC
Latest news
Latest news
Project Zero
Project Zero
V
Vulnerabilities – Threatpost
Y
Y Combinator Blog
S
SegmentFault 最新的问题
Schneier on Security
Schneier on Security
C
CERT Recently Published Vulnerability Notes
W
WeLiveSecurity
罗磊的独立博客
Stack Overflow Blog
Stack Overflow Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
L
LINUX DO - 热门话题
N
News and Events Feed by Topic
PCI Perspectives
PCI Perspectives
C
Cisco Blogs
Application and Cybersecurity Blog
Application and Cybersecurity Blog
爱范儿
爱范儿
T
The Exploit Database - CXSecurity.com
The Last Watchdog
The Last Watchdog
人人都是产品经理
人人都是产品经理
GbyAI
GbyAI
Know Your Adversary
Know Your Adversary
U
Unit 42

PostHog's RSS Feed

Training our own AI models - PostHog From 270GB RAM to 5GB: Moving local flag evaluation from Django to Rust The best analytics stack for vibe-coded apps The do's and don'ts of minimum viable product marketing - PostHog The best MCP servers for startups, by workflow 4,063 errors closed without a human opening PostHog – here's what we learned - PostHog PostHog Code and the self-driving product - PostHog Why attacking your competitors online is dumb - PostHog The best real-time analytics platforms for developers, compared DuckDB vs ClickHouse: Why we use both at PostHog - PostHog PostHog's next chapter - PostHog Making Claude Cowork actually useful - PostHog PostHog vs Matomo in-depth tool comparison You're doing lifecycle emails wrong Untangling Tokio and Rayon in production: From 2s latency spikes to 94ms flat The best HIPAA-compliant A/B testing tools - PostHog A beginner's guide to testing AI agents - PostHog I hate the standup bot (so I built an agent to do it for me) - PostHog The best CDPs for developers, compared The best error tracking tools for developers, compared The best feature flag software for developers, compared 7 best session replay tools for mobile apps 7 best free open source business intelligence tools right now 7 best free and open source LLM observability tools PostHog vs LogRocket in-depth tool comparison The most popular PostHog alternatives, compared Open source (and self-hosted) session replay tools - PostHog The 9 best GA4 alternatives for apps and websites - PostHog PostHog vs Google Analytics 4 in-depth tool comparison How we built automatic clustering for LLM traces - PostHog The 7 best HIPAA-compliant analytics tools 8 best open source analytics tools you can self-host - PostHog The best product analytics tools for startups, compared PostHog vs FullStory in-depth tool comparison The best in-app survey tools for product teams, compared The 7 best mobile app analytics tools PostHog vs Hotjar in-depth tool comparison The 8 best free and open-source feature flag services - PostHog The 5 best free and open-source A/B testing tools - PostHog The best mobile app A/B testing tools, compared What is a feature flag? Feature Flags vs Remote Config vs A/B Testing PostHog is now available in Vercel’s v0 The best Heap alternatives & competitors, compared PostHog vs Heap in-depth tool comparison PostHog vs Pendo in-depth tool comparison PostHog × Vercel: feature flags, minus the plumbing Your logs' final destination is in GA. You always end up here anyway Behind the scenes of a PostHog hackathon - PostHog The most popular Mixpanel alternatives & competitors, compared PostHog vs Mixpanel in-depth tool comparison The 9 best GDPR-compliant analytics tools How we use Logs at PostHog The best web analytics tools for developers, compared Stop AI slop: Run evals with LLM-as-a-Judge - PostHog You product data just got a job: Workflows is now out App onboarding: How to fix drop-off points Meet Logs (beta) – logs with all the tools you’re already using Why small teams crush tiger teams How we built user behavior analysis with multi-modal LLMs (in 5 not-so-easy steps) - PostHog The best Contentsquare alternatives & competitors, compared 8 learnings from 1 year of agents – PostHog AI - PostHog Why we killed our AI product assistant Workflows graduate to beta! Product data, meet automation The best Rollbar alternatives & competitors, compared Workflows are now in Alpha and I already broke mine - PostHog I've consistently underestimated how important communication is as a CEO - PostHog How we made feature flags even faster and more reliable The best session replay tools for developers, compared What I learned attending my first ever hackathon - PostHog Did you know AI is answering our community questions? - PostHog How not to be boring - PostHog We built an internal tool to generate changelog images for social media - PostHog What we built at our windswept Mykonos hackathon - PostHog How we built our onboarding email flow (with actual performance data) - PostHog We're building a better PostHog community by closing our public Slack - PostHog Introducing Notebooks for PostHog - PostHog Why we've launched PostHog user surveys - PostHog How we made feature flags faster and more reliable - PostHog In-depth: ClickHouse vs Redshift - PostHog Introducing HouseWatch: An open-source toolkit for ClickHouse - PostHog Introducing HogQL: Direct SQL access for PostHog - PostHog What we built at our sun-kissed Aruba hackathon - PostHog In-depth: ClickHouse vs BigQuery - PostHog In-depth: ClickHouse vs Elasticsearch - PostHog HogMail #22: Why do companies over-hire?" - PostHog Our simpler goal: Help engineers to be better at product - PostHog In-depth: ClickHouse vs Snowflake - PostHog HogMail #21: Avoiding the "Product Death Cycle" - PostHog Sunsetting Kubernetes support for PostHog - PostHog Why 'Product Engineer' is the most fun role I've had in tech - PostHog HogMail #20: Why do startups fail? - PostHog The best Google Optimize alternatives for apps and websites - PostHog Array 1.43.0: Massive performance improvements! - PostHog In-depth: ClickHouse vs Druid - PostHog HogMail #19: Which meetings should you kill? - PostHog CEO diary: The things I learned in 2022 - PostHog The essential tools used by product engineers - PostHog HogMail #18: What can SaaS learn from the New York Times? - PostHog What is a product engineer? - Product Engineer Handbook - PostHog Array 1.42.0: Get beta features via our roadmap! - PostHog
Building an all-remote company from scratch - PostHog
2020-09-01 · via PostHog's RSS Feed

Many companies are currently having to adjust to remote work, but what about the ones that started this way from scratch?

PostHog has a team of 12, 10 of whom have never met each other in real life.

So, what's it like building an all-remote company from the very first day?

GitHub Chat

Communication is perhaps the single most important value for us at PostHog. In our view, getting this right is essential to running an all-remote company successfully. As such, we highly value the following concepts:

Asynchronous Communication

Async communication means people shouldn't rely on getting an immediate response from someone else in order to do their work.

In our case, most of our communication happens openly on GitHub. This is great because each conversation occurs within a specific context (e.g. of an issue or PR) and all the information needed to discuss the topic should be readily available within that context. Additionally, people aren't pressed to reply immediately, and will get to it when they get to it (sometimes with a little nudge).

We also don't send internal emails. Zero, zilch, nada. 99% of the time, we're talking on GitHub, Slack, or a call. We also mostly use Slack for non-work-related, private, and more urgent conversations. If it doesn't fit one of those categories, chances are it could be on GitHub.

Transparency

Transparency means that if some information or a particular conversation can be public, we should try to make it public. 

This way, we create an ever-growing record of things that have been previously discussed, questions that have been asked, and answers that have been found. 

As such, when someone needs some info, they don't need to message a team member to get what they need. They can just find it immediately.  We extend this concept quite deeply, having our entire Company Handbook public, which outlines things like how we do sales calls, our approach to talking to investors, and how we hire people. As such, if there's ever a question about how we operate as a company, referring to the handbook will usually get you the answer. 

Additionally, our massive backlog of issues and pull requests also contains very useful information regarding how we've come to certain decisions, from engineering to marketing. 

Transparency pairs up especially well with the fact that we are an open source company: it's not only our code that is "open source". Heck, James, our CEO, even used to keep his to-do list public.

Written Communication

Underpinning the aforementioned points is our preference for written communication. 

The mantra goes: WRITE STUFF DOWN

At PostHog, a large part of our async and transparent culture is underpinned by written communication. In our view, writing things down is great because it is:

  • Faster: If something doesn't need to be a call, it shouldn't be a call. Calls are great for the social aspect they bring, but for day-to-day work, they often are a slower process for making decisions, given that they include small-talk, internet issues, and scheduling difficulties. Communicating via writing can help save time.

  • Referenceable: Unless you record all your calls, chances are you might forget something that was discussed in a meeting. However, by trying to write instead of calling, and taking notes when we do call, we can always refer back to what was discussed and easily expand on the discussion later on.

  • Clearer: Writing something out requires some effort to communicate your point of view effectively. As such, writing can help you distill your thoughts into concrete points, as well as present these points to others in a more solid way. 

Virtual Coffee Bot

Being all-remote, our team is unable to grab a beer together after a week of hard work.

As such, we have to make up for this somehow!

In order to socialize virtually, we do a lot of the traditional things remote companies generally do. We have a bot that schedules virtual coffee meetings between random team members, we have banter in Slack, and we plan offsites.

However, our favorite concept is what we call "Life Story Fridays". Every Friday, someone from our team spends about an hour telling the entire company about their life. It's entirely up to them how they go about this, but we generally get a bit about their professional background, a good amount of childhood photos, and a whole lot of interesting facts, such as:

  • Max, our Software Development Intern, ranks in the Top 5 for Pi digit memorization in the UK, is an accomplished ballet dancer, and runs a popular website for learning Latin.

  • James, our CEO, wanted to be a professional cyclist. Being a programmer on the side was just a way to keep that dream alive.

  • The other James, one of our Engineers, is on his way to get a pilot license.

  • Tim, our CTO, was first paid for work as a programmer at 13!

We're big fans of our Friday event, and it's brought us closer as a result.

Slack do not disturb

At PostHog we simply don't track hours at all. All we care about is output.

If you're getting your work done, that's what matters. It's not important where you like to work, when you like to work, or how you like to work. We just expect team members to:

  • Do the tasks that have been organically assigned to them
  • Be proactive in helping out where they recognize they can lend a hand
  • Enjoy their work

All we ask if that you join our daily standup and make sure you keep up with our team communication. However, we don't need you to be online all the time, since we generally prefer asynchronous communication. More on this means later.

We also believe you shouldn't overwork yourself. As a result, anyone at PostHog can have unlimited time off, and we strongly suggest taking at least 25 days a year. It's not good for the individual nor the company if team members are feeling stressed or low on energy.

As a result, it's not uncommon to hear something along the lines off "I'm renting a 4x4 and going off to the mountains tomorrow" on Thursday's standup.

It all comes down to trust. We hire people we believe in and give them autonomy and flexibility to drive us forward.

Remote work banner

Photo by Shaah Shahidh

When you're working with a remote team, especially one distribute across timezones, it can be difficult to get things done fast if they rely on more than one person's work.

For this reason, we believe in asynchrony, as mentioned before, but also the concept of shipping whenever.

The idea is: you've done some work, either individually or as a team, and it feels like it is ready to be published, even if it's not perfect. Well, just ship it. 

This can mean a blog post, a tweet, or a new software version. If a failure wouldn't have massive consequences, just put out your work. Once it's live, you can review it, gather feedback, and improve upon it. We do this a lot.

At PostHog, on a small scale, this means not waiting for our designer to make an amazing blog illustration to put our a new post, or waiting for QA to change a typo on the website. On a larger scale, it can also mean not waiting for a feature to be perfect to launch it to our users. The PostHog Toolbar is a perfect example of this.

The key to this is a culture of iteration, as well as giving the team a sense of autonomy and responsibility. You should always aim to unblock yourself if you feel it's right and can do it without serious negative consequences.

GitHub PR

At PostHog, we try our best to create a culture of submitting pull requests over opening issues.

The idea is, if you find a bug that needs fixing, or want to build a new feature, if you can do it without much work, you should just do it. Rather than opening a ticket for someone else to handle, just pick it up on the spot and fix it.

This requires a culture of flexibility, where people's work is allowed to diverge based on what ideas they have or issues they encounter throughout the day.

However, with such a culture in place, you build a team of doers who are consistently pushing product quality and willing to help out with things outside of their official job description.

Dakar Couchsurf

In addition to having access to a much broader talent pool, building an all-remote team across various countries gives you the unique chance to get people on board who have distinct backgrounds, speak different languages, and most importantly: think differently.

This can mean discussions about what a "biscuit" is, as well as having a team member run a call with a customer because they share a native language.

Since our goal is to build an innovative product, it's important to be exposed to multiple perspectives, and there are few better ways to do so professionally than hiring people from various corners of the Earth.

At PostHog, for example, we currently have people based in the US, Brazil, England, Cyprus, Belgium, Estonia, Germany, and many other countries. As a result, we consistently get exposed to perspectives we may not have come across before, growing both as individuals and as a company. 

PostHog has been remote from day 1, and we don't intend on changing that.

It's been a journey full of "Wait, so where are you right now?" questions, through which we've managed to put together a world-class team to build an ambitious product.

And while it hasn't been the easiest, sometimes because of bureaucracy, sometimes because of bad internet connections, we wouldn't trade it for anything.

After all, we want to continue hiring talented 18-year-olds from Poland and experienced founders from Mexico. Because remote isn't what we do - it's who we are.

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

We'll share your email with Substack