The “Why” Behind Work

Aligning on “Why” for product development work is always important in work 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”.

Product Development Practices

This post is a collection of some product development practices that I think are valuable. It’s not meant to be an exhaustive list, just a collection of thoughts.

Goals and Planning

“Plans are worthless, but planning is everything”

Dwight Eisenhower, 1954

Planning allows teams to get aligned and having clear goals, priorities and metrics for success creates a shared understanding of what is important across an organization. If more people understand the ‘why’ behind goals and how these goals ultimately roll up to the company’s mission then the product details reflect these goals and values. It feels subtle, but over time translates to better, more consistent product quality.

The best organizations plan but are also able to abandon plans or adjust quickly based on new internal or external data. Many large organizations become rigid and slow, although perhaps more intentional, which is often the argument against medium or long term roadmaps.

Roadmaps: Now/Next/Later

All teams should have a public roadmap (an extension of planning) and my favourite framework is Now/Next/Later because of its simplicity.

Roadmaps should be lightweight, flexible and become less precise as they look further in the future. When all teams use the same format (and this is accepted across the organization) it’s easier to roll up work across teams. It’s even easier if all teams to use the same tool (particularly for managers of multiple projects), or if there is seamless two way information transfer between roadmapping tools.

To help determine priority, which is ultimately an ordered list, I like to use an Impact vs. Effort framework (taking into account Risk as well). Impact is the potential value to users and the business, and Effort is how hard it is (T-Shirt sizes like S, M, L, XL are an easy way to visualize).

Top 3 Things

At every level of the company write down the top three projects at any point in time and share them publicly.

This is a simplification layer on top of roadmapping to make it easier for folks outside the team to understand their work, quickly. It also acts as a forcing function for teams to decide what’s most important It’s a process can scale across large organizations and roll up nicely from teams, to divisions to the top of the organization.

The top three things should be specific, have a clear outcome and refreshed at the end of every sprint or planning cycle (typically 2-4 weeks).

Shaping (“One Pagers”)

Thinking is cheaper than making, and crystal clear though upfront can save multiples of that time (and cost) down the line.

One pagers should shape problem spaces into a set of solution spaces and assess the viability of these solutions to solve a set of user or business goals. It’s a collaborative document typically assembled by product managers with engineers and designers contributing. This process helps build alignment between the team, allows multiple solution spaces to be explored, and ultimately results less discarded work and clearer requirements for design and engineering teams.

These documents are short 1-2 page descriptions of the feature that anyone across the organization can read (as little jargon as possible) and get a sense of the value and the scope of the project. They should cover the goals, metrics, problem space and options for solutions with a recommendation of an MVP.

Burndown Lists

Burndown lists are simple, ordered lists of all the tasks/bugs/polish that need to be completed before we launch a feature (can be any version of launch – internal or external).

These are typically assembled when a large feature gets close to launch and the ‘launch line’ is a moving target. Once everything above the launch line is completed, the feature can launch. It’s an excellent system to help with prioritizing what is necessary for launch in a binary way, which simplifies the decision process.

Burndown lists a simple, visual powerful and motivating tool for folks who are getting ready to launch a feature. Checking off things that get you closer to the launch line is very satisfying 🙂

Feature Reviews & Retros

After launching a feature (especially Large or XL: projects) it’s important to get together to reflect on the project. This allows teams to step back to reflect on the process, celebrate their work and their colleagues and codify learnings for the next project. I prefer doing retros once we know the outcome (metrics) of the feature to see we met the intended goals.

I could also see an argument for separating this into two pieces, the process and the outcome as there are cases where quality product development (for a risky feature) do not achieve goals. In these cases it’s important to celebrate good work, and share learnings. If taking risk is not accepted by the organization it will be avoided, which stifles long term innovation.

Dogfooding

Use your product. At every company I’ve worked at, a significant portion of the people who work on the products are not regular users of the product outside of their daily work.

