When I have a bit more to say, I’ve found Typefully as a really nice writing tool. They also have a “Profile” view that rolls up tweet threads into blog post form. My latest posts are here:

https://typefully.com/philfreo

Enjoy!

Recently I spoke with our CEO, Steli, who just came back from his own sabbatical, about how our sabbaticals went and what we learned. Our conversation was recorded for our company’s internal podcast (we use Castos) but I thought I’d also write up some of my sabbatical thoughts and lessons learned while our conversation is still fresh…

Why take a sabbatical?

Besides just being a great perk to take advantage of, a sabbatical is meant to be a time for rest, recharge, and renewal.

I’ve been at Close a very long time (9+ years). Given enough years in the same environment, anyone can get burnt out or just want to take an extended break. Vacations and other regular time off (among other strategies) can help avoid this, however a week at a beach (knowing that your inbox is piling up while you’re gone), is pretty different than taking a more extended break away from work.

Both at Close and elsewhere, I’ve seen long-tenured employees quit or come close to quitting their job even without any specific plan on what they want to pursue next – simply because they felt burnt out or wanted unstructured time to reflect, deal with personal issues, and/or consider their next steps in life.

A sabbatical is a great way to have space for this, without having to quit or use up a year’s worth of vacation time all at once.

I think given several years in the same company, everyone would benefit from an extended break. Hopefully you come back refreshed and renewed!

Planning a sabbatical

Timing – When should I schedule my sabbatical?

Sabbaticals are best planned months in advance, to give yourself and your team adequate time to prepare for your absence. Beyond having advance notice, it’s also good to choose a time when (as much as you can foresee) things aren’t going to be too hectic, so you can truly disconnect during it.

I had first planned, in Feb 2020, to take my sabbatical in the fall of 2020. Not long after making those plans, COVID-19 introduced a huge amount of uncertainty into the world. It soon became pretty clear that 2020 was not going to be a great time to leave the company in great shape since it was such a chaotic time, nor would it have been good for me to be stuck at home on sabbatical. So I waited until things were returning to normal and the company was in a more certain state before I ended up taking mine, earlier this year.

That said, there’s never going to be a perfect time to be away from work, so at some point you just need to pick dates and commit.

Expectations, Hopes, and Goals

I had big expectations for my sabbatical. Beyond just wanting to take an extended break from work and recharge, I wanted to do a lot personally.

I wanted to spend a bunch of extra quality time with my family. We also wanted to take a vacation and take our kids to see snow for the first time.

In the several months prior, I had also accumulated a very large list of other things I wanted or needed to do. My Apple Reminders was full of tasks to accomplish, things to read/explore, home improvement projects, side project ideas, etc. I was excited to have time to really take a crack at this list.

Twice previously, I had taken 4 weeks off for paternity leave and had looked forward to those for similar reasons. But parental leave is very very different from a sabbatical – more about surviving, adjusting as a larger family, and helping with the baby/kids – pretty much the opposite of rest & renewal or lots of time for of personal interests.

Preparing at work

I lead Engineering at Close – nearly 20 people. It was critical that I left the team and company in good shape while I was on sabbatical so things could keep humming along without any disruption.

4+ week sabbaticals are pretty different than a 1-2 week vacation. If you go away for a week or so, things generally operate fine without you. For example you may only miss one instance of a weekly recurring meeting. People will still email you and just expect that you catch up on everything in a few days. At 4+ weeks away, it’s different. Initiatives don’t (or at least shouldn’t) really pause while you’re gone, and you can’t just catch up on everything when you get back. You need to ensure your team can really operate without you, versus just waiting on your turn.

So in the weeks leading up to my 4-week sabbatical, I worked hard to help the company be best prepared for my absence. Examples:

• I helped ensure that our product development roadmap/plan was planned out a bit farther than was typical.
• I wrote up new internal wiki pages to document processes that I had previously been doing that I wanted to start delegating.
  • Example: We introduced a new “Cycle Lead” role that an engineering manager would take on to be the person most responsible for a specific 6-week cycle of product development work and communicating that work to the company.
• Previously I had led all of our weekly Engineering Sync meetings. I changed that by setting a schedule with our engineering leadership team to rotate through leading these meetings both while I was out and after.

In addition to allowing the team to operate smoothly while I was on sabbatical, these were all good things to do anyway, and also gave a chance for others on the team to lead in new ways.

Writing more things down and having processes that don’t rely on you – these are all good things even if you’re not going on a sabbatical.

This preparation work allowed me to more confidently take time off without worrying about how things were going at work.

The Time Off

Finally, my sabbatical came! Now to enjoy it…

Keeping a log

First, I have one big tip for anyone taking extended time off…

I kept a daily log of what I “worked on” or spent significant time on that day. I just used an Apple Note and just wrote a few bullets grouped per day. A day might just look like:

• Gym
• Tax prep & call with CPA
• Lunch out + bike ride with family
• Caught up with Matt

This simple task helped with a few things:

1. Help have an idea of where your time went. It’s not hard to wonder “where has all my time been going?” after having long periods of unstructured time, and this helps.
2. Give a sense of accomplishment each time I added a new thing, even if that thing was just “fun” and not a task.
3. Prepare for others’ questions. Having a log helped me be able to look back over my entire sabbatical to be able to answer the common question every one of your colleagues will ask: “So, how was your sabbatical? What did you do?”

Don’t underestimate that last point… you can safely expect that pretty much every coworker you talk to in the following month will ask you what you did on your sabbatical. Especially if they haven’t had a chance to do a sabbatical yet, they may have big expectations for you! Be ready to give a clear answer. Reviewing a log can help.

So what did I actually do?

Looking over my daily logs, my time went toward the following.

• Family: More quality time with my own family every day. Met up with extended family we don’t see often. And when a family member was in the hospital, I was able to visit them.
• Vacation: Planned a family trip to North Carolina and had a great time: road tripping, mountain cabin, snow tubing, alpine coaster, met up with friends there.
• House projects: Organized garage, improved home audio setup, planned our house to be painted, got some trees trimmed, got some pool staining handled, fixed that pesky loose toilet paper holder, etc.
• Friends: Caught up with quite a few friends that I hadn’t talked to in a long time.
• Personal finance: Worked with a financial advisor, did a lot of reading about investing (Bogleheads, books, articles, FI/RE), did an EOY finance & spending review, did tax prep / worked with CPA, restructured some charitable giving, etc.
• Learning: Read a couple eng management articles, learned about some new tech stuff, listened to podcasts, watched some talks.
• Networking: Met with some local SaaS/tech people in my city.
• COVID vaccines: Got my parents appointments for shots, my wife and I got our shots (made calls daily looking for leftover doses, etc.) Felt a big relief after getting this “project” done!
• Tech projects: Improved my Raspberry Pi setup and a bit of work on other side projects.
• Shopping: research and buying a new kitchen dining table set, a new printer, etc.

In summary, my time was spent on a combination of:

• Family/fun/relaxation/downtime
• Work on my personal todo list
• Entertaining whatever unexpected things (good or bad) that came up

Reflection

4 weeks off sounds like a lot of time, but I didn’t get to do probably even half of what I wanted to do. For example, I thought I’d make a lot of improvements to a side project, but didn’t end up spending any time on it at all.

But I am happy with how I spent my time. In particular, I realized that I ended up spending a lot of time on good things I hadn’t planned on.

In hindsight, it was great having a combination of proactive stuff I wanted to do, but equally great to just have time and space for entertaining other unexpected things that come up.

I went back to work recharged and happy to be back. Extended time away gave me a fresh perspective and clarity on what was most important. I went back with renewed focus on how I should best spend my time/energy at work.

Tips & Lessons Learned

Beyond learning a bunch through reading during my sabbatical, here are my lessons learned about taking sabbaticals:

• Anything at work I’d need to document or turn into a “process” in order to take extended time off – these are things I probably should have done regardless.
• It was really great to have a combination of
  • proactive plans and goals to move forward, plus
  • unstructured time to allow space to react to new opportunities and do things I didn’t plan on.
• Keeping a log of where my time went was really helpful.
• What I’d do different next time:
  • Would have planned my actual travel plans well ahead of time, before things got mostly booked up.
  • I’d have a bit lower expectation on how much I’d be able to do / how long the time would feel (it did go by very fast)
• Sabbaticals are a great way to clear your head and come back to work with clear perspective and priority on what’s important.

Overall my sabbatical was a great experience and I was really grateful for opportunity.

TeamHome.app – An internal company directory designed for remote teams. Try it out and let me know what you think.

Read on for details & some background…

Tweetstorm version here:

Some screenshots:

I built TeamHome to both:

• give me what I always wished existed for seeing my remote team
• productize some ideas I think have helped Close as we’ve grown from 6 to 40+ people remotely.

It has 2 modes:

1. Just you – visualize your coworkers’ time zones, see a world map of your company, & embed to keep your public About/Team page always up-to-date.
2. Team – when embraced company wide, everyone has rich profiles/bios to serve as an official company directory.

Big companies get entire teams dedicated to building internal tools.

I wanted to help smaller companies… to make smooth what’s commonly a duck tape solution where companies keep their team information together across wikis, spreadsheets, manual emails, google docs, etc.

It’s been years since I’ve created a product from scratch, and I was getting the itch to make something new. I wanted to try out some new frameworks and just experiment some. Side projects are great for that.

There’s basically nothing brand new here, just packaging together a few different ideas in a hopefully useful way:

• Stripe Home
• User Manuals
• Mapbox maps, Slack API, Tailwind UI, etc. (details further on)

This was just a little side project for me… why did I bother?

• To see something like this in the world
• To experiment w/new tech & building from scratch
• To stay sane during a pandemic

Plus, I’ve seen how useful User Manuals can be, especially when new hires join

Give it a shot – you can use it for free and see your team as soon as you sign in with Slack. I’d really love any feedback!

TeamHome.app

Behind-the-scenes

Building a SaaS like this has never been easier. I got some questions on what it’s built with.

So I wanted to give some shout outs to what made building TeamHome in a very limited amount of time possible… 🙌

• App UI: Tailwind UI components made it easy to quickly create something that feels rather polished.
• CSS: Tailwind, which I really started liking and would choose for future projects.
• Icons: Heroicons.com pair nicely with the above
• JavaScript: Stimulus – paired nicely with Rails to give my JS some structure. For any site that isn’t a SPA but needs some JS, this is a really great choice.
• Backend: Ruby on Rails – such a rich ecosystem of gems meant I wasn’t reinventing the wheel.

A few more:

• Mapbox – Beautiful maps API
• Slack – Thanks for a rather open API that let’s you see your entire Team automatically
• Render – A formidable Heroku competitor at lower cost
• Stripe – With Checkout & Customer Portal, I had to write almost no billing-related code

And lots of open source code. As I mentioned, mostly just glueing ideas together.

We host our main marketing website, close.com, as a static site (in our case, generated via Lektor) served by AWS. We store all the staticly generated files in S3 and have a Cloudfront distribution in front as our CDN.

Occasionally, we’ll need to setup a redirect, to point an old URL to a new URL, for example when combining two pages.

In S3 hosted static websites like ours, there were basically two main ways to accomplish redirects…

Approach 1: HTML meta tag redirects

The first is to do HTML meta redirects, by putting this tag on the page to redirect away from:

<meta http-equiv="refresh" content="0; url=http://close.com/new-url-here" />

Whether your hand-code each redirect in this way, or use your static site generator to help (e.g. Lektor’s support for Redirects), the result is the same – redirects that happen fully client-side.

While this approach is convenient since everything is 100% static, it can be difficult to maintain in a large website and has real downsides for both performance and SEO compared to server-side redirects.

Approach 2: S3 Static Website Hosting Redirects

S3 does have some support for server-side redirects, which we were using in addition to meta tags previously described.

These redirects do solve the performance and SEO concerns compared to meta redirect tags.

Here’s an example of that XML format (configured in AWS Console under your S3 bucket > Properties > Static website hosting > Redirection Rules):

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>home</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>close.com</HostName>
      <ReplaceKeyWith/>
      <HttpRedirectCode>301</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>old-page</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>close.com</HostName>
      <ReplaceKeyWith/>
      <HttpRedirectCode>302</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
  ...
</RoutingRules>

Problems with this approach included:

• Their XML syntax is verbose
• Difficulty redirecting to URLs that contain querystrings (details)
• Desire for our marketing team to be able to setup webpage redirects without AWS access

So, it was time for a new approach.

Approach 3: Using Lambda@Edge and Cloudfront to do server-side redirects

Lambda@Edge is a feature of Cloudfront that allows you to run serverless functions to tweak the HTTP requests or responses between Cloudfront and your Origin or visitor.

We had recently deployed an extremely simple Lambda@Edge function on our close.com Cloudfront distribution in order to force visitors to the HTTPS version of our site by adding the HSTS header to all responses.

We could then build upon this to create a user-friendly system for managing redirects.

Goal

I envisioned a very simple system like the following:

• Keep a redirects.json file in the same GitHub repository as rest of our website, which our marketing team could easily maintain (with some instructions nearby).
• Have a Lambda@Edge function attached to our Cloudfront distribution do server-side redirects based on this file.
• Setup our CI/CD pipeline (in CircleCI) so that changes to redirects.json would get deployed automatically.

Here’s the redirects.json format I went with:

{
  "/jobs": { "to": "https://jobs.close.com/", "statusCode": 301 },
  "/resources/the-follow-up-formula": { "to": "/resources/followup", "statusCode": 301 },
  ... etc. ...
}

