Sherif's blog https://sherifnada.com A blog about startups, management, and engineering. Wed, 06 Mar 2024 15:16:02 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en Sherif's blog https://github.com/sherifnada.png https://sherifnada.com All rights reserved 2024, Sherif Nada <![CDATA[Necessary risk]]> https://sherifnada.com/necessary-risk https://sherifnada.com/necessary-risk Wed, 05 Mar 2025 00:00:00 GMT Building a business is really hard. Many things need to come together for it to succeed. Your product needs to solve a big enough problem. Customers need to be willing to pay for it. Your sales approach needs to work. You need to convince very talented people that working on your startup is mutually beneficial. And when they join, you need to keep them happy and engaged. The list goes on. If enough of those things don’t materialize, your startup will fail.

One way to increase your odds of success is to be very intentional about when to take risks and when to avoid them. Some people think of this as managing your “innovation tokens” or making boring choices.

But it’s not always obvious that you’re even taking on risk.

Let's take an example: You want to hire one additional engineer for your early stage startup, and your recruiter asks your opinion on where they should source candidates from. Your only options are:

  1. Source candidates from both startups and big tech
  2. Source candidates from big tech only
  3. Source candidates from startups only

Absent any other information about the role, your current team or company, and absent any additional levers for filtering candidates, what would you choose?

I would choose option 3: only source people who worked at startups.

It’s not that I think people who worked at Google can’t hack it at startups — obviously they can, and they often do. But I also believe that previous success at a startup is a better predictor of future success at a startup than previous success at big tech, just because it’s a direct proof point of success in a similar context. Plus, there are probably enough engineers who were previously successful at startups to fill the role within a reasonable amount of time. I’m sure a huge number of big tech employees could succeed in the role, and we could add more steps in the resume screening process to find that out, but given the beliefs above, I don’t gain anything by taking on the additional risk. I can achieve my goal without it.

This is a toy example, but illustrates how you could be taking on risk without even realizing it. Now of course, if you were hiring for real, you’d know way more about the role, your current team composition and needs, and you’d be able to filter candidates on more than just “worked at startups” vs. “worked at big tech”. But in business you are often faced with decisions when you have very little information. You constantly have to choose between spending time collecting more information or acting on what you already know. In those situations, you may be able to move faster by eliminating unnecessary risk and doing what you already know will work.

The other half of this is knowing when you should take on risk. If you only do what you know, you won't innovate. This can also kill a startup by causing it to offer the market nothing new. An incumbent can afford not to innovate (for a while), but startups by definition cannot.

The trick is recognizing the level of risk you’re taking on, and which risks are worth it.

]]>
<![CDATA[Make your company handbook public]]> https://sherifnada.com/make-your-handbook-public https://sherifnada.com/make-your-handbook-public Thu, 29 Feb 2024 00:00:00 GMT At Airbyte, we did a lot of hiring during the zero interest rate era. It was ridiculously competitive. Every good candidate had multiple offers. Each company went to great lengths to close them, outbidding, out-persuading, and out-wining and dining the next one to get them to join.

We quickly learned that there are good and bad ways to differentiate ourselves to candidates. For example, whenever we won a candidate solely because of higher comp or title, it usually ended poorly. Candidates that were successful at the company joined because they were excited about our mission, the product, or how we worked, not because we offered an extra perk or marginally increased compensation (though we did pay pretty well).

To capitalize on this observation, we made our company handbook public. Our thinking was that by transparently and authentically broadcasting our mission and culture, we’d get more of those mission driven candidates who are more likely to succeed at Airbyte.

Since then, we heard plenty of positive feedback from candidates about it. Almost anyone who joined the company cited the handbook as a reason for their decision to join. In many cases, that clarity made the difference when they were weighing other offers.

Why is a public handbook useful when hiring?

An effective handbook gives a clear idea of what a company is about and how they work: their mission, their culture, what they value, what they dislike, the archetypes of successful employees at that company, and more.

