Tag Archives: management

A Framework for Developing Cultural Values

Every startup talks about their cultural values, but very few live them in a way that better allows them to win. Most are too vanilla and therefore forgotten by the team over time. There is a difference between cultural values, where companies say how they intend to operate on a spectrum compared to other companies, and principles that should apply to all companies trying to become great. Assuming good intent of co-workers, for example, is not a cultural value; it is a principle for great teamwork inside a company. It’s a dominant strategy for every company to operate that way. Cultural values should state the way this particular company does things that might be different from others. When cultural values work, they, along with dominant company building principles, should impact who gets hired, fired, and rewarded.

During the pandemic, Eventbrite felt like our company strategy had changed, we had a lot of new leadership, and our values weren’t helping us deliver against our new strategy. This was also a time where there was a lot of corporate pressure from employees on how they engaged on social issues, which was both generally distracting for a company trying to survive in war time. Other companies at the time were making headlines for, perhaps, some over-reactions to internal conflicts surrounding these topics (see Coinbase and Basecamp), and social media was over-reacting to those changes too.

So, we defined a process to evolve our cultural values, which I recommend all companies go through over time. I’m publishing the framework on how we did as a few of the startups I advise have found it helpful. This is just a framework; you don’t have to use it. The important part is to be intentional about your cultural values, and to keep them up-to-date with how you actually want your company to operate.

David, our Chief People Officer at the time, and I were inspired by a Harvard Business Review article called The Leader’s Guide to Corporate Culture. The article describes eight predominant cultural styles across companies. I created a spreadsheet that broke down these cultural styles based on a few different attributes, and asked our executive team to mark what they believed their predominant style to be. The attributes we focused on (which could be tweaked for your company) were:

  • Secretive vs. transparent: Do you default make things need to know or try to share everything?
  • For profit vs. for good: Are you a non-profit, willing to trade off some profit for your values, or entirely profit driven?
  • Independent vs. interdependent: Do you encourage people to move on their own or build consensus so everyone rows in the same direction?
  • Stability vs. flexibility: Do you try to keep the strategy the same or encourage pivots based on new information?
  • Whole self vs. focused on the work: Is work about work or are social causes a big part of the culture?
  • Top down vs. bottoms up: Do leaders make all the decisions or are decisions pushed down the org chart as much as possible?
  • Individual vs. team rewards: Do you reward everyone on the team the same or provide more rewards to those who deliver more impact?

You can view and copy the spreadsheet here for your own personal use. 

Hopefully, you can see on these attributes there is no right or wrong answer, just preferences of individuals on how they like to work. Obviously, I have my biases, but I have examples across every spectrum of companies operating differently and being successful. What’s important is the company is clear where on the spectrum they are. 

Each leader then picked for each attribute where on a scale of five points where they would ideally like to operate. For Secrecy vs. Transparency, for example, they would pick either: Very Secretive, Secretive, In the Middle, Transparent, Very Transparent. We then collectively ran an exercise where we defined what we believed the current leadership style of the company was today, and where the company operated today on these key questions. We then ran an exercise of where we wanted the company to go that might be different from how the company operates today.

As an executive team, we learned a lot about each other and the Eventbrite culture through this exercise. We unanimously agreed that Eventbrite was a Caring and Purpose culture as defined the HBR article. And we liked a lot of those attributes. We also noticed that a lot of the new leaders Julia had hired recently reflected more of a Learning and Results orientation. This seemed to be a deliberate exercise by Julia, if a bit of a subconscious one. So we wanted to communicate to the company more of an intentional move in that direction.

Once we aligned on these attributes and styles, what we did not do was write new cultural values. Because one of the attributes we wanted to change was to be more bottoms up, we then went to the rest of the company with this desired change, and formed a group of people across the company to develop the new values based on these directions. By workshopping every so often with David and myself, this working group defined new cultural values we then introduced to the entire company.

You will not come up with the same answers the Eventbrite executive team aligned on, or perhaps even debate the same attributes. But spending time on this alignment and using it to communicate clearly with the rest of the company can mitigate a lot of cultural issues as well as drive clarity on how certain decisions should be made beyond personal preferences.

Be sure to subscribe to my Substack to catch future posts.

Currently listening to my Synthpop playlist.

Founder Intuition vs. Team Expertise vs. Customer Expertise

When founders of startups start to hire employees to work on various parts of the business, it tends to be uneasy for both the founder and the employee early on. The founder may have done that job in some capacity before they hired for it, but they are not an expert. The incoming employee may bring more expertise, but they don’t know the business yet. The founder is going to have a lot of opinions as is the employee, and they won’t necessarily match. In this essay, I’ll talk about how to think about balancing founder intuition vs. team expertise, and how that changes over time. I find that this same balance is true for customers vs. founders when they start businesses too, so we’ll cover that as well.

Generally, the biggest mistake founders can make when starting to hire a team is defer too many decisions too quickly to new employees. This is most painful with new executives, but can also be damaging when hiring new individual contributors. Founders frequently convince themselves that this new person they hired is an expert on this topic, and they should defer to them. The opposite actually tends to be true. The founders are experts on the business. And incoming employees should defer to them until they are confident they have become more of an expert on a certain aspect of the business.

The opposite mistake tends to happen later on as the business grows. The founders have now staffed the company with a lot of great talent who have had time to learn the business, have impact, build processes, know customers really well, etc. Meanwhile, the founders are scaling a bigger business and getting further away from the details. Founder intuition becomes less reliable because the founder(s)’ advantage of having spent more time on the problem goes away. Their thoughts become perhaps dated. And they won’t really know it. This degradation of founder intuition also happens at different times for different parts of the business.

Great founders start to back away from relying on founder intuition when they see the expertise developing on the team, or are proven wrong in a meaningful way by the team that makes them start to question their often blind faith in their own judgment. Moving forward, founders have to calibrate how their intuition stacks up against team expertise on every topic of the business to know how much to intervene vs. let the team drive. Think of this as a simple graph.

