Tag Archives: communication

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 Autonomy Spectrum: How Much Autonomy Should You Give Your Teams?

Many people are familiar with Dan Pink’s work in Drive that to be the most productive, happy at work, etc., you need to have autonomy, mastery, and purpose. While a lot has been written about how to create purpose inside companies and crafting compelling missions, I would like to spend some time to dig into the details on autonomy. As founders and senior leaders of companies, it can be tough to understand how to give autonomy to employees and also drive toward a singular vision and commit to things that need to happen for other components of the business to work. I have found creating a spectrum of autonomy is helpful, and discussing with senior leadership and your team where you are on that spectrum.

How do you create an autonomy spectrum for your team or company? It’s helpful to start at the extremes. On one end of the spectrum, you would tell your team exactly what to do and how to do it. This is a complete lack of autonomy. On another end of the spectrum, employees have free reign to work on whatever they would like to work on. These projects may have nothing to do with the business, or could be completely aligned. That represents 100% autonomy.

Usually, people agree that neither extreme is particularly helpful. So how do you decide where in between your company or team should be? I like to work backward from 0% autonomy, and see where leaders start to get less comfortable. Let’s take an example recently from my time working with one of the companies I advise. The CEO asked me to come in and help the leadership team think through an expansion of their product. So that is step 1 of the autonomy spectrum, handing a business opportunity to the team from the CEO.

CEO: We have this opportunity for expansion (Business Opportunity)

Working down from that requirement, one executive volunteered to lead this initiative and did a bunch of research on the expansion opportunity. She talked to potential customers of the expansion, validated the pain points of this segment, and discovered a need the company could solve. So, she started settling around a vision of a new product experience leveraging the company’s existing strengths and identifying what new strengths needed to be built.

Executive: The way to attack this opportunity is to solve this specific problem for this segment (Persona and Product Vision)

The team she managed built an MVP attempting to solve this problem, and measured a lot of early usage and did qualitative research on what they had built. At this point, I stepped in to temporarily lead the product team and saw specific issues from the data and the research around the breadth of the solution, the quality of the options we provided, and the value of our solution vs. existing competitors in the market.

VP Product: Solve these four problems with the event discovery app (Problem Scope)

I also saw a team whose operating cadence matched a mature product with clear requirements rather than a fast moving team that uses research and experiments to find product-market fit. So, I created a new process that would structure them better for the problems they were facing and give them more autonomy.

At this point, we worked as a team to organize all of the product teams to work on these problems. As a leadership team, we chose not to identify solutions to these problems, but to put the product teams in charge of determining their own potential solutions. We created a weekly time where our persona would be in the building to provide feedback to our work. We also created a weekly meeting to review research feedback and experiment results.

VP Product: Test ideas with our target persona and run experiments targeting these problems (Process)

This is where we chose to sit on the autonomy spectrum. Prioritize business opportunity, vision, scope, and some process. Create autonomy for the team to define solutions and deeper process on how they want to get there. There are of course other options here. We could have chosen to prioritize ideas the teams invent to solve these problems, even come up with the solutions or how they would validate with research and experiments. There is no clear cut place to draw the line where you start thinking this way.

What is more important is to try to move the line to the left over time. When I advise leadership teams, I tell them that their goal should be to push decision-making as far down the org chart as possible. For leaders that have historically erred on the side of low autonomy, they need to understand how far they can start to push decision-making down without creating chaos. After all, Pink says that mastery is about providing stretch assignments, but not assignments employees cannot possibly be successful in. This process usually starts by moving to one additional layer of autonomy than normal and measuring results. If that is successful, leaders can be confident moving to another additional layer of autonomy. If this is not successful, then leadership needs to think about what type of training it needs to build so that this is possible in the future. I foresee a future at this company where the teams are in charge of prioritizing the problems as well as the solutions because they will be the experts from talking to our persona every week.

This is how Pinterest operated. Product teams created their own missions and problems they wanted to solve, and they were approved by the leadership team. Every six months, teams updated their OKRs to define the new problems they wanted to target and how they would measure success. No company starts there. Especially with startups, founders are used to setting the vision as well as coming up with product ideas. But as companies scale, leaders have to defer decision-making more so they can continue to move fast. The founders cannot be in every meeting nor can they be the experts on every topic.

