Startup Hiring

I’ve been helping a few startups with hiring, have hired large teams and have been a candidate on the other side. Labor is getting more and more competitive and the best candidates have lots of options so it’s important to have a good process.

To hire the best people you need to see a lot of good people (top of funnel), select the best and win them over the other options they may have.

Here is how I recommend you run your interview process regardless of the role:

  • Leverage networks: The best way to get quality candidates is to leverage your network of investors, advisors and existing employees. Good brands (team/investors), good PR and good written content can also attract candidates.
  • Screen: Arrange a screening call with someone on your team who is directly responsible for running the recruiting process. This could be the hiring manager or a recruiter/HR lead depending on the size of your company. If you’re going to scale quickly, then someone who can lead recruiting and HR is a very good investment and takes pressure off the operators. Skip this step if the candidate comes from a trusted source or you need to move fast.
  • Clarity: Once candidates pass the initial screen (skills, fit) then provide clarity on the recruiting process. What skills are you testing for? Who will the candidate meet on the team? I suggest doing this via a templated message with a bit of character. It displays organization, transparency and builds trust.
  • Skills: Decide what skills are important for the role and explicitly agree (in writing) on them as a team . Each interviewer should know what skills they are assessing and multiple interviewers should assess the same skill (to find disagreements). Look for candidates that have at least one “A” skill. “ABC” candidates are better than “BBB” candidates because it’s often easier to build complementary teams than move someone from a B to an A. You should bias towards candidates with a “high ceiling” over relevant experience especially if you’re doing something new – experience becomes outdated faster than you think.
  • Questions: Pick questions that test for the explicit skills you are looking for and ask the same set of questions to each candidate (reduces systematic bias, and helps calibrate). Don’t be afraid to ask challenging questions. The best candidates will enjoy this process and it will help with closing if candidates feel they will learn from and enjoy working with their colleagues.
  • References: Use references (backchannel or formal) as a confirmatory signal. Ask more open ended questions (gauge depth of relationship, strengths, areas for development) but also understand the candidate’s percentile relative to others in a similar role and if the referencer would work with the candidate again.
  • Offer: You have 5 levers to use when making an offer: title, salary, equity, responsibility, and one-off payments (e.g. signing bonus or relocation). Ask candidates what they value and why before making a specific offer, as it’s another opportunity to build trust and tailor the offer for the candidate. Title is a cheap lever unless you are recruiting for a “head of” position, as it’s harder to hire above this person. I prefer candidates who pick equity and responsibility over anything else as it aligns long term incentives but also understand that everyone’s circumstance is different.
  • Winning: When a candidate has multiple offers winning can be challenging. If you have a organized, transparent process with smart, kind interviewers it’s a great way to build a trusting two-way relationship even before the candidate joins your company. You should leverage your network of advisors and investors to close candidates, but this is not a replacement for running a really great recruiting process.

This was designed to be a general recruiting post, but read this post for more detail on hiring product managers, if you’re interested.

The “Why” Behind Work

Aligning on “Why” for product development work is always important, but it’s especially important for distributed teams. When the “Why” is consistently missing, projects end up feeling like a list of context free tasks from ‘up above’ and teams can become demotivated and resentful – no one likes being told what to do all the time.

In synchronous, in person cultures, understanding and reenforcing the “Why” happens more organically in corridor conversations, social time (lunch/after work) that colleagues to have conversations about the reasons behind their work more naturally and transfer energy and enthusiasm to each other (also an important lever for leaders). As a leader, it’s easier to notice misalignment or lower motivation because you can ‘feel it’ and course correction can happen faster by grabbing a room talking through something and emerging with a decision.

In distributed, asynchronous cultures it’s very important that the people doing the actual work have a strong understanding and believe in the “Why” and are rowing in the same direction because detecting misalignment can be slower. This is amplified in importance if you are changing product direction and focus or are working on a new product (with lots of potential directions).

