Many founders struggle to prioritize the seemingly endless demands on their time and attention. This post outlines a method for creating a shared resource any team can use to take stock of challenges, their primary constraints, and any must-do next steps across Go-To-Market, Product, and People. The goal is to help you better focus your time and energy as a founder and align your team around common goals.
As a founder or CEO, there are a hundred different things you could be doing at any given point in time. It’s easy to get off track with so many demands on your attention and seemingly endless things on fire. Billy Bosworth teaches a session in our Unusual Academy about how to ruthlessly prioritize as a founder or CEO to align your team and get things done. He describes the “GPP Heatmap” he came up with and used as CEO of Datastax to figure out what needed his and his team’s attention and energy.
Create a copy of this heatmap template. Take a rough pass at filling out each the Go-To-Market, Product, and People categories for your company:
It doesn’t have to be super detailed or perfect. The goal is to create a common resource for your team to work off of and discuss how to best prioritize as a team.
The pre-filled template reflects the real challenges and priorities Bosworth faced when he first joined DataStax in 2011. As you can see, he didn’t sugar coat the situation and there were a number of failures and learning opportunities to confront immediately. This heatmap became the most vital tool he used to get the company on track to where it is today.
Use the GPP Heatmap regularly as a tool when discussing priorities with your internal team and board of directors. Doing so will help clarify and narrow the conversations around topics that matter the most.
Here are some points for you and your team to think through as you tackle GTM, Product, and People:
In 2017, DataStax crossed over the $100M mark in ARR (annual recurring revenue). It was an emotional milestone to hit for the entire company and changed the tenor of everyday work. Founded just seven years earlier in 2010, the company appeared to be a classic Silicon Valley “rocketship” story — but that wasn’t the case. The DataStax journey was filled with twists and turns that required constant assessment and prioritization to confront the most important challenges at hand. Never was this more important than in its very first year.
In 2011, Billy Bosworth was approaching 20 years working with databases: everything from development to administration to working as an independent software vendor building advanced tooling. When he got the call to join DataStax as CEO, the company was just getting off the ground. In those early days, it was known as the company behind the open-source software (OSS) database Apache Cassandra, which represented a radical shift away from the database architectures of the last 30 years. Moreover, there were some 250 open-source databases flooding the market on almost a weekly basis. Market confusion was rampant, rapid change was constant, and there were innumerable choices in front of Bosworth.
With approximately 20 people in the company working from a small Series A fundraise, there was much work to be done. Bosworth needed to very quickly establish priorities in three areas:
1. Go-to-Market (GTM)
The market was moving extremely fast, and there were already two prominent OSS leaders in the general space: Cloudera (Hadoop) and 10Gen (MongoDB). As people were getting their first glimpse of what a post-relational database might look like, those were the two names they knew: Hadoop and MongoDB. Bosworth recalls:
It was a truly interesting confluence of events. First, there was definite momentum building behind these new technologies, but only in the very innovative and nerdy markets. Mainstream people were a long way from understanding what these technologies meant, and were also still a little leery of an OSS database — which made our audience the most technical of the technical. Second, the media latched onto Hadoop as “a thing” but had very little idea of what it really could do, or how it should be used. Everyone started to believe they should have a Hadoop strategy, but few could explain how they were actually using it to affect business. Third, MongoDB was gaining strong traction with the hacker crowd — scripting developers, mostly, who liked to iterate fast and furious without the constraints of a relational database. Into that world comes Apache Cassandra — a powerful but complicated OSS database that could scale and perform like no other. But it was built only for the best of the best engineers. From this swirling pool of market forces, we needed to start building a real company right away.
The list of commercially successful OSS companies consisted of a grand total of one: RedHat. No other had been able to crack the commercial code and, in 2011, many were still skeptical of OSS in general. Therefore, Bosworth had to get clarion clear on something: If Apache Cassandra was not successful, then DataStax had precisely zero chance of becoming successful.
We had to attack the market with that mindset, knowing full well that it would cause us some brand challenges down the road. The Apache Foundation does not allow commercial companies to use project names in their commercial products, or company names. Therefore, we had to invest heavily in the “Apache Cassandra” brand, first and foremost. Trying to educate the market on both Apache Cassandra and DataStax was not as easy as one might think because the OSS community is a fickle bunch. They want the project, not the company, to be successful. Moreover, when you’re coming from behind like we were, you have to prioritize the most important thing for your next 12 months. Without that, there is no year two or three to even worry about.
Bosworth’s assessment meant that DataStax needed to quickly gain credibility in the OSS world, while only thinking about its company brand secondarily. He knew this would be a problem later, but he first had to earn the right to even get that far. Some key requirements in this Go-to-Market phase were:
‣ Get associated with very cool brands who would talk about Cassandra.
‣ Start providing free, high-quality materials for the open-source community.
‣ Create target persona(s) who would absolutely need the power of Cassandra.
‣ Create venues for these newfound Cassandra zealots to tell their stories.
But there was another problem. Because DataStax was many years ahead of the mainstream market, the problems that Cassandra solved (distributed, infinitely scalable, always-on database) were only being experienced by a handful of companies in 2011. Many could not see why they would need a technology this powerful. That day would eventually come, but in the meantime, Bosworth would have to emphasize the the importance of showing Cassandra growth momentum above all else:
Whatever events we did, I wanted them to be PACKED. I wanted everyone to feel they were lucky to get a seat. If we thought that only 30 people would come to an event, I wanted a room that held 20 comfortably. If a third didn’t show, it would still feel packed. And if everyone showed, it would feel off-the-hook with electricity. It also needed to feel first-class. We were coming from behind Hadoop and MongoDB, so we couldn’t look like we were smaller or weaker or newer to the game. For our target audience, we needed cool surroundings, good pizza and drinks, and a fun environment where people would feel they were part of something special.
If DataStax could demonstrate that Cassandra was a fast-growing, very cool database used by some of the most disruptive brands in the world, then Bosworth knew they could earn the chance to move to the next phases of the company: DataStax brand awareness and, ultimately, a monetizing business model. But before that, he had a lot more work to do in two other key areas: Product and People.
There was no getting around it — Cassandra was difficult to use. Bosworth recounts an early conversation with one of the lead Cassandra engineers on his team:
Hadoop was complicated, but it’s value proposition was clear: cheap batch storage and batch analytics. We were real-time in nature, which meant we would get compared to Oracle or MongoDB. One day, I asked one of our engineers, “What would you say to a MongoDB user who is using Cassandra for the first time?” Her reply still echoes in my head all these years later: “I would say, ‘Put that down before you hurt yourself’ and go back to playing with toys.” I groaned. Not only did we have a complicated product, but we had a complicated product built by amazing engineers who took some amount of pride in the fact that it was complicated. To them, it was a sign of its sophistication and power.
Bosworth knew that wasn’t a way to win markets, especially when you’re already chasing other players. He had to ensure the engineers knew the importance of greater adoption by people who were far less talented. He recalls one of his speeches to the team:
I gathered the small company together and told them, “This is some of the most amazing technology I have ever seen. On its current path, it’s ultimate achievement will be an interesting asterisk in some Wikipedia article on NoSQL databases — right there next to 200 other entries.” I had to drive home the point that this was not a science project. If we were going to build a real company, that meant creating a product for real users who are in the middle of the bell curve, so to speak. With that corrected attitude, we took to assessing the product.
Bosworth sees this as one of the most fundamental lessons that a startup needs to learn: product-market fit is very stage dependent and can change throughout the life of a company. It was critical to first understand the GTM developed in step one to determine what kind of product was needed at this early stage. “Easy” is a meaningless term to an engineer without further context. Easy for whom? Easy for what function? Easy compared to what other database?
Some naturally wanted to have it all and pushed for the product to be as easy as the competition. However, Bosworth knew that they could not deviate too far from their roots and try to be something they were not. The danger was that the product become something in the deadly middle: not as easy as the competition and not powerful enough for the hardest use cases. The fact was, Cassandra was built to solve really hard problems that no other database could solve. Unfortunately, that came with a certain amount of complexity, no matter what. Therefore, in light of DataStax’s GTM strategy, the goal became to make the product easier relative to a given persona and use case:
‣ The user persona was a back-end engineer, not a scripting language hacker.
‣ The use case was multi-datacenter data distribution for real-time transactions.
‣ The skill set required was java and devops (not relational database skills).
With those key components in mind, the product prioritization and evaluation became much simpler, and DataStax could focus its resources accordingly.
Finally, Bosworth had to ensure that he was hiring the exact right people based on the stage of the company, its GTM ambition, and the product requirements. As a first-time CEO, this was all new to him. Here’s where he found himself:
I had been an individual contributor, and independent contractor, and a manager, then general manager in a 4,000-person company. Building teams from scratch was something I never had to do before, especially at the fast pace with which we were moving. I learned very quickly to do two things: (a) find good mentors; and (b) ask a lot of questions.
Bosworth quickly learned that there was first a philosophical choice to make. He could either build the team top-down, hiring great leaders who could build their teams; or he could start from the bottom up, hiring only people who were needed to get DataStax to the next round of funding. He chose the latter:
Hiring too far ahead of your need will absolutely crush you in the earliest stages of a company. This is where you earn your equity as an entrepreneur and early-stage CEO — you are going to wear a lot of hats. But it’s imperative that you stay close to the business. VERY close. That means only hiring a manager when you absolutely cannot handle the load yourself, either due to expertise or bandwidth. Even there, it’s tempting to over-hire. You do not need a true worldwide head of sales. You need a scrappy rep who can win your first few customers. And when you have too many of those to manage, you still don’t need a worldwide head of sales. You need a scrappy sales manager who can work as a player coach. Eventually, a tipping point will be reached and you will have to adjust to building a great team of executive leaders. But not right now.
Bosworth decided to work closely with one of his early investors to screen candidates that would get the job done for the next 12 months. After that, they would earn the right to figure out what the company would need next. This lens was incredibly clarifying.
I still remember struggling over a hire because I just did not know if he would scale with the business. That’s when I asked John, our founding investor, what he thought. His answer felt like a weight had been lifted: “Billy, I don’t know if he’s the right person for three years from now or not. Do you believe he’s the right person for the next four quarters?” I ended that conversation and immediately drafted the offer letter.
From there, everything got easier for hiring priorities. Bosworth was able to identify the key roles required for the next 12 months, determine if they were full-time or contracted positions, and then start hiring aggressively and with confidence.
By 2012, one year into the job, Bosworth had formed an open-source evangelist team that launched GTM initiatives at scale. The first-ever “Cassandra Summit” was held with over 300 people attending. Early deals were aggressively pursued by a few hungry sales reps and a sales director. The product reached a state where cool companies like Netflix and Apple were openly talking about its use in production. The open-source growth surge was underway, and Cassandra was demonstrating not only viability, but superiority in solving some of the hardest database problems in the world.
This process gives executives a framework for describing what their key strategic initiatives will be, why they chose those initiatives, the resources needed to pull them off, and what success will look like as a result. We also describe how this tool can be used to aggregate strategic plans from all executives to inform an overall operating and financial plan for your business.
When a startup has enough momentum to raise enough capital ($15–20M in the bank), they eventually reach a phase in their journey where they need to hire and onboard their first executives and build an executive team. That’s usually when they have tens of millions in capital and the founder needs to offload responsibilities to functional experts, such as a VP of Product, Engineering, Operations, Sales, and so on.
The type of business model you have and sector you’re in will ultimately determine the type of executives the company needs most. For example, if you’re building a marketplace startup, you may need to bring on a CRO to build supply and demand. Or if mission-critical infrastructure is needed, such as the real-time services required to support products like Uber and Lyft, it’s essential to have a CTO and VP of Engineering in the executive ranks very early in the life of the company.
As a first-time founder, assuming you’ve recently hired a few key executives, how do you manage those executives effectively? It turns out that managing an executive can be quite different than managing an individual contributor.
An executive’s job is to focus primarily on taking strategic risks. Each year, they should identify 2–3 major initiatives, large enough in impact to shape the direction of the company and enforce great execution against those initiatives. This is in contrast to non-executives, who you want to be focused primarily on tactical execution.
A simple analogy explains it best. An executive’s job is to swing for home runs. An individual contributor’s job is to go for base hits. Because of the fundamental difference in role expectations, managing an executive also requires a specialized approach.
Below, I outline the process and simple tool that can be used to successfully onboard and manage a new executive and an executive team. The tool gives executives a framework for describing what their key strategic initiatives will be (their home runs), why they chose those initiatives, the resources needed to pull them off, and what success will look like as a result. As an added bonus, this tool can be used to aggregate strategic plans from all executives, which will then inform your overall operating and financial plan for your business.
But before we jump into the tool, let’s talk about what to look for when hiring an executive.
Rule #1 is that you’re not looking for a consensus candidate. In other words, don’t aim to hire the person that is perfectly agreeable and willing to go along with what everyone else thinks and that everyone else likes. You’re much more likely to pick a great executive when the decision to hire that person is non-consensus.
A consensus hire is someone that everyone finds nice, agreeable, and low risk. Sure, we all like working with people we enjoy being around and that behaves amenably. But the risk with an agreeable executive is that person won’t take the risks required to hit a home run. Instead, you’re looking for someone with non-consensus ideas because they’ll have the appetite for risk that’s required to sometimes change the outcome for your business.
With non-consensus executives, you kind of love and hate the person. Not because they’re a terrible person void of integrity who treats people poorly, but because their approach is risk-seeking and that introduces discomfort. You don’t necessarily like all of their ideas and suggestions. Some you really dislike. But a few open your eyes a bit and make you think “Hmmm… I hadn’t thought about that… but that sounds like a big opportunity.” These are the sorts of executives that you want to hire. They are willing to go against the grain in some situations and move forward in the face of uncertainty because there may be a large payout that comes from taking a calculated risk.
Again, you want them swinging for the fence. They may only be right 3 out of 10 times, but the 3 things they were right about could lead to a step-change improvement in the performance of the company. Perfectly agreeable consensus executives are much less likely to produce the same outsized benefits because they don’t take enough risk.
Assuming you’ve now hired the non-consensus executive that has a tendency for taking intelligent risk, how do you onboard that person and set them up for success? To do so I like to use a straight-forward template that requires the executive to succinctly describe what their operating plan will be.
First off, the executive should do their 30-day review where they reach out across the organization to learn as much as they can. After concluding this 30-day lay-of-the-land exercise, then they come back to the founder/CEO and say, “Here’s my plan.”
Ideally, what they come back with is a strategy that has 2–3 major initiatives that they find are important, along with a list of success metrics and resources they need to get it done. For instance, they may need to hire/fire or make headcount changes. They may need a budget for tools or services to lean on, including agencies or consultants. In summary, they lay out the initiatives they think the company should undertake, the resources they would need to pull it off, and the outcomes they envision if those are successful. Just as important, they need to provide justification as to why those initiatives matter.
From that vision document, they will work with their teams to develop a roadmap to accomplish that strategy.
As the CEO, your job is to make it clear what the mission and vision of the business are so you’re pointing your executives in the right direction. It should be clear to the executive what the business should look like in 2–3 years. As long as they understand that vision and you’re very clear about the overall direction of the company, the executive should be able to put together their strategy.
There’s no better tool for forcing clarity of thought than long-form writing, which is why I’m a fan of the 2 or 3-page memo. The process of writing, editing, and revising are required to arrive at the utmost clarity.
Once they’ve produced that memo, you now have a simple tool that can be used in three different ways:
Companies can choose a different cadence (quarterly, for instance), but the purpose is to be thinking big and long enough that you produce room for iteration. That’s critical because as a startup, things change all the time. If the window of time is too short, you’re unlikely to be thinking big picture enough.
I’ve seen this process go wrong in a couple of ways. The first happens when the executive does not produce a structured plan and instead jumps immediately into a medley of initiatives without a coherent plan. They start doing 5–10 different things in parallel and have emphasized busy work versus focusing on the largest points of leverage for the company. The rest of the organization sees and feels that lack of clarity and they have a hard time understanding why they are working on certain projects, and how it all fits together in terms of the direction of the company. And they’re definitely wondering why this person is in charge.
The other failure mode is the agreeable hire that isn’t willing to take risk. You’ll have a very clear sense of this as soon as you ask the executive to draft their strategy memo. You may find that all of the initiatives laid out are too incremental in nature. Not enough risk is being taken and as a result, the impact of their stated initiatives is quite small. For this reason, it’s sometimes useful to have an executive candidate write this type of strategy memo as part of the interview process. You can feed them background context on the business and then ask them to produce a memo to assess their clarity of thought, ability to think through execution nuance, and how risk-seeking they may be.
I’m a believer in early and often communication with executives at least once a week. When you do a check-in, it should be rooted against this plan that they produce. For example, if they say they’re going to build three new product lines and they need to hire 20 engineers, 2 PMs, and 2 designers to pull it off, I would know that the biggest bottleneck is hiring. So each week, I would say, “What are you doing on recruiting?” And if it’s 1–2 months in and I don’t see them building out a team, I know I need to be focused on helping them recruit. Or, worse, I may be working with a bad hire that I’ll soon need to replace.
As an early-stage company, you might just have one or two executives. You may only be able to execute one or two initiatives in parallel as a company since the engineering team is 5–10 people But that’s ok. Your strategic plan would be very simple. In this case, the memo format is even more helpful since it is forcing clarity of thought down to one or two initiatives since that’s all the organization can support.
If you have too many initiatives, you’ll spread the team way too thin and be slow to execute with a very small headcount. So it’s ok for an executive strategy to just be focused on one thing for the next six months. If you pick the right targets and dogpile resources into them, that’s when you produce the most output for the business, and with this memo format, you’ll have a simple tool you can use to make it happen.
Running a board meeting is an art and a muscle you build up over time. It is also part of being a great founder/CEO and critical to learn. This guide breaks down how to communicate with your board and capture the key performance indicators for your business to keep everyone aligned.
Learning to lead the board is part of becoming a world-class CEO and founder. Hopefully, my perspective as an investor is helpful to other entrepreneurs at early stage startups who are learning to manage investors and boards for the first time. I think in some ways it applies to seed stage entrepreneurs too, who may not have official boards, but do meet with the investors on some regular cadence.
Timing: At the Series A stage, you should have the board meetings every 6–8 weeks. Duration ~2–3 hours (not more).
Purpose: Don’t think of the board meetings as a time when you and the team are meant to present your “progress report.” The board meetings are for the CEO and the executive team. It is the occasional opportunity to step back and think about the strategy of the company and its main functional areas. The goals are to ask:
These meetings are an opportunity to get feedback from the board — who in theory should be people you value input from and trust. If you don’t do this step back every 6–8 weeks, I guarantee you won't do it enough because the day to day will consume you. In a market that is moving fast, these check-ins are critical.
Style note: The board is always evaluating the CEO to see how it can help. You must lead your board the way you lead your team. If you aren’t leading your board, people will wonder if you are doing the CEO job well. The board meetings are not SALES meetings to the board. This is time to candidly discuss the good, the bad, and the ugly. You have an experienced board which means you will NOT scare them with anything. You are all in the boat together and the only way they can help is if they know what is working and what isn’t. Intellectual honesty and transparency about the facts of reality greatly improve your chances of success.
Board meeting agenda: The CEO should start with highlights and lowlights. In 10 minutes, give the board the update on how the company is doing in all areas. In the CEO’s own words —
If the board meeting were to end after 10 minutes, the board would have the 80/20 on the situation.
Next there should be overviews of the critical 4–5 areas.
Goals: For each critical functional area, there should be stated current quarter and annual goals that can be measured. At each board meeting, review the goals and recap how you are doing against those goals. What’s working and what isn’t?
Areas to Focus On: The key areas to cover are similar to every Seed stage or Series A funded startup:
1. Team — Show your current org chart and desired org chart. What are the open positions you want to fill immediately? Show your pipeline of candidates. What are the other key hires you need to make in the next 3-6 months? How is morale? Any attrition? (wanted and unwanted).
2. Sales Pipeline — Detail the current customer conversations in progress. What stage are they in? (Establish a qualification label everyone can understand for each stage of the sales process.) Note for each account in progress: What is required to close? What is the use case? Identify that use case which BEST fits your current product offering and be sure you are addressing a “hair on fire!” situation.
3. Product/Engineering — Produce a clear, visual timeline everyone can understand. Include dates that are tied to specific releases and the functionality you expect with each. Constantly ask yourself — Does your engineering/product road map align with the “What is required to close?” for top accounts. Are you prioritizing what your desperate users need?
4. Marketing — Review with the board the marketing “plan” for the company. Any updates on outbound activities? Demand Generation plan and targets (top of the sales funnel pipeline which includes any content strategy, PR, conferences, cold calling). What are your goals in terms of awareness? Quantify them so you at least have something to measure against. Website visits? Articles published? Qualified leads? Distinguish between who is just interested in getting educated about what you do and who has a timeline, project, budget, and authority to buy your product. Marketing is revenue creation. Sales is revenue conversion. So how is your revenue creation engine working?
5. Finance — Walk through your 12 month operating plan including monthly and quarterly targets. The board will review with you how you are doing against the plan. It is less important that the targets are precisely correct. It’s more important that you have measurable goals and can talk together with your board about whether they are right or wrong and how you should adjust.
Focus: Typically it is too much to cover all 5 areas in detail. Instead, the better approach is to give at least an overview for each of the main functional areas of the business (1–2 slides for each area). You want to keep the format generally the same from board meeting to board meeting so everyone can easily track progress. At each board meeting, it is normal for the CEO to want to do a deep dive into one key area and discuss and get feedback on the plan and the metrics. These are NOT brainstorming sessions. These are meant to be the CEO leading the thinking on the plan and talking through the metrics. And then getting feedback on the go forward plan to improve. Do you need additional headcount? Is the current leader of this function not up to the task? Why isn’t the team hitting its targets? etc.
Who talks? Who is present? Over time, the board would expect your VPs who are responsible for each area to present their sections of the board deck. Early stage founders might not have all of those executives, but that’s a great reason to spend time on the org chart and talk through the plan and timing of such hires. As you hire great VPs, you will have more time as the CEO to work on the strategic decisions for the business — which only you can do. There should be an open session where all Directors, Observers, and Executives can participate and a closed session where the board reviews sensitive matters like compensation.
Goals to Accomplish with the Series A Funds:
Team — Get you more “A players” on the engineering team and start to build a Go-To-Market team and engine with an early sales rep. Once you are clear about our desperate user and use case, you can start adding marketing resources.
Product — Understand your highest priority use case — the situation where you can land and delight early customers. Then make sure your engineering road map and timeline are prioritized based on this.
Sales Pipeline — Clarity on which conversations are just conversations and those that are likely sales in the next 90 or 180 days. Life and death difference between “we are excited about what you guys are doing and want to learn more” and “we have to have that ASAP.” If there is one thing startups get wrong, it is having “happy ears” and thinking customers really want to buy, but not qualifying what it will take to actually close a deal.
Reference Customers — You need early evangelists. The accounts that use your product and want to tell everyone how happy they are about the choice. Aim for 5–10 of these in the next 12 months. It will take iterations with them on product to make sure they are thoroughly delighted with our solution. You simply can’t add aggressively to sales expense (headcount) until you have those 5–10 delighted customers. The worst thing a founder can do is add to sales expense too fast before the product is showing signs from customers that they’ve nailed it.
Lastly, remember that there is no one right style or way to run a board meeting. No one is perfect at it starting out. Running a board meeting really is an art and a muscle you build up over time. But it is part of being a great CEO and critical to learn. Communicating with your board and capturing the key performance indicators for the business in a way that explains what is happening is essential to success.
Jason Warner is Venture Partner at Unusual Ventures and current CTO at GitHub, where he’s been for the past three years. GitHub was acquired by MSFT in June of 2018 for $7.5BN. Prior to joining GitHub, Jason was Head of Engineering at Heroku, Canonical, and 41st Parameter -- all distributed companies. He has a great deal of experience managing remote teams and building remote cultures, having been remote himself for over a decade. Unusual Ventures held an AMA session with our founder community where Jason shared some key advice, perspective, and tactics learned from his time leading iconic companies during normal times and past market corrections. This is a Two-Part Series
Editor’s Note: Jason Warner is Venture Partner at Unusual Ventures and current CTO at GitHub, where he’s been for the past three years. GitHub was acquired by MSFT in June of 2018 for $7.5BN. Prior to joining GitHub, Jason was Head of Engineering at Heroku, Canonical, and 41st Parameter -- all distributed companies. He has a great deal of experience managing remote teams and building remote cultures, having been remote himself for over a decade.
Unusual Ventures held an AMA session with our founder community where Jason shared some key advice, perspective, and tactics learned from his time leading iconic companies during normal times and past market corrections. This is Part 1 of the series.
Part 1 will cover:
Stripe, Uber, Airbnb were all founded in the wake of 2008/2009. As a small company with very low burn rate, how do we best leverage our comparative advantage in flexibility and ability? What are large companies struggling with right now that startups can take advantage of?
Great companies are formed in many different times, but particularly in times like these. Right now, if you're frugal and you're able to achieve your goals in that manner, the likelihood of succeeding is going to go way up. Bad companies spend money to achieve outcomes. Great companies are able to achieve the same outcome without spending as much. It's just the nature of hyper-frugal businesses and business in general, so it's going to be a forcing function. A lot of very well-funded companies are going to survive this and still not be great companies, and a lot of very great companies won't survive this time period unfortunately. But you put yourself in a position to survive by being frugal. If you do survive and come out the other side of it, you're likely to be a great company.
Large companies by their very nature struggle with nimbleness and adaptability, and that is something that is key right now: how quickly can you adapt to the changing environment? In the course of two weeks, every company in the world basically became a remote company. How well you adapt to that singular change will tell you a lot about what you're able to do in the next 24 months. Amazingly, some large companies have been able to adapt to the situation quickly. On the other hand, there are some large companies who are claiming to be “essential businesses” because they’re not great at change and they know that going remote would put their business at risk. How adaptable you are and how nimble you're going to be—that's really what survival will be about.
What is an advantage to starting a company during a recession?
You become more frugal by default. You understand the value of dollars way more and that is something that is incredibly valuable as you grow and scale. I think dollars hide a lot of sins and you can get away with a lot of stuff because you have a lot of money. And a lot of the last 5-10 years have basically been about raising these mega rounds and not forcing companies to become capital efficient. We're all seeing the price that's paid by that. With valuations and even exits, money alone is one of the worst indicators of whether someone has built a good business. If you had a major exit out of your career and the only thing people want out of you is your money, you have failed in your career. The same thing applies if you're building a business. If the only value you bring is because you were able to raise mega rounds and endure and withstand, but you don't actually know how to run a capital-efficient business, probably not a good business to be in. I think that's one of the biggest advantages you can all take away from this—become a capital efficient business. Understand how to become a good business. Once you do and you survive and get through this time period, you will become immensely fundable. You'll have all the money thrown at you. But now's your chance to batten down those hatches.
How did your GTM strategy change/adapt to the market uncertainty (E.g., deal-sizes, time to sell, open-source?)
It's not business as usual anymore. At GitHub, we made an initial plan, but we're going to wait and see how the next few weeks go to obtain more data to make an informed decision of how we will have to adapt as a company. GitHub is in a very unique position. We're post-acquisition so it’s not a typical startup environment. However, I am a board member of a couple of startups and working with them through this. If you think about this as an 18 month to 24 month window, where we expect that the capital markets are a little bit more tightly closed, and you expect that your ARR might be reduced 50% or even two thirds, start modeling different scenarios there to understand what that looks like for your company. On go-to-market strategy in particular, just assume super high frothiness for the next 2-3 weeks, maybe even a month and don’t put too much pressure on yourselves or your team. You might say, "We've got to figure out what the data is actually telling us at this time. Are the deal sizes going to change or are people going to be receptive to what we're selling?" Because there's uncertainty all around. Obviously, if you're selling through a bottoms-up motion with developers, it's a much easier time for you right now compared to a tops-down motion with CIOs and CTOs because nobody knows what their budgets are going to be for a little while. Everything will change. People have to get approvals. Microsoft just instituted for the first time an approval process for over a certain amount to be spent, which is unheard of, because they needed to batten it down too.
Do you see enterprise customers now being open to discussing deals completely offline?
I think some people will permanently be changed, and some people can't wait to get back to getting in their office and doing business as usual. The best companies in the world will never go back to business as usual as they had before. The ones who do go back to business as usual are the ones who are aging and dying slowly. That's a very strong opinion because I think that most companies are too slow to adapt to the changing environment, and the changing environment is being distributed by default anyway. In the meantime, everyone has to adapt and figure out how to do deals remotely. A lot of people are holding out hope that this is a two or three week thing, and I think that they're trying to wait it out as well. I think that we're talking about a multi-month, possibly rest of this year type of scenario where it's not business as usual. Now it doesn't mean that we're all quarantined and we're all sheltered in place, but I don't think that we're getting back to business as usual the way that it was before for the remainder of the year.
I think businesses' appetites to consume technology and purchase it all virtually is definitely there. I do think you're going to have a maturity curve where companies that are probably between 200 and 1,000 employees will be more apt to purchase a piece of software remote and then maybe above that, it's going to be a little situational depending upon who you're working with or potentially the industry or the vertical. But we had teams doing millions of dollars a year where it was not rare for them to not meet with their prospects in person. I think the other thing too is you think about your responsibility in the current situation to actually close deals. Your job would probably be to make it so it's a no brainer for them. Remove the obstacles to saying no to get them to say yes. So, if you have found that the customers that you serve are uncomfortable because they don't have the budget, make it so they don't need to go ask for the budget or something like that. Or if you're uncomfortable because they're so traditional that they need to see someone in person, find a way to make it so that they don't need to see you in person, whatever is needed. If it's education or a lot of these things, lean into relationship investment. Or if they need to physically feel a product because that's what you're selling, ship them a whole shit ton of product. Figuring out a way to make the sales process more comfortable for them. So flip it from what they're going to change behaviorally , to what your responsibility could be to get them to that point.
With conferences getting canceled, what are effective ways to compensate for the dip in leads?
I would over communicate to everybody in the organization, your board, and executives that conferences are getting canceled and that you're going to change tactics to find new leads and are looking for other ideas from your organization and/or your board. When you think about sourcing leads, obviously, the more diverse source of leads you can find, the better. I think it's a good time to revisit how conference-driven you want to be for leads, or you could change and become more of a bottoms-up motion or a tops-down.
If you had an event that was set up, and you were going to do a presentation, you had a finite target audience. I'd look at things where you could take that and turn that into some sort of asset. A lot of the companies are writing e-books and codifying their expertise into content they can post online. Maybe it's something that you can then drive either organic or paid traffic to. Now, it's an asset that can be long-living and last longer than that event. Basically, it's like thinking about it from a channel perspective. You don't have the direct channel, but you still have the indirect and online channel, and you can still think in terms of building assets that are marketing assets that can then drive leads. These assets can then be used in any outbound sales to help spur conversations with prospects. Use this opportunity to become the known expert in the area. By codifying it, you then can more easily broadcast it, and you could reinforce that you're the expert in whatever your domain is.
If you’re able to find an attendee list or potential attendee list for the event, you can also still reach out to them. You can use the outbound through LinkedIn or email and say, "Hey, we know this conference was canceled. Saw you were planning on attending. We're still plan to do our session, but over Zoom." Give your outreach a two-week lead time and then say, "Hey, we're going to run our session virtually. We'd love to have you in attendance, even though the event itself has been postponed."
How do you see agency engagements being impacted? What considerations would you make in terms of negotiation tactics during these times of forced remote work and uncertainty?
Everything in life has always been negotiable, but everyone is more willing to negotiate now. I don't think that you should think of it as off the table to have negotiations because you've got financial pressures—they've got financial pressures; everything is available at that point. Don't use it as a moment in time to become gross. This isn't a moment in time to just go in and fleece the cupboards. I always think that all of these long-term arrangements should be equitable. Agencies will struggle in this time period, and so there will be opportunities to engage with them, just like you're going to have a glut of talent on the market. If you're in a position to hire people in the coming months, you're going to be able to pick up some top talent. It's just the nature of what's about to happen to everybody, so just be ready for those things.
How do you balance striking the right tone with various stakeholders?
Similar to the advice I give in normal times, you as a leader of your organization should be intentional about the type of organization you want to be and how you communicate. Being empathetic and having situational awareness is Leadership 101 from a communication standpoint.You can try to overthink it, but in times of crisis just like normal communication, you're going to make some people angry no matter what. You're not going to satisfy every group of people or every class of person by doing something on a good day, but in crisis that'll get worse. I recently said something that annoyed a group of people and I was fine with it because the thing needed to be said. I would have said it on a normal day. I was a little bit more empathetic than I normally would be, but I was still trying to strike that tone and balance. Ultimately, at the end of the day, you can't get bogged down all the way one way or all the way another.
How do you address this question: 'Will there be layoffs as a result of what's happening in the world?'
People’s worst behaviors or mindsets get magnified in a remote environment. Everyone's going to assume that layoffs are coming, and if you don't say adamantly no, people will assume the worst. The rumor mill is going to start. You can't say affirmatively no because if you do say affirmatively no, and you do have to do it at some point, you become a liar. People do not give people the benefit of the doubt in these types of scenarios. I think you just need to be transparent. Be super, hyper-vigilant, and transparent with your folks and say, "We do not intend to do layoffs. Here's our numbers. Here's our revenue. Here's our run rate. Our confidence is we'll be checking in with you on a regular basis. If it doesn't dip below X number, we don't have to do make cuts. And I'll be hyper-transparent with you all on this." That's the best way to navigate that situation. If you do have to do layoffs for whatever reason, don't do trickle cuts. Measure twice, cut once. You don’t want to have to go back and do that again because the second time you do it, everyone expects there to be a third time or a fourth time.
In these times of uncertainty, what is some tactical advice to ensure morale of the team remains high?
Morale sucks. It's going to suck. People are going to be worrying about their jobs. They have stressed home lives. I have been working remote for 10 years, and my home life is different now than it was while I was working remote because I've got three kids at home now. It's different. It's not business as usual. Winning solves a lot of morale problems so find those things to celebrate. It might seem trite in a normal course of business, but celebrate them. Find the small moral victories if you can and celebrate them on a regular basis. Find the examples of your culture that you want to reinforce. Celebrate that person and the achievement. Take a little bit of money and do some of those swaggy type of things to try to build some of the tribal nature. Be more thoughtful about it. Go and talk to somebody that you might not talk to in the company normally, and then just ask them some questions and get to know them. I have sent a lot of text messages or placed phone calls in the last couple of weeks, and they're all just healthy check-ins. Make time to do that. But I think the spirit of winning solves a lot of those problems. Find the small wins and the victories and celebrate those things. This is a part of scaling as an organization too. When you're two people versus 5,000 people, the first customer you get with a $100 check, you're like, "Oh my God, we got it." Now as a behemoth, you don't celebrate until it's a $10 million deal. Somewhere along the line, all of those expectations change. Well, now start rationing them down, back to where they might've been two steps earlier, and celebrate them. Maybe it's the completion of a sprint, and things went just slightly better than they normally would have. Awesome. Let's celebrate that a little bit.
Editor’s Note: Jason Warner is currently the CTO at GitHub where he’s been for the past 3 years. GitHub was acquired by MSFT in June of 2018 for $7.5BN. Prior to joining GitHub, Jason was Head of Engineering at Heroku, Canonical, and 41st Parameter -- all distributed companies. He has a great deal of experience managing remote teams and building remote cultures, having been remote himself for over a decade.
Unusual Ventures held an AMA session with our founder community where Jason shared some key advice, perspective, and tactics learned from his time leading iconic companies during normal times and past market corrections. This is part 2 of the series.
Part 2 will cover:
Can you talk about how to approach headcount planning with the given uncertainty, when there is runway and some key milestones to hit on the product roadmap?
When it comes to headcount planning, ask yourself, "What's our burn? What does 18 or 24 months look like?" If I were running a venture-backed company, I'd be thinking about basically making it through 18 to 24 months. What does that look like? That's my first question I want to ask and answer. I’ve been through '99 and 2000 and '07 and '08. I've experienced a couple of market corrections. In some cases, depending on where you are on your funding and maturity curve or your customer base or ARR, it might just be about survival. And if that's the case, understand that and be realistic. If it's not about survival and it's about acceleration and thriving, understand where your competitive advantage comes from and how you're going to thrive and get better through this. If you're a later-stage company at this point, you could focus on becoming more efficient and making your communication pathways better and becoming a better company. But if you're a seed or A stage, it's cockroach time to some degree. You have to get hypervigilant about your burn.
Tactical advice on hiring strategy (possibly remote team) in the current environment, especially if you're just getting off the ground and running with your MVP team?
You're going to have to get really good at remote interviews because you're never going to see this person if you plan to hire them quickly. You're going to have to find questions that allow you to feel comfortable with that person pretty quickly. I am super expressive on video calls with my face. I try to express my emotional state with my eyes, my face, my hands, and I get overly dramatic. It's intentional. I’m trying to convey what is happening here, because it's a lot easier in person, but over video, no matter what we think, it's a little bit harder, so overdo it. Expect that the other person's not that good at it and that it’s your job is to pull out who that person really is. For your interview process, if you're 1-2 founders and you're interviewing for new employees, I would recommend you do the interview together, because you're going to want to coordinate your information with the other person with the same context. Individual 1:1 phone calls don't allow you to calibrate, and you want to calibrate now more than ever on hiring decisions. I do think that projects are useful, but might be harder at the earliest stages.
Would you change any part of your interview process if you were not able to meet a candidate in person before making a hiring decision?
Not necessarily. You just have to be a little bit more adaptable to the human element of someone being remote. 30/60/90 presentations are great, which you can still do remote. Having someone do a presentation followed by a Q&A session still works really well remote. There might be awkward silences at times so you have to be mindful of that and help candidates through those situations. Fun fact—I did my entire interview with GitHub remote (except for meeting the founder once in person). The process included a presentation that I gave multiple times to the GitHub exec staff and the investors—all virtually. So it's very possible to run an effective interview and hiring process entirely remote.
Any tips for onboarding people remotely?
Onboarding people remotely is hard. Your onboarding goals should fit whatever their role is. For instance, if they're a developer, you want to get them pushing code as quickly as possible. Think about their onboarding in the context of what they need to get that done. Try curating a ticket or a project for them to execute quickly. Going through that process will help them to understand how work gets done at your organization and how to communicate along the way. I do think that if your company is large enough, you should assign an onboarding buddy for them for their first 1-2 weeks. Their job as a buddy is to have a daily standup with them and say, “Here's what you're going to do or how you're going to do it. What questions do you have? Let me help you with a couple of those things to break the seal.” If you're big enough and you have an onboarding class of people, you should have a person who handles the class so you can onboard the entire group of people and make sure that experience is consistent and positive.
How do you share our team vision, values, and culture with new hires?
I feel very strongly that the habits of a distributed company are the ones that make great companies in general. My advice here is the same that I would give to a co-located company or distributed company. It's all about communication. I feel very strongly that the best companies in the world exhibit a couple of traits. They understand their mission and vision very distinctly. Everyone in the organization knows what that is, and they're able to know how they're going to make decisions in line with that mission. Think about your communication channel inside your organization as a feed that looks like this:
There’s the CEO at the top left. Your job as a CEO or a senior leader in the organization is to provide the mission, vision, context, and build the pathways that communicate all the way down to the marketers, engineers, devrel team, etc. You’re communicating those values, those contexts, and the “Why’s” in the organization. Then, on the way back up, you want to create a feedback loop. That includes project status and making sure that things are progressing. You need to build those mechanisms. Now, your job as a CEO is to close that “V” as much as possible to create that tight feedback loop. The sooner you are able to provide the context, clarity, and vision and get the feedback loop that things are progressing, the better your company is going to be. You're never going to get to a straight up line. However, the further you get away and look more like a horizontal line, the worse your company's going to be.
How would I go about closing the “V”? Particularly in a distributed world, I would write it all down. I would provide a lot of the context around why we're making this decision, who we're going to do it for, and in what timeframe we hope to achieve it. The job of any leader in an organization is to make the set of decisions that only they can make and to empower the people below them to make all of the other decisions that can be made by others. That's how you achieve scale. So if you are able to do that and you're providing the context and the autonomy for those groups to make those decisions, you're going to tune the organization over time. Tactically speaking again, write it down. Over-communicate. Do it in multiple mechanisms, put it in GitHub; have weekly status meetings; send all company emails; put it in Slack channels. Say it once, say it again, say it multiple times, and then provide the feedback loops that things are happening. Write down your company goals, how you’re going to measure progress, and give regular updates about the achievements of those goals.
Github has been transformational for many teams in a lot of ways. Most of the founders can only dream to achieve such massive impact. How do you operate to be able to consistently deliver great quality products? What level of autonomy is given to Engineering and Product teams?
This has gone through many evolutions at GitHub over time because this is one of the ways that you grow and scale companies. It's two people in a garage vs. 5,000 people. GitHub right now is about 2,500 people because we absorbed internal Microsoft teams post-acquisition. My view, in principle, if you go back to that “V” that I mentioned before, is how I think about company building. To take a little bit of liberty in answering this question, I want to give you a little bit of history of GitHub and why some of us had success.
GitHub had massive initial success because it had a massive immediate market appeal for several communities—programming language communities, dev communities, etc. At the same time, the zeitgeist was changing from Java, J22E, to Ruby on Rails and going through a weird transition. But the product just clicked and what GitHub did incredibly well initially was hire a bunch of people who knew its core audience deeply and just unleashed them and let them go build features that they themselves wanted personally. That proved to be a formula for success. GitHub didn’t invent the pull request but it made it popular because what GitHub had really early on was this notion of taste. It knew that its customers wanted a lot of taste and it biased towards that.
GitHub then went through about a four-year period where it was terribly run. It had almost no feature releases. It famously got a letter called, "Dear GitHub'' from the open source community because it was ignoring its needs. What happened is it over-oriented too much toward individual opinion and ground to a halt where no features got released. It was a very strange dichotomy. I essentially was brought in to help GitHub fulfill its potential and get back on track. When I joined in 2017, coming on off Heroku, GitHub was basically a plane hurtling towards the ground. It was by all accounts a highly successful product, but internally it was so mismanaged and so poorly run that the numbers didn't support its valuation anymore and investors were wildly worried.
How we got our mojo back (which is the way I put it) is that we basically unleashed the teams again, but in a structured sort of way. So, I as the head of the company at this point, said, "I will make a set of decisions and then I will finetune and train the neural net that is GitHub's management ladder to make the same sets of decisions, but better than me." So I set out to give us a mission and vision. I put out a five-year charter. I said, "In five years, this is what we want to do." That immediately clicked with everyone. They understood why they came to work every day. The next step is slowly tuning the organization to make decisions that you once needed to make, but slower inside the organization at each level. Once you're able to unleash those people on the mission and vision, you're able to achieve massive success again. However, the challenge in doing that is keeping people aligned. That's why you need to make sure that that “V” is as close together as possible because the further the “V” moves away from each other, the less alignment you have.
When I joined GitHub, the "V" was basically a horizontal line. My job was to create the “V” structure again and then slowly move it closer and closer together. And I did this via a series of mechanisms, but to distill it all down: I told the organization where we were going by telling them what I wanted to do first. I told people what I wanted to see and in what timeframe. Then I started holding people accountable to achieving those objectives. And I just ruthlessly used meetings or other organizational constructs to see if we were making progress and tuning the organization along the way. I had to do it when Github was around 800 people. Today, the mechanisms would look very different because you can't use the same tools at 5,000 and you shouldn't use the same tools at five. But that clarity around communication and alignment underlies my philosophy for company building at any stage.
We usually have a lot of discussion of product design overview. We used to create documents, and then you would go with a document and post them in your white boarding sessions. Now it's getting difficult for us to do it offline. How will we make sure that things are fun and productive working from home? Any virtual whiteboarding tool recommendations?
Brainstorming is weirdly one of the harder ones to do. It just doesn't quite translate remote. I took cues from the open-source community on this one, which is to show it in code. And for developers that's easy. But get to code as quickly as possible. Use Figma, InVision, Framer —those types of tools to do a lot of the mockups and demos. InVision is a completely 100% remote design company, and that's why their tools are pretty good for this stuff. But if you're a developer, show it in code or mock code or some high level prototyping code, but get to it as quickly as possible. That is one of the habits you need to get to. Don't spend three weeks or even three days on a prototype. Get to a workable passable prototype you're willing to throw away in a couple of hours. Have a Zoom session up while you're typing away. Use VS Codes live coding sessions or other telepresence software.
For non-tech teams, I think Google Docs, InVision, Framer, or Figma with a video call is a good passable alternative for now. I use pen and paper all the time. However, when I'm doing a brainstorming session, we do it in Google Docs. iPad with Zoom and a pencil is worth a shot too.I heard of a tool called Miro where you can whiteboard virtually. Everybody either uses Confluence or Google Docs to document. If you're in the early stage, incorporating a general writing culture really helps. Many of my own decisions for my team—even stuff that's usually understood—we just write it down. And over time, you start seeing that people make those decisions and write them down a lot more than you would expect. That leads to a written down communication culture that makes a positive difference. In general, write stuff down here, document it, and ratify it. Google Docs has certain sharing and permissions issues. My rule of thumb is if it doesn't have a long-lived URL, you're in trouble. Screenshots, mockups, Figma, InVision sketches, screenshots with annotations on them are way better when they're text and those combined. It just lands orders of magnitude better than straight-up written text. Slack screen sharing is also great. When you share a screen, other people can actually just write directly on your screen and it's collaborative as well, so you can see what everyone else is typing in real time. And then if you are an engineer, the more code you can have on an online collaborative text editor, instead of just running locally, will dramatically increase how effectively you're able to communicate.
How do you handle your 1:1’s remotely?
So I've always done 1:1’s the same way, which with a shared Google Doc that we have shared beforehand that’s also in the calendar invite, alongside a video call. We open up the shared doc while we stream things during the week that we need to discuss, whether it's personal or work things. I'm not one of those people that believes that 1:1’s are all about career development, nor do I believe it's all about work. It's a mix of things. It's whatever is top of mind for everybody. A lot of the conversations now have been, “Anything that's on your mind? How's the home situation? Is it different? Is it causing you to have any sort of stressors?” Once you acknowledge the human to human factor, most people want to move on and actually get back to work discussions. They just want you to acknowledge the human side of things a little bit more in light of COVID.
Can you share your weekly cadence with your remote teams?
My weekly cadence doesn't look that dissimilar to the in-office stuff that I would do. My Monday is just executives basically and we conduct exec staff, and review meetings, including a product review meeting, go-to-market review meeting, and marketing plan review meeting. I also do a couple of 1:1’s with other execs on Monday. These can be monthly, bi-weekly, or weekly, depending on how much I need to interact with them. Tuesday is staff. I'll do my staff meeting and then my review meetings, such as an infrastructure review meeting or security review meeting. The review meeting is a chance for those teams to come and present what they're working on, whether they're the boulders or the rocks or big initiatives or whatever, and get feedback from me. I call them my “editing meetings” vs. my “author time”. I'm basically being presented with a whole bunch of things and I review them. Then I do all my staff 1:1’s. I try to get them all out on Tuesday, so that my week is front-loaded. Wednesday and Thursday, I have work time, and Friday is mostly review—we do demos or reviews of things that have happened that week that we need to course correct, make decisions on, or adapt for the next week. I bifurcate my week so it's heavy on exec on Monday, my staff on Tuesday, review meetings, course-correct with planning, and then review on Friday about what we achieved and what we didn't achieve. And then what we might have to correct for Monday. As for tools, I use GitHub, Slack, and Zoom. Those are the big ones. Google Docs for shared collaboration. I very much encourage everybody to pull up a Google Doc and co-write things as you're doing it. Don't take notes locally here, take notes in a shared space. My 1:1’s are tracked in a Google Doc. We do that so both of us can see it at the same time. We memorialize decisions in GitHub, have the one-off chats in Slack, and then take it to video as quickly as possible with Zoom.
What strategies have you found most effective when dealing with communication barriers due to timezone differences? (e.g. 12 hours gaps)
Communication is incredibly important, now more than ever. I break it down to three communication channels (not counting email). Type 1 refers to channels for storing institutional memory, ratified decisions, and things of that nature. A good example would be Github. Type 2 is for high bandwidth communication like a video call or Zoom. Finally, Type 3 is for more casual, real-time chatting like Slack or text. If you have timezone gaps, it is incredibly important that you ratify decisions in Type 1 channels like GitHub as opposed to Slack. The reason is it's easier for team members to consume that information once they come back online.
That said, one of the best strategies to mitigate that time zone gap is to actually have timezone overlap. I have had a hard rule for many years that there can be no more than a four-hour time zone gap between teams. If you wanted to be on an overseas team, you needed to have at least four hours of timezone overlap with that team. We've got a team in London; therefore they can work with the East coast and maybe a little bit of the West coast in the U.S. at times if it was an exceptional case, but they won’t have members of the team in London, the U.S., New Zealand, and Australia. It's just not going to work out well. Too many things go wrong. Too much lag happens because you're not able to speak live when you need to. One of the most important traits that you need when working distributed is the ability to pick up the phone or Zoom as quickly as possible. Any slight miscommunication, you need to jump on the phone. But if you need to have 12-hour gap coverage as well, make sure that decisions are ratified in institutional Type 1 channels like GitHub, and that is where people consume their context from. If you force someone to scroll Slack, it’s a horrible experience. You're going to miss many, many things.
What are telltale signs someone is struggling with the remote work setup?
Telltale signs people are struggling with remote tends to be that they go for longer than expected without hearing from them, or the opposite where they reach out way too much, because what happens in a remote scenario is that the worst attribute of your own personality tends to get exacerbated. So if you're a highly anxious person, you might be worried that somebody else is talking about you when they're not. And you just have to watch for those signs. If you know your folks well enough, you can actually see those signs pop up early. On the flip side, your worst attributes as a manager are probably likely to come out too. So if you tend to be a micromanager, in our current scenario, you're likely to be an extreme micromanager. And that's probably going to cause all manner of problems, too. It’s important to understand what your failure modes are and know if you're over exhibiting them in a remote environment.
Especially if you're working full time remote or even just during the time now, how do you keep a line between home life and work life? How do you delineate between the two if right now everyone’s lives are pretty combined.
I'm an "always on" person. It drives my wife crazy. One tactic I’ve found to work is picking a couple of times when nothing can interrupt you except for something literally being on fire. And so I've picked dinner, bedtimes, and my workouts. Those are my three times that nothing can interrupt me and I've had to set boundaries pretty stringently. As a matter of fact, I got called by a boss once and I missed it while I was at dinner. When I called back I said, "Hey, I’m at dinner." He said, “But when I call, you pick up." And that was a chance where I could educate him that wasn't going to happen. I was at dinner, I was not going to pick up, I will call him back right away and if he needed something in the moment and it was super urgent, he can text. But there's very few things that he needs at the moment. So, I was just using that as a time to set the expectation. But I have had to pick three times to keep a line between home life and work life and my wife has to hold me to it.