—
Autonomy is a difficult topic to grasp inside a company. No CEO or senior leader wants to hand over the reigns to every decision to a team of varying levels of experience and confidence, but trying to make every decision stifles creativity and limits execution pace. Use the autonomy spectrum to build a honest understanding of where the company or teams you manage are and where you would like it to be over time. When you’re confident you are in the right place, communicate this spectrum and why you have made the decisions you’ve made on the level of autonomy you’re comfortable with. Employees will have a much clearer understanding of their role and can build better mastery and purpose as a result.

Giving and Receiving Email Feedback at a Startup

If your startup is anything like Pinterest, you receive a lot of email. Sometimes, that email is feedback on the things you’ve worked on. Since email only communicates 7% of what face to face communication does (with 55% of language being body language and 38% being tone of voice), email feedback can sometimes be misread. Email feedback can be given especially directly in a way that can be hurtful to the team it’s given to, making them defensive instead of receptive, because they fill in a tone and body language that isn’t there. I liken some kinds of email feedback I’ve received to someone walking in your house uninvited and starting the conversation like this:

“Man, what’s up with your door? You need to get that fixed. Oh man, those curtains are awful. Why on earth did you pick those? Is that your wife? You could have done better.”

Startups are making tradeoffs all the time. Everything is harsh prioritization with very limited resources. Employees at startups know this because they live and breathe it. But quite often, when startup employees give feedback to other startup employees, they forget that those people have to make the same kind of hard tradeoffs they do, and that might lead to some of the issues they’re emailing feedback on in the first place.

If you’ve gotten in the habit of giving this type of email feedback, a better way to give email feedback is to ask questions:

“Hey, I came across this experience today. Is it on your roadmap to take a look at this? If now, how did you come to that decision? Is there a experiment/document that explains this because I’m happy trouble understanding why this experience is this way? Here were some things I didn’t understand about it.”

If you’re on the receiving end of harsh email feedback, there are generally two things to think about. Firstly, if the email is to you personally, what I tell myself is to divorce the content from the tone, because the tone is in my imagination. A thought out response to the details of the email and why things are the way they are may seem to be annoying, but it’s worth it. What would be even better is if you point the person to a place they can learn about these things in the future.

If the email is sent to other members of your team, long term, you want to train your team on divorcing the tone as well. If you haven’t, you might need to use the email response to defend the team. Otherwise, they think you are not sticking up for them. What I do in this case is send an email defending the decisions as well as explaining them. Then, I will follow up with the email sender in person and tell them “Sorry for the harsh email. You really put my team on the defensive with the perceived tone of the post, and I felt I had to defend them. Next time, can you word your email a bit differently so we can focus on the issues instead of the team feeling like we have to defend ourselves?”

Currently listening to Sold Out by DJ Paypal.

Building Up Respect For a Product Team

An under-appreciated challenge in a tech company is creating a new product team and building it up from scratch into a valuable, high functioning, and well respected team. Having seen it done well and done poorly, much of what will make a team successful in doing this is pretty counter-intuitive. There is a well established sequence to doing this successfully in a high percentage way. There are two key components to optimize for:

  • team health
  • organizational understanding of the purpose of the team and its progress

Team Health
Team health is about trust between the individuals of the team and confidence of the team. It’s amazing how much of this is solved by having the team collaborate on a few successful projects out of the gate. It is tempting for a team to go after a huge opportunity right out of the gate, but this is typically a mistake as the team isn’t used to working with each other and won’t do its best work on its first project.

The right approach is to find small projects that have a high probability of success to start. This gets the team comfortable with each other, and they build up confidence in each other as well as the mission of the team as they see things ship that impact key metrics. How I like to prioritize projects is to forecast impact, effort, and probability of success. These can be guesses, but ideally a new team has quite a few high probability of success projects with low effort it can start with.

If you’re a team leader or product manager building a roadmap, you should be upfront that you’re prioritizing low effort, high probability of success projects to start for team building purposes. Otherwise, the team will be itching to start on high impact projects they might not be ready for. What happens when you start with one of those types of projects is that is by definition they are less likely to succeed, and with a new team working on it, that increases the project’s probability of not being successful. If the project isn’t successful, the team starts to doubt the mission of the team in general as that was supposed to be one of the highest impact projects for the team.