As a leader of these teams, you need to put systems in place to understand if people have a shared understanding of the business or user problem they are solving. Include your teams on the journey towards the decision (to improve shared understanding and acceptance) vs. just communicating the decision in isolation. I would try over-indexing on time spent on the user and business goals with more space reserved for discussion upfront for new projects. The contributing teams need to be able to express concern, propose alternatives and build motivation for the problem space. This can admittedly feel slow, but over the long term it’s better for both the people and the product.

I’d suggest experimenting with more rich media (audio, video, pictures) to allow people to understand your thinking as a complement, not a replacement to longform text which is still the most important as it’s easy to scan, indexable and searchable. I’ve been experimenting with quick Loom Videos to give product feedback or sharing a short video colleagues (in addition to a bullet point summary) to transfer more context of sentiment and detail across, whereas previously I would have defaulted only to text. I think this helps communicate with more personality and context but also preserves some of the benefits of async communication and culture.

As a leader, try not to be be a taskmaster. When you’re trying to align teams, try to have them write the “Why” documents and determine and justify own problem spaces (with your guidance). You can guide and get alignment by asking questions to shape the problem spaces and making decisions about priorities. Being a taskmaster creates single person failure risk (you) and ultimately leads teams being demotivated over the long term. Having to do something ‘because someone senior said so’ is deeply unmotivating over many cycles. There are periods of ‘War Time‘ where being a taskmaster is appropriate, but should is not the case for business as usual work.

We all have to execute things that we don’t fully believe in – it’s just part of the nature of work. In these situations state your position clearly but ‘disagree and commit’ if the decision has been made. When you communicate the problem space and the “Why” to your teams, emphasize on the components you actually agree/believe (versus the areas you don’t), as your team will be able to sense authenticity and energy.

In summary, as a leader of distributed teams, it’ll pay long term dividends to focus more on “The Why” upfront especially for new projects or when you’re changing directions even though it may feel slower at times. Plan for more time and space to get all folks involved to understand the rationale (user and business) and build motivation for their work whenever possible.

A good book on this topic is Simon Sinek’s “Start with Why”.

Measuring Productivity of Distributed Teams

Measuring productivity is hard, especially for knowledge workers and craftspeople who are building software products. 

People are typically the most expensive asset for technology organizations, yet it feels like the internal systems for defining and measuring productivity are archaic and don’t match the methodical approach we use for external product development (iterative, data+gut) in customer facing products. 

As more of our work happens in the cloud (and distributed) we are now able to actually record contribution and interaction in a way that was impossible even just a few years ago. 

This post is not meant to be an ‘answer’ but a set of early thoughts (from someone who runs a distributed team at scale). I’m excited to see how our work evolves, and how our tools evolve to power more productive global and distributed work. 


Defining productivity

  • How do we define “productive”?
  • How do we think about this at both an individual and a team level?
  • How do popularity and personal (and cultural) bias factor into this?
  • How frequently / over what time period should we measure productivity? (Creative work happens in phases)

These are hard questions, and I don’t have clear answers, and I think there is room for improvement across the industry for in-person, hybrid, and fully distributed teams to define and measure all of these better.

In my mind, productivity is a function of volume, quality, and impact. It’s easy to say this, but these are all hard to define, track, and attribute which is why this is still an unsolved problem.

The most productive teams can have no outstandingly productive individuals, and the least productive teams could have exceptionally productive individuals. It’s hard to actually parse individual productivity when running a larger organization.

As managers of managers, we don’t have sufficient tools to be able to understand most of this and most of our information is driven by sentiment and infrequent interactions with individuals on our teams.

For in person teams, productivity is often a function of time spent in the office combined with their team’s sentiment/perception of their work (and likeability) which is imprecise, and polluted by biases and proxies for actual productivity.


Measuring Productivity

To measure productivity of teams and individuals, we should look to both quantitative and qualitative measures. I prefer measures that apply to individuals but can also roll up to both teams and projects.

Quantitative metrics

Quantitative metrics to measure productivity can be hard to pick, measure and implement in the organization. These types of metrics may make employees feel ‘watched’, don’t tell the full story, and could encourage suboptimal behavior to gamify metrics.