Especially for consumer products, the more people at the company who use the product like ‘real users’ the better the product will become. Using products creates empathy for customers, because you’re a customer, and helps improve product sense (although increases bias) and find corner case bugs.

It’s also a powerful cultural force, and I think that leadership, in particular, should lead by example by being power users of the product (s)– the product something everyone in the organization has in common.

Product Lead Role

I’ve been leading product development teams for over 10 years in different industries (ads, gaming, fintech, tools) and customer segments (consumer, enterprise, SMBs). There are a few things have been consistently true across these industries particularly at scale.

I typically broken up my role into three different buckets:

  • Product: What are our goals? What we are building to achieve these goals? Why are these features impactful from a user or business perspective? What priority order should we build these features? How do we measure our success (metrics) against these goals? How do we align with other stakeholders (e.g. other product leads, marketing, finance) across the company? What are the right health metrics for the product and are we monitoring them effectively?
  • People: Do we have the right people in the right places? Are we aligning the right mix of complementary teams with the right problem spaces? Am I helping the people on my team achieve their personal goals, as well as driving business outcomes? Am I managing performance (both outstanding and underwhelming) effectively?
  • Process: What is the ‘product development system’ that ultimately allows us to build great products? What are our rituals that are consistent across teams, and what can be flexible within teams? How do we ensure continuous iteration and experimentation on our system?

When running a suite of products with multiple product, the very practical things I like to spend my time on include:

  1. Identifying problem spaces that roll up into a coherent strategy to drive user and business outcomes [this is often the hardest].
  2. Aligning each team to a problem space and a clear ‘why’ for their work.
  3. Working with product development teams to craft their solution spaces and roadmaps.
  4. Giving feedback on product specs for high investment features.
  5. Giving feedback on products that are shipping (quality control).
  6. Acting as the pattern matcher/glue for related work across teams.

These practices need iteration and refinement based on the type of company (and culture), the type of product (e.g. enterprise is more customer led), and the mix of the people on your teams but being intentional about priorities and practices is always helpful (I published a version of this internally).

Operating Systems for Distributed Work

Even after we no longer have to physically distance, more software development teams will be fully distributed (people can work from anywhere) or employ a hybrid structure. Hybrid structures could include people hybrid (some people in an office and some people working remotely) or time hybrid (entire teams working some days in the office and some days remotely). This shift will continue to happen for both large, established businesses (e.g. Twitter, Stripe, Slack) and for new startups, many of whom choose to be distributed from inception.

Regardless of how companies chose to be organized a few things are clear to me:

  • Software development is all happening in the cloud – this is unlikely to change.
  • Work will be powered by a wider set of SAAS tools which are the best tools for the job to be done (v.s broal tools which may not be perfect for purpose).
  • APIs and systems for information transfer between these tools will, and must get much better.
  • Companies will want to own and control their IP across these external tools systems.

I think we will look back in a few years and realize that our systems for working in the cloud were outdated. In particular we are missing connective tissue between all the external SAAS tools that we rely on every day to power our work and collaboration.

There are many startups and established companies working on aspects of these problems, but nothing I’ve seen is flexible enough to power work for every software development company in the world. I think more of the solutions need to be open source and focus on enabling companies to own their data.

If the connective tissue or “Operating System” is open source, it allows developers to add in house custom tools or connect their unique mix of SAAS tools together without relying on a provider to ‘support’ that integration. Companies like Rippling spent over a year in stealth just building over 100 API integrations, and continues to have large teams focused on adding and maintaining these integrations. With open source, the community can power these integrations and adapts faster and more durably as new tools are built and adopted.

If the connective tissue or “Operating System” allows for better data connectivity and transparency then companies will own more of their intellectual property. This results in less, mission critical, operating data being walled in third party products (which also forces lock in) and gives companies more flexibility to organize, find and analyze their information. It would also allow for new use cases like measuring productivity of teams, which are very difficult to achieve today.

I’m personally excited about innovating, and supporting innovation in this space.

A More Open World

