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

推荐订阅源

Google DeepMind News
Google DeepMind News
爱范儿
爱范儿
J
Java Code Geeks
L
LangChain Blog
V
V2EX
大猫的无限游戏
大猫的无限游戏
S
SegmentFault 最新的问题
博客园 - Franky
Microsoft Azure Blog
Microsoft Azure Blog
Jina AI
Jina AI
Blog — PlanetScale
Blog — PlanetScale
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Cloudflare Blog
博客园 - 司徒正美
B
Blog
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Apple Machine Learning Research
Apple Machine Learning Research
Engineering at Meta
Engineering at Meta
MyScale Blog
MyScale Blog
有赞技术团队
有赞技术团队
Hugging Face - Blog
Hugging Face - Blog

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
How to choose job titles in your early stage startup - Po...
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