Organizational Understanding
Once a team is working well together and has some victories under its belt, it is time for the team leader to evangelize the team and its mission. I have seen high performance teams not do this second step as well, and it leads to things like organizational distrust and inability for the team to increase its headcount, which then impact overall team health.

So, how do you optimize for organizational understanding of a team? This depends a lot on the culture of an organization. What’s important to remember is that you need to optimize this understanding both above you and across from you. So, this means you need to increase understanding not just at the senior leadership level, but also to other peer teams of yours. This is not easy. I advise you start with senior leadership and optimize communication for whatever the way that team works. Do they like long strategy documents? Then write one. Do they have status updates? Leverage those.

Once senior leadership has a good understanding of why you exist, you need to address peer teams. For this, you need to understand how information diffuses at your organization. If product managers or engineering managers are hubs, start there. Email them directly with your strategy saying you wanted to give them a heads up as to what is going on with your team. Send them documents. Occasionally ask for feedback even if you don’t need it. Have a notes list? Over-communicate via that. Don’t be afraid to send emails about significant wins the team has had either. You also need to remember new employees and optimize for how they learn about things at the company.

There can be a tendency to just want to move fast with your team if you’re gelling and not invite feedback from other parts of the organization. This is a mistake. Lack of clarity for your team’s role outside your team can kill your progress if you’re not careful. You need to have the entire company on board with what your team is doing, or their lack of awareness could lead to distrust or roadblocks in the future. Addressing both team health and organizational understanding is the only way to have long term progress with a team in a growing organization.

Currently listening to Bizarster by Luke Vibert.

Entering Marketing at a Startup

With software eating the world, many marketers are deciding to enter startup organizations for the first time. CEOs, being told they need a brand, or to spend on paid acquisition or insert X marketing activity here, are trying to find marketing talent in a industry that has a dearth of it, so they’re happy to accept people from other industries or larger technology companies. Sounds like a win-win, right? Not exactly. The culture shock as a marketer from switching to a startup from almost any other type of company is hard to over-estimate. The switch chews up and spits out as many, if not more, people than it accepts. I’ll talk a bit why that happens and what marketers can do about it to be more successful.

The first thing you need to accept is that marketing is not understood as a function at most startups, and therefore it is not respected. These are organizations that have gotten to where they are without marketing, have probably never read a definition of marketing, and whose connotation of marketing is the seediest of snake oil sellers you can imagine. Starting from a position of distrust in a new position in a new company is never a fantastic option, but it’s where almost all startup marketers start. And they are not prepared for it. I remember a meeting my first week at GrubHub where one of the co-founders suggested firing me (referring to me in the third person even though I was there) to the other co-founder and just growing organically. The following week, I proposed doing email marketing to retain users after their first purchase and was met with a flat out “no, that’s not a good use of time.”

No one tells you to expect these types of barriers before you join, and many marketers never get past it. Marketer’s first instinct typically is to rely on the best practices argument. “But, every other company does this.” I can say from myself and watching several other marketers try it that it’s pretty much a worthless argument. If it’s a best practice in marketing, but your company thinks marketing is bullshit, then your argument doesn’t hold water. So, if best practices won’t work, you need to find arguments that will.

In the past, I’ve recommended AB testing with people, and I still do. In this scenario, there is one strategy that is almost guaranteed to work, and that is relying on data. Entrepreneurs live and die by metrics, and with most startups being founded by engineers, they trust data above all else. So, marketers first need to think about how they can generate data on their activities. AB testing is generally the best way, even if it’s pretty crude. The other is to write out a clear strategy. If something is a best practice, it’s because it’s logical. Breaking down the logic in detail can be the right way to help those not familiar with your craft why something is the right course of action. I prefer to write clear “because A causes B, and B causes C, and we want C, we should do A” type papers, but feel free to adopt your own style. In the email marketing example, I started sending emails manually and built the campaign up to drive thousands of orders before I proposed a technical solution again. It was much clearer the value then, and the project was accepted. In the Pinterest case, one of our marketers just started sending emails without telling people, and it’s now a significant re-engagement channel for us.