I’m excited to bring my children up in a world where anyone can learn anything, anyone can invest in anything, where world class software/tools are free to use and customize, and where anyone can contribute to software development regardless of their physical location.

We have made progress on all these dimensions and we’ll see even more foundational progress over the next decade. I hope it will lead to a more open and connected world and empower more diverse groups of people to create amazing things together.

Caveat: To participate, people need access to an internet connected device, and this is still only <60% of people in the world. As internet becomes more widely available and the cost of devices and data goes down substantially, more people will have access to these opportunities and be included.


Open Finance

I hope that everyone will be able invest in anything.

New projects will have (near zero cost) legal entities automatically spun up in the background, regulations will allow all of us to invest in products with any amount of money and own equity (with drastically simplified legal agreements). These micro pieces of equity will be liquid and easily to other people and there will be clear, immutable record of all these transactions.

People of any age/location will be able to contribute to projects with their friends with both their time or capital. They will all be able to create and capture value without the need for angel investors or venture capitalists (who currently have to meet accredited investor standards). They will not be excluded from early stage investing. People in any country will be able to buy fractions of securities in any other country, diversifying their exposure (particularly important for emerging markets).

Syndicates (groups making an investment) are still really expensive and has high friction, despite the progress we’ve made. SPVs on AngelList cost about ~$10k to set up and run over their lifetime and so only make sense for investment rounds of a few hundred thousand dollars (which is a lot of money). Rolling funds can accept much smaller amounts of capital than traditional funds, but are still expensive to run and require capital scale to make sense.

Software will power the legal and financial framework for investing (combined withj adoption of cryptocurrency and smart contracts) and will be able to reduce the overall cost and hide the underlying complexity.

Ultimately, this will provide access to more asset classes to more people at any quantum of capital. This will lead to more projects getting funded, and more people generating wealth through owning equity vs. renting their time.

Open Learning

I hope that anyone will be able to learn anything.

Access to the highest quality teaching materials will no longer be locked in walled gardens and this content will be completely open. Many leading universities are already opening up much of their teaching content (e.g. Harvard, Stanford) and this is the mission statement of the Khan Academy which has helped people learn all over the world, for free.

Students will be able to learn (at their own pace) using whatever format works best for their preferred method of learning (e.g. watching videos, reading text, listening to audio). They will easily be able to then test their mastery with interactive problems and real world applications at no marginal cost. I, personally, learn better visually and orally and that is why I found lectures in college so useful (and why I watch a lot of YouTube videos).

Schools and higher education will need to adapt (culturally and practically) to asynchronous learning, and a more diverse mix of students in each class. One of the main benefits of school and college is the ‘cohorts’ of students who go through the shared experiences (much of which happens outside of the classroom) and I still think it’s important to try and create opportunities for young people to have shared experiences and work in groups.

I hope that higher education, in particular, will preserve the cohort and community aspect but there will be specific focus (v.s. community as a byproduct) on collaborating in groups, building lasting friendships, and creating stuff together.

Open Software

I hope that anyone will be able to build anything (software) and getting started with the best tools in the world is free.

Open source is a very powerful movement and, at scale, encourages global collaboration and development so that software can easily modified to meet local expectations and standards. One of the best examples is WordPress, which powers 39% of the top 10 million websites in the world with tens of thousands of contributors working together asynchronously.

Software is now being developed in the cloud first and new projects are powered by more self serve SAAS tools than ever (Slack, Notion, Figma, Asana, GitHub). I hope that all of these tools start free to reduce the barrier to try out these tools, and also reduces the barrier for projects to start and for people to collaborate. It also puts more pressure on SAAS software developers to build quality products, have quality customer service and continue to improve their products over time.

In order to build a sustainable business SAAS companies will need to charge for features that become necessary when projects evolve into businesses that scale. This could include customer support, security, performance, connectivity with other applications, hosting and payments.

I also hope that more SAAS tools expose more of their information via API (in addition to building integrated solutions) and give project owners more ownership of their data own (so they don’t remain locked into these tools). This will also be better for the ecosystem as more tools will be able to talk to each other and less information will be lost across different tools which will improve the quality and efficiency of software development.

Open Work

I hope that anyone can work from anywhere.

The Covid-19 Pandemic has catalyzed mass adoption of distributed work especially for technology companies. If companies can hire globally it significantly increases their accessible talent pool v.s. the constraint of hiring locally (along with many of other benefits). I’m a big fan of distributed work for software development, and write about it on my blog.

With more open work, people of all ages, races, nationalities will be able to collaborate on projects together, bringing more perspectives to the table. These products will end up being better suited for global audiences, as these perspectives and empathy will naturally make it into the product development process.

Workers will be more focused on collecting skills and knowledge vs. collecting brands. When we recruit now, we use proxies to infer skills or background; where we went to school, what companies we have worked at, or how we were brought up. This should evolve into showcasing our specific skills backed up by actual contributions to specific projects that roll up into a more accurate picture of our whole self. Companies will also become better at assessing skills, knowledge and experience over relying on brands as a proxy for the requirements for jobs to be done.


I’m excited raise my children in a more equitable world where less of their fate is decided at birth and I’m inspired and hopeful at the progress we are making globally.

We will see continued improvement in social and economic mobility, better products from more diverse people and more collaboration across groups with different ages, genders and countries. 

Crypto Investment Strategy

Bitcoin has increased by 300% in the last three months from $10k (Oct 3) to $33k per $BTC (Jan 3). Ethereum has also increased by 270% in the same period from $350 (Oct 3) to $950 (Jan 3) per $ETH.

I started buying Cryptocurrency in early 2013 ($BTC mainly) mainly because I thought it was an interesting concept at ~$50 a coin. I ‘lost’ most of these coins as part of the Mt Gox Bankruptcy in 2014. I’m hopeful that 10-15% of our holdings may be returned soon, after seven years of waiting.

The US government has printed more than 20% of the total USD in circulation in 2020 alone (over $USD 9 Trillion) and many people have no idea we just got a lot poorer. Given this is happening globally (across governments) I’m starting to think that I should have a more significant percentage of my savings in $BTC and cryptocurrency in general over fiat ($USD). There are also lots of other benefits/value of cryptocurrency beyond inflation protection but I won’t cover them here.

Ultimately, I’d like to allocate 10%+ in Crypto, 20% in technology companies (private), 30% in real estate and 40% in public equities (mostly in tax advantaged retirement and non liquid accounts) but this will take many years and a good amount of luck, too 🙂

Given these observations, here is how I’ll modify my strategy going forward.