Defining quantitative metrics that can roll up from individuals to team level and project level metrics are best, because it allows us to have the most flexible view of contribution and productivity, but these metrics are hard to select.

Here are a few ideas:

  • Volume: A measure of activity across different tools (e.g. Slack messages, GitHub commits, words on internal Wikis). These metrics will vary by team and role, and need to be measurable across tools. I don’t think more activity necessarily implies more productivity but an absence of activity likely implies a lack of productivity.
  • Quality: Quality is hard to measure. There are some heuristics we could use like rejected pull requests, bugs, live issues, comments/likes on internal memos. I don’t have a clear view if these would actually work at an atomic level without running some experiments to figure out if they are actually predictive of quality.
  • Impact: First we need to define impact (e.g. OKRs, trackable metrics). What business or user goal are we trying to achieve? How do we attribute work directly to these goals, especially at the individual level? It’s easier to do at a project or team level, but still difficult to map work to impact accurately.
  • Micro-contracts: I generally work using a series of micro contracts. I commit to a specific scope and timeframe and it’s usually an agreement between me and one other person. It would be valuable to track these micro contracts in a transparent, two player view (vs. separate todo lists) that integrates nicely with my existing workflow (e.g. a Slackbot). This is a feature, not a product, but it would be useful to capture data (e.g. missed, delayed, complete) on this over time across the organization.
  • Engagement: We have an internal tool called P2 at Automattic (replaces email) which we use to write and store long form content and share it transparently with our colleagues. Much of my work as a manager is engaging with these P2 posts, leaving likes, comments and asking questions. We track some of this data internally, but don’t have a great view for managers to look at aggregate views for individuals, teams or projects (which would be helpful). 
  • Project Iteration: I strongly believe that speed of iteration is a sustainable advantage for companies, and many companies lose this speed as they grow. Something which captures progress towards stated project goals, as well as the project state over time, would be very helpful especially when combined with some of the other individual metrics listed above.

I’d start by tracking all these metrics individually (and creating a time series for each) and then worry about creating compound metrics later, for the metrics that are most accepted by the organization.

Qualitative Metrics

Qualitative feedback is important both as a source of positive and developmental feedback for individuals and teams. This feedback contains the most bias, but is the most widely used and accepted form of assessment across our industry.

  • Peer Review: This provides a good view of the person’s capabilities as a team player, and a measure of their ‘popularity’ with their peers. It’s also a good measure of team fit as different teams can have different microcultures.
  • Manager Review: Managers typically write regular (e.g. annual) reviews which are a useful point in time synthesis but have recency bias (something of which I’m certainly guilty). Managers don’t record all the ‘micro feedback’ and ‘micro improvements’ in a transparent way to the organization (e.g. logged in a database) which I think could be interesting to try.
  • Direct Report Review: This is similar to manager reviews, except it’s many to one for the manager. This is useful to check for consistency of feedback, which can be a stronger signal than an isolated piece of feedback which we could over-react to if particularly positive or negative.
  • Self Review: This is an opportunity for individuals to synthesize what they think is most important and impactful retroactively. I personally find it useful, and think it’s also useful to kick off a conversation with a direct report (when there is discrepancy in perception). It’s also a good measure of self awareness (if self view is very different from the others).

In general, storing micro feedback (e.g. positive/developmental plus a string), and periodic summaries (discrepancies, sentiment by group, change over time) would be a good place to start, and then HR teams could perform analysis on the usefulness and predictiveness of each of these inputs over time.


Both this qualitative and quantitative data would be helpful to both the individual and the manager to track their development and journey during their tenure at the organization. It would also make manager handoffs (team switches or people leaving the company) cleaner and easier without losing valuable organizational data.

Open Questions