For example, if I were writing a handbook today, I would include at least the following topics:

  • Company mission statement & values
  • Code of conduct around how we behave with each other & our customers
  • Expectations that apply to all employees around communication, working hours, work habits, etc..
  • Organizational principles e.g: around how to prioritize product decisions or how teams should be structured or interact together
  • The philosophy and processes underlying hiring, performance management, stock options, compensation, and promotions
  • Onboarding process for new employees and offboarding process for outgoing employees
  • Organizational defaults like default software for employees or default tech stack for the engineering team or the default hiring locations for distributed teams
  • Useful HR information like expense policies, benefits, holidays, etc..

Now imagine you were considering working at a company and wanted to learn where they stood on the points above. Sure, you could ask your interviewers about these points after each interview. But wouldn't it be better to go into the interview process already knowing all these things?

For one, it's more efficient since you wouldn't need to schedule a whole interview just to get 5-15 minutes to ask questions.

It also allows you to pick companies where you'd be happier and more successful. If you read all that and still decide to apply, it probably means you share their values and thrive on working there. I know I would also feel more trust in a company that is that transparent with their culture.

As a company, these are obvious benefits. Your funnel will contain more candidates who self-selected into your culture, which improves hire quality as well as retention since people knew what they were in for when they applied.

Plus, on the margin, a public handbook is a better differentiator than a little more extra salary or perks. This is because culture, which is what a handbook communicates, is nonfungible. Two offers with the same compensation or benefits cancel each other out, but two companies that publish their handbooks do not. So even if every company in the world published their handbook, they would still attract candidates more likely to a succeed in their respective environments. Winning candidates solely on salary or perks does not have that effect. Practically speaking, most companies don't publish a handbook, so those that do will gain an edge due to the transparency their handbook signals.

Making your handbook public will also result in a better handbook. If everyone online can see your handbook, you'll have a stronger incentive to keep it updated, clear, and high quality. And insofar as you believe a handbook is useful for your own employees, making it public means you’ll be forced to make it better, thus increasing its impact inside your company.

An example of how a handbook enables self selection: Posthog

At the time of writing, Posthog had an entry in their company handbook about how they prioritize work and how it impacts their hiring. Here are some selected quotes that I think do a great job of showcasing their culture:

[At Posthog, there is] no product management by default. Engineers decide what to build. … In nearly any company, having each engineer decide what to work on would fail. They simply lack enough context. [But] PostHog is exceptionally transparent. … It starts with hiring. We hire people we think will flourish in an autonomous environment. We often hire people with broader rather than narrower skill sets, who are more flexible. … A high percentage of the company are engineers. 80% of the company are shipping product.

I love this part of the handbook because it authentically and unapologetically exhibits one part of what makes Posthog different. Lots of people - including engineers - will think it's crazy that engineers are running the roadmap. Those people will probably never apply to work at Posthog. But those who end up applying would probably thrive with this expectation.

The best part: it costs nothing

A relatively small percentage of companies publish their handbook.

I find this surprising because on top of all the benefits discussed above, making a handbook public has zero marginal cost. All the hard work is in creating and maintaining the content of the handbook, not changing its visibility from private to public.

If you're worried about the effort that needs to go into polishing the handbook, just publish a public Notion page. That's what we did at Airbyte.

If you're thinking "but we don't have a handbook!", I would be skeptical. Most companies above 5-10 employees have something written down about their process, values, culture, and expectations from employees. Slap it into a Notion directory and call it a handbook. You may need to clean it up, but given that it's a document setting expectations for your entire company, that's probably for the best.

Handbooks that influenced my thinking

Here are some handbooks that influenced how I think about culture and handbooks in general:

  • GitLab — the OG public handbook. Gitlab was one of if not the first tech company to publish their handbook and keep it up to date in public. It's more verbose than what I'd personally do, but it's a must-see if you're interested in this topic.
  • Airbyte — I was early at Airbyte and saw the handbook evolve with our culture, and I contributed to it as well. I'm biased, but I like that it's pretty informative while staying concise.
  • BaseCamp — DHH and Jason Friedman (the founders of Basecamp) are pretty opinionated about what makes a good company culture, and their handbook makes their opinions clear. It's a great example of how to highlight what makes your company unique.