Crypto Strategy

  • Focus on $BTC and $ETH: Most of my $BTC is locked up in Mount Gox, and this counts towards my overall allocation. I assume around 15% of coins returned at some point as $BTC (not fiat). My next largest position is ETH which I’ve had for years. I plan to hold BTC/ETH/All Altcoins in a 70/20/10 ratio in terms of USD fiat value.
  • Regular Purchase: I started taking 15% of my paycheck (2x per month) and purchasing $BTC and $ETC in the correct ratio (80/20), which I would ordinarily leave in fiat in a savings account. I’ve been doing this for about a month. The goal here is to remove emotion from the decision and dollar cost average over the next few years.
  • Crypto Savings Account: I started to move most of my $USD out of Marcus (CDs) into BlockFi (referral link). I have kept some $BTC and $USDC (a USD stablecoin) for the last 6 months or so, and I’d rather make 6-8% interest over 0.5% interest in alternatives. Note that BlockFi is not risk free (they are lending like banks do) but they do have some strong security measures in place.
  • DeFi: I have positions in all the stuff powering Decentralized Finance (DeFi) on the Ethereum network, but that is mainly for fun (which is how $BTC started for me anyway). I play around with staking, liquidity pools and lending but beware the large gas fees (I got burned). My largest position is in this DeFI Pulse Index (https://defipulse.com/blog/defi-pulse-index/) which is a weighted index of all the tokens powering DeFi.
    • Feb 5 Update: Given all the growth in the last 30 days this has now also evolved into a more ‘core’ position.

I also hold small amounts of other Altcoins like Stellar Lumens ($XLM), Polkadot ($DOT), Ripple ($XRP), Filecoin ($FIL bought in the 2017 SAFT), Arweave ($AR), UNI ($UNI), Sushi ($SUSHI), Cosmos ($ATOM) as well as about a dozen others, but those are more out of interest than part of an actual strategy. I also added NFTX as an index for collectibles to the mix.

All of this is still very experimental, and I wrote this up to share more easily and get feedback. Despite dabbling for eight years, I still feel like a n00b most of the time in the crypto world.

My Parental Leave

I just spent two months looking after my three month old son (Kal). I really enjoyed the time we had together and it was wonderful to focus on family and interests outside of my job at Automattic.

Time with my Son

The majority of my time was spent with my son, Kal, and with immediate family. I have a lot more empathy for my wife as looking after a baby is harder work than I had expected.

  • Bonding: I think most of the value of the parental leave value was for me to bond with Kal. I’m still not completely sure he knows who I am 🙂
  • Bathtime: I give him a bath every day before bedtime, where I play him a new song each day on Spotify. It’s a fun little routine and something I’ll continue doing even when back at work.
  • Sleep Training: We finally did this about half way through my parental leave and it was a game changer. It was amazing to get 6+ hours of uninterrupted sleep again although I wish it was more consistent.
  • Walks: Every day, I’d take him on 1-2 hour walks in the baby carrier which was both good exercise for me (and when I listened to audiobooks and podcasts) and also relaxing for Kal who loves being outside.

Personal Development

I made a concerted effort to eat better, exercise more, read/write and brush up on my programming ‘skills’:

  • Health: After Kal was born, I was not at my healthiest. I worked on eating better (less sugar and carbs, less frequently drinking alcohol) and adding in more strength and HIIT training (Peloton classes and Kettlebells) in addition to walking, running and cycling. I am already feeling better and want to codify and adhere to new habits over the next few months.
  • Reading: I spent more time listening to audiobooks and podcasts. I’ve enjoyed listening to the 20 Minute VC, Acquired, and All-In. I read Powerful (Patty McCord), Greenlights (Matthew McConaughey), Range (David Epstein), Leading (Alex Ferguson) which were all great. Ready Player Two (Ernest Cline) was disappointing (even though I LOVED RP1) but I’m happy I read it regardless. I’m now slowly making my way through A Promised Land (Barak Obama) which is very interesting as I don’t know much about US politics.
  • Programming: I started a Full Stack JavaScript course on Treehouse (completed about 25 hours) starting right from the beginning. It was great to reconnect with engineering and I now understand many elements of JS and can scan through code and understand how it works.

Developing Theses

  • Africa Investing: I set up a rolling fund (focused on early stage investing in Africa) to offer my friends/family and extended network access to both this asset class (private technology companies) and emerging market (Africa). This is an extension of the part time angel investing in Africa I’ve been doing for six years.
  • Future of Work: I spent some time learning, thinking and writing about different ideas mainly about the future of software development and investing. I made a few small investments (in support of these ideas) in entrepreneurs all over the world, mostly co-investing with folks I’ve known for a long time.

My wife and I also finally completed some life admin, such as moving out of our NYC apartment and finding childcare for when we are both back to work. We are hoping to move back to NYC once the weather improves and vaccinations are distributed widely (hopefully Q2 2021).

We are looking forward to life getting back to more ‘normal’ and being able to have closer physical interactions with friends and extended family.

My Top 3 Things for 2021

Every year I go through a holistic planning and review process between Christmas and New Year, and this year marks the 10th year of this practice.

2020 was a challenging year but there were also some really wonderful things that came out of it; my son’s birth and early life, getting to know my in-laws very well (as housemates) and having more time to read, write, and reflect without ‘normal’ social engagements. As a father, I’m now responsible for another person’s life and this has changed my perspective about the things that matter (particularly about my own health and the health of loved ones).

For 2021, I wanted to add a simplification layer (in addition to my usual planning process) by breaking down my priorities into the top three things:

  • Health and Habits: Improving my health will be driven by improving my habits. I’m implementing stricter rules about my diet and exercise routine that I can adhere to in a sustainable way. I’d like to complete my first triathlon in Fall 2021 (Olympic Distance), hopefully joined by some friends.
  • Loved Ones: I’ve missed being physically present with many of my loved ones this year. My parents, or my sister (and her family) have not met my son. I’ve not seen many of my closest friends and family all year. I’m hoping to make up for lost time with loved ones with extended time laughing, eating and drinking together.
  • Purpose: Improving my own happiness and fulfillment is about prioritizing purpose. I’m hoping to continue to build my career in service of entrepreneurs (e.g. software/tools, capital and learning). I’m planning to lean further in to work that furthers this purpose, and lean out of work that is inconsistent with this purpose.

Have a wonderful year ahead!

Tools to Power Distributed Work

The way we build software and collaborate is going through an accelerated evolution as more organizations adopt distributed and hybrid (partially in person) work. In both cases, tools and processes will be designed for distributed work first, which can then be adapted to in-person more easily than the other way around.

There is a lot of innovation coming in the tool stack to facilitate these new practices, which I’m personally excited about and plan to follow closely.

The principles that I think will become the most important for these tools are:

  • Asynchronous: Tools should enable both asynchronous and synchronous collaboration seamlessly. This should apply to both short and long-form communication (which should also have separate interfaces). Examples of tools that do this well are WhatsApp and Slack, which are both probably more important to me than email now.
  • Transparent: Organizations will move more towards ‘transparent by default’. This will allow more people to have more context and create more trust in organizations. A challenging problem to solve is information overload, allowing teams to better separate signal from noise, and picking most important things to consume and act on.
  • Connected: Organizations will want to collect and record more data on work created in the organization. Tools will need to be more connected (i.e. use APIs to talk to each other better) and information will need to be better organized and accessible across the organization.
  • Consistent: To be effective, a minimum set of collaboration tools need to be accepted and used by the organization, which can be difficult at scale as it may involve both cultural and behavioral change. This is pretty self-explanatory (I don’t go into more detail below).
  • Measurement: As work moves to the cloud, and we collaborate digitally, we will need more tools to measure productivity and organizational effectiveness, culture and morale.
  • Human: There will be more focus on being human and building broad and deep relationships inside and outside organizations. In person time is still great for driving creativity, serendipity, building trusting relationships, and humanizing work. We will find more ways to simulate these experiences virtually.

I’ll explore these in more detail below.

Asynchronous

Building a culture, a set of tools and a set of practices that allow for asynchronous work is the foundation for distributed teams. It’s more inclusive because it allows for people in multiple time zones (or working hours) to process information and give feedback. Systems that work asynchronously that can be adapted seamlessly to work synchronously (e.g. Slack) are great where communication can be organized around projects, teams or topics.

I think this should apply to audio, video and text. I’ve not come across tools for async Audio and Video (possibly Loom) in the workplace. I used WhatsApp personally for sync/async text and audio the most. We recently took a long (1.5hr) townhall video and ‘chunked’ it down to its components and pulled it together in a blog post so that teams in different time zones could consume it asynchronously. It was very well received, especially as we did it very quickly, so it was ready in a few hours after the presentation (but a tool would help do this faster).

There are arguments that asynchronous work can slow down the pace of iteration or reduce ‘riffing’ off each other to create better solutions. I think that these are fair points, but most of this kind of riffing is useful at crossroads or can happen in very small groups and teams can create synchronous time for this if necessary. I think synchronous collaboration (and in person) is especially effective for new projects which require finding product market fit, where rapid iteration and creativity are even more critical.

Transparent

I think that more companies will work more openly in the future. We will trust our employees with more, and they will have more context for their work. This applies to both short form communication (chat) and long form communication.

In order to enable this (particularly for long form communication) we need a set of tools that allow employees to be able to collaborate in the open. At Automattic we use a tool called P2 which allows us to publish anything openly (structured as a blog post) and for our colleagues to like, ask comments and questions and collaborate in the open (Notion also works well). We’re able to pull in information from other tools and embed them into the post or link to other areas of work that are relevant. We need to make improvements on how this information is organized and the ‘state’ of a post (e.g. is it ‘active’ or ‘closed’? which project does it relate to? how high priority is it?). We’ve tinkered with some ideas but not settled on anything just yet as we were worried about increasing the friction to share with colleagues.

In addition to building systems to share openly, we also need to think through the subscription and notification systems to alert people to the right information they need for their work at the right cadence and the right priority. Different people need different levels of breadth vs. depth depending on their role.

A crucial benefit of working openly and making this information easily discoverable (indexed, searchable) is that the work exists regardless of the organization’s mix of people. As employees move to different teams or companies, or when new people join the company the decisions and the reason behind these decisions is always available.

Connected

Organizations want to control more of their own information. As we rely more and more on external SAAS tools to power our work our internal data is more fragmented than ever.

Organizations need to be able to extract and record information from these tools which is currently difficult and requires a lot of custom integration work. Many SAAS tools make this difficult because they know that we are less likely to churn if we are reliant on their platform as a source of record.

Creating connected tools and workflow that enables data to move between these tools and ultimately be owned and stored by the organization is important. Once this (difficult) part is complete, building a UI (and search tool) to discover this information is a natural extension.

A few interesting companies innovating in this space include: PlaybookOnnaBento, Solve Data and Rock (which is a broader solution).

Measurement and Productivity

We don’t have good systems to track productivity for individuals, teams or projects especially as our teams become more distributed (and tools become more cloud based) and we become more output focused.

Managers need both qualitative and quantitative data to monitor teams more objectively with less bias, but employees also need to feel like they are part of the process and are not being micro-monitored.

Organizations need to log and visualize this data over time and understand that this is an input into productivity and does not tell the full story.

I wrote a detailed post covering this topic here – https://aadil.blog/2020/12/18/measuring-productivity-of-distributed-teams/

Human Relationships

Relationships are important for collaboration and teamwork. Trusting relationships in our immediate teams and around the organization can lead to more productive, more creative work with more candid conversations that get to better outcomes faster.

Even at Automattic, which has been distributed since 2005, we’ve relied on in person team meetups and a global ‘grand meetup’ to help build relationships and foster serendipity in the organization. There is value to seeing colleagues in person, enjoying lingering (less transactional) conversation, and eating and drinking together.

As we move towards more distributed and hybrid models of work, we will need to make sure that we create opportunities to build relationships (deep and broad), humanize our interactions during work, learn from each other and have fun with each other both within and outside our organizations,

A few interesting companies innovating in this space include RemotionLunchclubStart Playing GamesContra and On Deck.

Hiring and Onboarding (Bonus)

Hiring and onboarding of employees also evolves in a distributed environment. Hiring may take longer and leverage more text based (short and long form) collaboration trials versus traditional in person interviews. There are advantages to this process — it feels more two-way than one way, and helps remove more bias, and is more reflective of our actual work.

Onboarding and training employees needs a clear process which can be less rigid than typical onboarding bootcamps at larger organizations (and asynchronous). To achieve this we need better documentation and need to humanize the process as much as possible (e.g. pairing new folks with buddies, recording welcome videos for context etc) while giving employees the tools to onboard and contribute at their own pace (with guardrails, of course).

A few interesting companies innovating in this space include RipplingDonut and SkillMagic.


I remain very positive and excited for the future of how we build software and collaborate as humans. The more we can remove physical barriers to build high quality creative products the more we can improve liquidity in the global labor market and find the right people for the right jobs regardless of their location. This is is an exciting future, and better tools will continue to power this movement.

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.