A couple of additional open questions that I did not have good answers to:

  • Meetings: I almost added meeting time/number of meetings to the quantitative metrics section, but I’m in two minds about them. I think recurring meetings are a ‘lazy’ way to have individuals and groups get together and make up an agenda. Large meetings with lots of passive meetings are also very ‘expensive’ for the organization, and likely better handled via written, asynchronous alternatives. I do think there are a few exceptions (1x1s for direct reports, project kick off, strategy/direction changes) which have their place to drive alignment and build relationships. I personally like short interactions about specific problems spun up in real time but these are hard to coordinate if teams are over-scheduled.
  • Real Time vs. Synthesized: For all of these metrics, how much should available in real time vs. point in time? Real time plus history allows for better trend analysis, but point in time allows for synthesis. Point in time reviews suffer from recency bias and most creative work happens in phases (with natural spikes and troughs).
  • Transparency: For all the quantitative and qualitative metrics how transparent should this be to the individuals affected and the organization? If totally transparent, I worry about gamification but if totally hidden it feels like spying. I think it should be run as a contained experiment to see the impact on the culture.
  • Popularity vs. Objective Metrics: As humans, how do we eliminate bias? We are often biased towards people who we perceive to be similar to ourselves. We are more likely to excuse poor performance for someone we like v.s. someone we don’t. Measuring and accounting for bias is extremely difficult.

After writing this, I was left with more questions than answers, but feel confident that most organizations (distributed or hybrid) are not good at measuring and storing performance over time at the individual, team, or project level. I also think that the appropriate solution(s) will vary by company and its culture. Building tools to track performance and creating a culture of internal experimentation is necessary for organizations to get to better solutions across all levels. 

I’m personally excited about innovation in this space as a manager, and an increased focus on output over facetime and popularity as companies work in a more distributed or hybrid work environment.


As a side note, this was an interesting view on how the folks at GitLab think about this — I appreciate them being open with sharing a lot of their practices in general.

Performance Management

This post will summarize my personal learnings for managing performance in both a distributed and non-distributed environment. I recently hosted a discussion on ‘Remote Performance Management’ with engineering and product leads at other companies (through Enrich) and these were some of the topics we covered.

Performance management in a distributed environment is very similar to working in person, except you need to rely more on measuring actual contribution, and more written communication. 

It can be very draining for a team, and for managers in particular, to deal with performance issues on their teams. If these are not dealt with quickly, they can fester and affect the entire team. It is important to have a clear path to gather data, diagnose and solve for the productivity and for the ‘health’ of your team.

1. GATHER INFORMATION

Start by gathering data to figure out if there are performance issues.

Your Gut: Most of the time, you know if someone is performing well. Trust your gut and use it as the starting point. Write down examples of issues you observe in a document so you can spot repeated patterns. In a distributed environment, it can take longer to calibrate your gut – you can’t ‘feel’ the energy of a person or a team as easily, so you need to rely on the output of teams. The more teams work out in the open (public by default), the easier it is to understand their output.

Team: Ask for feedback from folks who interact with the person closely – peers, direct reports, other functions. This can be more casual or part of a broader discussion if you don’t want to cause ‘alarm’. You can also ask your HR rep to help gather feedback for you as well. 360 degree feedback tools are also really valuable for managers and teammates to give feedback on each other.

Data: Try and figure out objective measures of output – communication metrics (e.g. Slack stats, public posts and comments), projects delivered, GitHub commits can all help paint a picture of productivity. It’s important not to use these metrics as the starting point for performance management – they are simply a useful tool to help validate or invalidate hypotheses. If people feel like they are being ‘watched’ they will not like it, or try to game the system which is not where you want them to focus.

2. DIAGNOSE ISSUE

Once you have established there is a performance issue, the next step is to unpack the why behind the issue.

Capability vs. Effort : I start by trying to understand if there is a capability problem or a motivation problem and use this simple matrix. Folks who are high capability and effort should be rewarded, and folks who are low capability and effort should be transitioned out of the company quickly.

This image has an empty alt attribute; its file name is impact_effort_matrix_brainstorm_-_brainstorm.png

Manager / Team Fit: The individual may just not fit in well with the team culture or have a good rapport with their manager. Once a manager has ‘lost faith’ in someone on their team, it’s very hard to regain faith without a team switch.