If you’re looking for more inspiration, the following links collect some handbooks:

]]>
<![CDATA[Should you do anything about a productive but overleveled employee?]]> https://sherifnada.com/overleveled-employees https://sherifnada.com/overleveled-employees Sat, 24 Feb 2024 00:00:00 GMT At some point in your managerial life, you may find yourself in a situation where someone on your team is over-leveled i.e: their compensation or title is meaningfully higher than what their impact merits. Maybe you overestimated their seniority when hiring them. Maybe you inherited a team where a previous manager gave them a promotion or a raise they weren’t ready for. Or maybe your company rewrote your career ladder and it turned out that some people’s salaries or titles were previously inflated. Point is: someone’s title or compensation is seriously higher than what their impact justifies. What do you do?

This isn’t complicated if the person is adding no or negative value (in which case you'd just let them go).

Where this gets interesting is when someone is performing reasonably well at a level lower than the one the company expects from them. For example, your staff engineer is performing like a senior engineer, or your director is performing like a senior manager. It’s not that they’re doing nothing well - they may be doing a lot of good in your organization, but they’re not quite up to par to their official level. In fact, if it weren’t for this pesky over-leveling thing, you might even be perfectly happy to have them perform at their current level indefinitely at your company.

So what do you do? Should you even do anything at all?

Is this worth the hassle?

I mean, they're adding a lot of value, even if not technically at the level expected from them. Their team likes them. If you let them go, you'll need to hire a backfill, and how long is that gonna take? You might not even be sure that you'll get budget and time of day from the recruiting team. Plus, why should you go through all this trouble when, with time, this preson will eventually "grow into" their official level? Is shaking the boat worth all this trouble?

It comes down to which kind of pain you want to avoid: long-term pain, or the short-term one. If you want to avoid short-term pain, then do nothing. If you want to avoid long-term pain, then treat this exactly the same as a serious underperformance situation, for a number of reasons.

Setting the standard

The bar for what’s expected from a role in your company is derived from the level of those who currently hold that role or title.  Culture is how your company behaves, not what you believe or say. So regardless of what your career ladder document says about the bar required from a staff engineer, the real bar in people’s minds is, approximately, the average of the people currently in that role. If you have 5 staff engineers, all of whom are exceptional, then everyone will intuitively know, without even looking at your career ladder, that you need to be truly exceptional to get to that level. If you have 1 exceptional staff engineer and 4 average ones, people will intuitively know that the bar is not that high. This is true even if levels aren’t public within your company, because someone at your company is responsible for deciding people’s levels (probably a committee of managers or senior employees), and they’re going to compare promotion candidates with people already holding that title. 

If anything, you as a leader should behave as if the bar is set at the minimum level of everyone with that title, not the average, because that’s how a lot of promotion cases might get argued. A manager thinks their report is doing a great job, wants to reward them, and argues that “if so and so is a staff engineer, and my report is doing at least as good of a job as them, they should be promoted to the same level”. This reasoning is theoretically sound, but only if the minimum level of a staff engineer at your company basically never drops. Otherwise you’re just watering down what it means to be a staff engineer (or whatever other level you’re talking about). 

Opportunity cost

The second reason you should handle this situation is a lot more pragmatic: opportunity cost. Teams will typically have a budget allocation that is expected to help them achieve a certain output. Your team's budget might be expected to buy you a manager, one staff engineer, two seniors, two mid, and one junior engineer. If you have a staff engineer who's actually behaving like a senior, then someone still needs to do their job. Maybe you can fill the gap as their manager, but now you're spending your time doing their job, which takes time away from your own responsibilities and growth (which as a manager, frequently requires growing others to take over your current responsibilities). And you can't go to your manager and ask for another staff engineer because, well, you already have one. Now you're stuck having to pick up the slack and you can't get any staffing help.

Leading with integrity

Another reason you should act is: what happens if people find out about this person’s compensation? Would they think it’s fair? Would they continue to trust you and believe that you have their best interest in mind? Would they continue to feel motivated to do their work? This is a great litmus test of whether your compensation or leveling is fair: if a spreadsheet containing the level and compensation of every employee in your organization were to leak, would you be willing to publicly stand by every number on that spreadsheet? If the answer is no, then that's because those numbers aren't fair. This test may seem extreme, but the reality is that people talk about these things. Documents could leak. Private conversations could be overheard. So you should behave as if one day, that spreadsheet will leak out. 

Even ignoring all these practicalities, assuming you could somehow guarantee no one would know that someone is overcompensated or over-leveled, you should still do something because you know about it. You can’t lead with integrity if you knowingly allow a double standard just for convenience. So you need to do something. 

How to handle it

Here's something I wouldn't do: offer a demotion. Since the employee is doing well at a lower level than their official one, you could theoretically offer them a demotion if they think they can’t or don’t want to hit the improvement goals. This way, they don't get fired, they keep producing their positive output, and everyone is happy, right? I personally wouldn't do it, because it’s very difficult to reduce an employee's standing and still have them exhibit the same level of motivation or excitement about their work (unless they specifically asked for less responsibility after doing a good job in their role). If this works for you, though, please reach out, I'd love to learn about your situation.

Otherwise, generally speaking, this will look very similar to how you’d handle any underperformance situation. 

Before you actually do anything, loop in your manager.  Not only will they probably have a useful perspective, but they likely also need to fulfill some mechanical HR or paper trail requirements.

The first thing you then need to do is be absolutely clear with the employee that their performance does not meet the required bar for their role, and explain the gap. This step is crucial, because the worst thing you can do to someone who needs to improve their performance is ruin their chances for improvement by not even letting them know they need to do it and the level they need to reach. 

If the employee is interested in attempting to rectify the situation, then set very clear, time-bound goals for exactly what output level they will reach. It's important to be time-bound because otherwise you might procrastinate taking action (because let's face it, this situation just sucks for all involved). I mean this literally: set a specific date with the employee, in writing, by which they should hit their goals. Once that date arrives, you should make a clear decision one way or another. If the employee hit their goals (and sustains them): fantastic. If they didn’t, then the optimal long term outcome is to part ways. 