It’s incredibly hard to accurately graph where the founders and team are on this graphic for every topic within the company, and when they cross. Normally, founders tend to navigate this based on factors like personal interest, what areas of the company they perceive to be doing well or not, etc. Having worked with lots of founders myself as a leader, advisor, investor, or board member, I default to founders needing to operate differently at different stages. On a bunch of different axes, I have mapped how I think companies optimally behave as they grow (changes in italics).

Phase 1: Starting Phase 2: Scaling Phase 3: Expanding
Founder makes decisions Founder starts to delegate decisions Founder empowers team completely
Speed > Precision Speed with some precision Precision > Speed
Generalist > Specialist Specialist = Generalist Specialist > Generalist
Done > Perfect Done > Perfect Done Perfect Trade Off
Focus > Breadth Focus > Breadth Breadth Focus Tradeoff
Execution > Strategy Execution > Strategy Strategy = Execution
Hungry > Seasoned Hungry > Seasoned Seasoned > Hungry
Cheap > Robust Cheap Robust Trade Off Robust > Cheap
Teamwork > Process Some process Process First
Doers > Managers Doers with some doer-managers Managers + Specialists

Obviously, this table can be a bit crude, and understanding when the company is shifting between phases is not always apparent to everyone inside the company. But it provides a default guide on when to delegate and empower teams as a company grows. I find that just asking the question of what phase the company is in builds good awareness on how one might want to be operating at the moment.

If you are a startup employee or leader, you have to respect founder intuition greatly. The company would not have gotten to the point you could have even been hired had that intuition not served the company well. But when you’ve really spent the time to understand the business and you or your team can start to have better judgment than the founder, it’s important to signal that confidence and get alignment on the operating model shifting. It will not be an easy conversation, but worthwhile to have.

What can you gain from such a conversation? First, you make the above graph visible to the founder in a way they may not be aware. Second, you can calibrate where each of you think you are on this graph. If the founder believes their intuition still serves the business better on a topic than the expertise you have built, then you can have a conversation about what would signal those two lines crossing to change how decisions are made in that area? Keep in mind, in some cases, that answer may be that there will never be a signal that changes how much control the founder wants to exert in an area. Companies are not democracies, and founders have the right to run the company any way they want. If they want to drive decisions on what tech stack the company uses or which segments are interesting, they will. If you don’t like it, you should join another company. But most founders want to do what is best for the company, and giving them the signal on where it’s valuable for them to lean in vs. that potentially being unhelpful is worth figuring out.

On the flip side, if the founder is putting decisions on you or your team where the founder would be better fit to make the calls themselves, tell them! There is no shame in admitting you’re not yet equipped to make the calls and empowering the founder to make more direct decisions for a while. This is not an admittance of incompetence. It’s driving clarity on decision-making rights that are optimal for the business. If you’re still asking the founder to make those same calls a year later though, expect them to think you aren’t developing the expertise you should be.

What is ironic about founders and employees facing this split between intuition from expertise is both have to do that same analysis with the company’s customers. When startups are small, most founders and employees tend to think the customer knows best. This may be experienced by changing the product based on customer feedback, allowing customers to experiment with different ways to use the product that help them become successful, etc. But as a company scales, it starts to see every way customers use a product, and what works best. For a marketplace like Airbnb, it might be seeing that hosts that provide toiletries get higher ratings, or for Eventbrite it might be seeing that emailing past attendees of an event a certain time before the next event maximizes their chances of buying another ticket. Then, the company’s job switches from observing what customers are doing and adopting them to teaching customers what best practices the company is aware of that will make them more successful.

So, in summary, founder intuition is extremely valuable, and new employees and leaders should learn to leverage that vs. ignore it because they’ve seen things before. But founder intuition does ebb over time in most areas as founders scale up the company, and of course, teams get a lot smarter as they spend time on deep company problems. This also happens with your customers over time. Having a dialog about where teams are in this journey is important to helping startups scale, clearing a path for teams to have maximum impact, and for leveraging founders’ scarce time in the areas that are most highly leveraged.

Currently listening to my 2022 playlist.

Podcast with Lenny Rachitsky

Lenny Rachitsky recently launched Lenny’s Podcast, and I was happy to be a guest. We talk about how to communicate upward, different product design strategies for complex products, what it means to be a product leader, and much more. I’ll expand on some of these in upcoming posts. You can listen to the podcast here or on Spotify below.

Currently listening to my Downtempo House playlist.

Fire Every Bullet

In crisis situations, a new style or management and prioritization has to occur. Andy Grove famously called this “wartime”, and he and others like Ben Horowitz have described what it’s like to be a “wartime” CEO. I haven’t ever seen anything written about being a wartime CPO though. Being a wartime CPO means a lot has to change in how you approach building product. Most product leaders think about their team as the product, and they continue to iterate on their team through hiring, training, coaching, delegation, etc. In wartime, you’re not hiring, you don’t have time to train or coach, and you make more top down decisions. But there’s one big thing that needs to change for wartime CPOs I want to cover today, and that is prioritization and evaluation.

I hope you never have to be a wartime product leader. But as you might have surmised, Eventbrite has been in a wartime situation for over a year now. Let me give you some background. In February 2020, Eventbrite started to become aware of a big problem. While the company was off to a fantastic start to the year, we could see the tidal wave of a global pandemic coming. Neither the world, nor us, was ready for what our metrics were showing could happen: the global shutdown of the live events industry. We were about to go to war, but not against a competitor, instead against nature.

There were, of course, differing opinions about the severity of the situation. The media was making fun of VCs for banning handshakes and telling us to be more worried about the seasonal flu, but the media failed to take into account the true potential downside. When the downside is unknown and potentially disastrous, as Nassim Taleb would say, the only rational reaction is over-reaction.

