lukethomas

I didn't want to fleece future investors or existing/future employees.

When running a startup, it's natural to have unknowns, and for the most part, that's okay and to be expected.

But if you discover a new reality on the ground and continue to tell a different story, you are lying. I didn't want to do that.

We raised a total of $2.6m, so nothing too crazy in today's market.

This was precisely our approach, but we built our own features for the "gaps" that we believed existed in the other products.

If an existing app was doing a decent job, we didn't want to compete with them. The issue is that we ended up arriving in this "dead-zone" where we didn't replace an existing tool and pull budget from an existing category of tooling.

Absolutely. I will 100% keep this up and running and freely available for all. It may be on my own personal website though.

I bootstrapped the company for years before raising. I raised because I felt that I had to go after the bigger vision, which required resources ($$).

In short, I wanted to accelerate the pace of learning, because if I didn't, I would always kick myself for not stepping on the gas pedal.

I don't regret my decision either TBH.

Heck no. If we were profitable, I would have kept it up and running and reduced things to a skeleton crew.

I knew we needed to build a suite of tooling, as our goal was to be a "hub" for the most important stuff at work. In retrospect, we built too much product.

If I start another company, I will spend all my time focused on solving a very big pain-point with a few simple product.

With Friday, I wanted to keep the product simple, but the people we talked to always were talking about the "yet another tool problem" - so there was a desire to consolidate. How I interpreted this was that we needed to build the "suite" vs. spending all our time on one feature.

I could go on and on about what I would do differently, but I'm thankful for the opportunity and have learned a lot that will (hopefully) make me more effective in the future :)

I originally called it "Friday Feedback" - you will probably see a launch post ~6 years ago with a search for that :)

I made the decision after a lot of reflection. We still had ~6 months of runway so I could have spent more time "pivoting" around.

The issue was that what I was hearing from prospects, customers, users signaled a bigger issue that could not be solved with a product tweak or two.

At the end of the day, I felt like the story I would need to tell a future investor (and new/existing employees) would increasingly become disconnected from the reality I was experiencing talking to customers/users.

I didn't feel at peace about it at all. I considered it to be a form of lying.

I am considering it. I have a fiduciary duty to try to fetch a fair value for the assets, but if no one wants the codebase, I'd consider opening it up. Still TBD as I just announced this a couple days ago :)

Hey, I'm the founder. We worked really hard to not position ourselves as a task management tool, but instead, a tool that integrates with existing systems.

Task management is extremely competitive and we didn't want to play in the space. With that being said, we viewed our job as an interface to "glue" the work together, no matter the source.

Thank you. Just trying to do the right thing given the circumstances.

Hey there, I'm the founder. Happy to answer any questions people have. This was a decision I didn't take lightly.

Hi HN!

tl;dr - I wrote a 200 page user manual for team leaders and CEOs to navigate working from anywhere and open sourced it online for free: https://friday.app/anywhere

I'm Luke, the founder of Friday.app. 8 years ago, I first read Remote by 37 Signals and it's what caused me to start working remotely back in 2013. At the time, the book laid out a case that more organizations should offer remote work.

Over the years, I worked for a few different distributed companies in a variety of roles. I've seen what works and what doesn't. Now, I run a software company building async tools for distributed teams. I've also spent years digging through research on distributed teams, asynchronous communication, and more. Basically, it's been a huge area of focus for the past 8 years.

When the pandemic hit, people were CONSTANTLY asking me if I had any book recommendations. Unlike 2013, people didn't need to be convinced about the benefits of working from anywhere, which Remote did a great job covering. Now, they were looking for a playbook on how to implement this stuff in a way that tapped into the benefits of distributed work - primarily the flexibility.

I never imagined writing a book, it's not really my forte. But after seeing so many companies rollout terrible policies/practices that made working from anywhere worse than going into the office, I decided to throw my hat into the ring.

The book teaches high-level principles and then dives into specific practices and playbooks, like:

- How to go async-first

- What meeting should be an email? What email should be a meeting?

- How to hire people you haven't met

- How to quickly onboard new teammates

- How to feel connected & stay accountable

These are all questions I hear all the time. This book is heavily focused on shifting towards an async-first environment, because I believe this is the #1 transition an organization needs to do.

Anyways, the entire thing is available for free online. There's an audio version too and spent quite a bit creating illustrations for each of the chapters. If you want a hardcopy, I'm offering that at cost on Amazon (I make 1 penny for every book sold).

Here's direct links if you want to jump right in:

1. To Read: https://friday.app/anywhere

2. Spotify: https://open.spotify.com/show/4sfH4lZlydvzoSkKKkhJTa?si=rvKP...

3. Youtube: https://youtube.com/playlist?list=PLqnVBFm2Yol1H0dONrXa8LDoS...

4. Amazon: https://www.amazon.com/Anywhere-Operating-System-business-an...

I hope this helps you all. I'm just tired of seeing people act like this is all brand-new, when in reality, there's a mountain of evidence and best practices that can save you a lot of headaches.

async is not a losing battle. Trying to handle async communication processes manually is.

Right now, most async communication processes (like status updates or daily standups) involve a ton of manual effort to make sure that people share this information.

I strongly recommend creating systems and using automation as much as possible here.

Most workplace communication tools are focused on improving the efficiency of communication. I think of this as laying "pipes". It's never been easier to jump on a video call or ping someone in Slack or email. What happens is that the information/communication doesn't flow on a repeatable or predictable basis.