(Just be careful that your last entry does not contain a trailing comma.)

Setting up the Lambda@Edge function

Here’s the cheatsheet for creating the function properly:

1. From the Lambda section of the AWS console, create a new Lambda function and give it a name like cloudfront-site-redirects.
2. Choose the Node.js 10.x runtime, because that’s currently the latest that Lambda@Edge supports (despite regular Lambda functions supporting Node.js 12.x).
3. Under “Permissions”, choose “Create a new role from AWS policy templates” and search for “Basic Lambda@Edge permissions (for Cloudfront trigger)”, which will setup a good IAM role for you (do not choose “Create a new role with basic Lambda permissions” which is insufficient).

Then…

Add code for the Lambda function

Ours ended up looking something like this:

const REDIRECTS_DATA_REGION = 'us-east-1';
const REDIRECTS_DATA_BUCKET = 'example.com';
const REDIRECTS_DATA_OBJECT = 'config/redirects.json';

const AWS = require('aws-sdk');

const s3 = new AWS.S3({ region: REDIRECTS_DATA_REGION });

async function readFile(bucketName, filename) {
  const params = { Bucket: bucketName, Key: filename };
  
  const response = await s3.getObject(params, function (err, data) {
    if (err) {
      console.error('s3.getObject error: ' + err);
    }
  }).promise();
  
  return response.Body.toString();
}

async function getRedirectsData() {
  const txt = await readFile(REDIRECTS_DATA_BUCKET, REDIRECTS_DATA_OBJECT);
  let data;
  try {
    data = JSON.parse(txt);
  } catch (e) {
    console.error('getRedirectsData parse failed', txt, e);
    data = {};
  }
  return data;
}

const supportedStatusCodes = {
  301: 'Moved Permanently',
  302: 'Found',
  307: 'Temporary Redirect'
}


exports.handler = async(event, context) => {
  // Get the incoming request and the initial response from S3
  // https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html
  const { request, response } = event.Records[0].cf;
  
  // Enable HSTS
  response.headers['strict-transport-security'] = [{ key: 'Strict-Transport-Security', value: 'max-age=63072000' }];
  
  // request.uri is just the URL path without hostname or querystring
  let path = request.uri
  
  // Cut off trailing slash to normalize it
  if (path.slice(-1) === '/') {
    path = path.slice(0, -1);
  }
  
  const redirectsData = await getRedirectsData();
  const redirectData = redirectsData[path];
  
  // See if a redirect exists & sanity check that the redirect object is what we expect
  const shouldRedirect = !!(redirectData && redirectData.to && supportedStatusCodes[redirectData.statusCode]);
  
  if (shouldRedirect) {
    // Note: We can't completely create a new set of headers even for a redirect
    // because Cloudfront fails painfully if you set (or clear) a "read-only" header.
    // For Origin Response triggers, that includes leaving "Transfer-Encoding" alone.
    // https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/master/doc_source/lambda-requirements-limits.md#read-only-headers
    response.headers['location'] = [{
      key: 'Location',
      value: redirectData.to,
    }];
    
    return {
      status: redirectData.statusCode,
      statusDescription: supportedStatusCodes[redirectData.statusCode],
      headers: response.headers,
    };
  }
  
  return response;
};

Give the IAM role access to your S3 bucket

On the Lambda page, scroll down to find “Execution role” which gives you a link to the IAM role that was auto-generated for you. Now we are going to expand this role by attaching an additional Policy so it also has permission to access the S3 bucket containing our redirects.json file.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:getObject"
            ],
            "Resource": [
                "arn:aws:s3:::example.com",
                "arn:aws:s3:::example.com/*"
            ]
        }
    ]
}

If your S3 bucket isn’t public, you may need to change its policy too.

Publish

From your Lambda function’s page:

• Click “Save”
• Go to Actions > Deploy to Lambda@Edge
• Choose the Cloudfront distribution to attach this to, and set it up using Origin response as the trigger.

We choose “Origin Response” because this allows Cloudfront to cache the redirect itself similar to how it would cache any other response from the Origin.