One caveat: don’t manipulate data for your own gain. This is a mistake I see many marketers make. In the absence of data, you need to work to generate reliable data, not appropriate available data to try to explain your impact in a way that is forced. For example, when you see a lift in metrics, I’ve seen many marketers jump in to grab credit e.g. “That’s because of our Mother’s Day campaign on Facebook!” when the campaign was only seen by a couple hundred people and only had a dozen likes. This further deteriorates credibility, as startup employees see through it. Only claim credit when you’re confident and have the data to back up your claim.

Currently listening to 6613 by DJ Rashad.

How to Build a Marketing Team at a Consumer Technology Company

I receive many questions about how to build marketing at technology organizations. New entrepreneurs hear terms like growth, user acquisition, and positioning, and don’t know where to start. This should be a handy guide on how marketing looks for a healthy technology organization and why. To start, I’ll re-iterate the definition and explanation of the definition of marketing from my The Incredible Unbundling of Marketing post to understand how we cover everything that is traditionally considered a marketing activity.

Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large.
Source.

Since that’s a mouthful, marketers tend to shorthand with a series of P’s (four to seven depending on who you ask). For products, those are product (the creating part of the definition), price (the exchanging part of the definition), promotion (the communicating part of the definition), place (the delivering part of the definition), positioning (the value part of the definition), people (the people who do the activity), and packaging (another part of the communicating piece of the definition). For services, those are product, price, promotion, place, people, process, and physical evidence.

At technology companies, the product piece is typically carved out as a separate team, and various approaches exist for carving up the rest of the P’s. The most typical is to have a CMO in charge of marketing, and two VP’s that split two types of marketing that tend to require different skills (change that to VP’s and directors if you like).

Brand Marketing
Brand marketing typically includes the strategic and soft skills of marketing. These include the positioning, the target market, packaging, and physical evidence. Positioning primarily transitions to what the brand represents for its target, which is why the group is traditionally called Brand Marketing. They also tend to include the promotional elements that are less quantifiable: PR, content, social, community management, events, campaign building, etc. To be successful in positioning and identifying target markets, market research tends to be in this group.

Growth Marketing
Also known as performance, internet, digital, or online marketing due to its heavy reliance on those areas (sometimes also acquisition and retention marketing), growth marketing typically includes price, process and the parts of promotion that are quantifiable. These include SEO, email marketing, loyalty programs, landing pages, paid acquisition in almost all forms (not just online), referral programs, direct mail, and analytics about marketing and product performance.

How does Growth Marketing work with Brand Marketing?
These two organizations need to work hand in hand, Brand marketing determines who the product is for, and Growth Marketing is primarily responsible for getting people to start and to continue using the product. Growth Marketing determines the best ways to find the target market and reach them, and they work with Brand Marketing to receive appropriate creative that reflects the positioning. Growth Marketing should see branding as increasing the conversion rate on all of their activities. Brand Marketing should see Growth Marketing as the distribution engine for their message.

What about the product?
As we saw in the marketing definition above, product is one of the key P’s that does not seem to be owned by marketing. Also, what is typical in many technology companies is that some of the best opportunities to get people to start using the product come from the product itself (SEO, virality, and landing pages are the main ones), and marketers typically lack the authority as well as the technical skills to make these changes. Product and engineering organizations own these areas. So, what has become common is creating cross-functional teams where growth marketers, engineers, and product managers work together to help growth the product. Depending on which distribution methods work best for the product, the product manager and growth marketer can be indistinguishable or the same role.

Early on in a technology company, there is so much opportunity with product driven growth, that just product managers and engineers work on growth marketing. Growth Marketing tends to emerge as product managers become too busy with core product features, when expertise becomes more of a necessity, and when channels that are less product driven (paid acquisition, email,etc.) become more important. Paid acquisition is usually only tried once a lifetime value can be established, so that growth marketers can be sure to spend significantly less than that to acquire a customer.

How should the Growth cross-functional team work with Growth Marketing?
Growth Marketing needs to become a key stakeholder in the cross-functional growth team in key areas. I have spoken of cross-functional teams before, and the key elements. As we grow, we need to expand a three to four person group to include a growth marketing lead. Not every sub team needs a lead to start. You should never hire to fill org charts, only to add additional value. It should only be where they add value, and the cross-functional team adds value to them. In many of these areas, the product manager is also the growth marketing expert in the area, so the position would be redundant. The first area where Growth Marketing should fit typically would be on paid acquisition or email marketing, depending on the company. This person would get support from the team on the infrastructure to make paid acquisition or email successful (tracking, landing pages, etc.), and this person would bring in knowledge on success from these channels that can be applied to organic channels.