We planned for our mission, to bring the world together through live events, to be tested like never before. We acted swiftly to ensure the longevity of our business and mission, and the wellbeing of our employees, creators and investors. We launched resources and tools, we increased communication to keep employees informed, engaged and connected, and we realigned cost structure and secured access to funding. We also re-wrote the strategy of the business to align to this new reality.

More specifically, on the product side, we shifted all of our focus to help our creators prepare for the reality of a global pandemic and what that meant for their businesses. As we got to work, I recalled a conversation I had with Luc Levesque years ago when we brought him on as an advisor to Pinterest. Luc was the VP of SEO at Tripadvisor at the time (now VP Growth at Shopify), which was the only American company I could find that had succeeded at international SEO. Pinterest’s biggest impediment to growth was international growth, and SEO had been our primary lever to get U.S. growth into good shape after our initial strategy of leveraging the Facebook Open Graph stopped working. I was asking Luc whether we should prioritize different tactics to make international SEO work like international link building, localizing our URL structure, or making sure only content in local languages showed up on a page. His response was basically, “Dude, you do ALL of it.” We could figure out which one mattered the most after we’re successful. This is the approach we took at Eventbrite when the pandemic went into effect.

We built every possible thing we could to help creators and the company. We helped creators pivot online through virtual events; we published information on how to apply for loans; we built a bulk refunds tool, introduced the ability for creators to pay-in or wire money to Eventbrite to refund consumers and a credits system, and an easy postponement tool. We fired every bullet we had at the pandemic problem. We did not prioritize. It didn’t matter how much effort each activity was. We were going to do it all, and do it fast. We released things that would not meet our normal quality bar, because the only thing better than releasing these features for creators today would have been releasing them yesterday. We later learned other companies were doing the same.

One thing I would say, maybe feeling somewhat self-conscious right now, we made a company wide decision to lower our minimum acceptable quality bar due to the pandemic. If you observe Shopify right now, we are launching a lot. Almost just because of this one change. So we are pulling a lot of our roadmap forward in time. Everything that can help businesses right now, just because, again, we are in a crazy world right now.
Tobi Lutke, CEO of Shopify, on Invest Like The Best (May 2020)

You never want to be on the other side of a catastrophic event having failed saying “we could have done more,” and that has been top-of-mind for us throughout the pandemic. What is interesting when you take the approach of doing everything is some of the tactics work really well, and some do not. There is a tendency to evaluate those tactics in isolation for their success and failure. This is a mistake. You have to evaluate success or failure via the aggregate of all the bullets you fired. Did we save the company? We did. Did we save a lot of our creators’ businesses? We did. You can’t do an experiment or results review on those tactics individually. You have to look at the portfolio.

When should you fire every bullet? Do you fire all the bullets only in near death situations? How about live events recovery? Is Eventbrite firing every bullet to maximize the success of that? Prospect theory states that humans dislike downside impact more than they like upside impact of the same level. Many people have called this irrational. In fact, it is not, because extreme downside effects are things like death and ruin. Extreme upside effects don’t have the same degree of effect. So, firing every bullet makes a lot more sense for extreme downside scenarios than extreme upside scenarios. Think of the two by two.

The difference between we could have grown a little faster and death vs. safety is not at all the same. That doesn’t mean firing every bullet in upside situations is wrong; it’s just not as clear of an answer as in the extreme downside scenario. Quibi did everything to grow for its launch and burned through $100 million. It might have been better to do a smaller launch and iterate on content to find stronger product/market fit. Uber burned through billions for many years to try to both accelerate the size of their market and their market share within it, and it’s almost a $100 billion company.

The important thing to remember here is in extreme circumstances a lot of the best practices are different. Decisiveness, waste, and measurement will trade off in very different ways. It’s important to register when in these extreme situations that a different rulebook may be required to do the right thing for your business or product when in normal operations. Wartime isn’t over at Eventbrite, but I like to think of the situation right now as we’re finally having peace talks. 

Currently listening to Primitive Arts by Ron Trent.

Transparent Optimism

When I started managing teams at Grubhub over a decade ago, I was pretty obsessed with high performance. I wanted my team to have very clear goals, remove any roadblocks they would face to being successful, and make a big impact on the success of the company. I was able to hire a strong team, and we got to work, 100xing the size of our customer base over four years. As part of this process, a lot of what I tried to do was reduce distractions for the team. Any time there was strategic misalignment or confusion at the top ranks of the company, I would hide that from the team so it didn’t affect their performance. In other words, I wouldn’t let confusion at the top level create confusion at their level.

As the team grew over time both in size and in scope, I started to see cracks in this strategy I didn’t immediately understand. The first symptom was people on my team saying that while they felt very supported by me and were growing in their skills and their career, they didn’t have much visibility in what other members of the team did or how their roles worked. So, I created a Friday meeting we called “Team Learn” where every week, one team member would deep dive on what they were working on so the rest of the team could learn more about it. Initially, these were topics like email marketing or Google Adwords, but we started expanding them to other topics the team wanted to learn about, like venture capital and emerging channels. This meeting was so successful other teams wanted to participate, so I eventually expanded the meeting to include other teams.

This didn’t solve the root problem though. As my team got more comfort or clarity in their feedback, I started to understand the root problem more. While I was shielding my team from any swirl related to top level strategic decisions or screw ups or whatever elsewhere in the company, I was not the only person they talked to at Grubhub. So, they would hear from peers about all of these other things going on I had deemed to be unimportant or distractions, and the fact that I didn’t ever mention them made it feel like I was hiding things from them. It made them feel as if they couldn’t handle that level of knowledge and weren’t being treated as senior as they should be. 

So I shifted my approach. I made a commitment to share what was going on, but also contextualize it so as not to create doubt or swirl in their minds about what was going on at the company. We were definitely winning, after all. I moved from extreme editorial filtering to complete transparency, followed by contextualizing how this will all work out and why we win. When we hire great employees, the push to focus them and not distract them, while good, can easily be used as an excuse to not share hard things, and that creates a belief that the team can’t handle unresolved conflict, work through confusion, or understand strategic fog or even help lift it, and creates the perception that you as a leader are hiding things. It’s like hiring a bunch of strong engineers, and then only feeding them tickets of what they need to code through Jira because if we actually got them involved in deciding the problem, “they couldn’t possibly understand the business!” It doesn’t make a lot of sense when you think about it.

At Eventbrite, I have come to call this style transparent optimism. I’m going to give you all the context, the good, the bad, and the ugly, and explain how I think we come out on top. I trust my team with being able to handle all of that context and ultimately help us work through some of the thornier issues together. This is a style of communication that will not work with all cultures. Company cultures have to decide where they exist on a spectrum of open vs. closed in their communication. If I tried to apply this style at Apple, for example, I would quickly be fired for sharing things they do not want shared. So I bias toward cultures that have a comfort with this level of transparency, which is not all companies! Many companies would not even let me write a blog like this while working there. At Eventbrite now, I host quarterly AMAs with the team, the CEO does them twice a month, and both the CTO and I wrote monthly internal blog posts on what is on our mind. 

Obviously, I am biased, and communication styles come with pros and cons. With transparent optimism, I create risks of more interpretations of what is happening, external leaks, and it just requires me to communicate a lot more. But ultimately, I think it creates a default trust and default respect with the team, and helps them contribute more to the success of the company.

Currently listening to Scurlage by µ-Ziq.

The Rise of Department Operations Roles, and How to Tackle Inefficiency

At every company, there are well defined roles you would expect to see. In software, they tend to be roles like engineering, product management, design, marketing, legal, finance, etc. But as companies scale, they tend to invest in more specialized roles over time. During that transition, operating in one of these roles can be confusing. One interesting trend emerging at many companies including Eventbrite is the creation of departmental operations roles. Oh, you’ve seen them: Marketing Operations, Sales Operations, Design Operations, Product Operations et al. My first instinct when I hear an “operations” title is “inefficiency.” Not that the operations person is inefficient, but that there is inefficiency at the company. It is okay to be inefficient at things at your company. At various times, it will make sense to be inefficient in tons of areas of the company. The danger is in accepting inefficiency for the long term. We should strive to eliminate inefficiency over time at companies, not embrace it. Thus, the goal of departmental operations teams can be somewhat paradoxical. By explicitly attempting to remove inefficiency, they are actually attempting to remove the need for their roles entirely. 

The Intercom Biz Ops team was the first to just come out and say it. This can create a remarkable conflict of interest though. By doing a good job, will I eliminate the need for my job? As a result of this conflict of interest, we have started to see people in these roles try to define them as long-term necessities in organization, which means employees are optimizing for themselves instead of the company. What is interesting about this trend is that this job security issue shouldn’t be a conflict of interest. The goal of every job inside an organization should be to eliminate the need for it so you can do more important things. This is a great way to get more responsibility and promotions. There would be no greater pride for me than feeling like I am no longer needed in my current role at Eventbrite, for example.

So, if you want to do a great job in a departmental operations role, how do you do that? Well, the real question is how do we solve inefficiencies at companies? It’s like solving any problem within your company. You use various tools. I have a very specific hierarchy I like to follow to solve these problems, and I wish more companies used it instead of defaulting to hiring people and creating roles. If you’re in a department operations role, you can consider this a playbook to helping the company be more successful.

#1 Software
Any problem or inefficiency we can solve with software is superior to other forms because it automates away the inefficiency in the future once it is built. Now, it may be the case that we cannot think of or do not have the resources to develop a software solution to the problem, permanently or temporarily, or that there is no software we can buy that helps. This is okay, even normal. Companies tend to under-invest in leveraging engineering to build solutions that help their companies become more efficient, largely because so many companies are engineering-constrained. But just like engineers have started to work more on business problems like growth or marketing, they will eventually start to work more on internal tooling that enables their and other teams.

#2 Process
My next goal would be to solve the problem or inefficiency with process. Process innovation is a remarkable thing. By understanding the issue and proposing a way of operating to solve the problem, the pain point can frequently be mitigated or disappear. Now, this is not as automatic as software because it requires people doing things to follow the process and usually more training than software. But processes can become hard-to-break habits, especially once employees see the benefits of them inside an organization. This is more of where departmental operations roles tend to thrive today. By understanding the strategy of the business and the day-to-day operations, operations team members can spot inefficiencies, test different process solutions and assume responsibility for scaling out ones that work. But these solutions can be led by anyone. The more this happens without dedicated operations people, the more efficient an organization is.

#3 People
My next best option after process is to solve a problem with a person. Hiring is expensive, so it should be considered carefully. I definitely prefer hiring for concrete roles that have well defined value inside companies. Engineer, designer, analyst, etc. If you need to hire an Operations role because the problem is nebulous, temporary, or today can’t fit into one of those roles, you can do it. But you should have a career plan for those roles to evolve into a more well-defined role. Fortunately, team members that showcase generic problem solving skills are great fits for many other types of roles inside companies, so they rarely have to worry about their next internal career move. Still, it may be more efficient to actually look at one of the other solutions below.

#4 Advisors or Consultants
Sometimes the right person isn’t available, or the problem is well time-boxed. In this situation, I prefer to find consultants or advisors. Subject matter expertise exists out there in the world for almost anything. Working with individuals that have specific experience makes it easy to align incentives even if this subject matter expertise isn’t hireable full-time. If the issue is temporary, you may not want to hire full-time anyway.

#5 Agencies and Firms
Lastly, I look at agencies or firms. With these companies, it is hard to prevent misaligned incentives. But they do have expertise and bodies that you can throw at a problem with less risk of being stuck with them full-time. 

Where Operations Wins
I am not against Operations roles; I just want companies to understand how to use them well and to scale out of them whenever possible. Early stage companies can absolutely crush with Operations. Smart people Swiss Army Knifing problems is many times the fastest way to scale in the early stage. Operations roles can also thrive in larger companies, if they root out inefficiency with the tools above and don’t succumb to empire building. We can’t yet automate transportation needed for the delivery of the business? Call that the Operations team. We can’t automate training for our customers yet? Call that the Operations team. 

The COO role is very common, though its definition is ambiguous because it tends to be a grab bag of executive inefficiency. Usually, the COO manages what the CEO is inefficient at. That can be management in general, or parts of the company the CEO is less capable of adding value to. The COO role can also be a roll up of certain executive functions when the CEO has too many direct reports as well. 

This is all fine and even optimal. But every operations role you add you should also add to a list of inefficiencies you hope your company can solve one day, and always be thinking towards software or processes that make these current roles unnecessary so those people can take on even more important roles over time.

Currently listening to Good Times by Moire.

Why Product Leaders Fail

I’ve yet to meet a fellow Chief Product Officer or Head of Product say, “yeah, I’m crushing it right now.” In my conversations with fellow product leaders, there’s even a meme that’s started to form around product leadership roles. Effectively:

“Yeah, you just try to put some points on the board before you inevitably get fired.”

So, if a typical CPO feels their role is about trying to survive a couple of years i.e. long enough to help the business a little bit, what is causing that? Why is it so hard to endure as a product leader?

I would say there are three common failure modes depending on how far along the company is. The earlier stage of a company it is, the more likely the answer is going to be misalignment with the founder/CEO. What no one tells product leaders when they accept product leadership roles is that nine times out ten the founder and CEO still wants to drive the product vision. They want you to help execute that vision. And as founders scale, their founder intuition ebbs in effectiveness in comparison to product expertise in-house, but it takes a long time for founders to accept that. That transition period can be very rocky.

For later stage companies, the more likely answer is that the CPO is really only good at one type of product work, and the type of product work needed for the business changes over time. This can manifest in two ways: The product leader has skills that don’t match the type of job needed today, or as they execute, the skills needed change, and the leader cannot adapt. Not only is the product leader not good at that new job, they are also less likely to be interested in it.

Let’s talk about each of these failure modes and what both product leaders and CEOs can do to make them less likely to happen.

Failure Mode #1: Who Owns Product Vision?

Founders tend to have insanely good intuition about their customers and products because, let’s face it, no one has spent near as much time thinking about them and their problems. When startups tend to hire product leadership, it’s their first time hiring this type of leader. Interview processes can be clumsy or unoptimized, with the founder still figuring out how to articulate the real need. Commonly, what happens during this process is both the founder and prospective product leader end up jamming together on the future product vision. Both sides love this engagement, but for the founder, it’s not an effective test on how much the prospective product leader will help the founder, and for the product leader, it can give a false impression that they will have a ton of say in the product vision.

If at all possible, founders should leverage outside expertise to structure the recruiting and interview process for this type of role. One of the key questions to get explicit on before the process begins is what role will this leader play in setting the product vision? For non-product/eng/design founders, they may be asked to define it. For founders with product, eng, or design backgrounds, that is typically not the case until the company becomes much larger. Product executives usually play a consulting or execution role in a vision that is founder led. Founders need to tell candidates which one it is, and candidates need to ask. Neither of these happen as often as they should. 

Once founders understand their answer to this question, they need to vet for the appropriate skills. If what you really need is help executing on the vision, don’t spend much of the interview process jamming on the vision. Sure, candidates need to understand the vision, but what you really need to learn is are they comfortable receiving a vision from you and bringing it to life in the myriad ways that are difficult. 

Failure Mode #2: Does the Expertise Match the Type of Product Work Needed?

Different companies require very different approaches to their product strategy to be successful over time. Most of us understand there are different types of product work. There is tech and process scaling, there is building new products to find new product/market fit, there’s building new features and iterating on the user experience to strengthen current product/market fit, and there is growth work to get the maximum number of users to experience the product/market fit that exists. Traditionally, product leaders lean toward being experts in one or another. For example, I am definitely most known for my expertise in growth.

Founders often lack the understanding of what type of product challenge they are actually facing when they attempt to hire a product leader. Network effects businesses tend to focus more on growth because more users make the product stronger in a much more meaningful way than new features. DTC ecommerce companies / brands are always launching new products. SaaS businesses tend to need to launch lots of new features over time. Hiring a product leader that wants to build new features all the time into a network effects business likely isn’t going to work that well.

Failure Mode #3: Can the Product Leader Adapt as Needs Change?
Even if founders hire the leader with the right skills at the right time, as companies scale, how much weight they put on these will need to change over time. Today, the product leader’s job is to be what the business needs them to be. So while the old school product leader is a specialist, the new school product leader needs to be a chameleon, who can balance a portfolio across scaling, new product work, feature work, and growth weighted toward the needs of the business, and re-weight it considerably over time as business needs change rather than leave once business needs change. That’s hard, but inevitably how product leaders have to evolve to be successful over the long term within a company.

As a growth oriented leader, I am actually spending more of my time at Eventbrite on scaling, features, and new product expansion work, because that is what the business needs right now.

—

Product leadership is incredibly hard. Both founders and product leaders can eliminate some of what makes it so difficult by aligning on expectations before hiring roles, and on aligning which problems the organization is focused on right now. It is then up to product leaders to be able to evolve as the product needs change over time. They are both the best equipped to understand when needs change and help the organization change with them.

Currently listening to Rare, Forever by Leon Vynehall.

The Types of Product Team Organizational Structures

There is no one perfect way to structure a product organization within a company. Like most things in a company, organization structures only make sense for given moments in time, and as changes happen with the business, so does the organizational structure to match. Product teams are no different, but they tend to vacillate between four different types of structures over time, which I’ll explain along with their pros and cons. These structures tend to work best when aligned with how engineering, design, and other partner functions are structured, so there are 1:1 relationships between leadership roles in those functions.

Alignment of Structure

By far the most important rules of product organizational structures is that they should closely mirror the partner functions. So engineering, product management, and design should tend to have structures that match each other whenever possible. This can’t always be 1:1 as engineering teams tend to be much larger, but if engineering is organized in a very different way from, say, design or product management, it can cause many problems. It can create misaligned incentives as well extra coordination between managers as one director may have to interface with four different peers to align their work instead of one. Assuming the company tries to align all of the development functions, let’s talk about a few ways they can be aligned.

Organization by Type of Product Work

In the Reforge Product Strategy program, we talk about the different types of product work. A common organization structure is to separate teams based on the type of work they are doing. One pillar is the innovation pillar working on new products. One pillar is the core pillar trying to strengthen the core product with additional features and maintaining the core. One pillar is the growth pillar trying to grow overall usage of the current product. One pillar is the platform pillar working on internal features that support other product and engineering teams to allow them to scale. 

The organizational structures can be quite stable, but the level of investment in them can change quite dramatically over time. Product leaders need to consistently be thinking about the right allocation between these different types of work and changing resourcing among them based on the needs of the business. This reshuffling can create change fatigue of individuals that have to move around teams.

Organization by Customer

If a product has different types of customers, a common structure is to separate product teams by the customers they build for. This is very common in marketplaces that have supply and demand teams, or in subscription companies that have self-serve and enterprise, or free customers and paid customers. This allows product people to become experts in understanding their customer well to deliver them value. 

These organizational structures tend to be very stable in marketplaces, but less so in subscription companies if the contracts between those teams are not written correctly. For example, I’ve seen companies that have split into free and paid where the free team is penalized when a person upgrades, which should be the very goal of a free plan. But, since the free plan was goaled on usage, whenever someone upgraded, their usage was removed from the free pillar’s metrics. Even in marketplaces, there can be issues with this model as great products are things that benefit both supply and demand, and it’s hard to build a great product if you only know one side well.

Organization by Value Proposition

If a product has different value propositions, a common structure is to separate product teams by those different value props. For example, at Pinterest, we thought about our value props as Discover, Save, and Do, and had different product pillars for each of those value props. This makes it easy to align OKRs or goals to the value you’re trying to provide your users.

This organizational structure can last for quite a while as value propositions do not change dramatically over time in most companies, but some necessary product functions don’t easily fit into this structure. Great product goals tend to be focused around value created for the customer that, in the long run, create value for the business. Value prop structures are more likely to ignore or de-prioritize that second part of long run value for the business. These structures can also overly focus on the product engineering part of the engineering stack as their goal is to deliver more value. If not handled correctly, this structure can lead to an under-investment in important maintenance, scaling, or growth work as the desire is always for new features that aid in delivering this value prop.

Organization by Initiative

Companies tend to have strategic initiatives that emerge from annual planning, so a common organizational structure is to align product and engineering around those initiatives. This process can work well when initiatives are new, and the organization isn’t sure what types of product work will be most important to succeed in an initiative yet. The initiative structure allows PM’s and engineers to flex between innovation, growth, scaling, etc. as needed to support the ultimate outcome for the business. This requires product folks to be more agile in their planning and in the skill sets they are leveraging. We organized this way at Eventbrite when I started as Chief Product Officer.

This organizational structure tends to be the least stable because initiatives change frequently or at least on an annual basis. Once the type of work that is required to be successful for an initiative becomes clear, many times teams like to specialize by switching into one of the other structures above.

Mixing and Matching 

What a lot of companies end up doing is mixing and matching a couple of these approaches to fit their needs. For example, while Pinterest used the value prop structure for the core product team, it also had growth and monetization teams to balance the business needs of the company. That combination proved fairly stable for a while. No organizational structure is perfect, and emerging trends in product, like having product managers work deeper into the technical stack on platform, infrastructure, and DevOps, will continue to shape changes in how product leaders structure their teams to drive effectiveness. Nevertheless, it’s important to think through the tradeoffs of different organizational structures to make sure they match best to the needs of the company at the specific point in time. What is most important is aligning this structure between engineering, product, and design as much as possible to the teams work in unison.

Currently listening to Hand Cranked by Bibio.

Taking On Too Much

There is always a time in your career where you’re asked to take on more responsibility. This is normally a good sign! It means your manager or CEO or whoever trusts you and seeks you out when problems arise. If you’re like me when I was earlier in my career, you always said yes. I thought of this as moments to increase responsibility, learn new skills, and have more impact. Now that I’m older, I am no longer so eager to take on more. When these situations arrive in my career now, I take real stock on my capability to handle the increase in responsibility. Today, I’ll walk you through the three most common scenarios you’re likely to find yourself in when this happens, and some recommendations on what to do in each situation.

Option 1: Scale
In the first situation, you have been spending years building up a team and/or some sort of scope you’re comfortable with. It could be an entire function like product, a group within a function like the email marketing team, or, if you’re an IC, an area of the code or a particular skill set the company needs. By all accounts, you’re excelling in this scope. If you’re stuck in this structure for too long, and you’re like me, you tend to get bored and are looking for new challenges anyway. This is a great time to accept the new challenge, and either empower your team with more ownership, or use some of the slack time you’ve built up from automation or process improvement to provide more value. This is usually not a confusing move. I only call attention to it in contrast to the other situations I’ll talk about in the rest of the post.


Sam Porter Bridges carries the weight of the world on his back. Don’t do this.

Option 2: Prioritize
In the second situation, you do not feel as if you’re excelling yet. You might still be building your team if you’re some sort of manager, or still learning the function if you’re an IC. Taking on more responsibility might prevent you from succeeding in your primary job, so it’s a pretty big risk. In situations like this, I generally advise people to do what they do in any sort of situation where they have too many things to do and not enough time to do it: prioritize. The difference in this situation is you have to force the person asking you for the additional scope (if they are more senior) to prioritize for you.

For example, I was working with an analyst, and he got a request from an executive at the company for an analysis he wasn’t planning on. He already had a lot of high priority stuff on his plate, so he was confused as to what to do. I told him to email back the executive, show her everything he was prioritizing and how and where this request should fit in. This forces people to acknowledge the value of the work you are currently doing and the amount of time you realistically have available for work effort. If you’re more senior, you can talk about the scope you currently have and whether it might be appropriate to shed some of that scope or de-prioritize progress to accommodate this new area. That’s a very healthy conversation to have.

Option 3: Stretch
In the third scenario, there is no ability to prioritize or shed scope, and you just have to stretch your ability. It’s important to understand this is not a sustainable state. The only way stretching works is if it is short term until you can figure out how to prioritize. Not doing so will result in failure or burnout.

Triage
There are times in a company’s lifecycle (frequently described as war time) where it feels like you might be in a position for a prolonged stretch. What this really means is you need to switch to a variation of option 2 called triage. Triage actually comes from the medical field, and is a process of extreme prioritization of who to treat when you have a large number of wounded or sick, invented for wars, of course. The process focuses on helping what you have the opportunity to meaningfully help on, ignoring things that will likely get better with you, and accepting that some things will go poorly because you do not have the resources to prioritize everything. This process is mostly associated with bugs as a company always has more bugs than it can possibly fix, but I prefer to reserve its use for periods of war time when some things will fail, and you are acknowledging that beforehand.

A mistake that can be made in triage mode inside an organization is to make a decision on what to prioritize and not re-evaluate over time or check on your assumptions. Prioritization in war time is a best guess on what’s most critical, what can fail, and what might be fine without you. If you make a mistake on the latter, it may become more critical, forcing you to change prioritization. And it can be tough to remember to stop and check up on things you’re not focused on to see how they’re doing, and also to remember to re-evaluate and re-prioritize. But it’s important to do so.

—
More responsibility can be a great or a troubling thing. You don’t want to fall over because too much is on your shoulders. Being honest about your capabilities at the time and the mode you need to be operating in can help prevent you from failing by being burdened with more responsibility than you can handle. Tomorrow is in your hands.

Currently listening to Run with the Floating, Weightless Slowness to by Kelpe.

Buffing, Nerfing, and OP: What Video Games Can Teach Us About Talent Management

One of the more interesting, but less talked about, dynamics in the video games industry in the last few decades is that the product they initially ship to customers is no longer the final product. Because of online connections via mobile phones, PCs, and consoles alike, video game creators can push constant updates to their games to make them better over time in response to real-time player feedback and behavior. This makes their approach to development much more like other software in that it can be more agile and less like producing a film or a piece of hardware.

Like any change in the video game community, gamers notice, and a whole lexicon has been created based on these new abilities of game developers. One of the more common genres of video games that receive these changes over time are fighting games and shooters. If you grew up pre-internet like me, then examples include Street Fighter and Mortal Kombat and GoldenEye. If you’re, the youth, as they say, then you might be more familiar with Overwatch, Fortnite, and Call of Duty.

What these franchises do now is ship their initial products, watch the community play, and make adjustments over time. As the community plays, players and developers notice that certain characters or items are incredibly powerful, perhaps more so than the developers intended, or they change the game in some unexpected way. The community deems these OP for overpowered or OD for overdone/overdosed.

Before game developers could update their games over the air through the internet, that would mean certain characters would stay overpowered and make games lopsided if you didn’t use those characters. Players would create rules to adjust for these issues, like not allowing anyone to play as Oddjob in GoldenEye, or just blaming losses on your friend using a “cheap” character.


Oddjob was considered OP in GoldenEye because he was smaller than other characters, making him harder to hit.

What developers now do is notice these patterns and update the games over time to re-balance the game. When this occurs through over the air updates, serious gamers read through the patch notes to figure out who has been buffed and nerfed. Buffing is when a character or item is underpowered, and the developers do something to make it stronger. Nerfing is when a character or item is overpowered, and the developers do something to make it weaker. When these patches occur, the power dynamics change overnight in the game, leading to a lot of players trying new characters to see who they can gain an advantage with. This also can extend a game’s lifetime because it forces people to try new things in the game.


Cassie Cage was nerfed in the first major update to Mortal Kombat 11. Holy graphic improvements, Batman!

I find the concepts of buffing and nerfing fascinating and incredibly relevant to organizations, where employees are the players. All organizations are going to, intentionally or unintentionally, overpower people or areas of the company over time. Organizations need more tactful ways to adjust when these mistakes occur, and the buffing and nerfing of the video game industry is a concept I think can be applied successfully to organizations in this case.

So, how do founders and executives get good signal as to the current dynamics of their “players”? Video game developers watch play data and observe the community. Founders and other executives don’t usually have the same analytics video game developers have, so they need to rely on qualitative signals. Many organizations use business results and culture surveys as a signal into organizational success, and use performance reviews, 360’s, 1:1’s, calibrations, skip levels, Q&A’s, and all hands to build even more signal. If you’re not doing any of these today in your organization, start. Organizations usually know how to use these tools to identify who is doing well and needs to be buffed, and this can result in more scope, more resources, or official promotions. But our tools for nerfing are incredibly crude today, so I’m going to talk more about how to effectively nerf in an organization.

How To Execute a Nerf — Conditions for Play

One thing I want to call out about being overpowered. This is often the failure of an organization, not an individual or a team. We tend to treat OP situations in companies as a failure of the employee or team because it’s a lot easier, and we have mechanisms for those situations, such as demotions and firings. And this is typically the way organizations fix OP problems. To do a nerf effectively requires an organization to understand that it failed in structure or talent management, creating the OP situation. Talent management doesn’t just include performance management, but mentorship opportunities and career pathing. Only then, can it think about using these nerfing tactics effectively.