Project Fit: The individual may not enjoy or be well suited to the type of work they are doing. This person might have a capability or effort issue, and in most cases this requires a move to a different role or to a different project. 

3. IMPLEMENT CHANGES

Once you’ve diagnosed the issue, the next step is to figure out a path forward. Many new managers simply avoid having these hard conversations because they are awkward and can be difficult.

Communicate clearly: Communicate performance issues clearly with the individual and then lay out a clear path forward with areas for improvement and timelines. This step comes before a formal performance improvement plan (PIP) which is more serious to developmental feedback.

Termination: If you have reached the point of termination, then be clear, direct and kind. Schedule a short in person meeting or video call, and get straight to the point. Often HR is involved in this call, and at some companies they are responsible for this meeting.

Team / Role / Project switch: If the individual is new to the company and has performance issues, and you suspect they are in the wrong role, wrong project or have fit issues with their current manager or team then you should allow one switch to give the person another shot. If the performance issues are persistent, then they should be let go from the company.

Permission to leave: Often, an individual was the right fit for the company or for a role at a point in time but given the stage of the company’s growth, or a shift in the nature of the work this person may not be a good fit any more. As a manager, you can give this person the ‘permission to leave’ and they will be able to find a place outside your team or company where their skills are better suited. It’ll be better both for the individual and the company.


Managing Distributed Teams

At Automattic, I lead a fully distributed product development and engineering team. This post will cover some of my personal practices for managing teams and if/how this is different in a distributed environment. These practices are probably more useful to newer managers running distributed teams for the first time.

I recently listened to Matt (Automattic’s CEO) and Raj Choudhury’s (Prof at Harvard Business School) discussion about the future of distributed work and the ‘Work from Anywhere’ movement which were the inspirations for writing this post.

DISTRIBUTED PRACTICES

The principles of managing a distributed team are the same as managing a team in person, but a few of the practices are different. People are still people, whether they are sitting right next to you or halfway around the world.

Here are a few practices that I’ve found helpful:

  • Trust: Start from a place of trust. Assume positive intent in written communication, and assume your team is working and trying their best regardless if they are sitting right next to you or they are working from home.
  • Expect Asynchronous Communication: Don’t expect a response immediately, even over chat tools like Slack. Learn how to use Slack asynchronously, and set the same expectation on your teams. I deleted Slack from my phone (because I would miss things), and close Slack on my computer when I want to remove distractions. I respond to messages in batches, and use the reminder feature if I need to come back to something later.
  • Focus on Output: Don’t falsely assume someone is more productive because they work longer hours (even when working in person). Focus on the quality and quantity of the work produced by an individual vs. the number of hours worked.
  • Clear Goals, Roles, Expectations: Develop clear goals and a shared understanding of the ‘why’ behind these goals, roles and responsibilities and what is expected of managers (and their teams) in terms of output. Extreme clarity here leads to more empowerment, not less, in my experience (one of my takeaways from Essentialism, by Greg McKeowen, which I recommend).
  • Project Kick Off: For new projects, with new groups of people working together or working across different teams it’s good to get alignment right at the start. I suggest experimenting with a kick off call with project stakeholders and participants followed by a written summary. The call may be difficult to schedule, and less conducive to working across time zones. but project kick offs are infrequent enough that I think these calls are worth it.
  • “Grab a Room”: If you sense a real time conversation is going off the rails in Slack and if it was in person you would ‘grab a room’ to chat it through, do the same over Zoom for 10 minutes. It helps if your team is not inundated with regular meetings so this can happen more seamlessly. I personally also leverage ‘office hours’ to skip level meetings a few times a quarter. 
  • Hiring: When hiring folks who are distributed, put extra weight on the quality of their written communication and their ability to work in a self directed manner. Documentation becomes even more important in a distributed environment.
  • Feedback: Give frequent, specific feedback both positive and developmental over Slack or in your regular 1x1s (both personal and project related). Write up more thoughtful feedback every 6-12 months. We all have recency bias in the longer reviews, so I keep a record of the small pieces of feedback in a running document. At Automattic, we have a tool called ‘Kudos’ which allows folks to send public thank you messages to a few colleagues a month. It’s a nice way to show appreciation.

