2025-12-21 14:59:22
This is a guide on how individual contributors (ICs) can achieve outsized impact within a software organization.
Individual contributors have the special property that they can get real work done. Managers are often constrained because their leverage is through people, which often means slower and steadier change.
ICs can bypass this. You can work a weekend to deliver a working prototype. You can spend nights finding an insane performance optimization. You can Proof-of-Concept a feature scheduled for next year.
So much of a company is bound by risk assessment, expected timing, and prioritization minutiae. Finding a genuine breakthrough cuts through the bureaucracy and fundamentally shifts the timeline.
If this work is so important, why isn’t it prioritized? It’s not prioritized because if you make it part of the day-to-day, it gets bogged down and dragged out like everything else, often resulting in sunk time with nothing to show for it.
By taking a calculated risk on yourself—the risk that you might fail—you can deliver a breakthrough that dramatically increases your value and the company’s. Occasionally, ICs should go all-in, work intensely, and find a breakthrough.
If you want to be a leader, you have to act like one.
That begins with being optimistic, not starting or encouraging big commiseration sessions with more junior people, not trying to set up an us-vs-them dynamic against “management” or treat other company structures like the bad guy.
Many senior ICs think it’s their job to be the union rep for ICs. The only thing that actually accomplishes is undermining your own credibility. It doesn’t deliver the value that would make people’s bonuses go up, and it doesn’t change hearts and minds.
But you also shouldn’t be a shill for management.
Like it or not, your job is to be an unaffiliated, unbiased leader, and doing what’s right in individual situations.
Another critical part of being an IC leader is owning things.
One of the specific virtues of the manager position is that it provides radical clarity on ownership - you own the team. With that ownership comes risk, reward, and accountability. The team wins, you win. The team fails, you fail.
Too often ICs get slotted into being 1 of n engineers on a team, becoming a non-unique, non-owner of outcomes. In fact, agile development processes often specifically encourage interchangeable resourcing.
But ICs should avoid taking this too far. Ownership and accountability are critical forcing functions for growth. You should ask yourself - what specifically could fail that would cause me to get less rewards? What specifically could do well that I should uniquely get credit for?
If you don’t have a good answer, you don’t have enough specific, named ownership. While ownership can come in many forms (services, features..etc), the core unit of ownership is a goal. If you don’t uniquely own any specific goal, you are shortchanging yourself.
Send regular updates.
Bi-weekly is usually a good cadence.
Send your boss a doc that says what you’re doing, what you need help with, and cc their boss.
This serves multiple functions
The benefits of this ritual are truly massive.
You’ll be shocked at how much better you get at self-management when forced to do it.
You’ll be shocked at how often your boss/boss’s boss can solve your problems faster when presented this way, and how grateful they will be for the clear updates.
PS if you use AI to write these updates you’ve destroyed their purpose entirely and are subtracting value.
Talk to people more senior than you in the org chart.
Seriously - book time with senior people, or ask them for 30 minutes to discuss what they think is valuable and worth doing. Senior leaders absolutely love this, because it lets them get more important work done through their team, and it often doubles as a therapy session.
Talk to five people from different parts of the business.
Then go solve one of those problems.
This is an extremely underrated activity because:
2025-12-15 14:59:22
Compensation is difficult. Even more than that, it is sensitive, business critical, and often has almost nothing to do with the rest of your job as a leader. Here are some rules for making compensation decisions effectively and efficiently.
It might seem obvious… but your foremost goal when running a compensation cycle is to maximize the talent and enthusiasm of your team. Full stop.
Creating a talented team means that you can get great people to accept your hiring offers. Creating an enthusiastic team means that these great people are motivated to work for you, engaged in their work, and (in the upside case), will work much harder than otherwise due to their compensation structure. And you need to fit this into a budget that allows your business to function.
If you spend enough time as a manager, you start to realize that:
To hit that final metric, you roughly want to target paying at least the amount where team members can’t easily find another job that will pay them more. (And on top of that, of course you need to try to make your work environment as otherwise appealing as possible)
The intuition here is that many jobs basically kind of suck, so if you don’t mind your current job, switching jobs is risky – and most people know that. What you want in your team’s head is some version of “perhaps I could theoretically get paid more elsewhere, but it would probably take a lot of effort and maybe the new job would suck in other ways.” This will retain most otherwise happy employees, which is ultimately what you deserve and the best you can hope for in any case.
Of course, this is easier said than done! You need to track the market, both via surveys and seeing what new candidate offers are accepted / heavily negotiated / rejected. You need to watch for attrition on your team, observing where departing folks go and why. And when you get new signal you need to react – don’t allow your compensation to get out of line with your target market percentile. But all of that is tractable as long as you put in the work.
But while you can’t make an unhappy team member happy with compensation alone, the converse is not true: how you compensate can absolutely make an otherwise happy team member unhappy.
What makes people absolutely furious about compensation is finding out that they’re paid the same, or less, than someone they think is less deserving. There are some people who will literally quit a company on the same day if this happens.
The best way to prevent a sense of injustice is simply to have clear compensation bands, and essentially never allow employees’ compensation to drift outside of them. Compensation bands are excellent at preventing some of the most common sources of unfairness – managers using their discretion to play favorites, and new hires making more than existing team members at the same or higher seniority (salary compression). The latter occurs regularly when market compensation shifts, hiring managers are captivated by a shiny new hire, and they allow their team to fall behind the market. Rigorous compensation bands prevent this from occurring (if you move your bands to accommodate a new hire, you need to move your existing team’s comp as well).
The most common cause of unjust compensation is simply laziness. Keeping track of everyone’s compensation to prevent unfairness or setting up a system that enforces standards takes effort, and many teams fail to do it. This is a huge mistake, as perceptions of unjust compensation are one of the ugliest and most acute sources of employee dissatisfaction. Additionally…
Many people talk about their compensation with others. As a result, you should be willing to explain exactly why any team member’s compensation is set where it is, in front of the whole company. You won’t have to do this often, but it’s the standard to hold yourself to. The reasons that comp is uneven between employees can actually even be random or somewhat weak, but there needs to be some justification. Some common, defensible examples:
Some of these reasons aren’t necessarily emotionally satisfying, but they’re all completely intelligible without any whiff of injustice. And injustice is the critical factor that drives people crazy.
Since the goal of compensation is creating an enthusiastic team, there are additional ways that you need to think about pay in order to maximize return on your dollars.
The most immediate levers are performance-based compensation such as bonuses and sales commissions. The main heuristic to keep in mind for any performance-based comp is that:
But equity is a much more powerful lever – specifically, a lot of equity.
If someone has 10% of their annual compensation in company equity, they will act like an “owner” the way that you act like an owner of your rental car. They’ll take care of things, generally be responsible, and won’t badmouth your company (much).
But if someone feels like their equity will change their life, most will act like a completely different kind of owner. They’ll start to treat your company like their child – they’ll stay up all night caring for it if there are issues, they’ll think about its well-being all the time. For your top performers it’s really worth getting them to that point via equity compensation if you can. If you want a quick heuristic, the most common amount of money that most people consider to be life-changing is roughly the price of a good-condition 3 bedroom home in their nearest metro area.
In summary:
2025-11-26 14:59:22
If you are a senior engineer or PM or designer, you should own a graph.
One of the quickest ways to get better at your job is to own a graph.
There are many ways to do work that don’t matter and there are many ways to do work that matters but fail to articulate that value well. Owning a graph solves both of these problems.
At a senior level, you must own big problems. Basically every problem worth owning can be shown on a graph. On a multi-quarter timeframe, the things you’re doing should be visible in graph format. Things like:
Not every bit of work you do has to be part of a graph, but if you don’t have at least one graph you’re owning, you’re not operating at a senior level.
One of the most common frustrations of senior people is that their impact isn’t understood. One of the hardest truths for people to learn is that that’s a them problem - they’re not communicating well enough.
Graphs are the most powerful tool you have to communicate your impact.
People often try to explain their impact in words. They might say something like “I reduced pages by 15%.” If you send that to your leadership, good leaders will immediately have 20 followup questions. 15% from what to what? Over what time period? Did it happen all at once or steadily? Was it already declining or did your actions clearly impact it?
Graphs show all of this information right away. You see scale, history, volatility. One graph can replace paragraphs of language. You also often get a free link to the data, so the recipient can spot-check the graph to gain confidence in it’s integrity.
Further, this ability to concisely communicate impact and effort is a critical tool for getting feedback. Sometimes you’re not working on the right thing. Sometimes the scale of your impact isn’t worth the time you’re putting in. If you represent your work in ambiguous prose, you’re not going to get direct feedback on it.
Representing your work as a graph gives you an ultra-concise way to both get credit but also get feedback.
In On Achieving Goals we talked about the radical simplicity of getting things done - set a goal and check in on it.
This is an addendum to that concept - you should do that process, with a graph.
This combination is so effective that it can be the difference between high performance and unemployment.
Graphs are a critical unit of ownership for senior people to track their progress, communicate outcomes, and get feedback. If you don’t own one, fix that ASAP.
Assorted tips and ticks:
2025-11-12 14:59:22
One of the hardest things I’ve found about being a Head of Product / Chief Product Officer is that you really have two jobs:
The first is setting up a strong product culture, establishing strong design/roadmapping practices, mapping out product processes, managing cross-functional partners, etc. Basically, being an executive that runs a strategic cross-functional team. I’m aware that “cross-functional” is one of those buzzwords that might seem to mean nothing, but I think it’s important to emphasize that PM teams tend to touch almost every project that an organization takes on, in at least some form. As a result they need to run efficient, high-quality organizations.
The second job of a CPO is aligning tightly with your CEO to set the right product strategy. Every CEO-CPO pairing falls in a different place on the continuous spectrum from “CEO sets all product vision” to “CPO sets effectively the entire product vision.” Regardless of where you fall, it’s essential that you and your CEO are on the same page. This is basically an Individual Contributor job, and is only barely delegate-able. It’s like raising your kids – you can delegate a few aspects of it but you are solely accountable and the spirit of the job must be done completely by you.
Job #1, setting the right product culture, is essential for your team to work well. Without this you won’t have enough impact. But if you don’t do job #2 well and align with company strategy immediately and forever, you will not remain head of product for long. And the two jobs are surprisingly different.
There’s no perfect way to balance setting up the systems that build the product and setting the direction of the product itself. But you can dramatically increase the odds of success by looking for efficient ways to balance both jobs.
First off – realize that the job of setting direction is the more important of the two roles. If you aren’t perfect at setting product culture, but you’re pointing your imperfect ship in the right direction, then you’ll have time to iterate and continuously improve. But if you are great at setting product culture and point your well-oiled product building machine in the wrong direction, you’re going to get replaced. CEOs and boards of directors are rightfully uncompromising about alignment between your product strategy and the company’s direction. You can sometimes be a bit early or a bit late to pivot towards a strategy that aligns to your CEO, but going in a different direction is unacceptable.
Worth defining: Strategic alignment doesn’t mean that you just do whatever your CEO says, and that all of their ideas are your ideas. It just means that you 1. Incorporate their ideas into your product strategy appropriately, and 2. That you elevate and support your team’s best ideas. Unwillingness to admit that others have good ideas and inability to inspire others are non-starters for a head of product.
Second, it’s valuable to efficiently set up a strong, stage-appropriate operational muscle on your product team. Get the right templates in place; set up the right rituals; set the right expectations; establish the right interview plans. Because of how product teams operate (typically 1 PM per team), a team of PMs has a huge amount of room for drift; much more than other vocations. 10 engineers might all be on the same team. 10 designers will work on different products, but they’ll need to establish shared design systems and protocols for customers’ sanity (and their own). But 10 PMs can legitimately end up running 10 different products, some of which have different pricing, technology stacks, business models, and even customer profiles.
One of the best ways to find balance is by delegating or establishing key product operational tasks once it’s clear that your team will be scaling up significantly. Be warned, however, that it can be very counterproductive to delegate product culture or process-setting to someone who hasn’t spent a lot of time building products themselves. Shipping product is really nuanced and you can’t just slap some generic template on a lot of it – the systems you set up need to be configured for your business and for a high-quality culture of builders.
For a tiny example, on my product team we spend a lot of effort curating and managing early access periods for new products due to types of workloads that we run (medium-high business criticality, very high scale). We’ve also had to devote meaningful effort alongside engineering to making sure that there are firm limits on the product due to cost/scale concerns. This is something that a prosumer note-taking app simply wouldn’t care as much about; but I bet that they care more about interaction design than we need to. You need product experts to make these sorts of calls, and can’t just hire a generic ops person.
Scaling strategy is much harder, especially for a complex product. But luckily it can be steered individually much more easily - think about how one person can turn a cruise ship but it takes dozens to operate the engines.
One of the most important ways to run strategy is to just be a dictator. How to run your team can be a debate and active discussion; the direction that you’re going should not be.
Hiring or training people who get “the plan” of how your product is going to win is one of the best ways to get strategic alignment. Businesses are complicated; having someone who can support the company’s strategic direction without being hand-held is invaluable. The litmus test – they should jump on new key opportunities in their area of responsibility before you realized that they exist. Training enough of these people will allow your department to maintain strategic alignment without the CPO having to audit every single decision.
The two jobs of a head of product are hard but tractable.
It’s not that the two different jobs are inherently incompatible. It’s simply that they are each distinct jobs, requiring large amounts of effort and expertise, and it’s hard to accomplish two hard tasks at the same time. The danger comes from the fact that many people don’t realize that their job is to set both product culture and strategy, and that one of them can be worked on iteratively (product culture), while strategy is a do-or-die requirement from day 1. Keep in mind that your manager will feel an asymmetry in these jobs as well; they are the god-emperor of your company’s strategy, but you are likely more of an expert at the tactical details of building a great product team.
I suspect that the dichotomy between these two roles is also why Chief Product Officers are one of the harder positions to fill once a company gets to scale. The skills that get you hired as a CPO are all about product culture and process setting. But the skills that keep you from getting fired are all about strategic alignment, and finding that alignment with a high-octane, highly confident CEO is an entirely different skill. A lot of companies hire product culture builders because the skillset is portable, and these hires then fail to lock-in on where the company should go.
If you’re a head of product, it’s critical to realize that you have two major directives that won’t directly reinforce one another. Communication with your CEO / manager is key – help them understand what you need to do, and how far along you are at accomplishing it. That way you can keep everyone on the same page and actually do the job you were hired for.
2025-10-22 14:59:22
The best way to win as a business is to move fast. And the best way to move fast is with a smoothly functioning team.
There are many ingredients that go into an effective team – hiring, performance management, incentive structures, clear goal setting, streamlined processes, and more. But in the broadest sense I believe that there are two fundamental activities, one fast and one slow, that are essential to a well-functioning team and that anyone can put into place immediately.
The best way to ensure that your team gets better over time is to ensure that you’re constantly leveling them up, and that teams never degrade in effectiveness and performance culture.
Organizations have a natural gravity that will pull them towards the lowest common denominator that they observe around them. Let’s say that you have 5 teams, and one of them works at a slower pace, has worse outputs, or takes on a less strategic role. All of these weaknesses will provide air cover for lower performers on the other 4 teams, and ultimately bring down the quality of your organization.
The key, replicable activity to keep in mind: You should always spend some amount of time debugging your weakest team, and bringing them back up to at least the median of the rest of your teams. Over time, this will gradually improve your organization – and more importantly, it will do it in a way that is highly stable, as this evolution doesn’t require massive changes or sudden changes to multiple teams at once. At any given point in time as a manager, you have a weakest team: Some percentage of your efforts should simply go towards fixing them.
The simple fact is that it’s pretty hard to debug multiple teams at once. It is very rare to have a team that sucks for reasons that are purely their own fault. 95% of the time, once you begin debugging, you’ll find that the situation is due to some combination of poor incentives, weak partners, or misunderstandings – in addition to any raw competence gaps. And if you want to be fair (which you should!), that will require investigation and follow-up with some degree of nuance.
The solution is to focus on one team at a time, and make sure that you are always working on the most challenged team. That way, even when things seem fine in general, you’re building up a buffer of higher performance that you can bank on when times are rough.
But this inexorable shift towards higher performance moves slowly. If you can debug one team per quarter (which is not a bad rate at a scaled up business), that’s a positive trajectory but a gradual slope across an organization of dozens, hundreds, or thousands. So you need a faster lever.
My favorite quick lever for performance upleveling is simply to put the most competent people in charge, regardless of their vocation or title or the shape of the org chart:
Companies that are >50 people hate doing this – it disrupts the chain of command, can create the perception of playing favorites, and doesn’t follow the MBA playbook. More significantly, it requires a degree of leadership resolve that is rare among career executives – it’s politically destabilizing to your organization, and the way that you tend to get ahead as a career exec is by making your team extremely politically stable.
But it works – because one thing that you find if you operate in fast-moving businesses for long enough is that the best members of your organization are often far more competent than the baseline team member (even on really strong teams!). You can ignore this, causing top performers to become more frustrated – or you can empower them and use them like battering rams that smash your worst problems into little splinters. The latter obviously works much better, and it works shockingly fast. Like, the project was screwed up this morning, but it’s 4pm and now the entire team has a skip in their step and confidence that they never had before.
The other reason that this works is that most organizations default to having a lot of hands on the steering wheel. This is a strictly worse situation – while some cars can be driven with 3 people holding the wheel simultaneously, it tends to require extreme competence, trust, and experience working together from every single person involved. I’ve seen this rapport get established between startup founders, siblings, or a combination of startup founders and extremely early employees (first 50), but never with any other group of human beings. For your situation you’re almost certainly better off just putting Jennie the Genius or Bob the Badass in charge and telling everybody else to shut up and fall in line.
People want to know that there’s a plan and that it’s going to be okay – and very competent singular leaders provide that drive and direction.
And I’ve also found that once you’ve established that leadership, the politics disappear. By constantly leveling up your teams (see part 1), you’ve hired good people. Good people love winning, and they love following a single great leader because that helps you win. And that’s all that anyone was looking for anyway.
2025-10-16 14:59:22
As companies grow, there is a stark shift from having a team of generalists to a team of specialists.
A young startup might ask an engineer to play roles ranging from engineer to PM to interim manager to solution consultant and more. A young startup might ask a PM to be a PM and pricing expert and a product marketing expert and a documentation writer and an ersatz designer and an interim engineering manager.
In bigger companies, all of these roles are done by specialists.
The upside of this transition is that, most of the time, you get higher quality output for each of these vocational tasks as you specialize. A dedicated pricing specialist is way better than a pinch-hitting PM. A PM is way better than the average engineer doing PM stuff.
There are major downsides though.
The number one downside is that all of these specialists must coordinate to get anything done. Coordination effort skyrockets. This can lead to dramatically increased times to deliver projects. And, sometimes, the coordination effort is so significant that the project slows to a crawl and lacks time for iteration, leading to lower quality.
In a world where slowness kills companies, this can be existential.
Another major issue is that as the number of required specialists goes up, the probability of an underperforming member of a project team goes to 100%. Most companies have 0 ability to react in realtime to an underperforming member of a project (perf management is too slow; embedded roles lack visibility). This can lead to serious deficiencies, slow delivery, and morale issues.
Finally, an amazing engineer is actually better than an average PM at product management. An amazing PM is actually better than an average pricing expert on pricing. As a result, deference to specialists can be deadly. If a great PM says that the design sucks, I don’t care if a middling designer has more experience, the design probably sucks.
Headcount growth is part of any successful company trajectory. But, to avoid these pitfalls, ensure that:
