Book Recap: The User Experience Team of One by Leah Buley

TL; DR: If you want to do user research but don’t know where to start and could use a collection of no-nonsense tools that focus on practicality instead of formal correctness, consider picking up this quick read.


The User Experience Team of One by Leah Buley is written for a specific kind of person.

If you’re a part of a mature product team or your company has one, this book might not be for you.

But if you need to be able to go from idea to a solid, research-backed product spec without much help and don’t have a ton of experience, this is absolutely the book for you. A few scenarios where it will come in handy:

  • You’re working on a side project and want to take it to the next level without leaving your day job.
  • Everyone is suddenly asking you to “provide a strong vision” and a “crisp roadmap” without giving you a lot of specific direction. You’re not sure where to start.
  • While you historically relied on your intuition to figure out what you (and your team) should work on, for whatever reason, that is no longer working.

If this sounds like you, you could benefit from this book.

If you don’t have the bandwidth to read an entire book but would still like to learn a bit about how to do user research in the next five minutes, read my Poor Man’s Product Research Tips post instead! 😏

Format & Contents

The majority of the book is a collection of practical UX research and design tools & practices, organized based on where in the overall process they come in. There are also a bit boilerplate-feeling, “what is user research?” and “how can I grow as a UX person?” chapters that seem safe to skip for most readers.

The parts of the process the tools & practices cover:

  1. Planning & Discovery introduces methods like UX Project Plan or Strategy Workshop to help you set the overall project goals & rough direction.
  2. Research lists methods that take you through conducting user research and information synthesis.
  3. Design goes over essential design tools like Wireframes and Task Flows.
  4. Testing and Validation helps you validate your designs through Black Hat Sessions, UX Health Checks, and more.
  5. Evangelism shares tips on leveraging artifacts you produced throughout the process to spread the UX gospel in your organization.

Altogether, the tools & practices portion of the book is around 140 pages.

The Good Parts

The User Experience Team of One is a great book to give you a quick sense of the glaring gaps in your UX design process. It also helps you patch them by providing practical tool ideas you can quickly put into practice. After finishing the book, you will likely walk away with a few concrete ideas you can try in the following weeks or months.

The book presents all tools with a consistent structure that makes the book a great reference. I especially appreciate the inclusion of:

  • Average time Being explicit about how long something should take makes it easy to prioritize where to put your effort.
  • Try it out – Step-by-step instructions make a bulk of each tool’s description. The steps are always clear and easy to imagine.

If you suffer from imposter syndrome as a product manager, this book should help. You are likely already doing a fair amount of the activities mentioned in the book. Seeing that you are not that far off in your process from someone who has written a book on the topic and most of the gaps in your process are relatively straightforward to patch should make you more confident about the level of your product work.

Lastly, if you like paper books, do yourself a favor and get it in paper format. It’s full color, quality paper, and lots of fun to leaf through. Mine arrived only after I wolfed down the ebook, and I wish I had waited for the paper book as the ebook doesn’t contain any of the visual flourishes of the paper edition.

The Bad Parts

The book was written in 2013, and part of it feel stale. Picking up the book, I expect that the problem area will lend itself to evergreen content well, but there are two areas where the book shows its age:

  • If you work remotely… – These sections are written in an era where working remotely meant you were working alone, detached from the physical office where the rest of your team is located. Therefore, the tips presented are impractical for fully remote organizations and doubly so for async ones.
  • Mentioned software tools – Figma has taken the world of design by storm, and many of the tools mentioned in the book feel a bit obscure at this point.

The second thing to mention is that at 39USD for an ebook, the book feels relatively expensive given the rather casual nature of its content. At the same time, this is a book for a particular market, which makes the price feel more justified.

Note to Europeans: Avoid ordering from Rosenfeld if you can. They are very slow to ship and send books from the UK, making it likely you will need to pay a not-so-small import tax.

Biggest Takeaway

If you’re not talking to your current or prospective users, find someone to talk to and schedule a call this week.

Before you get your bearings, ignore articles about selection bias, unrepresentative sample sizes, etc. Instead, focus on getting the ball rolling. Remember that since your research techniques are not rigorous, you still need to apply your product taste to check them, and you’ll be fine. Once you feel comfortable scheduling calls and talking to real people about your product, you can gradually add more rigor to your process.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!


Cracking Personal Planning with Todoist

Even though I’ve worked on Todoist for several years as a developer and a product person, I’ve never really felt that I figured out how to use Todoist myself. There was too much friction and disorganization in my setup. I’ve fallen off the wagon many times over the years.

This year, for the first time, I feel like I’ve finally nailed it, and I’m here to share; hopefully, it will give you some valuable ideas for your Todoist usage.

Problems to solve

To make Todoist truly useful, I need it to do a couple of things for me.

#1 (work) Support my weekly planning cycle

Every Monday, I reflect on the prior work week and plan the next one, as every Doister.

This process includes looking at my Todoist to keep commitments and make meaningful progress beyond the usual firefighting. The goal is to generate a list that looks as follows.

My weekly tasks that I post for transparency in Twist, our communication tool.

#2 (personal) Keep up with life

I don’t excel at recurring chores, as our finance team could attest to 😅. Making sure all personal monthly payments are going out, doing my Japanese homework on time, etc. If I need to rely on my memory and will, all is lost.

At the same time, I don’t want to make my personal life overly deadline-driven. If I don’t manage to code a new feature for my side project on Sunday, it’s a shame, but I don’t want to feel bad about it. I don’t want to come to a Todoist overflowing with overdue tasks at the start of my Sunday; that’s completely demotivating.

#3 Separating work and personal tasks

I need to strongly divide my work and personal tasks. I don’t want to see tasks I have overdue at work during the weekend as I’m not going to do anything about them anyway.

