Keyring is a generalized framework for WordPress which handles authentication with, and authenticated requests to remote services. It provides a set of predefined “Services” which describe how to communicate with a collection of popular platforms, and also makes it easy for you to plug into that framework and define your own Services for other systems.
This version includes a bunch of improvements and compatibility updates, including all sorts of contributions from other folks. There are a lot of fixes and tweaks that have come back into the project as part of it being used on WordPress.com, and as part of the hiring process at Automattic.
Enhancement: Define the self endpoint for Tumblr, and add helper methods to retrieve user info. Props @glendaviesnz.
Enhancement: Add a keyring_{service}_request_scope filter for OAuth2 services, matching the existing filter for OAuth1 services. Props @glendaviesnz.
Enhancement: Add a 'full_response' param to Keyring_Service_OAuth2::request(), which will cause the method to return the full HTTP response object. Props @glendaviesnz.
Enhancement: Some services (looking at you, Strava) seem to double-encode redirect URIs, resulting in “corrupted” parameter names. Added a method to clean that up.
Bugfix: Make the Google services always request a refresh token for offline access. Props @kbrown9 and @atrniv for input.
Bugfix: Update Strava to use refresh tokens and offline access, per their new API requirements. Props @mdrovdahl for pointing it out.
Bugfix: Update use of add_submenu_page() to comply with WP 5.3. Props @jhwwp (wp.org) for the fix.
Bugfix: Apply the keyring_access_token filter consistently in Google Services. Props @pablinos.
Bugfix: Use static “Cancel” URIs in UIs. Props @pgl.
Bugfix: Remove some WordPress.com-specific code from Eventbrite.
Bugfix: Ensure that PUT requests have a Content-Length header set. Props @glendaviesnz.
Bugfix: Compatibility with more recent versions of PHP7, and PHP8.
Bugfix: Apply keyring_access_token filter properly in Instapaper.
I worked as a full stack engineer/developer for many years before going into more leadership type positions, where an understanding of the business itself became much more important than specific product experiences, features, or codebases. Along that journey I’ve needed to learn a lot of acronyms and concepts that aren’t a part of pure engineering, and would like to summarize some of the more fundamental pieces below in case they’re useful for others making a similar transition.
A lot of this is likely to come across as very basic for anyone who’s spent time thinking about these sorts of things — that’s entirely intentional. Think of it as a primer for someone who’s never needed to look outside of pure code/implementation, or care about the business side of things. I would also add a huge caveat that in my experience companies often define the specifics of these concepts differently when you dig into exactly what they’re referring to, so it’s very important to verify exactly how your company is using them.
Net vs Gross: Mostly used in the context of revenue or income. Basically Gross is the overall/total you take in, while Net is Gross minus “deductions”. Exactly what those deductions are is where things can get complicated. For personal income, deductions might include taxes, Social Security, Medicare, etc. For companies, they might include refunds, returns, and specific expenses involved in producing/selling a product. This page is a good explainer (and talks about some of the vagueness in these terms).
Conversion rate: This is an extremely common term in the software industry, and just refers to how many times one event happens after another. The same concept is applied to all kinds of usage metrics, from clickthrough rates (the conversion rate of people who view something, vs those who click it) to signup conversions (people who visit a site, vs those who complete the signup process) to purchases of products (which are a “conversion” from viewing a product, to purchasing it). To calculate a conversion rate, you just divide the number of “later” events by the number of “earlier” ones and convert to a percentage. So if 5,000 people view a link, and 1,000 of them click on it, that’s a 20% conversion rate — (1000 / 5000) * 100. Conversion rates are useful at all levels of granularity, so they could be very “macro”, looking at perhaps a conversion rate from visitors to the homepage of a website, to completely verified signups, or they could be much more specific; looking only at the conversion rate between those who enter their email to sign up, and those who actually receive and open that email. Understanding conversion rates and those levels of granularity are really powerful when combined with the next concept —
Conversion funnels: Everything is a funnel. Conversion funnels take the idea of conversion rates and apply them throughout any series of events, documenting a series of conversion rates from event to event. It’s called a funnel because at each event, there are likely fewer observed instances of whatever you’re measuring than there were at the previous event (so when you visualize the funnel, it gets narrower further “down” the funnel). Conversion funnels can be applied to all sorts of things — hiring processes, usage in a UX flow throughout a product, organizing sequential contributions to a celebration, etc. Once you start thinking about conversion funnels, you see them all over the place. “Pirate Metrics” are a fun version of the classic implementation of a conversion funnel for marketing/sales/growth (don’t get too caught up on the specific events/stages in the funnel though). Understanding your funnels is important because it gives you a way to numerically analyze the path towards some desired outcome and identify bottlenecks or inefficiencies in that path, then remove/reduce them. When people refer to “top of funnel” they are talking about the very beginning of the flow; so the number of initial visits to a website, or the number of applicants to a hiring process. Conversion rates are measured through each step of the funnel, sometimes “flipped” to show a “drop off rate” between events. You might also look at an overall conversion rate which compares “top of funnel” to “end/bottom of funnel”.
The Pirate Metrics conversion funnel. AARRR!
Lifetime Value (LTV, sometimes CLTV for Customer): LTV refers to how much revenue you expect to make on average from a paying customer. So if you sell a single product for $100, and everyone buys one of them, then your LTV will be $100. Things get a lot more complicated when you’re selling subscription products/services, at different rates, over different periods. In that context, understanding the average purchase price and the average duration of a subscription allow you to come up with an LTV. If you sell an average $10/month subscription and most customers stick around for 18 months, then your LTV is $180. Note that if you’re also selling annual subscriptions then you might need to convert those numbers by dividing by 12 to make them monthly. LTV can be quite hard to come up with depending on the frequency of purchases, how “spiky” purchases are, and a number of other factors, but is very important because it’s a key value in figuring out how much money your business can spend to acquire customers (see below), without being in the red. This article has an extensive breakdown on the math.
Customer Acquisition Cost (CAC, sometimes SAC for Subscriber): For most businesses, you’ll be spending money to acquire customers. That might be through printed newspaper advertising or search engine marketing or banner ads on industry websites, but you’ll likely be paying to get people to check out your product and hopefully buy it/sign up for something. CAC just refers to how much it costs on average for you to get a single paying customer. So this effectively becomes a conversion rate (see above) between “dollars spent on marketing” and “number of people who become paying customers”. If you spend $2,000 on search engine marketing, and get 15 paying customers from that campaign, then your CAC is 2000 / 15 = $133. This is another really important number to know and understand because if it exceeds your LTV (above), then you’re spending more money to acquire customers than you’re making from them. CAC normally doesn’t even take into account all your other operational expenses, so the picture is even worse if you include those. Keep in mind that you can also look at a “blended CAC” which includes all marketing costs, or more specific ones for different sales channels (where you might find that some are profitable, while others are just wasting money).
Monthly Recurring Revenue (MRR, also ARR for Annually): These figures help you understand how much of your revenue is predictable for a period (Annual or Monthly) and are based on reducing subscriptions to the same time period. To get it just multiply your averaged monthly subscription billings by your number of customers. Baremetrics has a pretty good explainer on MRR and related concepts around expansion, contraction, etc.
Growth rate: Refers to the change in a number from one period to another, and is presented as a percentage increase (or as a negative if a decrease). It is often used in the context of month over month (MoM or m/m) or year over year (YoY or y/y) in financial contexts, but could be used on shorter periods for measuring something like a usage metric. Growth rates can be used on revenue, subscribers, order volume, or pretty much anything else that you’re measuring. To calculate growth rates, make sure your numbers are based on the same periods (e.g. days or months or years or whatever) and then use: ( ( later - earlier ) / earlier ) * 100. So if the value being measured is $205,000 in March 2020 and $145,00 in March 2019, you’d have ( ( 205000 - 145000 ) / 145000 ) * 100, or 41.4% growth, year over year.
Retention and Churn: I’ve put these two together because they’re often used in similar but “opposite” ways. They are mostly used with subscribers/customers, or revenue. Very roughly speaking, Retention measures how much of your revenue (or how many of your customers) is sticking around from period to period, while Churn refers to how much of it is disappearing. They are normally both shown in percentages, so they should add up to 100%. Let’s imagine you have a monthly subscription product, and you get 1,000 subscribers. When it comes time to renew those subscriptions only 800 of your subscribers successfully renew. You have a retention rate of 80% and a monthly churn rate of 20% (this is very bad!). Where things get trickier here is that you presumably get new subscribers constantly, so you need to be able to look at cohorts (grouped by month perhaps), or something like “revenue retention” where rather than look at subscriber counts (especially if they reflect different subscription dollar values), you look at the amount of revenue that their subscriptions represent, which can help paint a more complete picture (especially if you’ve got upsells, downgrades, and other things in the mix). Churn is an extremely complex topic, and is often quite difficult to understand. Customers could be leaving your product for all manner of reasons, some of which are entirely out of your control. Generally speaking you want to keep churn as low as possible though, because those are customers you’ve likely already spent money to acquire (CAC), and should theoretically be much easier (and cheaper) to keep happy than going out and acquiring new customers. A high churn rate is also normally a clear indicator of a lack of product market fit/lack of customer satisfaction with your product. This is a good guide to different types of churn.
What other useful metrics or acronyms have you come across in “engineering adjacent” vernacular?
I used to have Wink set up, managing some smart home devices throughout our house. I liked it because the app UI was quite nicely done, and it seemed to be compatible with “everything”. I had even upgraded from their version 1 hub, to the version 2. But then a few months ago they decided (somewhat out of the blue) that they were going to start charging a subscription fee. Coupled with some recent outages and frequent command delays, and it was the “motivation” I needed to invest in a Home Assistant system, and move away from Wink entirely.
Set Up + Config
I chose to install everything on a Raspberry Pi 4, and am using the official images and recommended way of configuring things. Things mostly worked as expected, although I had some trouble getting Z-Wave working, and also getting used to YAML in general. I also wrestled with getting DuckDNS and SSL working for a while, but some of that ended up just being me port-forwarding the wrong ports. Here are a few details on some of the things I’ve got running which I think are useful:
Dropbox Sync: Back up your system snapshots to Dropbox, for safe keeping. I have an automation which syncs daily, and then only retain the most recent 3 on my HA install locally.
DuckDNS: This is how I get external access to my install, which is nice especially for the iOS app, so that I can control things from a distance.
FTP: I turn this on/off when I need it, but it’s nice to just get quick access to files for editing things via a real editor.
File editor: When I’m making quick tweaks to config, this is an embedded/browser-based file editor that gives you full access to everything.
Alexa Smart Home integration: Pretty tedious to set up, but it’s working smoothly and allows me to easily add/remove devices and control all sorts of things.
I configured static IPs for as many of the “permanent” devices as I could (HA host, Lutron bridge, Roomba, MyQ, Tempest weather, and our AppleTV), which has made it a little easier to keep track of things. I also forwarded ports 8123 and 443 into local 443 on the HA host, which is required for getting external access (and Alexa control) working.
Platform Details
I’ve ended up with a few key pieces to my configuration, namely:
Z-Wave: 2 Schlage door locks and 1 (relay) switch, controlled via an Aeotec USB stick (I’ve had the most trouble with Z-Wave devices, and currently don’t have one of those locks added to the system).
Zigbee: Aqara buttons and climate sensors, controlled via a ConBee II USB stick.
Wyze Sense: Door open/close and motion sensors, controlled via the Wyze USB hub.
Lutron Caseta: dimmer light switches, controlled via their separate hub.
There are also a few other pieces (like a MyQ garage door controller) and some native integrations (HomeKit, SONOS, Roomba) that round things out.
Automations + Smarts
The point of all of this is to add some “intelligence” or convenience to your home, so this is where things get fun. Here are a few of the things I’ve been able to do (so far!):
Mailbox Sensor: I added an open/close sensor to the mailbox, so that we get push notifications and an indicator in the HA dashboard when we (probably) have mail. I also have an NFC sticker near the mailbox that allows me to clear the sensor easily.
After dark door/lock notifications: If we leave a door or lock open for 15 minutes after a specified time, we’ll get a reminder to make sure we close things.
Goodnight button (via Python script): I have a button next to the bed that locks and turns things off when we’re ready for bed. If something is left open we get a verbal warning via SONOS speaker.
Door announcements: We get a verbal announcement when a door is opened.
Doorbell: I replaced our doorbell with an Aqara switch. Now when someone presses it, a door chime is played on our SONOS speakers, and we get a push notification with a snapshot from our security camera at the front door.
Garmin HassIQ: I have a Garmin Fenix 5, and I found a neat little integration that allows me to control most “switching” devices directly from my watch!
Motion controlled lights: I’ve configured various lights to turn on automatically based on motion, and to turn off after periods of inactivity.
Garage Car Door left open: If we leave the car door of the garage open for more than a few minutes, we get a push notification to make sure that it’s intentional. If it’s not, there’s a button included in the notification that allows you to close it immediately.
Automated chores: I control our Roomba via HA now, and run it a few times a week. We get a notification when the bin is full. We also have some automated sprinklers that are now controlled via HA. If/when the integration controlling my weather station is fixed, I’ll also add in some smarts around temperature and rain (delays and increased watering).
Shopping List
Here are all the pieces I’ve purchased so far in building out our system.
I also ended up adding an (excessive) UPS and extra battery to keep things running smoothly.
I’ve got a few iSP5 switches connected via HomeKit as well, which I had from my previous set up
It’s been a pretty big and long-running project, but I’m happy with the results. I love that it’s (almost) all local (no external internet connection required for most pieces of the system), and it’s been quite fun tinkering around. I’m also able to dial in automations to a level that wasn’t possible with Wink, and the sheer scope of compatibility I have now is pretty impressive. It has been nowhere near as hard as I expected to get it all working (I was expecting a ton of command-line mucking around, but it’s mostly UI-driven).
There’s still a bunch I’d like to do, especially around UI and control, and setting up a tablet or 2 to have around the house to control things, but overall I’m really happy with it. Open source FTW!
I’ve been searching for years for the “perfect tool” to help me take notes, organize ideas, and keep track of all the tasks I need to do. I’ve also been deeply obsessed with lists forever. At some point I came across Workflowy, which I quite liked. I don’t remember why, but I then discovered and switched over to Dynalist.io. I don’t know if it’s the perfect tool, but I’ve adapted a way of using it that’s working well for me. I now pay for a yearly subscription, and use it for most things.
The Big Idea
The big idea for both Dynalist and Workflowy is really that everything is a nested list. So you can create lists within lists, to your heart’s content, and expand and collapse things at every level to view more or less detail. Dynalist does allow you to split those lists out into separate documents (not sure if Workflowy does this now), and even organize those documents in folders (see below), but generally speaking these systems encourage you to think of things as all connected through one giant structured list. I like that idea from a deep philosophical level, based on the premise that there’s some kind of grand scheme to things… but my pragmatic side also likes to be able to split things up and handle them separately, so let’s dig into that. This line of thinking goes back a really long way, including a stop on OPML along the journey.
Top Level Organization
I have 3 top-level folders in my Dynalist sidebar:
Folders in Dynalist.
I try not to delete any real “notes”, so if I don’t need them, I move them to Archived. Work and Personal are pretty self-explanatory. Inside each of those, I have the following three lists, at the top of that folder:
TODO: structured lists (varying structures, we’ll get there) of things that I think I need to do. The Work one is the most structured.
Notes: general notes, about anything and everything, organized based on topics/high level ideas.
Calls: notes that I take during various phone calls/meetings, for my own reference. Mostly structured by person/company, and then date.
Work > TODO
The top level of my Work TODO list looks like this:
Work TODO list
Backlog: This is kind of an inbox for things that I am not specifically doing yet, but it’s not handled like GTD (“immediate” processing), so things can sit in there for a while. It is set as my Dynalist inbox, so when I hit cmd-ctrl-i I can add directly to it from anywhere.
Daily: Here I have a sub-list for each weekday, which I set as H2 headings. Each of the days just contain everything I’m doing that day. I have a single repeating event on Friday to write up and post some “weekly notes”, a habit I maintain internally to keep colleagues informed with what I’m up to. That event repeats at 3pm on Fridays, and when I check it off it automatically adds a new one ready for next week.
Periodic / Scheduled: I have some things that I just want to make sure that I do, and they are on schedules less frequent than weekly. I keep an entry for them each in this list, and make sure that they recreate entries when I cross them off.
Daily Usage
To support scheduled tasks (using the !date notation), I sync Dynalist with my Google Calendar (Pro feature), so those items show up in my calendar along with other appointments, and remind me when it’s time to do them.
A lot of my entries involve interactions with people, and I mostly use @someone to refer to people consistently. I use some #tags but not very consistently. Since I delete a lot of my items (see below) I don’t find too much value (e.g. being able to refer back to things) in maintaining a lot of metadata.
Either at the end of each day, or the beginning of a new one, I try to spend a few minutes and map out what I’ll be doing that day, in the appropriate list (Work > TODO > Daily > Tuesday). I take a quick look at my calendar and add an entry for any scheduled meetings, 1:1s, etc. I put things in rough time order for the day, so my lists are both numbered and have checkboxes (cmd-shift-c to toggle checkboxes). If there’s a relevant link for an item, I’ll add that in the Notes field (shift-enter), so that I can quickly open/jump to it when I get to that item.
During the day, I try to focus in on a single thing, so I navigate to the specific item I’m working on, and my view will look something like this:
Focus on a single item. Sidebar collapsed, this is the only thing I can see.
I’ll leave Dynalist in my second monitor, in that view, while I’m working on that item. It serves as a constant reminder whenever I see it, that I’m supposed to still be addressing that item, otherwise I’d have checked it off. Once I’m done, I will in fact check it off (cmd-enter) and then navigate to the next item on the list. I recently discovered the keyboard shortcut to do this directly (cmd-shift-]) and it’s been a huge win for me. I found that previously I’d navigate back to the specific day’s list, and then start looking at/thinking about all the other things on my list for today — now I can just bounce straight to the next one and ignore everything else. I do leave checked items showing (Preferences > Viewing options > Show checked items) because it lets me progress throughout the day when I go back to that main list.
At the end of the day, I’ll delete everything completed, and if I have any items left in that day that I didn’t complete (happens all too often, I’m afraid), I’ll either roll them over to the next day, or reassess what to do with them entirely. Sometimes I’ll move them back to my Backlog list, sometimes I’ll change the entry to get me to delegate it to someone else, or sometimes (eventually) I’ll accept that I’m never going to do it, and I’ll just delete it.
Delete checked items, via the hover-hamburger menu.
I think those are the main unique pieces of how I use Dynalist. It’s been working well for me, and I’ve been doing things like this for a while now. If you’ve never used Dynalist (or Workflowy), but are a compulsive list-maker like I am, check them out. For longer form note taking and idea capture, I’m curious to give Roam Research a real try, it seems like a less-structured, long-form version of these tools.
COVID-19 (aka coronavirus) has many companies suddenly experimenting with remote work for the first time. I tweeted yesterday that unfortunately people are likely to have a pretty rough time due to the rushed nature of the experiment, and some folks asked if I could expand on that, so here we are. There are already a bunch of write-ups, resources, and tools if you look around (including one from our CEO Matt, and this great webinar-format session from Cate and Nicole), so it’s worth getting other views and ideas as well.
If this is your first experience at remote work, it’s unfortunately probably going to be pretty rough. Don’t let it taint your view though – to do it well requires cultural and process change in your org plus a lot of adaptation.
We’ll look at some concepts that I think underpin successful distributed work, and then we’ll dive into a loosely-structured “day in the life” to look at some of the specific tools and approaches we use currently at Automattic. This is all based on about 13 years worth of working remotely or fully-distributed, 11 of which have been with Automattic where I’ve been a part of growing the company from ~40 people to ~1,200 people, spread across 76 countries. I’ve been everything from an individual engineer to a leader across groups up to about 60 people. We’ll focus on the day-to-day type work of an engineering-heavy organization rather than the business/human resources/operations side of things. This is going to be long, and probably a bit rambling.
Before we get into it, three quick notes;
I tend to use the term “distributed work” rather than “remote work”, because at Automattic we don’t have a central office to be “remote” from. We’re fully distributed. Like a decentralized network. Have been since day zero.
We operate across many timezones (almost all of them), which creates its own complexities and amplifies the need for certain practices and approaches. If you’re taking an existing shared office remote, that might not be the case, but a lot of the approaches we use will probably still be useful to enable more async work (we’ll get to that below).
Tools are not the answer. Working remotely requires a cultural shift from your org, and a change in how you do business. Tools are part of the puzzle, and having good tools helps, but they won’t make or break your success.
.gutentoc-toc-wrap ul li a, .gutentoc-toc-title-wrap .text_open{ color: undefined}}
Key Concepts
Transparency, Trust, Access
Our DNA at Automattic is firmly rooted in the WordPress open source community. From that world, our default is open; most people can access most information (including most conversations) about most things across the company. We trust everyone to make good decisions and spend their time wisely, and so they have access to “as much as possible” (and of course is prudent). This gives everyone much better context for what they’re doing, eliminates many “can I get access” type requests (and associated delays), and allows people to operate more independently which is critical when any kind of feedback loop can potentially stretch into days (if there are timezone differences, back and forth/approvals required, etc). This is probably one of the hardest things for a lot of companies to adapt to/adopt.
Default to open. There’s probably no harm in most people having access to most of your work communications. If there is harm, consider why. It turns out there’s actually a lot of good to be had here.
Trust people to make good decisions. You hired them, hopefully because they are good. Don’t optimize for the lowest common denominator. Implement minimal policies/guard-rails to help people keep making good decisions.
Communicate, Communicate, Communicate
I firmly believe that communication is critical to any successful endeavor, but when you are in a remote or distributed context, that criticality is amplified and multiplied. In an office or shared space there’s a certain amount of ambient or baseline communication — you run into people in a hallway, you see them flip a table or slam a laptop shut, you overhear a conversation — online you have none of that. You have to get a lot more intentional, and probably a lot more “prolific” in your communication. Overcommunicate. What you think is overcommunicating is probably not. So communicate more than that. Then figure out a sustainable pace. When people are not communicating in remote work, they become invisible. Invisible is bad. Over time it tends to indicate someone is disengaged, struggling, or already checked out. Don’t be invisible.
Get really good at illustrating and explaining things in written form, because it’s still the native format of the internet. Supplementing with videos, diagrams, animated gifs or whatever else works is very valuable, but the written word still rules. In the almost-11 years that I’ve worked at Automattic, I’ve written 1,769,219 words across 29,620 posts and comments on our internal P2s. I’ve probably written a similar amount across IRC and Slack (about 2,000 messages a month on Slack), and have consumed/read multiple times that many.
The vast majority of our communication (see below for more detail) happens via:
When everyone is working from their own space, on their own schedule (might not be relevant if you continue requiring people to work 9-5 in your local timezone, but it’s a big part of the benefit of distributed work), it becomes really important to make sure people can work independently (“asynchronously” from each other). That doesn’t mean that they always have to work on their own, but they should ideally never be blocked or held up because of someone or something else (that’s out of their control). Avoid requiring people to constantly interrupt each other just to keep moving. Write everything down. This is a weird cultural shift for some orgs, but we make sure all decisions especially, but often the discussions that lead to the decision, are published internally as written text. It requires people to be able to communicate their ideas clearly, in sentences (and diagrams, videos, whatever else), but becomes more and more valuable over time. “If you can’t link to it, it doesn’t exist” is a common refrain for us. We often refer back to conversations or decisions from months, if not years ago.
Some specific tactics:
Document everything. Having things documented and available to reference means people can self-serve rather than having to ask/interact on every little detail. This goes for decisions, architectures, vision, mission, roadmaps, project plans, discussions, processes, etc. We’ll explore a few options for where to document things further down.
Prioritize unblocking other people. Do whatever you can to make sure that other people are never waiting on you for anything. Sometimes that means telling them you’re going to take a while, or that you’re not going to do something. That’s better than waiting.
Reduce cycle time on communication. Compress greetings and questions into a single message/exchange, rather than “hi, are you there?” (delayed response) “cool, can i ask you a question?” (delayed response) “how do i…”, just send it all together so that the other person can see, prioritize, and respond in a single hit “hi beau! don’t know if you’re the right person to ask this, but how do i…”.
Anticipate possible responses and provide alternatives. This is a variation on the above, but instead of doing something like asking “does this time work for you?” and then possibly having to go back and forth, it’s faster over all to offer a few options, and anticipate that the first option might not work. The same goes for all sorts of interactions, where you can ask a question and add “if not that, then what about…” alternatives.
Spend time face to face
Sorry coronavirus, but this is actually a key part of making remote work successful longer term. This one might not be as relevant in the current environment, since presumably you already know your coworkers and have spent time together, and the whole point is to avoid being face to (coughing) face. For us, it’s really important to get together a few times a year and really get to know our coworkers. Spending some time with people allows you to get to know them on a level that I’ve just never seen replicated through the types of transactional, work-based video chats we normally do (more on that later).
We normally hold meetups at the team level once or twice a year, and at the entire company level once a year. They go from ~4 days to a full week, and people are together “24/7” during that time (except sleep, of course) during that time getting to know each other, planning, working on projects, participating in activities together (like going on photo walks, bike tours, museums, cooking classes, all kinds of stuff).
OK, so now that you have some of the underlying concepts, let’s look at a day in the life. I’ll try to break this up into some chunks that make sense, and we’ll dive into some detail here and there where I think context is useful. Feel free to ask in the comments if something doesn’t make sense, or you’d like more examples or whatever.
A Day In The Life
I mostly work from home. Some people prefer co-working spaces, cafes, libraries, or whatever, but my schedule tends to be heavily-laden with video calls these days, so it’s easier for me to just work from home most of the time. I’m lucky enough to have space for a separate office, and no one else is home during the day, so it’s quiet and I can avoid distractions (or distracting others). I don’t know how people do it when they’ve got a whole family at home with them. I used to work at a stand up desk (literally) inside a closet because New York. It worked for a while, but I don’t miss it at all. As you can see below, I have a Mac laptop, with an external screen. In the second photo you can see that I use the built in keyboard on the laptop now. I go back and forth using an external mouse and just using the built in trackpad.
My standing-desk-in-an-IKEA-closet when I lived in Brooklyn.
My sit/stand desk at home in Denver. Obviously I cleaned up a lot for this photo.
Schedules & Timezones
Set your own boundaries/delineation between work and non-work. It turns out your commute was doing that for you.
Timezones are terrible, and will likely require you to be a bit more flexible with earlier/later appointments.
Setting some scheduled time to work might be better than being super flexible.
I usually get up at about 7:15am. I try to have something resembling breakfast, but highest priority is coffee and breakfast is often skipped until later in the morning (or entirely). I think the cool kids call that intermittent fasting? Whatever. I make a single mug of very nice pour-over every day, and try not to have more than that unless I’m really dragging. I have no real need to leave the house in the morning, although when the weather warms up it’s nice to get outside and walk around the block, check out my garden, or otherwise get some fresh air. I actually miss my previous commute of about 20 minutes once in a while, because it was a great time to read, listen to a podcast, and just “mentally prepare” for the day. Sorry productivity experts, I don’t meditate, go to the gym, journal 1,000 words or all of the other “must haves” in the morning.
Once I’ve got my coffee, I will take a little bit of time to read something non-work-specific, and “ramp up” a bit. Sometimes that devolves into trawling Twitter and Instagram. Then I’ll start checking in on Slack, P2s, etc (more below) and get into the swing of the day.
Thanks to timezones (uuugghhhh), and my teams being spread all over the world, my mornings are often heavier on calls/”meetings” (hi, UTC+!). I try not to schedule anything earlier than 8:30am, but sometimes I’ll have something important or unavoidable at 8, or as early as 7:30. I’m pretty non-functional earlier than that. Since I’m on Mountain time, and since we tend to have fewer folks in the APAC region, my afternoons are when I can get more of my own solo work done. Don’t get me started on Daylight Savings Time. You think it’s bad within the US? Combine that with different timezones and DST schedules across the rest of the world.
I try to end my day around 5:15pm by going to the gym (or doing something else) rather than just having the day fade out and me wandering out of my office to flop on the couch (literally 5 steps away). Setting boundaries is pretty important when you’re working from home (or are you living at work?). I’m quite bad at setting those boundaries myself so having something like a scheduled session at the gym helps force the end of my day. Sometimes I’ll come back and work more in the evening, but at that point I’m making a decision rather than just sliding into it. It turns out that a commute is good for something — explicitly starting and ending your work day.
I’ve experimented with much more flexible schedules over the years (split time early and late, weekends, etc), but have found that I work better and more sustainably if I just set clearer boundaries, and keep it roughly in line with a “normal office work day” (in my timezone). While I may have a flexible schedule, my wife and friends don’t, so if I want to spend time with them, it’s easier to just be at least roughly on the same hours as them. I also need to be available for certain scheduled calls/interactions, so that dictates things to an extent.
Calendars, Calls, & GTD
Zoom for video and audio calls.
Google Calendar (and Fantastical) for calendaring/schedules.
Google Docs for collaborative docs, meeting notes.
Calendly for external scheduling.
Dynalist for personal productivity/lists.
What you refer to as a meeting, I probably refer to as a call. All of my calls are done through Zoom. You could use Google (whatever their latest renamed video conf thing is), or any number of alternatives, but Zoom works well, and everyone at the company is on it so it’s the easiest for us. I use a Sennheiser headset (this one is USB-C!) to improve audio quality. For most calls (especially repeating ones like 1:1s with direct team members/manager), I use running Google Docs where we both/all have access and can set agenda items and take notes collaboratively. Some teams use something like HackMD to similar effect, but despite its weight, I think Google Docs feels pretty natural and works well. Add a link to the doc in the calendar invite so you can always find it. Always send an invite so that everyone has the event on their calendar. Move important things/summaries to P2 (more below) so others can find and reference it easily. Consider recording the video/audio of a call if it would be useful for others to watch/reference as well.
Speaking of calendars, I use Google Calendar (via GSuite) to schedule everything and then have Fantastical on my Mac to help keep on top of multiple calendars (personal/work/others). GSuite works well to easily add other people within the company, confirm availability etc. If something is not in my calendar, I’m unlikely to remember to do it, so I schedule in personal stuff as well, and include blocked out chunks of time to get things done.
I use Calendly when I need to give someone (especially external) the ability to quickly find a 30 minute slot in my schedule.
It’s changed multiple times over the years, but I’m currently using Dynalist to keep track of my own things that need doing. I’m not using a strict GTD approach, but I have some daily lists, longer running stuff, repeating items etc, and try to move everything to a list somewhere if I’m going to actually do it. I also use iDoneThis (via an Alfred shortcut) to track what I do throughout the day.
Active Communication
Slack for immediate or ephemeral communication.
Use emoji reactions for fun, efficiency, empathy, emotion.
Zoom for screen sharing/pairing.
Weekly (possibly more) team sync calls.
Multiplayer mode required for everything.
Slack
We use Slack a lot. When I started with Automattic, we used IRC (really!), so Slack is an upgrade, but fundamentally it’s pretty similar. We do have a lot of automated bots posting into Slack for various things (new P2 posts, GitHub activity, outage alerts, all kinds of stuff), and some that we can interact with for various workflows. We also have some automations around adding/removing people from certain channels and groups which make it easier to notify groups to certain things, or know where you’re supposed to go to talk about something.
Within Slack we have (lots of) channels based around all sorts of things. Every team has their own. Most large projects have their own. We have some announcement-only ones for various levels of the org (entire company, different roles, business units within the org). There are channels for specific working groups and cross-team groups as well. There are watercooler channels for all sorts of things (#bake, #great-outdoors, #bike, #gardening, #fishin, you name it). Mostly they’re public, but there are definitely a lot of private groups and DMs as well. More than we’d like/like to acknowledge, but at our size you do start to have a lot of conversations that either need some level of privacy, or it’s just easier to pull in a specific group.
I think Slack is generally good for quick questions, clarifications, updates (“here’s what I’m doing today”) and things like that. It’s bad for nuanced topics, things that require a lot of detail or thought, or anything you’d like to be “evergreen” (something you might reference later). We encourage people to move to P2 for those sorts of things, as well as for documenting decisions that might get made in Slack. It’s dangerously-good at being distracting though, so you need to manage your notifications and availability carefully. I think emoji-reactions are a deceptively powerful addition because they allow for micro-interactions while conveying a surprising amount of information. We have 7,954 custom emoji in Slack (😱).
Teams at Automattic mostly have at least one synchronous call a week. Depending on your role and what you’re working on you might have more than that (sprint planning, solving a specific problem etc). These calls are all scheduled to try to cater to the timezones of those involved, and on a cadence that makes sense (most either weekly or fortnightly, some monthly). They are a chance to spend some time with your team, chat through personal (get-to-know-you) and work things, hash out blockers, plan for the upcoming period, etc. We heavily encourage teams to post notes from their meetings covering what was discussed and any decisions or actions to come out of the meeting.
Zoom, and…
Ad-hoc calls are used when you need to get into a deep problem, discuss something in more detail or at a faster pace than is possible via Slack or P2, or if you need a higher-bandwidth back and forth (e.g. diagramming, design, whiteboard style). I mentioned Zoom already, and it’s the tool of choice for most calls/meetings. It’s also used a fair bit to supplement other real-time collaboration such as screen sharing and pair programming. We’re in the process of onboarding a few junior engineers and they’re spending a lot of time in “knowledge transfer” and pairing sessions with more senior folks (all over Zoom), learning, watching, asking questions, etc.
MURAL works quite well for a lot of post-it or diagramming type collaboration, and I love Whimsical for certain types of diagrams. I’ve heard good things about Miro, but haven’t personally used it. Our designers all love Figma. Opening a Zoom audio channel while collaborating on any of these tools adds an extra dimension to the interaction, and of course multiplayer mode is critical for anything to be useful in this area (e.g. they need to be good at real-time, multi-user interactions).
Async Communication
The hallmark of a good collaboration tool in my mind is that it can span across async and sync collaboration, while it probably leans more towards one or the other. I think Google Docs leans more towards async (write a bunch of stuff, then someone reads it all in one hit), but it’s also good for real-time collaboration as mentioned above. Notion is the new hotness in this space and a lot of people seem to love it, but I haven’t really used it much so can’t comment too heavily.
P2
P2 is the evolution of a WordPress theme we built within Automattic over a decade ago to help us communicate internally. We wanted something longer-form and more thoughtful than IRC, but more dynamic than monolithic-feeling blog posts. It uses WordPress (of course!), and provides a more real-time feel (live-updating posts/comments), formats things in a more conversational manner, and elevates comments to be closer to posts in importance. It leverages the full media (embedding, linking, etc) capabilities of WordPress, and allows you to use tags, @mentions, and a bunch of other tools that make collaboration easier. I use Google Docs extensively to draft things for P2 publication when I expect to have others collaborate/give feedback before publishing.
Similar to Slack, we have P2s for “everything”. Teams, projects, announcements, roles, watercooler topics, etc. I just checked and we’ve got 989 different P2s in various states of activity. We customize our P2s very heavily, mostly through CSS, so that each one has its own personality. Because it’s all WordPress, we can also change menus/navigation, add widgets to the sidebar, make posts stick to the front and other things.
P2 is what I would consider the central communication system for Automattic. It’s the longest lived, most consistent thread throughout the history of the company. We control (and host) it completely, have customized it heavily, and added things like the ability to search across all of them in one place, get notifications when any regular expression is matched within our network of sites, all sorts of custom syntax and embed formats, etc etc. As I mentioned it’s also based on WordPress, so it’s interoperable with all sorts of tools including most of what we build on WordPress.com (especially things like notifications), the WordPress mobile apps, and more.
GitHub
Most of our engineering work happens in GitHub these days, although we do still have some code bases in Subversion (and using Phabricator on top of that). We have hundreds of repos across multiple organizations that are a mix of public (open source) and private. We use project (kanban-style) boards a lot, and some teams also include tools like Zenhub or Asana as part of managing their projects. We’re generally pretty disciplined about writing good commit messages/issue descriptions, labeling things, etc. We treat most work as if it could be public, which changes the tone of interaction, and the expectations around documentation and workflows.
Archive Communication
Once they’re no longer active, our P2 interactions form a part of the greater Automattic corpus. They become part of the “archive”, although they’re never truly static. Everything has a permalink (including comments), and you can always go back and add more detail later. For the most part things move into a “read only” state after a few weeks.
P2s also usually have (WordPress-style) Pages (static pages, outside the normal chronological flow of a P2) that are used for P2-specific documentation, similar to a mini Field Guide (below). Teams use these for their own context-relevant documentation, some projects might have them on their own P2, etc.
Field Guide
One last thing worth mentioning would be our Field Guide. This is our employee handbook, but it also includes all sorts of evergreen documentation, processes, and reference material. It’s another WordPress site, and uses a theme that makes it work similar to a wiki (or Notion). Anyone can edit it, add to it, etc, and it’s referenced heavily when onboarding new folks, establishing new processes, and formalizing things.
That’s all I’ve got to share for now. There’s a ton of other interesting things to talk about in a distributed environment, but hopefully this gives you something to work with, some idea of how we operate at Automattic, and perhaps sparks some questions. Good luck out there, and let us know how it goes for you. This is going to be a huge learning experience for a lot of people, so I think it’s going to be valuable if people share what’s working and what’s not, especially in companies that are trying to rapidly move to a more remote model.
Constantly-changing priorities and surprise projects erode team morale and leave everyone unsure of if they’re working on the most important thing, or if they’ll ever get to finish anything. While being adaptable and flexible is critical for most teams, it’s always important to have some kind of roadmap and approach to prioritization and planning work. There are many different ways to plan and prioritize your work; what’s important is that when priorities change — and they will change — you acknowledge that change and adapt quickly.
If you don’t clearly acknowledge the change in plans, your team can start to question the point of the plan in the first place. They’ll start to wonder if they are expected to do this new thing and the old thing, or just the new thing, or since the new thing is not in the plan, perhaps they should actually ignore it? Don’t leave room for interpretation. Clearly set expectations and make sure you communicate unambiguously what is being asked of them. Sometimes they need to be given clear “permission” to really work on this new thing, and delay or drop the old thing.
On my teams, we use a process we call a “Priority Exception” to clearly address a major change in our plans. This process is used when we had a plan of work, and for some reason something not on that plan jumps to the next most important thing for us to work on. The goal is to acknowledge the change, clearly communicate the impact this change will have on existing work, and critically; highlight why it is so important that it should disrupt our plan. We use this template to ensure the right information is always included, and distribute the details to everyone on the team (and any other relevant stakeholders).
What new thing is happening?
Right up front, we outline the new work at a high level so that we all know what we’re talking about. We link out to our project management system or code tracker for further details. This section includes which individuals or teams will be required for the new work.
What existing thing is being delayed?
Next we’ll specify what work we’re putting on hold or slowing down because of this new work, or how we’re creating capacity to work on it. We’ll try to include details on the expected impact of our delay; If we can put a number on it, this is where it goes. Lost revenue? Delayed launch? Losing more users? Be specific.
Why is the new thing more important?
This helps head off questions about why we had to “drop everything” to work on something unexpected. This should clearly demonstrate why the new work is more important or more urgent than the planned work. You should be able to clearly illustrate why it offsets the impact of the delayed work (as detailed above).
How did this come about?
As a form of mini-retrospective, this is a chance to highlight why this work was such a surprise. It’s an opportunity to learn and avoid surprises in the future, or come up with other mitigation strategies, depending on what happened.
Timeline
We set a clear timeline covering any wind-down of current work, transition to the new work, and expected completion or progress milestones. Since Priority Exceptions often come with an external deadline, we’ll make sure that is clearly communicated as well.
Priority Exceptions are a useful, lightweight tool for communicating changes in priorities, and for learning how to reduce priority-thrash over time. Teams have appreciated the clarity they bring to otherwise-potentially-confusing times, and the clear permission they give to delay work in favor of something more important.
Before we get into any details, let me just get this out of the way — I absolutely love this thing, and giggle every time I get to use it. It makes no sense, I know, but here we are.
OK — now that you know how biased I am, let’s jump into some details.
I have the black and red, size Large. I’m 6’4″ and have bizarrely long arms, but the Norvan SL Hoody fits as well (if not better) than most standard long-sleeve items I get my hands on, and isn’t too baggy around the body. When I first pull it out of the pouch it might be a little short (because the fabric is all crumpled up), but then it smoothes out to full length pretty quickly. The semi-rigid hood rim and extended and reflective cuffs are really nice touches, and help make this jacket feel like more than just a super-expensive poncho.
When it’s tucked into the pouch, this jacket is so small and light that I end up taking it with me everywhere. I throw it in my work backpack in case it starts raining on me while I’m out. I take it to outdoor concerts in case there’s rain. I’ve taken it on a couple of work trips so that I could use it for a morning run in the cold and/or wet, or just to save space when I’m traveling carry-on-only. I throw it in my mountain biking backpack in case it rains while I’m riding. It’s great — it’s about the size of my fist, and just fits everywhere. I often just have it on a small carabiner and clip it to my belt loop if I don’t want to carry a bag.
On one work trip, I used it when running in 32 degree weather, over just a t-shirt. It cut enough of the wind and provided enough warmth for me to get 5k in without too much discomfort (my legs were a different story). On a ride, I was able to throw it on and avoid getting soaked during a surprise downpour. While I definitely heated up (and got more sweaty) wearing the jacket and riding in pretty warm weather, it remained impressively breathable and drawing the zipper down a little was enough to cool off a bit.
My only concerns with the Norvan Hoody are just how delicate it is, since I’ve read reviews about it losing its waterproof surface when used with a backpack (straps). I try not to wear a heavy backpack or move around too much if I have one on, to minimize damage. So far it’s looking good. I keep it in the pouch most of the time (vs hanging it up), and am hoping that’s not going to contribute to any fabric deterioration. I guess my one other wish would be pockets, but for something this waterproof, minimal and lightweight, we can’t have everything.
Since moving to Colorado, I’ve been lucky enough to get out mountain biking pretty frequently. I love it. On some rides you’re just trying to get up or down the mountain in one piece, but on some rides you get good time to think quite deeply. On a recent ride I was rolling around (pun intended, you’re welcome) some ideas about engineering management, and realized there are some good parallels between mountain biking and leading teams of engineers.
Look Out Ahead
When you’re riding single track, it’s really common to have your eyes glued to the trail right in front of your wheel. Big mistake. Not only does it mean that you’re going to be constantly reacting and trying to respond to things as they appear right in front of you, but it also means that you’re not going to have any advanced warning of big changes ahead. Like a tight turn. Or fast descent. Or a jump/drop-off.
Instead of staring right in front of your wheel, you should keep your eyes further out ahead. This gives you more time to react, some time to pick your line, and the ability to adjust your approach as needed by speeding up, slowing down, changing your stroke on the pedals, or even just bracing for impact 😉
With engineering teams, if you’re heads down responding to the things right in front of you, you’re going to be in that same reactive position, and things will constantly take you by surprise. Take some time to not only plan out ahead, but forecast and “game out” what the future might hold. Will you need to hire more people soon? Adjust team structure? Train your people up in some specific skill? Transfer knowledge between key people? If you’re not looking ahead, these things can catch you by surprise, and become a much bigger issue than they needed to be.
Build Momentum
When you’re on a really gnarly section of technical trail, it’s all too easy to slow right down and find yourself picking your way through rocks and bumping across things uncontrollably. As counter-intuitive as it sounds, it’s often better to speed up and keep moving than it is to slow down and try to delicately navigate every little obstacle. You can end up feeling like a bit of a steamroller, skimming over the top of everything, but you end up with a smoother ride, and it’s a whole lot more fun than bumping and grinding through every rock in your path. Instead of slowing down and being overly cautious, a common refrain is “let it roll”, meaning don’t brake, just roll through the obstacles using your momentum (and then quickly move on to the next one).
Something similar can be said for engineering teams, who benefit from building and maintaining momentum in their work. Get in the habit of shipping, and always protect that habit. Don’t slow right down and get stuck in the details. If you adopt an extremely slow and overly-cautious approach to shipping, then you can quickly find yourself in a state where you’re not shipping at all. Once shipping becomes a habit, that momentum is easier to maintain and build upon, to continue increasing your velocity.
Find Your Velocity
As a balancing point to the previous one, it’s also important to find the right velocity. On a mountain bike, if you go too slowly, you’ll have a rough ride, experience every bump and rock, and probably not enjoy yourself much. If you go too fast, well, there are plenty of YouTube videos to show you what happens. You need to find a pace where you’re making good progress, but you’re not completely out of control. It’s probably a little faster than you think it is, so you should push yourself and really find your limits.
If you’re moving too quickly as an engineering team, it probably means you’re shipping sloppy work, failing to validate ideas, accumulating a ton of technical debt, or just plain old rushing things. Find a sustainable pace where you can deliver quality work, without burning people out, and without shipping junk. That being said, moving too quickly is rarely a problem with engineering teams, so remember that speed matters, and always push to move as quickly, but sustainably, as possible.
I’m sure there are more parallels to be explored, but these were the only ones that came to me before I hit the more technical section of the trail, and had to really pay attention!
Yesterday I released new versions of both Keyring and the Keyring Social Importers packages, containing a bunch of updates and new additions. If you’re already using them, you should have update notices in wp-admin. If you’re not yet, then download them at the links above, or search for “keyring” in wp-admin under Plugins > Add New.
What’s changed? It’s been a while since the last official release of Keyring, so there’s a bunch to catch up on:
All Google services have been modified to use a shared base service (cuts down on code duplication significantly).
Lots of bugfixes, including token refreshing should now work properly.
The Social Importers haven’t seen an official release since 2017, so there’s a ton going on there as well:
Added a Strava importer (props @mdrovdhal) and introduced a bunch of improvements via iteration (props @marekhrabe). Having another service with map-based data makes me want to add some core to make it easier to map things visually.
Introduced a global option (for all importers) that allows you to set posts to published, draft, private, or pending when importing them. A lot of people were asking for/hacking this in, so I figured I’d just add it to the core package. Being able to import as draft and then selectively publish, or import an entire service to “private” posts is a nice addition.
Lots of improvements and bugfixes to both Twitter (some props @chrishardie) and Swarm/Foursquare.
Added a Pocket importer, again props @roccotripaldi. It works similarly to the Instapaper one, so if you’re using Pocket instead, check it out.
If you’d like to keep an eye on things more closely, or even contribute, check out Keyring, and the Keyring Social Importers on GitHub. It’s been really awesome to see some more contributions to both packages coming in, so I’d love to see more of that.
After drooling over it for months at Costco, I picked up a bundle package with a DJI Mavic Air back in November. I’ve now flown it a fair bit, and wanted to write up some observations on it.
First of all — this thing is amazing. It’s so much fun to fly, and honestly feels a bit like magic, especially when compared with cheaper, fully-manual quadcopters. Probably the coolest feature of this thing (for me, a n00b) is that if you let go of the control sticks, it’ll automatically just hover in place. Brilliant.
The bundle that I got came with propeller guards (2 sets actually, which turns out to be ridiculous — if you break those guards you’ll almost certainly manage to destroy the drone itself), so I started out flying with them on. It has object detection/avoidance in three directions (forward, backward, downward), so between that and the prop guards, it’s relatively safe. I still managed to crash it pretty hard a couple of times, and break some propellers. I got carried away and bought a bunch of replacements, but now haven’t needed any in a while.
I’ve purchased a second battery, and got a little carried away and purchased an Anbee Power Bank so that I can recharge batteries without access to an outlet (e.g. if I was out backpacking or mountain biking or something, and watched to capture more than 2 batteries worth of action; about 30 minutes). The batteries claim to be 21 minutes of flight time, but in my experience they’re pretty much always 14 or 15 minutes (stopping at about 20% battery remaining, for safety). I haven’t tried running them down to 0% to see how long they actually go, so maybe that’d get me to 21 mins before it fell out of the sky.
Beginner mode + propeller guards is a good way to get used to things. Once you graduate out of there, you’ll end up turning off/ignoring a bunch of warnings and things; these devices and their software really try to make sure you’re doing the “right thing”, safely. The app takes some getting used to (especially the special flight modes), but generally is pretty good and pretty intuitive. It always tells you everything that’s going on, and lets you tweak and configure things a fair bit.
I find that I have to calibrate the compass almost every time I go out to fly, which is kind of annoying, but pretty quick and simple. It reminds me of calibrating the compass on an iPhone, where you have to way the phone around. In this case you’ll be spinning yourself around in a few directions, and then you’re up and running. From deciding to fly, to having it in the air, it’s normally less than a couple of minutes.
The drone itself (and the controller) is amazingly portable/compact. When you pack it down into the small case that comes with it, it’s hard to believe that the whole thing is in there. I specifically love how compact the controller is. The control sticks detach and stow inside the controller itself, genius! With the controller compacted down, and the drone folded away inside its case, you can just slip them both in jacket pockets, or throw the whole kit in a backpack.
I’m definitely still figuring out how to get the most out of my drone, especially when it comes to video. I’m looking forward to spending some more time on that, and trying my hand at editing some short videos.