How does Brand Marketing work with a Core Product team?
Brand Marketing should be an early voice in the core product development process helping to mold who the new products is for and how it is positioned. Once development is kicked off, typically the Product Marketer becomes a project manager designed to maximize launch impact of the feature and ongoing adoption, coordinating between the rest of the Brand Marketing team (PR, social, content, events, campaigns,etc.) and the Core Product team. It’s important a Product Marketer has short and long term metrics for adoption.

What does the org chart look like typically?

The Three Stages of Online Marketplaces

Prior to Pinterest, I worked on two sided network businesses my entire career, for apartment rentals (Apartments.com), real estate (Homefinder.com), and food delivery (GrubHub). As a result, I’ve admittedly become somewhat of a marketplace geek. And today is a very exciting time for online marketplaces. Marketplaces are evolving online. It’s hard to keep up with the innovation, but I’ll describe the three phases I am seeing, and why certain ones may prevail in different industries.

Phase 1: Connect buyers and sellers
This is the basic requirement of a marketplace. Early marketplace businesses like Ebay allowed you find people looking for your service if you were a seller, or find people selling what you were interested in if you were a buyer. To make this work, companies need to get past the chicken and egg scenario and build trust through their network. Things like ratings and reviews and guarantees make buyers trust they would get what they paid for, and sellers knew they would get paid if they delivered the service. Marketplaces in this scenario also had to find a way to get paid, using taking a lead generation or transaction fee for increasing the seller’s volume of sales. This phase is still in use with successful marketplaces like Airbnb, GrubHub, OpenTable, and others, but almost all are desperately trying to migrate into phase two or three right now, as you’ll see in the following paragraphs.

Phase 2: Own the delivery network
More recent marketplaces, not content to just facilitate a transaction, are actually working to implement the transaction by owning the element of bringing the service to the buyer. Marketplaces know that if they don’t control more of the experience, a great experience can be ruined by things outside of their control, supply side fault or not. Startups like Instacart don’t just allow you buy groceries online, but their workers deliver the groceries to you. Postmates and Doordash do the same for delivery food, picking up food from restaurants that don’t deliver and deliver it using their own workers. While this model is not new (restaurant delivery services have been around since before the internet), companies are now trying to build delivery networks at scale.

This is risky, as delivery networks all rely on the same pool of drivers. So, on the delivery side, marketplaces in different industries compete for delivery drivers. In a zero sum game there, it’s most likely the marketplace with the most demand wins (at this point, that’s undoubtedly Uber).

GrubHub, for example, bought two delivery services in Q4. OpenTable is moving into payments at restaurants. Airbnb is working on concierge services to improve the stay of guests. The companies starting in phase 1 see this as owning more of service blueprint, injecting their brand into the blueprint wherever possible.

Phase 3: Own supply
An even newer trend than owning the delivery network for an online marketplace is to vertically integrate the supply side of the business. Now, you may ask, what makes this a marketplace? In reality, it’s not, but from every other element, the business is designed or is mimicking an existing marketplace. Sprig and Spoonrocket do this with food delivery. They are delivery only restaurants that make their own food and have their own delivery drivers. MakeSpace and Boxbee, instead of just building a marketplace to help you find storage space, built their own storage spaces and will pick up your items and deliver them to storage and deliver them back for retrieval if needed. Margins are very different for their businesses.

The question for me becomes how far up the pyramid can you build a successful business. In many cases, owning supply will be victorious, but in many others, owning the delivery network is the best option. In other, a traditional marketplace is the best option. It will be interesting to watch almost every vertical determine the best model for customer satisfaction, scale, and profitability over the next decade.

Building Cross-Functional Teams

Frequently people ask me how our growth team is structured at Pinterest. In our case, it is a cross-functional team. Engineers, product managers, analysts, and designers all work together on shared goals. Pinterest believes the best results arise when people from different backgrounds work together on a problem. I’ve thought a lot about how to develop effective cross-functional teams in an organization, and I’d like to show how to do that successfully. These, in some ways represent how Pinterest is structured, and in other ways, don’t.