At the same time, I don’t want to see that I’m late on my phone bill while at work, as it’s super distracting.

Previous setup

My previous Todoist setup was heavily deadline-driven. If something should get done, it gets a specific day, and I will pluck it from the Today view when the time comes.

This system kind of worked but had a bunch of weak points:

  1. By pretending that everything has a hard deadline (most things don’t), my prioritization became about hitting as many arbitrary deadlines as possible, not focusing on what’s the most important.
  2. Brutal for work that involves async collaboration. Deadlines for personal work items are very stressful when working asynchronously. Response time and quality vary significantly between people within async companies, so planning to finish tasks requiring collaboration within a specific day is a fool’s errand.
  3. My Todoist required constant upkeep—rescheduling late tasks, scheduling new tasks, etc. If I didn’t do it for two days, the overdue tasks overwhelmed the app, and I became resentful of opening it, compounding the problem.
  4. Keeping personal and work tasks were difficult, as they both surfaced in the Today view with Todoist.

New setup

To tackle the above problem, my new setup has several building blocks:

  1. The @current and @upcoming labels indicate work that is in the current or upcoming batches. However, I define those two timeboxes.
  2. Only tasks that must be completed by a specific date get a due date, nothing else.
  3. Only two top-level projects exist in my account: Doist (where I work) and Personal. Both of these have many subprojects.
  4. Finally, four filters. Personal (current)Personal (upcoming)Doist (current), and Doist (upcoming)
The Personal (current) filter view

For Todoist pros, the queries are as below.

Personal (current)
##Personal & (@current | today | overdue) & !assigned to: others

Personal (upcoming)
##Personal & @upcoming & !assigned to: others

Doist (current)
##Doist & (@current | today | overdue) & !assigned to: others

Doist (upcoming)
##Doist & @upcoming & !assigned to: others

This system allows me to meet all actual deadlines while still tailoring my day based on where I feel I can make the most impact today based on which collaboration ping-pongs moved forward and how I feel.

As a bonus, it also cuts the time I need to spend on rescheduling tasks as I need to switch from @upcoming to @current and scout for the next @upcoming tasks only when I’m done with the @curent ones. I still typically do this weekly at work, but it’s much more fluent for my personal life.

I hope you found learning a bit about my setup helpful, and if you’re struggling with your Todoist setup, you have walked away with some fresh ideas for things to try! ~


Poor Man’s Product Research Tips

My team is responsible for developing a diverse array of integrations into other products. We don’t use most of these products and lack the intuition to figure out how to connect them with our products in a helpful way. For that reason, user research has become indispensable to help us learn what integrations to develop and what shape they should take.

At the same time, our company as a whole is vision-led, without dedicated user research resources. If you want to make user research happen, you have to do a lot of the leg work, with only occasional help.

And that’s exactly what we’ve been doing over the past few months. In this post, I’ll share a few tidbits that I’ve learned that help with running lightweight user research efficiently on the side.

The below ideas assume that you want to do user research but don’t have much experience and need the process to be dirt cheap, as you need to take care of your other responsibilities.

#1 Talk to users before planning anything

User research can be intimidating to start with if you don’t have prior experience. There is a large body of theory on meticulously planning your research – calculating sample sizes, thinking about different kinds of interviewer bias, sending out screening surveys, etc. I’d recommend that you hold off on the planning a bit.

Instead of jumping straight into planning, conduct a few semi-structured user interviews first. It doesn’t matter where you find the users; internal users work as well. Prepare a couple of questions, but let the discussion descend into chaos if the interviewee feels like sharing. Look for similarities between what interviewees care about.

Once you have a couple of interviews under your belt, you will be in a much better place to decide on the exact goals of your research and what questions to put into the screening survey. Talking to users gives you a better sense of which direction you want the research to take. It’ll also whet your appetite for more opinions, which is crucial for grinding through dozens of interviews with a smile.

#2 Practice writing meeting minutes

If you’re alone for the interviews, writing coherent meeting notes is a critical skill for executing user interviews.

There are two main ways you can record the contents of a user interview.

First, recording the audio/video of the meeting. This approach gives you a carbon copy of the meeting for posterity. Nothing else beats it in terms of completeness. It doesn’t come without downsides, though. Unless you combine it with an outstanding transcription tool, reviewing the interviews is very time-consuming. And no matter what the interviewee says, knowing you’re being recorded makes many people uncomfortable and alters their behavior, making them less willing to share.

Second, typing up meeting minutes as the interview is happening. You can opt for having a colleague in the meeting to type up the meeting notes. This is great but also risks that the interview will start feeling more formal, making the interviewee less comfortable sharing.

Personally, I enjoy typing up the meeting notes myself as they are happening, for a few reasons:

  • Provides the most “private” atmosphere conducive to interviewees sharing the small and embarrassing details that can reveal significant usability gaps in your solution.
  • I end the meeting with a complete transcript containing bits of my thoughts about what the interviewer said, things to check later, etc. It takes only a bit of time to polish the transcript up after the meeting, and it’s ready to be shared.

This said, making meeting notes of a user research interview is hard. You need to keep typing and thinking at the same time. You are not used to the particular person’s accent and way of speaking yet. And sometimes, you just don’t get what the interviewee is trying to say, so you’re not even sure what you should be writing down.

If you’re not strong at doing this kind of note-taking, I recommend you volunteer to be the meeting notes taker for as many work meetings as you can, even if no one reads them. This helps you improve your speed and notes coherency over time, making you a stronger interviewer in the process.

#3 Source Interviewees on Reddit

This bit of advice only applies if you work on something that is or interacts with a consumer-facing service, it might not work as well for business-to-business offerings.