What people really need when remote is a way to help create and automate a series of communication habits/workflows, so instead of hunting around or perusing Slack to understand what's going on, the information flows to you. Like a series of communication pumps.

Right now, most managers manually collect this, which is an epic waste of time.

Self plug, but after 8 years working remotely and constantly running into the workplace chat firehose, I've built software to help automate any routine update at work (https://www.friday.app).

Any wiki software suffers from the problem that only a small percentage of the company uses it. It's essentially a tax on the most productive people. If someone asks you for the same thing 8x, you will write it down and share it via a wiki.

I've spend years trying to solve the problem - how do you get the average person writing more at work? What I've come up with resembles a company "journal", but helps you automate any routine communication or update (daily standup, weekly update, retros, etc).

Would love any/all feedback on the idea, here's the website (https://www.friday.app/). You can use it as an individual, team, or with the entire org.

This is right on. Slack's pricing is based on regular usage, so they have an incentive to keep you distracted (to put it bluntly).

Microsoft sees chat as a piece of an overall communication "puzzle". They have Sharepoint for more persistent information and Yammer for "outer-loop" communication.

My startup (https://www.friday.app/) is based around the idea that there needs to be a "home" for the most important stuff at work that complements workplace chat. It's somewhere in-between Slack and a wiki (which most people don't use regularly).

Workplace chat tools like Slack are wonderful for quick collaboration, but if you over-index here you will run into trouble. That's why Zapier, Automattic, and Stripe have all built their own internal tooling to help.

My journaling habit started with Ohlife.com way back in 2014. I found the idea of quickly recapping my week to be therapeutic., plus it was great to see entries over time.

I ended up building a product (https://www.friday.app/) to make this easy and automated. While it's built for teams to share updates and reflect (think weekly updates, retros, etc), there's "single-player" mode available too.

I like the digital journal format because I could never start the habit with paper. The automated reminders were critical to establish the habit. I still keep a regular notebook where I'll document thoughts, but it's more ephemeral.

This is awesome! I've really enjoy watching the interviews they publish on Youtube: https://www.youtube.com/channel/UCNc-Wa_ZNBAGzFkYbAHw9eg

The solution to Zoom fatigue is to eliminate meetings where the purpose is to share basic facts & information.

Save meetings for collaboration, relationship-building, and working on thorny problems.

This is a great point. The issue is that the current best practice advice is to use a wiki.

Wikis are riddled with problems. They become out of date quickly. They need a librarian over time to organize the content in a way that's meaningful. There's also no "habit loop" to encourage people to regularly contribute content.

Right now, wikis are a tax on the most productive people in a company. If someone asks you the same question over and over, you will eventually document it to share.

At my company (https://www.friday.app/) we've found a way to get people to regularly communicate asynchronously via regular updates like daily standups or weekly status reports. It's more like a work journal vs. a file cabinet.

When collaborating over ambiguous topics where the potential to be misunderstood is high, you need to use the "richest" communication channel possible. Body language, facial expression, and the fast feedback loop can help you quickly establish a sense of common ground.

On the other hand, status updates or sharing of metrics/information can easily be done asynchronously, because the potential to be misunderstood is low. It's also a more scalable approach and persists over time.

I'm the founder of a startup with 6 employees (FT/contractors) and have one 1-1 meeting every week (30 min) + a "coffee shop session" for an hour where we shoot the breeze and talk about non-work stuff.

A couple thoughts:

1.) communicate asynchronously as much as possible. If you have a synchronous conversation like a meeting, make sure there is a written representation of what was discussed. If it doesn't persist, it doesn't exist

2.) Understand that implementing a wiki by itself will not work. There's a gravitational pull to throw a bunch of junk in it (like a file cabinet). Things become out of date and each person will structure things in a different way.

3. Create some loose structure around sharing regular, written updates about what each person/team is working on.

At my company (https://www.friday.app), we've created a tool that is somewhere in-between Slack and a wiki. It's kindof like a work journal. As a distributed team who only has 1 meeting every week, it's a place where all our updates are captured in a single place.

This is great advice. As an employee, I've found success with the following:

- Send an agenda beforehand. This gives your manager an idea about what you'd like to discuss, so then they can prepare themselves and/or not get caught off-guard.

- At the end, I try to ask, "do you have anything for me?", which typically opens the door for them giving you feedback/thoughts if they have it. It also is a nice way to prep myself for receiving feedback vs. it coming without me "opting in."

I wrote about some other ideas on 1-1s in this guide...not sure if useful: https://www.friday.app/p/employee-1-1-meetings

A lot of this depends on people on the maker's schedule vs. the manager's schedule.

Or put another way, some people like the office environment because it matches how they communicate and get things done. The office environment is built around the idea of real-time conversations, which can be helpful for collaboration if it's not overused.

With that being said, the office (especially open-offices) take this idea way too far. I just finished a post about it a couple minutes ago: https://www.friday.app/office-vs-remote-distance-communicati...

If anyone wants to dig into when to use sync vs. async, I strongly recommend learning about "grounding" when communicating:

https://en.wikipedia.org/wiki/Grounding_in_communication#Gro...

Totally agree - I wrote a rebuttal to the concept of "virtual office" tools for distributed teams a few minutes ago:

https://www.friday.app/remote-work-virtual-office

I used Sqwiggle back in 2013 and while I appreciated the idea in theory, as an employee, it felt like an employee oversight tool.

Essentially, it gave the impression that my boss didn't trust that I was doing my work. This tool made it so someone could see if I was actually at the computer doing work.

It also drained my battery, so I always needed to have my computer plugged-in.