Nerf Tactic #1: Change the process

One way an employee or team becomes OP is because they manage a key process in some way that gives them undue influence over others. The easiest change then is to change the process to re-balance some of that power. In order to understand how to do this, you need to a) understand the process and b) understand the failings of it according to others. When members of your team that are OP manage a process, they seldom see the flaws in it because of how much control it gives them. So you have to seek out different people’s opinions in the organization as to what is going wrong. A signal that revisiting a process may be a good solution is when other senior team members complain, or if they have enough power, start opting out of certain other processes.

Nerf Tactic #2: Change the structure

Another way an employee or team becomes OP is the structure itself. This tends to happen when functions are grouped. For example, if a GM also has control of sales and marketing, they may become OP. Or if your CMO owns customer service, they may become OP. Neither of these are bad if they occur, but they may end up giving that executive too much power, so they can bully other teams, or they may not be as effective at managing either the scope or the function they’re less familiar with. In this case, the easiest path is to separate these functions or create more dotted line ownership to re-balance the teams.

Nerfing Mistakes to Avoid

#1: Don’t Wait Too Long to Nerf

The longer a power balance is allowed, the higher the chance that the organization will blame the strife on the person/team that is OP rather than the structure itself. Even when that person or team is nerfed, animosity will remain that may make the organization not want to work with the person or team, and continue to impair their performance. When you wait too long to nerf, you’re effectively destroying people’s careers in your organization, which may lead to them leaving. The worst situation is when you have to let go of someone who could have been great with a less powerful scope, but you waited too long to do it. In this case, firing or radically moving the person to something else is the only option.

#2: Don’t Change Titles When You Nerf, Especially Downward

As I said earlier, the most common way organizations nerf today is through demotions, which implies the employee failed instead of the organizational structure. If you absolutely have to change titles because the scope change is that significant, I prefer keeping the level the same, just changing the functional name of the role. Say, for example, you have a Director of Strategy, and they became OP, but you want to retain them. Changing their title to Director of Competitive Research is better than changing their title to Manager, Strategy. Why is this? The demotion indicates failure not only to them, but the rest of the organization. These people usually exit their organizations shortly after the demotion.

Organizational Mistakes That Prevent Effective Nerfs

#1: Inflate Titles

I was talking with a startup recently who hired someone to be their first product manager. They had made a mistake that happens commonly in startups — to make the role attractive or to reward performance once in the role, startups inflate the role title (to be more senior than what that role means on the market). One common example is calling your initial Product Manager a VP Product, or worse, a Chief Product Officer. When the company grows 3x and you’re now asking that product manager to manage people for the first time, these people frequently aren’t ready. Then, in order to fix your organizational mistake, you either have to change their title, which will look like a demotion to them and the organization to hire someone more senior, or try to seek out on the market effective mentorship for them to scale up their career progression faster than is normal.


In the words of Keith Rabois: Wrong.

It’s enticing to inflate titles to make people happy or to attract talent, but it removes your ability to nerf without demoting. In practice, I like to reserve C level titles for public companies and VP titles for managers of managers, though I will be the first to admit that impact is not defined by the number of direct reports. This is not always possible with companies that need their employees to do a lot of external to company work. “Head of” is a happy medium startups are starting to use, but it can still feel like somewhat of a demotion when that title is converted to, say, a Director, when a VP is hired.

#2: Confuse Being OP and Poor Performance

I want to be perfectly clear: do not nerf for poor performance! You nerf when someone was performing well, and a process or scope changed to unintentionally give them too much scope. If you have a good CMO, and you ask them to take Customer Service, and they don’t manage it well, you still have a good CMO. Change the scope, not your performance management strategy for the CMO.

What if you promoted someone to a new level, and they are not meeting it? Well, that is not following performance management best practices. You should be promoting someone when they are already performing at the next level for some time, which eliminates the risk of overpowering them. This is why you want to have career guides with clear levels and expectations for them, so you promote only when it is appropriate. Hired someone at too high a level? Do not nerf; demote or fire. Yes, they will most likely leave, which is why you want to be careful about the titles you give just based on interviews and not actual job performance. What if you have a big hole to fill in the organization and have to do it internally with someone who hasn’t demonstrated all the skills necessary? It happens, but recognize this should be more of a last resort situation.

What about people who move into new roles where they are not effective? This is also a situation I prefer not to have happen. I much prefer creating apprenticeship programs within organizations where individuals try the role for a while before they are permanently placed in that role. Apprenticeship is therefore the evaluation of whether the person can meet the expectations of the role. I recognize this is not always possible, but it’s a sound strategy nonetheless. We do this in product management at Eventbrite today. Those in other parts of the organization in good standing with their manager can work with a product manager on a project to see if they like it, and for the organization to see if they would be good at it.

Nerfing Best Practices

#1 Take the Blame

If you are nerfing an individual, it’s important to make sure they don’t feel like it’s a demotion. When announcing the nerf to your employee, make sure they know the reason for the nerf to occur, and that it is your fault, not theirs. You gave them too demanding a scope, and you’re fixing it. If you’re nerfing a team, this is usually less of an issue. Also, make sure that others in the organization that were affected by the OP individual or team know that you believe this to be your fault, and they should not hold animosity toward the individual going forward.

#2 Thank the Individual You’re Nerfing

Whether the change that made the individual or team OP was intentional or not, thank them for their effort to help the company, and say that the nerf is a way to make sure they can create a positive impact for the company with the right scope. People should not be penalized for trying to step up for the organization.

—
I think it’s incredibly important to manage performance of people and organizations. The gaming community has created a vocabulary that provides a solid analogy with corporations, allowing us to separate performance issues from structural mistakes. The more companies can separate those issues from each other and use different tactics to manage them, the stronger those organizations will be.

Currently listening to my 2019 playlist.