Sourcing people for research on Reddit is a slam dunk.

Compared to any other potential source of interviewees I’ve tried (Twitter, emailing existing users), Reddit is an excellent source of candidates for users research, for a couple of reasons:

  • Ease of use – While sending bulk emails takes you down the path of trying to put email addresses from a CSV into the BCC field (I’m doing it via Excel + Outlook for Windows), writing a post on Reddit is as easy as it gets.
  • Better engagement – Without knowing too much about Reddit, it feels like it’s where people go to deep-dive into a topic, not only skim the surface. If you ask folks to fill out a survey, people who upvote the post also tend to fill it out. Conversely, my tweets asking the same end up with more likes than responses.
  • Diversity – One of my significant concerns about Reddit is that I’ll end up talking to people that fit a similar mold. It couldn’t be further from the truth. Within a span of a few dozen interviews, I ended up talking to university professors, actors, product managers, CEOs, students, and more. While interviewing Redditors will skew your sample towards the “advanced & passionate” crowd (whatever that means in your context), it’s a great starting place for many kinds of user research.

I’m not arguing that Reddit should be your sole source of interviewees, but that it’s a great start. If you can, pad your sample with different kinds of users. Namely, users that just entered your product category or are trying out your product will provide a great counter-balance to the Reddit crowd. This combination, in turn, gives you a stellar overview of the field, from rookies trying to figure things out to “wow, I didn’t even know you could make that work in my app” kinds of users.

#4 Learn mocking & reuse existing mocks

At some point, you will want to show the interviewees mocks of your ideas. If your company has designers, asking for a little bit of help can take you far.

I got very fortunate to get help from one of our stellar designers when thinking about the first batch of mocks that I’d like to show to the users in the interviews. He prepared a few mocks and shared them in Figma, which allowed me to reshuffle and iterated on them quickly without depending on someone having time to help me.

If your company already uses a tool for mocking, learn at least the basics. Ask around about where do designers store mocks and if you can use them. If you can find a cache of pre-existing mocks, you’ve hit gold. Adopting existing mocks is much easier than making new ones from scratch; reuse saves you a lot of time.

Hopefully, the tips above will help you kick-start your guerilla user research, generate great ideas, and fine-tune them while also having a ton of fun!

Cover photo by David Travis via Unsplash

Leadership Remote

Hard Work

The best way to grow professionally in remote leadership positions is to proactively take over hard work in adjacent domains from your peers or boss. You will expand your ability to execute complex cross-team initiatives and prepare for the next step in your career.

This is the idea that stuck with me the most from reading An Elegant Puzzle. Let’s go deeper.

What Is Hard Work?

Hard work is:

  • Any work nobody is asking you to do.
  • It doesn’t look fun; nobody is rushing to do it.
  • Work outside of your domain and comfort zone.
  • Poorly defined, with loose criteria of success.
  • Requires functional skills you don’t have.

Example 1: You’re an engineering lead. Your scope is to lead the development of an API and accompanying docs. In one of the technical leads meeting, you learn that the company is gearing to revamp the budgeting process. This change will have a significant impact on all technical leads. Someone should represent engineering in the process. The head of the engineering org is swamped. Taking responsibility for representing eng’s interests is hard work.

Example 2: You’re a customer success manager. One of the technical teams is a frequent source of bugs that you hear from customers; long bug resolution times make some customers abandon the product. This is a frequently discussed topic in the company, but there’s no obvious resolution. You proactively offer to help the technical team improve their backlog management and find an effective triaging process. You don’t know much about the technical teams’ internal processes, but you have a great understanding of customers’ priorities. Crossing the team boundary to the other side and finding a solution within another team is hard work.

You can probably come up with several examples like this within your company without much thinking. All of these represent hard work.

Why Do it?

Aside from flexing your problem-solving muscle, hard work confers several benefits that are hard to find elsewhere:

  • Understand Other Teams
  • Understand Your Boss
  • Grow Your Horizontal Expertise

Understand Other Teams

Taking jobs in adjacent domains enables you to understand other teams at a level you can’t attain by reading docs or attending meetings. If your company doesn’t have a rotation program for managers, taking on hard work is one of the best ways to become a part of other teams within the company temporarily.

By moving work through other teams, you learn their cultural norms, what makes them tick, and their process.

This knowledge is a superpower when executing cross-team projects with ever-increasing complexity, a frequent expectation of all managers.

Understand how other teams spec out work, prioritize and schedule enables you to tailor information to their needs when the time comes. You will find yourself collaborating with them with little time to getting to know each other; serving information in the right way makes collaboration easier.

You will also understand how other teams operate within the context of your company. You will discover many tricks and strategies on how to work within your company’s system effectively. This information is specific to your company, so other teams are one of the only ways to source it.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Understand Your Boss

In many cases, taking on hard work means easing your boss’s load in one way or the other. Frequently hard work takes the form of representing your broader organization within the company or helping other teams within your org. These are workloads core to your boss’ role.

By executing hard work, you’re working on tasks that’d be your bread and butter if you were promoted into the next position on the company ladder. Hard work allows you to build an “ahead-of-time” experience that provides a peek at what’s next. Will it be a route you’ll end up liking? You’ll also make a stronger candidate in your company or others when the opportunity arises.

Even if you’re not gunning for your superior’s position, micro-dosing their workloads into yours can work wonders for your mutual partnership.

By taking your boss’s viewpoint, you can much better appreciate their points of leverage and uphill battles they’re facing. This new information helps you understand where you can offer valuable help and, conversely, what your boss can deliver to you. Your 1:1s will become more engaging as suddenly you share several workloads and challenges, sparking exciting conversations and lessons you can apply back in your home team.