MANAGEMENT DURING A PANDEMIC

Managing a distributed team during a global pandemic (Covid-19) requires greater care and empathy. Many folks who are working from home had it forced on them and it may have felt jarring. They may have additional responsibilities of looking after their children, caring for sick/old folks or dealing with loss either directly or indirectly. There is also a psychological toil that is hard to quantify, and simply not knowing when we will return to “normal” can weigh on people. As a manager, simply recognizing these issues explicitly and then being empathetic to their circumstance can go a long way.

I would encourage your teams to take the time they need for self care, and be accommodating to more flexible hours. If individuals or teams are going to experience a productivity hit, adjust goals accordingly (and publicly) as long as your business can afford it. It will pay off in the long term with improved happiness, productivity which will translate to better employee retention.

I’ve noticed extra output from some folks who are now simply working more to fill the extra time they have, and less output from others who are more affected. Teams realize and recognize this asymmetric contribution and much like any small community there are times where we need to contribute more to help out our colleagues. That’s ok, as long as it’s not permanent.


For more on this area check out the companion post around managing performance.

This series from Greylock is excellent as well – https://greylock.com/workfromanywhere-podcast/

Manage Energy, not Time

I read the HBR article in 2009 called ‘Manage Your Energy, Not Your Time‘ and it really resonated with me. I’d felt similarly for a long time but did not have a framework to describe it. I’ve since shared this article and this method of thinking with dozens of colleagues and friends and many have found it valuable.

I find that creative individual work or complex problem solving goes poorly when forced into a pre determined time slot. This kind of work is what highly compensated knowledge workers get paid for and we are often forced to do this during 9-5 and in our office environment.

There are three main takeaways for me and how I’ve applied it to my own life:

  • Understand my own energy level before starting a task, and if I’m not in the right mindset switch the task to something that requires lower energy (e.g. submitting my expenses, or other administrative tasks) or take a break to restore energy.
  • Understand what drains energy and what generates energy – a nap, some exercise or a walk with a podcast are all restorative for me personally and so if I’m unable to get something done, instead of staring at my screen I’ll often do one of these and come back more refreshed and ready to complete the task at hand.
  • Work on creative or complex tasks during high energy times – I usually feel most creative and productive in the mornings and try and do most of my IC work during the mornings. In my current job it’s challenging as I work with many folks in Europe so I block out a few mornings a week without meetings.

When you’re a people manager or have meetings that you have to attend for the benefit of others and (not yourself) you often have to compromise on these principles because you’re optimizing for a larger group which is rational but not always pleasant if you’re low energy.

It is much easier to apply these principles a distributed environment (e.g. at Automattic where I work) as we can work from wherever (and mostly whenever) we feel most productive and, in my opinion, is one of the best advantages of distributed work over a traditional office.

A few Management Frameworks

As a manager or manager of managers of product development teams, it can be hard to focus on the right things and to make sure that you’re making progress on your ever growing list.

To help others overcome the same challenges, I am sharing a few of my personal frameworks that have helped me focus better and be more productive over my career:

1. Understand Product and Team Health

I wrote a separate post about this here but one of the most important things you can do when managing lots of products/teams is to understand the health of both the products and the corresponding teams. I do this by asking the following three questions and tracking this over time.

  • What do the metrics say? Metrics are impartial measures of how the product is performing on an absolute basis and trending. Having valid, high quality data sources is essential.
  • What does the team say? Most of your insight will be from the team lead, but make sure and also talk to team members from time to time so you can further validate (or invalidate) the insight from the lead.
  • What do our customers say? Talk to customers, talk to customer support, get structured data on customer pain points.

Combining the insight from these three sources has helped me improve judgement around what we should build and also help with designing better teams.

2. Segment your work

I segment all of my work into three buckets:

  1. (10-20%) Set of things that only I can do (or want to do) myself
  2. (60-70%) Set of things I can structure and review
  3. (10-20%) Set of things that need zero oversight or someone else can do better

