1,501 karma · joined November 18, 2011
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.
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.
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.
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 :)
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.
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.
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.
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.
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).
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.
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.
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.
Save meetings for collaboration, relationship-building, and working on thorny problems.
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.
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.
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.
- 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
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...
https://en.wikipedia.org/wiki/Grounding_in_communication#Gro...
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.