Then, head to your Cloudfront distribution in AWS. You’ll notice its status is “InProgress” as the changes are propagated. You’ll need to wait for this, and you’ll also need to create an Invalidation (probably for /*) and wait for that too. (This process can take several minutes or more. Ugh.)

Finally, if everything is working properly, you can test out your new server-side redirects!

$ curl -I https://close.com/resources/the-follow-up-formula                
HTTP/2 301 
location: /resources/followup
...

Continuous deployment

Finally, just make sure that your regular deployment process uploads redirects.json to your S3 bucket (if it’s not already) and that a Cloudfront invalidatoin is created. For us that meant having a few lines in our deployment script like:

aws s3 cp config/redirects.json s3://example.com/config/
aws configure set preview.cloudfront true
aws cloudfront create-invalidation --distribution-id THE_ID_HERE --paths '/*'

Doing so has allowed our marketing team to have simple control over server-side redirects on our site.

Troubleshooting and other learnings

• As mentioned above, troubleshooting on real deployments can be a time-consuming process. Therefore, you can use a “Test Event” to simulate your code way faster than deploying and waiting for invalidation each time.
• To see if a Cloudfront distribution is using Lambda@Edge, go to the distribution > Behaviors > Edit and at the very bottom you’ll see the ARN with function name & version listed.
• When publishing a new Lambda version, you can leave the Name blank and it will autoincrement a version number.
• From your Lambda function, you can find a link to get to the CloudWatch Logs, which can be very helpful for debugging.
• In Cloudfront Logs: Look at latest Log Groups for both “LambdaEdge” as well as name of your function.
• You can only have 1 Lambda function deployed per trigger (e.g. for Origin Response) per distribution, meaning that the lambda function name should probably be specific to that distribution. (At first I thought I could add a second independent function on top of the existing HSTS one. That doesn’t work, however they do have a “Layers” feature I didn’t explore).
• Lambda functions can use async/await in Node 10.x, so it’s nice to use those despite most online examples using callbacks.

Feel free to hit me up at @philfreo with any comments or questions!

Hiring is hard. Really hard. I’ve been hiring on small startup engineering teams for the past 8 years (most recently grown Close’s engineering team from 2 to 14) and hiring really great engineers never gets easy. But it does get easier with practice and the right strategy.

Here I’m going to share some things I’ve learned about when and how to find the right people for your stage, how to structure a hiring process, and distributed/remote work. And most importantly: mistakes I’ve made along the way at Close.

When to hire

There are just two simple rules to follow about when to start hiring your engineering team.

Don’t hire too early (rule #1)

Hiring is hard. It’s a REALLLLLLLY hard, slow, painful process. Seriously, you don’t want to go through it before you have to. Avoid the pain as long as you can!

People are really expensive ($$$). Generally nothing in your startup will cost more money or take up more of your time and attention than… people.

Do the job yourself first. Be busy. Learn and do all the things! If you do everything yourself for a while, you’ll be in better shape to understand what really needs doing. You’ll be able to write a better job description, and you’ll be better at identifying a good person to fill the role when the time comes.

Small = fast & nimble. As much as everyone tries to avoid it, there’s just always inherent communication and process overhead of having a larger team. Enjoy moving as fast as possible while you’re small.

Focus on what matters: building a product that people love. Spending your time on hiring activities (job posts, resume screening, phone screens, in-person interviews, job offers, great employee onboarding, etc.) – none of these directly matter to your business! What matters first is finding product-market fit with a product that people love. Customers paying you money.

At Close, we got to company profitability making a few million dollars in annual recurring revenue, all with a 3 person Product/Engineering team (with total company size of 6). Take advantage of your small team size as long as you can!

Don’t hire too late (rule #2)

Because it takes forever. Remember how I said hiring is a really hard, slow, painful process? This means that if you wait too long to start hiring… by the time you really accomplish your hiring goals, it will take you even longer than you’d think to add more people to the team.

Our mistake: At Close.io, we started hiring way too late. We were heads down focused exclusively on building and supporting our product for the first few years. By the time we finally decided to start hiring, we were already in a bad spot. We had too small of a team to support our product’s complexity and all of our customers. We slowed down on our pace of product development. We just didn’t have the team size that the business size and opportunity size justified.

To make matters worse, once we started recruiting/hiring, we didn’t really try hard enough at first. We failed at it for too long because we didn’t really make it a true priority even after we started.

So, when?

I can’t tell you exactly when to hire, but…

Wait until you know you really need to

• When your current processes are breaking
• When you know you can’t accomplish your goals without more people

But then don’t wait any longer

• Once it’s time, make it a #1 priority
• You must really commit to hiring.

When we finally did really put in a full effort to grow our engineering team, it started taking 50%+ of my time for many months. You can’t half do it and expect results.

Who to hire

Just one simple rule here: Aim high. Don’t settle.

Aim high

In your early engineers, you should look for:

Senior people. Junior people can be a huge asset longterm but will take years to get there, you probably don’t have time for that.

Leadership potential. You need people you don’t need to “manage”. Your first few engineers should be people who you think you can trust leading major projects and taking on large amounts of responsibilities. They should be people you can envision leading future teams.

They should “wow” you somewhere along the way. Can you learn from this person?

Don’t settle

The temptation is strong. It happens every time… somewhere after about a dozen mediocre interviews you might start thinking you just want anybody decent. Resist! DON’T SETTLE. The management and culture hit will slow you down worse than not getting the help you need for a while. There are really great candidates out there – persevere to find them.

Maybes = No’s. If you’re not sold & excited about a candidate, there’s probably a good reason for it. Trust your gut. You should be excited about candidates to move forward. If you think of them as a “maybe”, that’s a great sign you should reject them.

Hiring the wrong people = VERY BAD. Hiring the wrong person can really hurt you in a way that’s hard to recover from. The wrong hire can quickly poison your culture, frustrate your top performers, and set you down the wrong path.

More about “who”

First few hires…

First hires are the hardest roles to fill.

It’s hard to attract the very first few people. Early stage startups barely look like a real job to people. Most people don’t “get it” until there are already other people in the role.

Story: I’ve literally had a fresh out of college job candidate reject our offer (that he was excited about) because his mother didn’t think it was a “real job”.

Most people also aren’t really a good fit for a really early stage startup. Tiny startups just aren’t for everyone. Most people need more structure and a more narrow job description than is typical for a very early startup employee.

First hires are the most important.

They’ll impact the caliber of your future hires. Your first engineers will help hire and attract the next engineers.

They will (or should) become leaders. It’s likely a bad sign for your first few hires if you cannot picture that person leading a project or team one day. Early in startups, you want people who can learn and grow quickly as your startup grows.

Find your bottlenecks

Different stages of your company require different types of people.

The first few engineers on our team were “Full Stack”. As a tiny team we needed engineers who could go both deep and wide. We were able to go deep in specific areas as needed, but also comfortable working across various parts of the tech stack.

Hiring generalists worked well when the engineering team was very small, but as we grew it was time to start specializing. That doesn’t mean restricting people to one part of the tech stack, but rather it meant finding our software development bottlenecks and really focusing on finding some great people in the specific areas we were weakest in.

At Close.io, our first specific bottleneck was on the infrastructure side. We had grown with so many customers, so much data, and a larger codebase to support that our engineering team was really slowing down trying to work on both the infrastructure and the product itself. We eventually hired a couple really great DevOps/Infrastructure Engineers, and that dramatically helped.

Next our bottleneck was Frontend Development (couldn’t keep up with Backend), then Design (we finally had frontend bandwidth to implement design work), then Backend, and most recently a Product Manager (for the first time it felt like customer problem discovery/definition was bottlenecking engineering effectiveness).

What’s your biggest team bottleneck for building a better product? Focus your hiring there!

Mistake: Focusing only on technical qualifications

A mistake that I’ve made a couple times is focusing almost entirely on a candidate’s technical capabilities. It’s so hard to find programmers that actually know how to program, that when you find someone who passes your technical quality bar, the temptation is to assume they would be a great hire.

But in reality, it’s incredibly important to pay attention to their written and verbal communication skills, maturity, attitude, desired work/life balance, culture, how they will work with people, their work processes, and other “soft skills” that separates a senior professional from just somebody who is good at programming. Do they have experience working in companies your size? If you’re remote, have they ever worked remotely before? Ask yourself if you actually think you would like working with this person. Finally, always trust your gut.

If you aren’t careful about qualifying candidates as an entire person and not just based on their technical skills, you risk ruining your culture, building a team that is difficult to manage, doesn’t work well together, and who you can’t trust with important projects that aren’t 100% about the code.

How to hire

The 6 steps for hiring are pretty obvious, so I’m going to just provide a few specific tips or hard lessons learned for each one.

1. Prep work
2. Sourcing
3. Screening
4. Interviews
5. Offer
6. Onboarding (& beyond)

How to stand out

Before we get into each step of how to hire, let me first say a couple words about standing out from other companies. Every other tech company is doing these same exact steps. Great candidates have hundreds of great jobs to consider. So it’s important to figure out how to make your company and role stand out among the rest.

Stand out by making the whole process fun and respectful, and play to your strengths.

Be respectful

The best way to stand out is to just treat all your candidates with respect.

Get back to people quickly. People really appreciate if you always get back to them within a few days. Most companies don’t. Setup email templates to make this easy.

Declined candidates should still walk away impressed. Your goal should be to make everyone who interacts with your company to be impressed by you and want to tell their friends, even if they are a horrible fit themselves.

Make it fun

Try to find a way to make the application and interview process fun for candidates. This could look different at different companies, but a couple quick ideas…

Make your interview questions connected in some way so the candidate feels like they are making progress, rather than just being asked a series of unrelated technical questions.

Examples: For one position at Close.io we have a 1 hour interview where we ask 12 connected questions that lead a candidate through architecting a real-world standalone web service. For another position, we have an application question that is related to the take-home challenge they’ll do in round 2, and our final interview is based on their work done in the take-home challenge.

Help them learn about your company along the way. The more you can share about your own company and the type of real-world challenges you experience, the more a candidate will understand if the role is a good fit for them (and hopefully be excited).

Example: All our job applications require a candidate to send a POST with a specific JSON payload to an endpoint. The response payload returns not only the “answer” they need to apply, but also returns the URLs to a few engineering blog posts and open source projects of ours so they can learn more about us and our work.

Play to your strengths

There is something unique and attractive about your company or the specific role you’re hiring for. Something that can help you stand out as more interesting than the countless other jobs out there.

Here are some examples of possible strengths:

• Unique tech stack (niche programming language, big data, using cutting edge frameworks, etc.)
• New technology area (e.g. virtual reality, cryptocurrency, AI)
• High salary, significant equity, or unusually strong benefits, etc.
• Building a new product from scratch
• Employee #1 who will work closely with founders and wear many hats
• Ability to work remotely or set own hours

Whatever it is for you… make sure you focus on sharing that. Advertise it clearly in your job description, mention it in your interviews, repeat it when you make a job offer, etc. Play to your strengths.

For us at Close.io, we have several advantages over most companies: remote (work from anywhere, no set hours), good tech stack, and profitable. Sometimes we try to even fit these advantages into the job titles – e.g. we have advertised job posts with titles like “JavaScript/React Frontend Engineer @ a *profitable* fast-growing startup” which stands out among a sea of plain “Software Engineer” posts.

Prep Work

Plan your process

Who are you really looking for? Make sure both you and the rest of your team have clear alignment on exactly what type of person you’re looking for.

Plan the entire hiring process upfront. Once interviews start it will be much harder if you’re winging it.

For the last position that I hired for, before talking to a single candidate or even posting a job advertisement, I first wrote a document with the outline shown here (to the right) and made sure the rest of the team was on board with not only who we were looking for, but why now and how we would evaluate that person.

Write the job description

Take your time writing an excellent job post. It’s a mistake to just list out a bunch of requirements. Instead, be sure to:

Sell your company & the role. Remember that great candidates have lots of options – let them know why they should want to join your company.

Be specific about what they’ll do. People don’t just want to know they’ll be writing Python backend code, they’ll want to know specifically what types of projects they will be doing and what their impact will be.

Get feedback from people who are good at that role. After writing your job post, send it around to people who you think are excellent at that role and ask for feedback before promoting it. This is especially important when hiring for a role that you yourself wouldn’t be qualified to fill.

Sourcing

Where do you find candidates? 7 main places…

Outbound vs Inbound. You need to do both. But you have to treat outbound differently (more casual & more selling) in early stages of the process.

Your Network. Your direct and 2nd degree network is already full of great people.

• Directly reach out to people you think are great – even/especially if you think they are happy in their current situation. Often they are more ready for a change than you may think. And worst case, they might be able to recommend somebody else great for the role.
• Get everyone in your company to do the same. When you hire someone new, one of the first things you should ask them is who else they know that might be a good fit for your open roles.
• Use social media. Not as a replacement for reaching out to people directly, but in addition.

A good example of how effective networking hiring can be is how we found our recent Product Manager hire, Ben. I posted the tweet below, and Ben was one of the people who “liked” the tweet. I didn’t directly know Ben, but he had “Product @ [startup]” in his Twitter Bio and had previously cofounded a company with a former colleague of mine. Since he liked my post, I sent him a Direct Message asking him if he knew anyone who might be good for our PM role. Soon enough we setup a call to discuss the role for himself! Not long after, Ben became our first PM and has been doing great.

The most important part: Ben said that if I hadn’t sent him that message, he probably would have never applied!

Job Boards. This is the easiest way to find candidates, since you basically just pay ~$300 and you get your ad in front of a lot of people who are looking for a job. The trick is to post on the most relevant job boards for your specific role as possible. I suggest avoiding the very big name sites like Monster, and instead focusing on specific niche sites that have the most overlap with your ideal candidate as possible.

For example, since our roles are remote, we post on remote-focused job boards like WeWorkRemotely.com, RemoteOK.io, and Remotive.io. For Frontend Development roles, we post on sites like Codepen. For Designers, Dribbble. You get the idea – the more targeted, the better.

Targeted Communities. Similar to job boards, there are online (and even offline) communities where your target audience hangs out that often you can informally share a job post with. This includes Slack groups, tech newsletters, MeetUps, etc. Often the organizer of these communities are happy to share highly targeted job opportunities with their members.

When looking for targeted communities, consider: industry-specific, location-specific, or technology-specific.

Matching Sites. There are some sites that serve as middle ground between inbound & outbound recruiting. Sites like Hired, AngelList, AList, or TripleByte serve as a place to find profiles of developers who are job seeking (and sometimes pre-screened) where you can browse for developers who look like a really good fit for you and reach out.

Targeted Outbound. Good old-fashioned cold emails to people who look like they would be the perfect fit for your role based on their exact experience. This is a lot of work but can be more effective than you may think.

Tip: If you have open source projects that strangers have made helpful contributions to, reach out to them! If not, then reach out to contributors for open source projects for the libraries that you use.

Recruiters. If you go this route, just be very careful about how they are representing your company.

Relentless follow-up

When you find someone you really want to work with… never stop following up. Recruiting is like sales.

The screenshot to the right shows an example of how I followed up with Casey, a developer that I had met a couple years prior and was really impressed with. You can see how every few months for ~19 months I kept checking in with him. At the bottom, you can see it eventually paid off. Casey is now a really key person on our engineering team.

For two more great examples of this, check out Steli’s blog post on how he recruited me for 3 years before I finally joined him.

If there’s a single lesson here, it’s this: When you find amazing people, follow up and follow through with them forever.

Screening

Use an Applicant Tracking System. A dedicated ATS like Breezy.hr, Workable.com, or Lever.co will make collecting, screening, and tracking a large number of resumes/applicants much more efficiently than just using your inbox/Trello/spreadsheet.

Customize your application form. When advertising jobs online (especially if you’re open to remote candidates), one of the toughest parts is actually having too many applicants, where many of them are low quality. A good solution to this is to customize your job application form to make it fun for the right kind of person and turn away people who just want to blindly apply to as many jobs as possible.

The form should, of course, give them a chance to share their resume/experience, which you’ll pay close attention to when screening.

But a good application form will also include technical screener questions which should only take a few minutes for someone good to solve, but will quickly weed out those who aren’t qualified. We’ve done this and have actually gotten great feedback about it. People love little technical challenges in application since it makes it less boring to apply.

Finally, include questions to help you evaluate their written communication, which is often under-appreciated in engineering hiring.

Having thoughtful questions on your application form will give you way more data when screening candidates.

Interviews

Example flow:

• Phone Screen (30-60m) – Intro, quick technical screener questions, hear about their experience and determine whether they seem overall impressive.
  • Get good at phone screens – this is where most of your recruiting time will be spent.
  • Have good technical screener questions that get you to a “No” as quickly as possible if someone isn’t great. For me I like to ask something one level deeper than frameworks might take care of for you, e.g. asking about SQL escaping/injection (for people used to ORMs), or direct DOM manipulation (for people used to React).
  • Use coderpad.io for quick “can they actually code” live coding exercises of something simple.
• Technical Interview 1 (60m) – In depth technical/architectural questions
• Take-home project (2-3h) – Let’s see them actually build something (2-3 hrs). It’s important to timebox these for candidates so they don’t feel taken advantage of. Some companies actually pay. If you aren’t paying them, then don’t give a real problem that could be misinterpreted as trying to get free work from them.
• Technical Interview 2 (60m) – Drill in on missing technical areas, evaluate softer skills, overall seniority, etc.

Things to keep in mind during interviews:

The best interviews should feel like a dialog rather than just you asking a bunch of technical questions in a row. For example: Let them tell you about their experience, and ask questions along the way to go deeper.

Remember to sell. Use every interview as a chance to share what you think is great about your company and this role, since great candidates can have many opportunities to choose from.

Let them ask good questions. They should have good ones and be engaged. No questions is a bad sign.

Gut check / do you like them? If something doesn’t feel right during an intro call (when everyone is trying to put their best foot forward) that’s usually a sign of a bad fit.

Have all interviewers leave detailed notes & a summary/conclusion. It’s best if each interviewer independently writes their thoughts immediately following interviews to avoid groupthink. Press interviewers to summarize with a simple rating scale. For example we use language like “strong like” or “weak dislike”. This allows you to review everyone’s feedback afterwards and reject anyone where most interviewers are only ambivalent toward a candidate.

Offer

So you found someone you like? Great! Now comes the pivotal offer stage.

Always check references. Before you make the offer, reference checks are key to validate that someone is as good as you think they are, and not just good at interviewing. Great people with a decade or more of experience should easily be able to come up with a long list of names of current or past coworkers that would happily vouch for them.

Cautionary tale 1: Early in Close.io’s history we made a hire that turned out to be really, really terrible. In hindsight, I’m sure we would have avoided this hire if we had done thorough reference checks. Sadly, we also saw him go on to get hired (and also eventually fired) by another startup we respected. Had they talked to us first, they could have also avoided wasting time.

Cautionary tale 2: We were once trying to move quickly with a candidate, so we made an offer first but contingent upon reference checks. It turns out that once we did references, we detected that there was a significant error on his resume about the duration of time he spent in the role that was most relevant to us.

Make the offer & close it. Remember to focus the offer not only on the salary & benefits, but especially on selling the opportunity, quality of the team, and their ability for learning/growth.

Trial periods. If you have the opportunity to do a contract / trial period with someone before jumping to a full-time offer, that can be a really great lower risk way to see if they are truly a good fit (and if you are a good fit for them). Not all candidates can risk leaving a good job for a 1 month contract, but when possible, this can be a very useful tool.

Mistake: Assuming that accepted offer = position filled

It’s a rookie mistake to assume that just because a candidate accepts your job offer, that you’ve actually finished your job hiring.

Recruiting doesn’t stop at signed offer. Believe it or not, I’ve had more than one example where a candidate accepts an offer (including signing paperwork) and then changes their mind before their start date. I’ve heard reasons like “I got more excited by a different company”, “my current employer made a counteroffer too good to refuse”, and “my spouse ended up not being okay with the retreat travel requirements”. Don’t get mad, just move on.

You’ll have to make more offers than you think. Between some offers being declined, and some candidates dropping out before their start date, you will end up needing to make more offers than positions you’re trying to fill. While you definitely shouldn’t make more offers than roles you’re prepared to hire for, I do recommend that you continue talking to candidates even after you’ve made an offer, until you have somebody on board doing a great job.

Sell to start date. Keep candidates engaged from offer to start date by checking in along the way and continuing to sell. Specifically, we make sure that in the days/weeks between offer and start date that we send candidates at least a couple emails with links to blog posts we wrote, links to 5 star reviews of our product left by customers, a keynote video from our CEO, etc.

Onboarding & Beyond

Mistake: Assuming that your hires will work out

For the candidates that do make it to their start date, unfortunately many will still not work out – probably a higher percentage than you may think. Either you or they will determine the role isn’t right for them.

Your work doesn’t stop at their start date – focus on post-hire success. The first 1-2 months of onboarding is critical!

Don’t assume new hires are happy. Be checking in with new hires frequently. Ask questions like “We’re a couple weeks in and you’ve gotten a better sense for us now — what’s different than what you expected, good and bad?” New hires just may realize the job isn’t for them. For example, we’ve had someone tell us “I learned more in the past 3 months than the 3 years before that – but the pace is not for me”. Do what you can to make people happy, but then move on if it’s the wrong fit.

Learn from each bad hire. Your goal from each bad hire is to learn how you can improve your hiring process to avoid similar mistakes in the future.

Make sure you’re still excited after 30 days (or fire fast). Realistically, you’ll never get a perfect sense of someone from a few hours of interviews. So after you’ve had some time actually working with someone, if you’re not still excited about them being on the team, fire fast so you both can move on.

Hire more people than you think you need. Realizing that many hires don’t work out, you should plan to hire more people than you actually need in order to end up with the people you really need. Of course, you need to be able to afford everyone that you hire. But where you have room to hire an extra person (e.g. hiring 3 instead of 2 people for a role), doing so will increase your odds of success. It’s much easier to hire in parallel than serial for the same position, so it’s also more efficient to over-hire upfront than to keep restarting your hiring process after a hire doesn’t work out.

Onboarding tips

• Have a well thought out onboarding plan. I create a Dropbox Paper doc with a long list of checkboxes with a combination of things that they should do (project work) and learn (reading, talking to specific people, etc.) broken down by day and week for the first month.
• Ship on day 1. Get new engineers to ship something (even if super tiny) on their first day if at all possible. Definitely within the first week.
• Start with small quick wins but rapidly give them increasingly difficult projects. Get them in the habit of moving fast and shipping, quickly working toward giving them big amounts of responsibility.
• Spend a lot of time with them. Check in multiple times per week. If hiring remotely, try to find a way to start out in-person if possible.

Managing/running a growing team

Eventually all your hard work hiring will pay off and you’ll start to have a larger team. Now what? Leading a growing team is where things get fun. This topic really deserves its own blog post, but here are a few quick principles that have helped our team scale…

Hand over responsibilities. The sooner you trust your team with big problems and stop trying to control everything yourself, the better.

Have frequent 1:1s. Give the people you manage a meeting every week or two that is primarily their time. Discuss challenges and how they are feeling about work. Ask questions and listen. Tip: I like to keep an Apple Note per person on my team and when I think about something to discuss with them (a question or positive or negative feedback) throughout the week I’ll jot it there, and then use that Note before/after the 1:1 to take notes.

Build camaraderie. Especially with a remote team, it’s important that everyone feels connected and like they are a part of building something great together. Here are a few things that have helped us accomplish that:

• Retreats. 2-3 times per year we get everyone physically together in one place for about a week (different places around the world). This is where the most important team bonding, vision setting for the year, etc. occurs.
• Retrospectives. We try to (but need to do them more often!) have open discussions after projects wrap up where we discuss how it went, what we learned, what we did well, and what we’d like to do better as a team next time. The goal is to have a culture of continually seeking growth and improvement through healthy/safe discussions.
• Show & Tells. When you’re tiny, everyone knows what everyone else is working on. After you grow beyond a few people that’s no longer possible, so having a regular time where people are encouraged to share details of what they’ve been learning/coding/designing/launched/etc. is a fun way to keep people on the same page and decrease bus factor.
• Highs & Lows. Recently we’ve introduced a time where each person on the team very quickly (~30s/person) shares their High (best part) and Low (worst part) of their past week – related to either their work or personal life. Especially for our remote team, this has been great for hearing about wins and getting a better sense of what everyone is struggling with.

Add structure as the team grows. Setup Project Leads, Tech Leads, Engineering Managers, etc. so that you can give people on your team more responsibility and ensure you don’t bottleneck too many things.

Remote hiring

Being a distributed / all-remote team has been a huge asset for us both in terms of recruiting as well as retention.

Really great people are everywhere. We’ve found amazing candidates from countries all around the world. The Close.io Product/Engineering team is 14 people – all remote – working from 6 different countries.

Way more candidates. We pretty quickly get hundreds of candidates for every remote position we advertise. There are just a lot of people in the world who want to work remotely. (This is a blessing and a curse, see the “Screening” section.)

You can really stand out as a top company. It was very hard to stand out in Silicon Valley among all the other tech startups hiring. But among remote-friendly companies we were easily able to stand out as a very attractive option for candidates.

Cheaper. SFBay area engineering salaries, housing, cost of living, and office space are all insanely expensive. Go remote and hire more great people!

Retain employees longer. People stick around longer, since they can live where they want, move around as needed, and don’t have to deal with commutes or distraction-prone offices. At Close.io, once we went remote, me and 3 other people on our team moved out of California when family or other needs arose. Our jobs stayed the same even as our locations changed drastically.

For me, working from home has been wonderful as I became a father last year.

Conclusion

Building and growing an engineering team is hard… but it does get easier. And seeing your new team be able to accomplish more than you could ever before is a really great feeling.

Do you have your own tips for growing an engineering team? Questions or want to hear more? Tweet at me.

Watch the interview here: https://www.insidesalessummit.com/interviews/wednesday/phil-freo/

Overview:

In this interview, Phil digs into his personal experience to share what he believes are the best ways for sales and engineering teams to work together, including how to pitch (in-demand) feature requests to product and engineering and how reps should address feature requests from high-value prospects. Phil also explains why technical founders need to care about sales, and goes over common misconceptions about both engineers & salespeople.

Interview Length: 19:14

Topics Covered: The best ways for sales and engineering teams to work together, how to pitch (in-demand) feature requests to product and engineering, how to address feature requests from high-value prospects, why technical founders need to care about sales, and common misconceptions about engineers & salespeople.

I’m sharing this publicly because I believe this advice can help other startups and SaaS product companies as well.

When a customer request for a new feature come in, it’s easy to not log it at all (“we’ve heard that one before”) or to log it in a suboptimal way. Here are a few details on how to best capture customer needs and why it matters.

The typical, but unhelpful, way

The most common way feature requests are logged is in a “light” format like this:

• “john@example.com wants feature FOO – [link to ticket]”

While this does provide a list of people to notify if we ever do launch a feature that we happen to call “FOO”, it falls short in many other ways.

This is typically very unhelpful for Product Development or for getting a customer’s needs solved because:

• Many people have different ideas about what this feature specifically could be.
• There are different ways a feature could work and this doesn’t give any insight into which way would be best.
• Frequently there’s a different, better way that their underlying need (use case) could be met instead.

Logging requests in this “light” format may seem at least like a good way to build a notification list, but in reality leads us to building and notifying people about something that turns out not to best solve their core problems.

Similarly, it may seem that this at least gives us a “votes” system to prioritize Product decisions, but in reality there isn’t enough detailed signal in the votes to design a feature we can be confident really helps most of them.

Caveat: Logging a feature request with “email address only” is still better than not logging any at all, because it at least does give us a list of people we can later contact for more information.

The better way

A feature request logging format that is 100 times more helpful is one that includes details of the use case. A use case should include:

• Who is the user and company, and what’s the user’s role within the company?
• What situation is causing the user to want this feature? (When did the need start?)
• In their own words, what do they mean by “feature FOO”?
• How, specifically, would they use this feature?
• Really, why do they want this feature? What is the specific use case?
• What is the business value they’re hoping to achieve because of this feature?

It all really boils down to asking “why?” and then logging in as much detail as possible, in the customer’s own words, the specifics about what they are actually trying to accomplish.

“In the customer’s own words” is really important because it’s easy for us to, in the moment, substitute our own current idea of a solution, when what’s important is logging their actual problem and goals. Having the customer’s own words helps us avoid bias.

How this helps

Demand based Product Development

Having concise but detailed use cases help direct us toward clarity when we try to validate whether a Product Proposal makes sense to move forward with. They help answer:

“Is there really a pattern of consistent use cases that are important enough AND that our specific idea of solution would be a GREAT solution to?”

When logging feature requests, it’s best to assume that, by default, no feature will get developed until there is a set of documented specific use cases with reasons/explanations on why it’s important to that customer and how they would use it.

From a Product Development perspective, it’s important that we pay most attention to the underlying need (demand) rather than customer’s ideas and requests for specific features (supply). (For more about this, there’s a great podcast on the subject).

Design Decisions

Even in times where there’s clear demand in a problem area and many requests for a particular feature, another factor is at play where detailed feature requests with use cases help tremendously.

Often, there are multiple very different ways a feature could work, but without understanding exactly what users are trying to achieve, it’s hard to know which way is better.

Most features which seem clear and straightforward on the surface can go in different directions once you really dig into the nitty gritty UI/UX or technical design. Being able to go back to the core use cases (specific real-world things our customers are trying to do) it helps us quickly and confidently choose a direction.

Who should do this

The Product team takes ultimate responsibility for fleshing out customer use cases and validating solutions with customers.

Anyone who talks with customers, however (especially Support, Success, and Sales), is in a unique position to already have many interactions where feature requests and customer problems come up. It is immensely helpful and valuable for moving the product forward in the right ways if these interactions result in feature requests logged with use cases. We love having the entire company championing customer needs and giving input into Product direction. This is the best way to do that.

At Close.io, the best place to log feature requests with uses cases is in our “Feature Requests & Customer Needs” Trello Board. If you’re ever inclined to write a Product Proposal, including a few curated use cases (in the customer’s own words) is useful to supporting the idea.

What do you think? Send me a tweet about how your team captures customer feature requests.

Either out of curiosity or out of a genuine need for a tool that some SaaS service is offering, I will often sign up for a free trial soon after learning about it in order to check it out. For a variety of reasons by the time the free trial is up, I’m not ready to purchase.

It could be because I was just poking around. But more often it’s because I got too busy. Or my reason for signing up didn’t stay a high enough priority to be ready to purchase and fully implement some solution. Or maybe because the product just wasn’t far enough developed to satisfy what I was looking for.

What I find happening is that 3, 6, 12, or 18 months later I’ll find myself thinking about this tool. Perhaps the problem that led me to originally check out tools of the service has become more pressing than ever before. Or perhaps I’m fed up with another tool I chose, and am searching again for a better option. Or I’m hoping that the product has evolved more. Or whatever.

When logging back into your previously-created account, what you typically see is something like this:

Your free trial expired. Please enter your credit card to continue.

At this point, it’s far too easy to just close the tab. I’ve done it many times, even when I actually was in need (and willing to purchase) a tool in their category.

Savvy users will email the site’s sales or support team and can usually get a trial extended, but this often takes a few hours, which sucks. When a user gives you enough attention to want to check out your product right now, you should always take advantage of that. It’s too easy for that attention to get lost if you make the user wait.

Similarly some users will just use another email address, which is really bad for understanding your marketing funnel and metrics, and is a bad user experience overall. Plus, this may mean losing whatever progress was made on the first trial.

Let’s stop punishing our older trials.

I always thought this was a bad user experience, but I knew we were guilty of doing the same thing at Close.io. Not anymore. Now if you login to a trial that has been expired for long enough (i.e. you haven’t checked out the product in a long time), we give you a single click to get started again.

The same applies for former customers. Once you’ve been around a while, it won’t be uncommon for an early adopter to have churned and then want to give you another shot a year later. We should welcome this!

It’s a super easy change to make and within minutes of pushing this change we already saw its effects pushed to our chat.

Don’t treat old users worse than new trials!

1. People who archive incoming emails when they are finished with them, and try to achieve “inbox zero”
2. People who leave all incoming email in their “inbox” forever but use “Mark as Unread” or Star/Flag message to indicate items still requiring action

If you’re a Type #1 person, you can stop reading now.

If are a “never archive anything” type person, I’d like to make a case for why you should become an “inbox zero” type person and archive emails when you’re done with them.

You may be thinking, “who are you to tell me how to manage my email!?” It’s true, I have no right to that, and I understand that different people have different workflows. But I have heard all the reasons and still strongly believe all Type #2 people would be better off if they become Type #1 people.

I have made my case to several people over the last few years and all of them that have ever tried it have thanked me later. I believe there is really no downside to becoming a Type #2 person and only upside.

I know that not everybody is used to archiving their email, but I’d like to make a case to you that it’s not any more difficult and that if you give it a shot, it will really help your workflow. First, let me address the top 3 reasons people usually give for why they don’t archive currently:

“Archiving is an unnecessary extra step”

The thing is, it’s not really an extra step to archive an email once you’re done with it! From Gmail it’s a single keyboard shortcut or a single click of the Archive button. You’d have to click Back anyway so it’s 0 additional steps to archive a message instead.

“I keep emails in my inbox so I can find them later easily”

Emails are still searchable even when archived, and you can see all those messages in Gmail under All Mail. Archived mail is not lost, it can still be easily browsed and searched.

“I treat ‘unread’ or ‘starred’ messages as my actionable items list, which is just as good as archiving”

Abusing the “Unread” feature to keep emails around that you actually did read but just haven’t finished handling / responding to yet is unwise for two reasons. First, it prevents you from having a true list of actually unread emails.

Second, using Unread status or Stars/Flags to indicate actionable items means that your inbox is a mix of “emails I’m done with” and “really important emails I shouldn’t forget to handle or respond to”. Those items are interspersed. Sure, having items as bold (unread) or starred can make the important ones stand out, but what happens if you don’t remember to handle them before they end up on page 2? With an infinite inbox, it’s too easy to lose messages that you saw but didn’t handle yet.

Even if you always handle these items before they get too far back in your inbox, it means you’re doing lots of extra mental work by having to continually scan your inbox for items that need handling. You have to keep seeing the already handled items unnecessarily which means more things for your brain to process. Wouldn’t it be better if there was a single concise list of emails requiring further action?

Why archiving is better…

We’ve established that there’s really no downside to archiving all email once you’re done with it. Let’s talk about the upside.

When you archive messages you’re finished with, what you’re left with is an inbox that consists only of actionable items. No more continually re-scanning past dozens of emails that are no longer important, in search of the one you need to reply to. No more lying to your email client saying you haven’t read an email after you really have. No more losing important emails in the stream.

Archiving makes your inbox the list for all your emails requiring action, and nothing else.

I bet if you give it a shot, you’ll like it within a week.

How to get started

Start out by doing a bulk archive of everything in your inbox that you know has been handled. In Gmail there’s a Select All checkbox, then a second link appears at the top to truly select all. Then you can click Archive.

When a new email comes in, of course you first need to read it (or at least skim the subject/sender). If you decide you’ve read enough and it requires no action, then simply hit Archive! If you’re done your part and replied to a message, hit Archive! If the email represented a task and you finished the task, hit Archive! If it’s a newsletter and you finished reading it, hit Archive! (If it’s a newsletter or promotional email you never care to read, then Unsubscribe… and then Archive!)

Now, you can look at your inbox anytime to see and handle emails that still need more reading, responding, or action.

Let me know how it goes!

– Phil

P.S. The best products, in my opinion, encourage an opinionated workflow that promotes success. It’s from this workflow that we built Inbox in Close.io, which syncs your CRM and your email account for an Inbox of actionable sales-focused items.

Hack To Start | Phil Freo, Full Stack Developer, Close.io

In the show we also discuss one of my latest blog posts: The last 20% before shipping.