Step 1: Define Metrics
In order for a cross-functional team to be successful, it needs a North Star metric. If you’re creating one broad team, it’s a broad metric, like MAUs or revenue. I prefer creating multiple, smaller cross-functional teams that carve a piece out of the main goal, like signups or new user revenue. Then, you can create another small team for something like retained users, or repeat user revenue.

Step 2: Build the Team
A core team for cross-functional team trying to impact a metric is usually:
Engineer
Designer
Product Manager
Analyst
Potential other members:
Marketer
QA person
Researcher

Depending on the goal, you may not need many of these, or the product manager can be the catch all for analysis, research, etc. One person should be the owner of the team. Usually, this would be the person with the most context. At Pinterest, it’s either an engineer or a product manager. Ownership should seem arbitrary as the team should organically align on initiatives over time, deciding between short and long term projects, based on a shared understanding of what is likely to move the key metrics. So, ownership is more so management has one person to go to with questions than anything related to authority.

Step 3: Re-train Managers
There shouldn’t be any managers on cross-functional teams. Managers are the glue between different cross-functional teams, making sure all the teams align to the global strategy, and don’t improve their metrics at the cost of another team’s metrics, which is easy to do. Here is what some managers roles will look like in this scenario:
Design Director: align visual style across the entire application
Director of Analytics: align use of tools across teams for easy translation of data back and forth and sharing of pertinent data across teams
Marketing Director: allocate budget effectively, communicate how teams’s activities affect each other and balance
Director of Product: ensure product opportunities on one team can be leveraged by other teams, prevent disjointed product experience

Benefits of Cross-Functional Teams:
1) Improvement of cross-departmental communication: You would be amazed at how quickly individual contributors of different teams start to understand other department’s needs once they sit with them for a while and work on a shared goal. The marketer starts to understand why having dozens of tags firing is bad for the engineer. Once designers internalize the metrics from analysts, they start to work differently, and get satisfied by moving metrics instead of how beautiful their design is. The engineer sees how hard it is for the analyst to measure impact and starts to design better tracking systems and design better database storage.
2) Better ideas: The best ideas typically come from the intersection of people with different backgrounds working together on a problem. Designers, engineers, marketers, analysts et al. think differently. They solve problems differently. They have different strengths and weaknesses. Having them work together on problems almost always ensures a more optimal result.
3) Better prioritization: Instead of a product manager getting a list of requests from various teams, all those stakeholder are actively brainstorming together and measuring projects on potential impact to the metrics.
4) Increased speed: When teams aren’t spending time coordinating with other teams, disagreeing on goals and priorities, and struggling with inefficiencies, they produce results much faster.

Currently listening to Through Force of Will by Torn Hawk.

More On Building Effective Relationships At Work

I don’t think there’s anything I’ve heard people complain more about than co-workers or managers or employees they don’t get along with. People tend to categorize their co-workers as pure good or evil, leading to toxic relationships. Sometimes, these perceptions start from a simple misunderstanding that goes unresolved and grows over time. Sometimes, work styles are just incompatible. Most workplace relationship advice I had heard previously focused on getting to know the “real” person. Friendship, it seemed, was the only key to working better with these people, and friendship could only be attained by learning about people’s families, their passions, etc. This always felt forced to me, and when people attempted it on me, it felt manipulative. Also, some of the most effective teams I’ve worked on did not have this friendship. If that process works for you, stick with it. But if it doesn’t, let me tell you a story about how I learned to build more effective relationships at work.

When we hired our VP of Marketing at GrubHub, it created two problems for me. The first was I had gotten used to not having an active manager and doing things my own way. The second was I had developed a very direct style from working closely with the founders and other members of the team for a long time. As I continued my normal working style, that created problems for my new manager. She didn’t appreciate the direct tone of my emails, interpreting them as harsh criticism of her and others. She didn’t like the way I evaluated ideas. She liked short bullet points for emails. I tended to write paragraphs that covered a lot of details. Things went on like this for a few months, until she basically told me I had to change. This is a moment every employee should understand. The manager has communicated some feedback, and you can either ignore it and likely get fired, or apply it and stick around. So, the rule for building effective relationships with managers is to adapt to their style. They don’t have to adapt as they can just hire for people that fit their style.