Horizontal Expertise

If you’re a lead, you should already be exceptional in your functional domain.

But to take the next level in your career requires more. You need to become a versatile leader with a broad set of knowledge in many functional areas – from marketing through product management to financial management. After all, the higher echelons of leadership are all about cajoling a diverse set of teams into pursuing a shared vision, goals, and process. Understanding individual vantage points is essential.

There’s no better way to ramp up quickly in a ton of functional areas than collaborating with other teams in the company within their domains.

When working with other teams, you’ll take part in their daily decision-making and pick up on considerations unique to the specific team. You’ll gain new vocabulary for discussing particular kinds of problems. And you’ll understand why they balk at seemingly minor asks.

All of this information will become immensely valuable in the future when you try to align your team’s resources, strategy, and execution tactics with other teams. The ability to appreciate specifics that matter to other teams enables you to take them into account ahead-of-time instead of becoming predictable scope creep mid-way during a complex project that’s already late.

Where to Find It?

If you’re convinced that hard work is worth tackling, where can you find it within your company?

This is where things get easy. There is a lot less competition for hard work.

In meetings, company chat, and anywhere else your company communicates, look for phrases like:

  • “It’d be great if someone…”
  • “We could really use…”
  • “We we’ve been talking about this for six months already…”
  • “There’s no responsibility for…”

These are all hidden prayers for someone to pick up the flag and run with it. In many cases, they’re loosely formulated as the person uttering them doesn’t have the time to specify the problem and required steps to solve it in detail. (this is a core part of dealing with hard work after taking it on)

Every time you hear these prayers, think about if the problem at hand sounds like a good learning opportunity, and if the risk that it brings is acceptable.

Try to prod a bit for more information before offering help, but most of the time, you will need to take a leap of faith and offer up a firm commitment.

If you manage your time well, you should always have a bit of slack time available for unexpected work. If you don’t, taking on additional work outside of your core scope is a great opportunity to improve your downward delegation ability and transfer some of your current responsibilities to your team temporarily (and hopefully make the changes permanent).

Note for Remote Leaders

In remote settings, we tend to have less organic collaboration and low-touch interactions with other teams. The social bonds that become bridges for organic collaboration between teams are weaker, and opportunities to strengthen them are scarce.

This scarcity makes hard work all the more valuable in remote settings. It’s one of the few tools to consistently increase ties to other teams and getting insights that allow you to find cross-team synergies that help your company thrive.

In Closing

As you take on hard work consistently, you accumulate essential knowledge that makes it easier to execute more of it. You enter the virtuous circle of collaboration where a robust internal network enables you to take shortcuts to success, becoming a ninja facilitator of the company’s most complex workloads in no time.

If this sounds great, you probably already have a couple of ideas about where you could make an impact. Commit and start your growth through hard work!

Photo by Thomas Marban on Unsplash (much like omakase sushi, hard work comes loosely defined and with high expectations 😋)


Cookie-Based Redirection with Express.js

Many sites these days have strictly separated their marketing pages from the main web app.

  • is where the marketing landing page lives
  • is where the web app lives

It’s common to redirect the users to /app when they have an existing authentication cookie for a faster experience.

If you don’t have a dedicated proxy and host both the landing pages and the web app on the same Express.js server, your setup might look as follows.

import express from "express";
import path from "path";

const app = express();

// Serves web app

// Serves landing pages

const port = 8080;

