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

推荐订阅源

Scott Helme
Scott Helme
Security Latest
Security Latest
T
Threat Research - Cisco Blogs
AWS News Blog
AWS News Blog
S
Securelist
Help Net Security
Help Net Security
T
Threatpost
C
Cybersecurity and Infrastructure Security Agency CISA
D
Docker
Simon Willison's Weblog
Simon Willison's Weblog
Microsoft Azure Blog
Microsoft Azure Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
P
Privacy International News Feed
V
Vulnerabilities – Threatpost
I
Intezer
Spread Privacy
Spread Privacy
WordPress大学
WordPress大学
C
Cisco Blogs
有赞技术团队
有赞技术团队
G
Google Developers Blog
Blog — PlanetScale
Blog — PlanetScale
S
Schneier on Security
Know Your Adversary
Know Your Adversary
C
CERT Recently Published Vulnerability Notes
Y
Y Combinator Blog
S
SegmentFault 最新的问题
G
GRAHAM CLULEY
F
Fortinet All Blogs
N
Netflix TechBlog - Medium
L
LINUX DO - 热门话题
K
Kaspersky official blog
P
Proofpoint News Feed
P
Palo Alto Networks Blog
Cyberwarzone
Cyberwarzone
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
GbyAI
GbyAI
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
T
Tor Project blog
NISL@THU
NISL@THU
L
LangChain Blog
B
Blog
aimingoo的专栏
aimingoo的专栏
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Cisco Talos Blog
Cisco Talos Blog
雷峰网
雷峰网
The Cloudflare Blog
宝玉的分享
宝玉的分享
SecWiki News
SecWiki News
L
Lohrmann on Cybersecurity
C
Cyber Attacks, Cyber Crime and Cyber Security

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
How to choose job titles in your early stage startup - PostHog
Mo Shehu · 2021-09-14 · via PostHog's RSS Feed

One huge mistake some startups make is using titles to establish and reinforce hierarchy. This is dangerous for two reasons:

  1. Iteration and speed largely determine the growth trajectory of most product-led startups. Because of this, it's important to eschew managers in favor of 'anti-managers' - superbly strong individual contributors with a bias towards action, not control.
  2. Titles can make it harder to give and receive feedback - from both colleagues and customers. Without clear feedback, it's harder for individuals to improve, which can limit the whole team.

At PostHog, we started off completely flat, with everyone reporting to our founders, James and Tim - and everyone getting individual contributor titles such as Software Engineer or Designer. If we’d had Senior Engineer and Junior Engineer titles, for example, that would've indicated that we care about hierarchy, thus discouraging peer-to-peer feedback and capping individual performance at the level of whoever was designated as Senior.

But we hit a snag.

When we first found product market fit, we had to step up our game in areas such as product, design, and user experience in order to continue growing. James and Tim also found they were struggling to develop people’s skills properly because they had too many direct reports.

Towards the end of 2020, we were shipping lots of code but nothing moved the needle for our growth because we'd reached a talent ceiling.

So we solved this problem in two ways:

  1. We introduced Small Teams: small groups of people who owned specific tasks within the company. We have small teams for marketing, growth, design, product, and more.
  2. We introduced light management and tweaked our titles to reflect this.

These changes have resulted in a huge lift to our product and design competencies - and much happier end users.

It’s tempting to give out meaningless but impressive titles to convince early hires to come work for you. After all, we've all met or heard of 'CMOs' who were essentially a marketing department of one. But doing so is a grave mistake because such candidates won't be joining your company for the right reasons. This is also why we don't allow new hires to set their own titles - we don't need 20 "VPs" on the payroll.

Ideally, the best team members are willing to start by themselves, set a world-class standard in their area, then grow a team around themselves. That sets a culture of individual contribution.

We sometimes have a candidate apply for a certain role then suggest a slightly different title upon hiring them. This happens mostly for roles that we’ve never hired for before.

In engineering, we advertise for “Senior Engineers” mainly because we get so many unqualified or under-experienced applicants - but everyone is referred to as a Software Engineer on our team page. We pay people more if they have more experience - per our transparent salary calculator - but we don’t use these titles internally.

It's impossible to objectively judge someone’s performance and experience enough to determine what title they deserve and what they'd need to advance from a Junior to Senior role, for example. You have nowhere near enough context from their previous roles to systematize this. We think raw experience makes a difference for the first couple of years, but then quickly tapers off in its impact. In fact, experience can sometimes be a weakness.

For example, we’d be extra diligent when interviewing someone with an MBA, because MBA programs often teach behavior suitable for companies with wildly different needs to us. We don’t care about control, revenue maximization, or predictability in the slightest. We care about speed, innovation, and building for our end users first.

It was tough hiring our first Designer.

We’re big believers in self-serve products and experiences, and our website and docs are our storefront - so we wanted someone that would throw themselves into our website.

But because we're not a design company, we couldn’t figure out if we needed a UX/UI designer, a frontend developer, a website designer, or a general designer. Many folks in the interview process told us we were asking for too much - but sometimes that's just what your early-stage startup needs.

It took lots of iteration in our hiring process to get this right. We ended up hiring Cory, a talented generalist who can take designs from concept to wireframe to execution. He now works across our website, docs, and the app.

"Great designers iterate. They don’t magically come up with something brilliant on the first try." - Malthe Sigurdsson, former Chief Design Officer at Stripe.

Ex-founders or early employees make for brilliant generalists. They’re less likely to be as deeply skilled in any given area, but if you need a quick uplift in a certain area, they’ll get you there faster and more flexibly. As your company grows and your requirements change, you can specialize your roles and titles. For example, as of writing, we're hiring for a Technical Content Marketing Manager and Developer Educator to bolster our content and developer relations efforts. (Check out our Career page for more open roles.)

James, our CEO, has had to wear many hats over the years. Although his role swings between dealing with customers, recruiting, fundraising, and marketing, he's always been focused primarily on selling with a bit of design on the side.

Before PostHog started, James had to sell to get Tim to join. After the company launched, he had to get early users on board, which meant a mix of selling and building our website. His role then cycled through getting investors to take part in our funding rounds (from seed to Series B), hiring people, and talking to customers.

On the ops and product side, it involves thinking about how the company and our business model should work - including our product, financing, deployment, team structure, and pricing strategies.

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

We'll share your email with Substack