This allows me to spend time on the areas that I can have the most impact while making sure that I don’t drop the ball on all the jobs that need to be done by the organization.

Over time, if your objective is to make yourself redundant you should aim to move more and more tasks from category 2 to category 3. This is also a good sign of a team that both well assembled and performing well.

3. Track your time

Each quarter I write up my personal goals (Primary focus, Secondary focus, Observing) and share them with folks I work with very closely.

As part of this exercise, I reflect back on the previous quarter and break down my allocation of time and highlight anything in my list of goals that did not get done.

I then take all the tasks that I don’t think should be on my plate going forward (not the right priority, or someone can do better) and plan to transfer them to someone else for the next quarter as part of my personal planning process.

This has helped me be more deliberate and focus on the things that matter.

4. Get buy in for projects

People are the most important asset in any product development organization and high performers do not like to be told what to work on. One of the most important things that managers of product development teams have to do is get buy in from their teams on the projects they work on.

In the ideal situation a specific job to be done matches both the interest of a team/person and their capabilities. In other situations you’ll need to get buy in from teams to take on projects, and the best outcomes are always situations the team is motivated to work on the project (ideally it’s even their idea).

Depending on the person or team and their preferences, it’s important to phrase the project in the right terms:

  1. Do it for the Company: This project the most impactful thing you can do for the company’s growth – logic and long term thinking.
  2. Do it for your Team: This is the most impactful thing you can do for your peers or your team – community and selflessness.
  3. Do it for Yourself – This is the most impactful thing you can do for your development/career – drive and growth.
  4. Do it for Me: This is something I need you to do for me – strength of the personal relationship. This line should be used sparingly, because it can be relationship damaging and/or selfish.

These are a small subset of tools that I’ve found personally helpful as I’ve worked with product development teams over the last decade and hope you do as well!

Early Thoughts on Distributed Work

I recently joined Automattic which is a fully distributed company. We have ~900 people (in all functions) working in ~70 countries, with no central office. We are one of the largest, if not the largest fully distributed company in the world.

I wanted to share some of my thoughts about the advantages and challenges of distributed work after two months – both strategically and from a practical implementation/execution perspective.

One very important principle about Automattic is we are set up to be a distributed company and all of our internal process is designed with distributed teams as the default state. This way, folks that are remote are not ‘2nd class citizens’ but are the core of the company.

Advantages

  • Work from anywhere: Our people can live and work from wherever they want, which ultimately leads to happier employees that stick around longer.
  • Work when most productive: People can work when they feel most productive and manage energy, not time (one of my fave articles) taking into account their personal constraints (e.g. family) into their schedule. Managers, however, have a bit less flexibility.
  • Custom work environment: Some folks like others around, others prefer a quiet environment, others like to move around. At Automattic, people can set up their environment to suit their unique style which is very hard to achieve in a traditional office.
  • Everything is documented: We document everything using our internal blog system (called P2) and folks can always go back and find out the ‘why’ behind decisions. This is very powerful.

Challenges

It’s worth noting that these are currently a set of initial observations for challenges, and I’m sure there are a number of good solutions to them which I’ll be actively thinking about as part of my work at Automattic. 

  • Onboarding as a new employee: Onboarding requires getting to know the right people (and building trust), learning the right systems, and developing the right judgment to know where to focus. Doing this remotely can be a struggle.
  • Building relationships: It’s easier to build bonds with people in person. Nuance is lost over Slack and Zoom and there is no substitute for time in person together. At Automattic, we have meetups to help build relationships but it increases the amount of time and ‘deliberate-ness’ required to get to know your colleagues.
  • Finding product-market fit: In the earliest stages of finding product-market fit, iteration can be slowed down because of async, documentation heavy nature of our work especially if vision is shared among different people. This is an area where I feel there are lots of areas for opportunity to improve with more frequent synchronous interactions. 
  • Changing direction: It’s much harder to get alignment and inspire towards a different strategic direction via text and video. It’s harder to recreate ‘energy’ and velocity in a distributed environment.
  • Separating signal from noise: We are a large team (900+ people) and there is a lot of content that is created daily.I’m spending about 15%+ of my day parsing through posts and comments to figure out what I should read, participate in, or make decisions on and as a new person it can be difficult to know where to focus. More experienced distributed workers have similar issues, but they are less pronounced, which shows that this is a somewhat learned skill.
  • Time zone management: It can be difficult to run teams across different time zones but there are also opportunities to increase velocity by folks working over a 24 hr period.