After I adapted, I began to build a better relationship with my manager. She really valued personal growth of her team. So, as part of her process, we examined all of the issues I was having at work on a quarterly basis (which I highly recommend). When I was having an issue with a certain junior person at work, I described how this person operated, where their shortcomings were, how they needed more direction, how they responded to my requests, etc. She gave me some advice that really resonated: “Assume that person won’t change. How can you change to work with this person most effectively?”

As members of the workplace, it’s easy for us to see the flaws in how other people work. We spend a lot of energy hoping that those people will improve their performance in these areas. This is wasteful energy. While you should give direct feedback whenever possible, you can’t assume it will be heeded. So, you have to think about what you could change in how you work with someone to be more effective as a combined team. Sometimes, very simple changes can make all the difference. The only way to do this is to try different approaches and see what works and what doesn’t. Many people do this with their managers, but it’s even more critical to do it with your other co-workers. Identify the issues, brainstorm other approaches, and test them.

The Three Levels of Trust with Successful Co-Worker Partnerships

I think a lot about how to create and maintain highly effective teams. To be a part of a highly effective team, you need to have mutual trust with your team members. Many companies approach this problem organizationally, but the more I’ve thought about it, the more I’m convinced individual tackling it one co-worker at a time is the right solution. So, I thought about what trust really means with your co-workers, and found that there are really different levels of trust in an organization. I’ll break them down here.

Layer 1: Same Goals
It’s amazing how many workplace relationships never even get to this step. I’ve been lucky to work with really exceptional teams with shared objectives and aligned incentives, but the first question you should ask when trying to establish trust with a co-worker is, do you really have the same goals. In more political organizations, co-workers tend to see things as zero sum. If she gets what she wants, I won’t get what I want. This can be related to project allocation, budgets, headcount, etc. Even in non-political organizations, I’ve found other people tend to assume we don’t share the same goals.

So, what do you do if you don’t share the same goals? I have tried to break down what we’re trying to accomplish to find some middle ground. Usually, people are at companies for at least some similar reasons. If you have frank conversations with your co-workers, you can typically find those out and build from there.

Why is it important to have the same goals? If you don’t, you can never be confident a co-worker won’t undermine you/your plans, try to make you look bad, get you fired, etc. This sounds kind of rash and unrealistic, but you’ll be surprised how often these things happen.

Layer 2: Doing What You Say
Once you’ve agreed to the same goals, you need to divide work to reach those goals. The second layer of trust is having confidence that if someone has said they will do something, they will actually do it. This probably sounds minor, but it’s probably a more common problem than sharing the same goals. Co-workers are constantly bombarded with tasks, and can easily get side-tracked. Some people also over-commit regularly and let co-workers down. Some people really mean to get stuff done, then when they excitement wears off, they get lazy. If you can’t trust someone to accomplish what they say will accomplish, you will not have a successful partnership with them. Now, it’s important that you commit to this as well. You can’t have a successful partnership if you don’t care of your tasks as well.

Layer 3: Covering
A truly highly effective partnership is not just about having the same goals and doing what you say you will do, but also covering all the gray area in between what you agreed to do and what actually needs to get done. Consider a typical project. As a product manager, I may write the strategy doc or requirements I said I was going to write or do the appropriate research, and it may cover everything I talked about with the engineer I’m partnering with on the project. But, sometimes, it won’t really cover everything it should cover for the project to be a success. Not only could I have missed something, but there could be something that couldn’t be foreseen that’s really important to the success of the project. In that case, both me as the product manager and the engineer could have done everything we said we would do, and the project would still not be successful. Layer 3 is about covering for these gray areas. You want to feel confident in a team that if you forget something, your co-worker will catch it and address it. You need to be able to do the same.

It’s really stressful being in a role where you feel you need to be “always on”, and if that you’re not 100% perfect on everything you do, everything will fail. Covering is about have a team member that can pick up the slack when you miss something or when something comes up.

So, if you’re trying to build better relationships at work, think about which layer you’re at with your co-workers and how you can ascend to layer 3. If you build layer 3 relationships with multiple members on your team, you’ll execute at an extremely high level, and will be way more likely to succeed.