Unfortunately, I believe it’s harder to hit this kind of improvement goal than in an otherwise "standard" underperformance situation. In a way, you’re asking someone to grow their skills in a very short amount of time (a few months at most), enough to earn a promotion that would have normally taken them a year or more. This is a tall order. People generally take at least a year, often more, to grow from one level to the next. If you find yourself in this situation, it will most likely result in separation. For this reason, when you share the improvement expectations with the employee, you should also give them an “easy out” where they can just resign and we don’t have to go through a whole ordeal which will likely end with separation.

Avoiding this situation

If you do your best to uphold a high standard of meritocracy in your company, you should ideally never find yourself in this position. Promotions should have a high bar. Your leveling in the hiring process should also be risk averse, only hiring people at a given level if you’re pretty sure they have what it takes.

Of course, no company is perfect and you may very well find yourself having to resolve this. If you do find yourself in this situation, it's important to remember that this is basically no different than a standard underperformance situation. It’s never fun to deal with, but it’s critical that you do in order to maintain meritocracy as an invariant of your culture.

]]>
<![CDATA[Your company doesn't have to be for everyone]]> https://sherifnada.com/your-company-shouldnt-be-for-everyone https://sherifnada.com/your-company-shouldnt-be-for-everyone Mon, 19 Feb 2024 00:00:00 GMT Building a company is an exercise in empirically testing your beliefs. Everything your company does is essentially testing a hypothesis. Your successful product was once a hypothesis that was proven correct. Your failed pivots were hypotheses that were proven wrong. This is how the game works: when you're right, you win. When you're wrong, you lose.

Take a contentious example: working "hardcore" hours. If you genuinely believe that working 14 hour days and weekends and sleeping in the office is the optimal way to build your business, then run your company that way, demand it from your employees and vendors, and let the free market decide.

If you're right, your team's work ethic will make the difference. You'll make the better product, get more customers, close more deals, and your company will do great. If you're wrong, no one will want to work for you, employees will churn, your product will fall over, and your business will die. Fun!

On the other hand, if you think a 9-5 is the way to go, or that a 4 hour work week is your path to success, then it doesn't matter what I think. The market will tell you whether you're right or wrong.

That's the beauty of this mental model: the only thing that matters about your hypotheses (aka how your company works) is whether they're right or wrong, not their overall popularity.

Put differently: it doesn't matter how many people disagree with you or criticize your company for demanding 14 hour days or 4 hour weeks from your employees. What matters is whether you're right about that being a good way to run your business. If you have the right customers and employees, then who cares others think? If it works for you, it works for you. So don't seek consensus about how your company should run from people not on the critical path of its success (i.e anyone who isn't a customer, partner, employee, or shareholder). As long as you can get the needed critical mass of people who want to work at your company and enough customers to use your product, your company will succeed, because your hypothesis was correct.

Companies often get this wrong in two ways:

  1. Ineffectively proliferating their culture
  2. Not being very clear with prospective hires about values & operating principles

The least obvious but in my opinion most important way that companies get this wrong is by having ineffective values. To explain this, it's useful to understand the difference between culture and values. Ben Horowitz explains culture pretty well:

Culture is basically: how does your company behave when you're not looking? Do they show up to meetings on time? If somebody calls them, do they return the call? If it's someone lower rank than them, do they return it? Do they return it after a day? The next day? The next week? If they do a deal, is it for the price, or the partnership? What are they optimizing for? All those things are not in your goals and objectives, not in your mission statement, and not in your OKRs. It's how people behave on a daily basis.

A culture is not a set of beliefs, it's a set of actions.

Values, on the other hand, are what you tell the world (employees, newhires, customers, etc..) about your culture. It's what you put up on the wall in the office or in your culture deck, things like "We take ownership of our work" or "We're a sports team, not a family".

In that sense, what most people think of as their company culture is actually their values. But here's the thing: a value is just an idea. By itself, it has no impact. The only impact lies in whether people actually abide by it.

This is where most companies stumble: they write up their values in a culture deck, hang them on the office wall, announce it in a roo-rah all-hands meeting, then expect them to automatically proliferate throughout the company. Unfortunately, this is not how it works.

Because culture is a set of actions and not a set of beliefs, it must be reinforced constantly. Ideally, every time someone does something in line with the desired culture, their behavior should be reinforced, if even with a "thank you" or "nice work!". Those of us who have lived in the real world, of course, realize that this is idealistic; not every positive display of culture will be seen, let alone acknowledged. At the very least, culture should be regularly reinforced in the most important venues: performance reviews, raises, promotion decisions, and public venues like Slack or all-hands commendations.

But more crucially, behaviors that run counter to the desired culture should be immediately corrected. If someone takes credit for someone else's work, even if in a small or inconclusive way, it should be made clear that this is not okay. If someone half-or-80%-asses an important task or assignment, it may be easier to let it go in the moment and touch up their work, but if you do that, you're also indirectly telling everyone who's watching that it's okay to keep doing this. So it's crucial in those situations to quickly correct the action and reset expectations.

For this reason, effectively proliferating a desired culture can be freaking hard. Every interaction within a company is potentially a test of whether you actually have the culture your values claim you do, and whether you're willing to make the effort to correct it. Of course, anyone who built a team will tell you that if you're spending all your time fixing culture, then your error was actually in hiring those people who don't already adhere to your values.

There's a lot of truth to this, which brings me to the second failure mode companies run into with regard to culture: not being extremely and unapologetically clear with potential hires about your actual culture (not the one you say you have, or the one you wish you had).

Picture this: you & your coworkers normally work 10-12 hours a day and sometimes on weekends (not that uncommon at startups). You're interviewing someone who you really like, and they ask some version of "how many hours are people at your company expected to work?". You really want this person to join because they're super talented and would help you push the business forward and relieve pressure on you or your team. So in the moment, you say what you think they want to hear: "It's not that bad, work hours are pretty reasonable and people only work on the weekends very occasionally and mostly because they're excited about the work, but it's definitely not an expectation". If the candidate joins with the expectation they'll work a 9-5, you've just screwed yourself and the candidate over. Either you'll begrudgingly water down what you believe deep in your heart to be true (everyone should grind) which will lead to resentment or a dysfunctional team, or you'll have wasted a ton of time hiring & onboarding someone who will leave the company when one of you realizes it's not a good fit. It's a classic case of how being short-term nice to someone can actually be long-term mean or dishonest to them and yourself.

I've seen this a lot when companies want to hit aggressive headcount growth or improve diversity. They'll represent their culture in a way that maximizes the chances that everyone will want to join, rather than maximize the chance that people who subscribe to your culture will self-select to join. To be clear, I'm not saying aggressive headcount growth or diverse hiring isn't worthwhile, but that if you have to knowingly misrepresent or tell a "innocent lie" about your company's culture to hit your goals, then you should either change your culture or your goals. Anything short of a genuine, real effort to do either of those things will come back to bite you.

One way in which companies got this right is by not trying to be everything to everyone, especially when the company values or culture changes after the fact. A great example is Coinbase. In 2020, Brian Armstrong, Coinbase's CEO, felt that political polarization within the company was hindering their ability to move forward as a business, so he banned all political talk within the company that is not directly related to the company's mission. He got a ton of stick for it at the time. But had he not stayed true to what he genuinely believed, his ability to run the business as he perceived it would have been diminished, and he have likely been a less effective operator of the business, if only because he's spending many brain cycles getting frustrated at what he perceive to be a huge inefficiency in the company. The people who disagreed with this decision left the company, which I'm sure sucked for everyone involved in the short-term. But long-term, I believe Coinbase is now a more cohesive and effective business for it, because its people are spending less time fighting about things unrelated to their direct goals, and more time doing things that help them achieve them.

At the end of the day, what matters in your capacity as a founder or leader is guaranteeing your company's success. People - often many of whom you geniunely deeply care about - might disagree or get frustrated or even not work with you altogether, and that really really sucks for everyone involved.

But only in the short-term.

In the long-term, it's in everyone's best interest to find the equilibrium that works both for them individually and for the business. It requires discipline to implement and may be painful to do. But in my experience it's the best way to minimize pain and maximize prosperity over the long-term. Every other solution I've seen may be short-term easy, but unfortunately, leads to suboptimal outcomes.

]]>
<![CDATA[Hello world]]> https://sherifnada.com/hello-world https://sherifnada.com/hello-world Sat, 17 Feb 2024 00:00:00 GMT Hi folks! Thanks for visiting my blog. In case the massive page header didn't give it away, I'm Sherif Nada.

In this blog, I'll write about engineering management, startups, software engineering, and anything else in between.

About me

Most recently I was founding engineer-turned-engineering-manager at Airbyte where I built products and teams responsible for developer tooling, data integrations, and AI data workflows.

Prior to that, I was a tech lead at LiveRamp where I built and maintained petabyte-scale data platforms and pipelines.

I went to school at Middlebury College where I studied Mathematics and Computer Science and founded Photon, the world's simplest photo printing service.

Oh, and in case this kind of thing interests you, I built this blog using NextJS & React as a way to learn what StAtE oF tHe ArT looks like in front-end these days. And boy let me tell you, the state of the art sure is something. It's been fun though! You can find the code here.

Enjoy!

]]>