app.listen(port, () => {
    console.log(`started on port ${port}`);


To set up the server-side redirect, we need to pull together a few pieces:

  1. Read the Cookies
  2. Write Redirect Middleware
  3. Use Redirect Middleware

1. Read the Cookies

To read the cookies, we can use the cookie-parser library. After doing npm install cookie-parser, we add it to index.js as the first piece of middleware as follows:

const app = express();

This will result in cookies available at request.cookies within our middleware.

2. Write Redirect Middleware

Next up, we need to create a piece of middleware that’ll look at the present cookies and perform the redirect if an appropriate cookie is found.

If you’re unsure about the concept of middleware in Express.js, have a quick peek at the docs first.

const redirectIfAuthenticated = (cookieKey, cookieTrueValue, redirectPath) => (req, res, next) => {
    const hasCookie = cookieKey in req.cookies;
    const isAuthenticated = hasCookie
        && req.cookies[cookieKey] === cookieTrueValue;

    if (isAuthenticated) {


The middleware checks for a specific cookie and that it has the desired value. If it does, the middleware redirects the user to the specified path, otherwise, it passes the request to the next middleware in the pipeline.

3. Use Redirect Middleware

Lastly, we need to apply the middleware to intercept all calls to our landing page at

We do this by adding the middleware to the app.use call that serves our landing pages, like so:



And we’re done. 🎉 Now all requests that contain the cookie authcookiekey=true will be redirected to

Entire Solution

For convenience, here’s the entirety of app.js after we’re done.

import express from "express";
import cookieParser from "cookie-parser";
import path from "path";

const redirectIfAuthenticated = (cookieKey, cookieTrueValue, redirectPath) => (req, res, next) => {
    const hasCookie = cookieKey in req.cookies;
    const isAuthenticated = hasCookie
        && req.cookies[cookieKey] === cookieTrueValue;

    if (isAuthenticated) {


const app = express();


    express.static(path.join(path.resolve(), "..", "build"))

    redirectIfAuthenticated("authcookiekey", "true", "/app"),
    express.static(path.join(path.resolve(), "..", "landing/public"))

const port = 8080;

app.listen(port, () => {
    console.log(`started on port ${port}`);

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Image Credit: Photo by Jens Johnsson on Unsplash


Becoming a Native Remote Citizen

In this post, I’m trying to summarize the pitfalls of working from home without the remote-first mindset I’ve experienced. I’m also adding a few tips that worked for me over the years. They helped me at various points of my remote journey. I hope others will find them useful as well!

This year, I’ve seen many of my family members and friends transition to working from their homes full-time. In most cases, their workplaces were not built for remote-first and now embrace the always-online culture. Hearing their experiences reminded me of how tough is the journey from working in the office to being fully-remote.

I’ve had the luck to work at Doist since its relatively early days. We’ve built Doist as a fully-remote company from the ground up. This advantage gave us the luxury to develop our culture and process from the ground up to complement remote work’s strengths and avoid its pitfalls.

We’re not the only ones; other great companies like ZapierGitLab, or Toggl together form a community of remote-native companies. Remote-native companies vary in many aspects, but they frequently emphasize two aspects of their culture:

  1. Asynchronous communication whenever possible. The belief that preferring longer-form but slower forms of communication produce better outcomes while taking less toll on their workforce by removing the “always online” requirement.
  2. Work-life balance. The belief that working 12+ hours a day is not sustainable and will hurt both the employees and the company in the long-run.

Asynchronous communication and work-life balance are tightly complementary. Work-life balance is hard to achieve with constant requests for meetings and phone calls from dawn to dusk. Asynchronous communication is likewise hard without minding work-life balance; slipping into DMs is just too comfortable without a mental block in place.

Unfortunately, many companies transitioning to online-first culture are altogether eschewing both asynchronous communication and work-life balance.

Late-night pings or Teams or Slack are commonplace, and so are meetings scheduled in the previously-sacred lunchtime. The amount of meetings has not decreased; online meetings are even more draining compared to in-person ones. To top it off, many people end up working longer hours, creating the perfect coctail for burnout.

A less talked about but crucial aspect of working from home while eschewing async communication and work/life balance is an impact on the family. Doing homework while your mom is going through a series of heated meetings in the other room is a draining experience for the kid. And for the rest of the family as well.

In short, lots of companies are going remote but are not picking up remote-native practices, hurting their people and themselves in the long-run.

In companies where the big picture is hard to influence, I’d like to share a few practical tips that helped me over the years, from two distinct perspectives:

  • Individual Contributor Tips. Tips you can apply individually, without requiring broader buy-in first.
  • Team-Wide Tips. If you can influence your team (being the team lead helps, but it’s not necessary), these tips could come in handy.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Individual Contributor Tips

Talk to your team lead. The first thing I recommend. It’s your team lead’s job to make sure you have the best possible conditions to succeed. If the new team meeting interferes with you needing to pick up your kid from school, it’s your team lead’s job to figure out a solution. If you’re exhausted by all the Zoom calls, ask your team lead to work on a team process that’s less meeting-heavy.

Ask for an agenda before accepting a meeting. If you can, explicitly ask for a written agenda before accepting a meeting or a call. If the other person can’t present an agenda, try to politely postpone the meeting until there’s one. Even if you fail in delaying the meeting, you have created an expectation for next time, resulting in fewer meetings down the road.

Comment on the agenda before the meeting. If you get an agenda before the meeting, try to reply to it with what you’d say during the meeting and ending the email with something along the lines of Let me know if you’d like to discuss further; otherwise, we could skip the meeting? Most people want to skip meetings as much as you do; make it as easy for them as possible.

Delay responses to unimportant requests. If you get lots of DMs from specific people asking you about things they could quickly solve themselves, intentionally delay your answer. This is frustrating for the other person in the beginning, but you motivate them to self-solve. In the long term, the stream of messages slows to a trickle; everyone is better off.

Unapologetically exit overtime meetings. If you have a problematic meeting scheduled for 30 minutes but routinely running for 60 minutes, try to schedule one of your meetings to follow the problematic one. This allows you to exit the first meeting at the 30-minute mark gracefully. Be explicit that the meeting was scheduled for 30 minutes and that you have another meeting coming up. Doing so generates pressure on the meeting organizer to run the meeting better and not go overtime. 

Have a hobby with scheduled events. Having hobbies with fixed time slots (language lessons, music band practice, etc.) that are hard to cancel is incredibly helpful to help to build the crucial work/life boundary.

Most of the tips are about adding small bits of friction to reduce the frequency of interruptions. If people contact you, they should feel a bit of pressure to come prepared.

Team-Wide Tips

If you can effectively influence your team or set policy, you’re well-positioned to improve your team’s well-being and long-term productivity.

Model individual contributor behaviors. If you start rejecting meetings without an agenda and make it clear that it’s ok to not respond within five minutes, as suggested above, your team will quickly follow and adopt the same behaviors.

Create a “Meeting Best Practices” document. Early during my time at Doist, we created a policy for conducting meetings that enshrined best practices like “no meetings without an agenda” or “all meetings last a maximum of 60 minutes”. This made it clear that meetings have limits. Having a similar policy on the team level can improve the meeting culture as well.

Designate a specific person to run team meetings. If you have a person in the team who enjoys running meetings and can devote energy to it, ask them to run team meetings. In many cases, this person will not be the team lead. If you can find a great person for this job, you’re giving the whole team a role model and a mentor for running effective meetings.

Promote a culture of sharing current stress levels and emotional challenges. By openly talking about your mood, stress levels, or health problems and encouraging the whole team to do the same, you can create a team culture of caring for each other and cutting folks slack when they’re not at their best. Team members are great at supporting each other through burnout or other work/life balance issues, but they need to know that it’s happening.

Model, document, and share. As suggested in the book An Elegant Puzzle by Will Larson, once you find behavior that works and spread it in your team, consider evangelizing it beyond your team as well. Other parts of the company will be happy to adopt battle-tested solutions to problems they’re also likely facing.

In Closing

Becoming a remote native is a journey. Working remotely has many great perks, but setting firm boundaries early in the process is essential to preventing burnout down the line.

Solid boundaries take time to build, especially within companies new at remote, but they pay off with sustainable personal and team performance in the long-run.

If you’re new to remote, take care of yourself, and be honest about your limitations to your team as well as to yourself.

Image Credit: Photo by XPS on Unsplash


Book Recap: An Elegant Puzzle by Will Larson

An Elegant Puzzle: Systems of Engineering Management by Will Larson is an excellent entry into the growing collection of books by Stripe Press.

The book is a personal narrative of leading larger technical organizations. It presents the author’s take on some of the most crucial challenges like organizational design, the hiring pipeline, career narratives, and product work.

In this post, I’m trying to pick out some of the best gems I’ve found. There’s a lot more to the book than I’m covering here; it’s a worthwhile read.

Four States of a Team(‘s Technical Debt)

Technical teams can be in one of four stages of technical debt.

Understanding the current stage helps the manager pick the right approach to guide the team along the progression curve.

  1. 😩 Falling Behind – The team is taking on technical debt. The system fix is to find quick wins and keep up the morale while hiring more people.
  2. 🤹‍♂️ Treading Water – The team is not taking on more debt, but it’s not repaying it either. The fix is to limit work-in-progress (kanban can be a great tool here!) and ensure that team members primarily look at the overall team performance instead of their individual one.
  3. 👷‍♂️ Repaying Debt – The team is paing down technical debt. Support the team by giving them more time to continue debt repayment and look for easy user-facing wins to prove to stakeholders that the team is not staying still, alleviating external pressure to stop focusing on debt repayment
  4. 💪 Innovating – The team’s technical debt levels are low and they are free to move quickly and innovate. Maintain slack (i.e., don’t aim for 100% utilization), innovate, and ensure that innovation is valued within the broader company

Grow Teams in Bursts

After each hire, a team undergoes a gelling process, i.e., going through forming-storming-norming-performing. Adding new hires disturbs this process and resets it to a degree.

For that reason, the author recommends going through “growth spurt” periods with periods of low hiring activity in between. This approach gives teams time to gel fully before adding more members that restart the process.

Ad-hoc Communication

Ad-hoc communication is a know productivity killer. Asks for help, feedback, troubleshooting assistance, external communication takes a lot of time.

The recommended setup is:

  • Funnel all team interruptions into an ever-smaller surface and automate aggressively (i.e., ask people to file tickets instead of having ad-hoc conversations)
  • Create a rotation of people that manage this communication surface

On a side-note, at Doist we handle this by having a “hero role”, which is a similar concept. We have a blog post if you’re interested in the details!

Goal Definitions

A good goal has four parts:

  • A target to reach
  • A baseline that defines the current state
  • A trend that describes the current velocity if no action is taken
  • A time frame in which the target should be reached

An example of a good goal would be: In Q4, we will improve the 2nd-day retention of our plugin users from 15% to 25%. Since the launch of the plugin, the retention has remained static at around 15%.

When defining goals, setting a countervailing metric can be useful to prevent focusing solely on reaching the target to the detriment of other metrics.

You can read more about goal setting on the author’s blog.


Lastly, here are a few snippets from the book that are interesting even outside of their context:

  • There is a lot less competition for hard work. When discussing how to grow professionally, the author points out that it can be more useful to picking up new work areas instead of focusing on the formal career ladder. EDIT: I kept thinking about this one and have written a subsequent blog post about it here.
  • It’s one thing to know that you’ve never used your education budget, and something else entirely to know that you’re the only person who isn’t using it. Showing people where they fall on the distribution to make a strong point.
  • Treating your peers as your first team allows you to begin practicing your manager’s job, without having to get promoted into the role first. This rings true with my experience! Taking on your manager’s work leads to closer collaboration with the manager as you’ll get insights into the problems your manager is having.
  • Rather, that approach (weeding out folks who don’t show passion about their work during the hiring process) seems to mostly filter for candidates willing to represent enthusiasm, as opposed to finding authentic passion. Something I’m always mulling over when discussing the hiring process as there’s frequently contention about this point.
  • Because (career) level expansion is typically driven more by the need for career progression than by the introduction of objectively distinct accomplishment, levels added at the top create downward pressure on existing levels. Expectations at a given level decrease over time. Having worked intensely on career definition in the past year, I’m curious if this statement will turn out to be true.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Cover Image Credit: Photo by Jeffrey Blum on Unsplash


“Partnership Feeler” Meetings

Organizing productive meetings with clear-cut purpose, contained to your team and company is challenging enough.

Then there are the partnership feeler meetings.

The purpose of the partnership feeler meetings is to establish a personal connection with a potential partner company while brainstorming ideas for possible collaboration, ideally within thirty minutes. It’s a tall order, especially for folks who are not born salesmen.

Compared to other forms of meetings, it comes with a few twists:

  • Lack of a prior connection makes it impossible to tailor the meeting to the preference of your counterparts.
  • Various stakeholders on both sides are curious and it could be useful to include them, but only a few participants contribute during the meeting.
  • Abstract meeting goals that frequently boil down to trying to find something to talk about in subsequent meetings.

The structure of the feeler meetings usually consists of:

  1. Pre-meeting. One person from either company initiates a meeting; people are looped in and invited; agenda is set.
  2. Small talk. At the onset of the meeting, people from both sides try to break the ice.
  3. Going over the Agenda. The meat of the meeting where ideas for collaboration generate before the meeting are discussed.
  4. Follow-Ups. Follow-ups of the most promising ideas are identified.
  5. Post-Meeting. Teams from both companies internally discuss their feelings about the meeting and potential next steps.

Nailing the partnership feeler meeting is a sum of excelling at executing the individual parts. Let’s examine them individually.


Keep the circle of participants from both sides as small as possible. People frequently join because they’re curious about the other company, but they have limited stake in the meeting. Being overly inclusive leads to large meetings with lots of uncomfortable silence. Make it clear that no definitive decisions will be taken during the meeting and you’ll keep notes and distribute them afterward. This disclaimer helps quell people’s fear of missing out and gives them an easy out of the meeting.

After you have the participants list, reach out to participants from your company and brainstorm ideas together. This will lead to stronger ideas and better engagement during the meeting. Sometimes you won’t avoid creating a presentation solo, but it’s always better to make it a team effort, even if others’ contributions are only symbolic.

Once you have the agenda ready, send it to all participants well ahead of time (at least a day, ideally more). This helps the partner company form an opinion on ideas and creates a bit of healthy pressure on them to come up with counter-ideas. Once you know that the other side has done a lot of prep, you don’t want to look bad by going to the meeting empty-handed.

Also, always prepare slides or other visual assets that you can share as agenda during the meeting. They help immensely with focusing the discussion and injecting a sense of momentum.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Small Talk

Most partner meetings start with small talk that focuses on either very general things (weather, season, etc.) on sharing tidbits about how each company works.

If you can, direct the small talk into talking about your respective companies. You can quickly gain bits insight into how the other company works and set expectations for yours. Small talk is a great opportunity to understand the planning cycles or organizational quirks of the peer company and share yours. If you can make this discussion happen, it can become the most valuable bit of the entire meeting. Whether the other company runs weekly sprints or if they execute top-down quarterly plans will have a big impact on your future relationship. Getting this information early is a win.

The fewer participants you have in the meeting, the better the small talk opportunities. Making fun of the process quirks is something people are understandably not comfortable doing if large portions of their company are present. Keep in mind that you also need to be comfortable sharing.

Lastly, don’t skip introductions.

Going over the Agenda

This part is similar to other kinds of meetings.

Ensure that the conversation is inclusive, and everyone is comfortable with sharing ideas as well as asking questions.

Keep in mind that the goal of these meetings is to generate ideas and establish rapport. Sticking to the agenda is less important compared to other types of meetings. If the meeting derails into an unstructured discussion, it’s a good signal that rapport is being built and ideas are flowing. If you tend to be a stickler about sticking to the agenda, loosen the reins a bit for this meeting.


If you succeeded during the Going over Agenda portion of the meeting, you have several concrete actionables in your meeting notes. Take a few minutes to recap the actionables for both sides and ensure that it’s clear who is responsible for the follow-ups.

Asking companies you’ve just met for deadlines might not be possible. Still, by sharing a specific timeline for individual actionables you’re responsible for and asking participants from your company for the same, you can maximize the chances that the partner company will commit to a specific timeline for follow-ups as well.

It’s helpful if you can formulate the actionables as concretely as possible. “Discussing with engineering and sharing which of the ideas are in principle doable” beats “Thinking about it more and regrouping in two weeks”.

Besides being more useful generally, concrete actionables make it easier to inquire about progress from either side should there be a lack of communication in the weeks following the meeting.


After the meeting itself is concluded, it’s useful to reach out to participants from your side to gauge the overall feelings and ensure alignment on the next steps. In most cases, you shouldn’t need another internal meeting to do the debrief; a few messages can do the trick just as well.

Don’t forget you’ve committed to provide meeting notes to people not attending the meeting. Take a few minutes right after the meeting to polish the notes and write a meeting summary, sharing it with all participants in the meeting and with any people who expressed interest. The longer you wait with this step, the longer it’ll take to clean up the meeting notes. You start forgetting nuances of the meeting the minute it ends.

Lastly, ensure you’re tracking follow-up items in the appropriate place. If they’re only in the meeting notes, it’s easy to forget them. Adding them to your task manager or the team issue tracker will help follow-up more consistently.

In Closing

Don’t worry if you feel like some of the partnership feeler meetings aren’t productive. You can do everything right; some meetings will still be unproductive. Not all partnerships are meant to be. Walking away with an understanding that the company is not a good fit is a valuable takeaway as well.

Regardless, excellent preparation and a positive attitude go a long way and positively impact the value you get out of these meetings, helping you find the best companies with which to partner.

Cover image credit: Photo by 🇨🇭 Claudio Schwarz | @purzlbaum on Unsplash


Engaging Your Interviewer

We’ve been looking for Windows devs to help us work on our Todoist for Windows 10 app.

I want to share a few tips on how to have a good interview. They’re based on my interviews of around 50 people. If the tips feel basic, you’re probably already making a consistent strong impression during an interviews!

For the busy crowd, the tips are:

  1. Prepare Good Questions
  2. Go into Specifics
  3. Provide Criticism
  4. Have a Conversation
  5. Don’t Ramble

1. Prepare Good Questions

This is a big one. Lots of candidates have no questions. Not about the role, not about the culture, not about our tech. It’s a red flag for a few reasons:

  • The candidate didn’t prepare for the interview. It might not be true, but a lack of questions creates that impression.
  • The candidate doesn’t care about our specific company. We’re looking for people excited to live our culture and build our products.
  • The candidate lacks curiosity. Again, it might not be an accurate assessment. But when you go through our blog and products, at least a few questions should pop up.

Thoughtful questions give you more information about us. They also serve to show your qualities as a prospective colleague.

Great questions are many, here are few common themes:

2. Go Into Specifics

Some candidates are reluctant to talk about the technical details of their work. It gives the interviewer less information to assess a candidate’s technical prowess.

I sometimes share this feedback with candidates. They frequently say they were afraid to stay within the interview time constraints. The best candidates demonstrate their expertise while keeping their answers concise.

Interviewer: “Can you share a technical difficulty in your last project and how you overcame it?”

Interviewee — Bad Response: “We were working with a large codebase that was very complex. Our biggest challenge was to try to simplify it. We worked for a few months on making the overall architecture more simple. We successfully made the app more maintainable.”

Interviewee — Good Response: “We inherited a monolithic codebase. It was tough to introduce new features without unintentionally changing behaviors of other parts of the system. So we broke the code into smaller components while using a DI container. We picked Unity because the interception feature is cool; we use it for a few cross-cutting concerns. Do you use a DI container in the Todoist UWP app?

3. Provide Criticism

It’s very hard to be critical of what the interviewer says. You want to make a good impression and are afraid that the interviewer won’t like you if you criticize them. If they get offended, you’re better off looking for a different job anyways.

Candidates that offer constructive criticism during a job interview impress. Giving feedback during an interview shows you enjoy both providing and accepting feedback. Willingness to express criticism under challenging conditions an essential quality for companies that want to keep improving.

For more on how to provide good feedback, give the Radical Candor book a shot.

4. Have a Conversation

This one is the hardest to do, especially if you’re not a great conversationist. But if you manage to draw the interviewer into a discussion, you will make a strong impression.

Aside from creating a strong impression, there are other benefits. Having a fluent conversation reveals more about company culture and engineering values. In cases where the interviewer is your future team lead, you can get a much better sense of what kind of boss they’d be.

If you don’t feel like a skilled conversationist, here are a few great tips from Sean Plott, one of YouTube’s engaging storytellers.

Sean’s Conversation Tips

5. Don’t Ramble

Rambling answers are common during job interviews. The interviewer asks difficult questions, and the interviewee doesn’t always have a crisp answer at hand. It’s easy to start answering and come up with the rest of the answer on the go. Don’t do this.

If you get a hard question, follow a three-step process:

  1. Take a few breaths; organize your thoughts.
  2. Answer the question.
  3. Stop talking.

Step three is the most difficult one. You will inevitably come up with more imaginative ways to answer the question as you’re answering and want to share it. This approach frequently results in hard-to-understand trains of thought from the interviewer’s point of view. It’s better to finish your thought and let the interviewer engage if they choose to.


When having interviews, try to be engaging and give the interviewer enough information to make a fair assessment.

Adopting these tips can also make the interview a fun experience; instead of a tense and stressed-filled one.

If you notice you’re having a good time while the interview is happening, you’re on your way to getting a great job. The best interviews are the ones where everyone learns something.

Cover Image Credit: Photo by Juri Gianfrancesco on Unsplash


Book Recap: Scrum, The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

One of the strongest books I read this year. Well written and to the point, it dives deep into motivations behind the elements of Scrum.

While the book focuses on “pure” Scrum, many of its ideas are applicable beyond Scrum as well.


Scrum is a way to build fast-moving, cross-functional teams. Some of the basic elements are:

  • Team performance is the main focus. Measuring individual performance is not a core part of Scrum.
  • Gain commitment and speed by time-boxing. Time-boxing is the practice of assigning work to a specific iteration. Every iteration has an equal, fixed duration. In contrast, Kanban achieves commitment and speed by constraining work in progress. More on that my next post 🙂
  • Relative estimation is the preferred method of sizing up work. The core idea is that relative comparisons of task complexity and size are less error-prone than estimating effort in hours.
  • Teams determine their capacity by looking at historical performance, called velocity.
  • Commitment to continuous process improvement is a core part of Scrum. Every iteration should yield ideas for further improvement in the process. These small improvements are called kaizen.
  • Scrum measures team happiness by the end of each sprint. Happiness is a leading indicator of future performance. According to Andy Grove, tracking and evaluating leading indicators is one of the most critical activities a manager should do.
  • Road maps are loose visions at best. The actual plan changes from sprint to sprint based on learnings from past sprints.

Further reading: Microsoft published a research paper that discusses practical concerns of implementing Scrum in software engineering teams. It’s a good read.

Solid Ideas

Shuhari 守破離. Breaks down mastery of Japanese martial arts into three stages.

  1. In the first stage (守), you obey rules without question.
  2. In the second stage (破), you experiment with breaking the rules and making them your own.
  3. In the final stage ( 離), you become the physical manifestation of martial arts ideals, rendering the rules irrelevant. This is an amazing way to think about learning any kind of system, including Scrum.
Image for post

Cross-functional teams. Small autonomous teams, also called feature teams, are the best way to organize work if you want to move fast. Instagram recently moved to this model. There are a few reasons for this kind of team:

  • Hand-offs between teams are an opportunity for disaster. Hence you need your feature teams to be cross-functional
  • The goal is set outside the team, but only the team decides how to achieve it
  • The marginal value of adding the 10th team member and above is negative

Use Planning Poker for effort estimation. Planning poker gets the best of the team’s collective wisdom when estimating. At the same time, it helps with preventing herd mentality and can surface diverging perspectives on implementation.

Process improvements are a part of the process. Kaizens are a fantastic idea for two reasons. First, by making process improvements a core part of the process they’re improving, you can make sure that they get priority. Second, by making it explicit that everyone needs to come up with kaizens, you increase the chance of soliciting good ideas from teammates.

The product owner needs to have enough time for the role. Jeff Sutherland recommends against appointing senior executives to be product owners. The reason is that a product owner is a time-consuming role. Senior executives tend to be time-constrained, so they might not be the best fit.

If you like the article, subscribe to email notifications to not miss future blog posts like this one!

Cover Photo Credit: Photo by Quino Al on Unsplash