Individual Contributor to Manager

In my last role at Pocket Gems, I transitioned from an individual contributor (IC) to a manager and then to a manager of managers. It was a hard transition as we grew from 5 people to 150 in less than a year and a half, but I learned a lot along the way. I was directly responsible for a team of about 10 -15 product managers and indirectly responsible for a multi-function team of about 120 people.

In order to transition from an IC role to a manager role, it’s important to be a functional expert so that you can win the respect of the people that you manage. If you’re not a top quartile functional product manager it’s very difficult to progress into a management role. When you transition from a management role to a manager of managers the skill set is completely different. Your skills as an IC become less relevant and your role evolves into a strategy, staffing, prioritisation and coordination role vs. being a great IC. You need to create systems to be able to get the right information at the right time through data, people, and process. This then informs strategy, which leads to prioritisation and staffing.

I personally found the transition from IC to a manager of managers role quite depressing. I realised that I gained fulfillment from completing tasks (running analyses, designing features etc) and I was doing very little of these tasks any more. I became much more comfortable in the role after I did a few things:

  1. I read the High Output Management and the Hard Thing about Hard Things
  2. I kept 10-20% of my time to work on IC type projects from running a particular analysis to designing a new feature that I wanted to test.
  3. I gained fulfillment from developing others and seeing them grow as product managers

I do think the best leaders are able to work along all the dimensions of IC, Manager and Manager of Managers. People who perform well at all these dimensions scale particularly well at growth startups and are a great fit for leadership roles at early stage companies.

There are a few other things that I learned, mainly by screwing them up a few times and dealing with the ramifications of my screwups. These mistakes can permanently break trust with people, create really strained working relationships and are hard lessons I learned along the way.

  • Genuinely care about people on your team. There is no substitute for authenticity and your team will be able to tell if you’re apathetic towards them.
  • What you say as a manager is amplified because of your position – you have to be even more thoughtful about what you say as you can distract the team unnecessarily and also affect morale both negatively and positively with even a few words.
  • Never take credit publically for yourself (give it to others) and always have tough conversations 1-on-1 privately. Building loyalty with your team will pay for itself 10x in the long run.
  • Great managers never complain about their team. They understand what the individuals are capable of, set them up for success and then manage expectations upwards.
  • Put yourself in the other person’s shoes – figure out what motivates them, what they care about and manage to those things. This should be one of the first conversations you have with someone new on your team. I often talk about my motivations first in order to break the ice.
  • Make each person feel respected and valued regardless of their role – if someone’s role is sometimes more ‘thankless’ (e.g. QA) it’s even more important to celebrate wins.
  • Focus on process to make things better vs. placing blame on individuals (very easy to do, especially in the heat of the moment). It’s very easy to damage relationships permanently by doing this repeatedly.
  • Deal with personel/performance issues expediently. The person affected and the rest of the team will appreciate this in the medium term (but often not in the short term). Dragging your feet here will lose you respect at all levels of the organisation.
  • Learn how to influence. People respond much better if they feel like they came to the conclusion themselves vs. forcing the outcome onto them. There are lots of levers for influence and using these levers thoughtfully is an art e.g. do it for yourself (own goals), do it for the company, do it for the team, do it for me (manager).
  • Be transparent with your team. If people have context they will perform better. This does not mean sharing noise (information that is not a useful signal or irrelevant) with the team; a common misconception when talking about transparency.

I am learning more every day in this capacity, and writing these learnings down helps me systematise my learning.  I hope that others out there find some of this useful as well.