It’s been a little quiet on the blog recently, and the reason for that is either perfectly valid or profoundly unnecessary, depending on your viewpoint. Even I am not entirely sure which one it is.

Over the past couple of weekends (and too many late weeknights) I have used all my spare time to build a mini-site for my obsession with music. It started as a small idea to just show the current track I’m listening to, and a list of recent physical albums I added to my collection. But then it snowballed into something much more. You can view the site at music.elezea.com, or by clicking on the link in the top navigation. If you want to know a bit more about how it works, read on!

It all started when I came across Andy Bell’s mini-site for his music collection. He uses a Notion database and Last.fm to show all the music he has in his collection, and what he’s listening to. Since I also still use Last.fm (yes, it’s still around!), and all my physical music is documented on Discogs, I wanted to build a small site that uses the Last.fm and Discogs APIs to show some of that information.

But once I got started and got stuck into all the information available via those APIs, I just couldn’t stop. I still have so much more I want to do, but I know it’s time to take a break. All in all this has been such a fun and rewarding thing to spend my time on. I know the site has pretty much zero value to the world at large. But I love checking it to get more information about something I’m listening to—and it helped me take quite a few steps forward in my technical skills. So I’m choosing to call it a win.

Below are some notes about what the site does, how it works, and also what the experience was like for me (as a non-developer trying to learn).

Now playing

• Get the most recently played track from the Last.fm API, and check if the song is currently playing or not.
• If it’s currently playing, show the current time and a message that what you’re seeing is what I’m listening to in real-time.
• If it’s not currently playing, mention that and show the time it was played.
• Pull in the cover art and other data about the song from Last.fm.
• Do a lookup for the artist and if Last.fm has data about them, show the first two tags (genres), first 3 related artists, and their bio.
• Do another lookup to a different API endpoint for the artist’s top albums, and display data about their two most popular albums.
• Use the YouTube API to do a lookup for the song, and embed the most relevant result in the page so that you can listen to it right there.

Top albums and artists

• Show the top albums I listened to in the last 7 days, including play counts.
• Show the top artists I listened to in the last 7 days, including play counts.
• Make a separate API call for each artist to get their genres and similar artists, if that data exists on Last.fm.
• Make another API call to get each artist’s most popular albums.

Recent purchases

• Pull the last 6 releases I added to my Discogs collection.
• Also pull in data about the genre, label, and release date.
• ⏳ The Discogs API is really great, so I want to add a bunch more stuff here, but that’s also for the mythical v2 of this thing.

Random thoughts, complaints, and what’s next

• The site is deployed with Netlify via a Github repo, and it just works. Netlify is so great.
• I don’t care what you “real developers” say, the two biggest problems in programming are environmental variables and formatting dates. I am thankful for ChatGPT for helping me with the date formatting piece, and my colleague and friend Derek for helping to get the environmental variables to work.
• Last.fm’s API clearly hasn’t been touched in years and the documentation isn’t great, so it’s been a bit of a mission to figure all that out. Postman has been a life-saver here to test the API calls and see what data comes back.
• YouTube’s API has a limit of 100 search lookups per day, which feels ridiculously low. I hit that within an hour while I was building and testing it. Oops! On the upside: I am now much better at error handling. If the site hits that limit it will now show a message to that effect, and link to a direct search on YouTube for the song.
• ⏳ I’m using YouTube only because the Spotify API makes it incredibly difficult to get an auth token. Auth tokens expire after 1 hour, and refreshing that token every hour is currently beyond my limited skills. I might come back to this as well because the Spotify API has sooo much interesting data.
• ⏳ Another huge data source is the MusicBrainz API. I plan to spend some time wading through those docs as well to see what else I could add.
• If you can think of any other cool things I might want to add to this, please reach out on Mastodon!

At Postmark we’ve long been fans of the “Entrepreneurial Operating System” (EOS) as presented in the book Traction: Get a Grip on Your Business by Gino Wickman. We also love the “W Framework” as outlined in the article The Secret to a Great Planning Process—Lessons from Airbnb and Eventbrite by Lenny Rachitsky and Nels Gilbreth. Both resources are excellent and highly recommended for the thesis and theory behind each of these frameworks.

In this post I’d like to describe how we combined these methods to set goals and run our business and product delivery process. I’ll start with a short summary of each method, and then go into specifics on how we used them together to ensure our teams are aligned on the same goals and have all the context they need to work autonomously on projects.

I promise I’m not here to start an argument about what is the best way to set goals. Instead, I hope this could be useful to folks who have tried a bunch of different frameworks—including OKRs—and found that nothing quite worked for them. Maybe this is a good alternative to try…

Goal-setting using EOS

We tried a several different goal-setting frameworks before landing on the Entrepreneurial Operating System (“EOS” from here on out). There’s no way to cover all it entails here, so please read the book, it’s very good. What I want to focus on specifically here is one of the primary outputs/artifacts of the system. EOS calls it the Vision/Traction Organizer (V/TO), but we adapted it into what we ended up calling the Vision and Focus Plan. This is sort of the equivalent of an OKR document, but we found the additional context extremely useful, especially when we layered W Planning (which I’ll talk about next) on top of it.

In its simplest form the document has two sections, one section for Vision, and one for Focus. The basic structure of the Vision section, using an example from our 2020 planning session for the Wildbit brand as a whole, is as follows:

Every year our leadership team got together for a few days to work on any edits we needed to make to the Vision section. Principles, Values, and Purpose should not change a lot. These are the long-term guiding principles for the company and though they should be revisited at least once a year, frequent changes would indicate that we don’t really know where we want to go with the business, so that should be a red flag.

The 10-year picture is a level down from the purpose—a way to look into the future of what the business would look like in reality if we achieved all our goals. The 3-year picture is way more concrete, and where we spend a good amount of time modeling and debating based on what we know about our business and the industry at large. These are the revenue goals that we want to achieve in the shorter term.

The Focus part of the document changes the most, and this part is the most directly comparable to OKRs. We generally made one of these for each product line (and sometimes even for individual teams). Here’s an abridged example from Postmark that we worked on during 2021 planning:

The sections can be summarized as follows:

• 1-year plan. Think of this as the “Objectives” in the OKR framework. In tandem with the Vision this is where we want to be at the end of the year from a business perspective.
• Quarterly plan. Similar to the 1-year plan, but a more immediate timeframe to reflect our planning cadence (this could also be 6 months, 6 weeks, whatever cadence you use for planning).
• Goals for the Year. This is similar to the “Key Results” part of OKRs. They are measurable metrics and indicators that will tell us whether or not we’re on track to meet our 1-year plan. It helps for this section to cover a longer time horizon so that you can prioritize projects and bets effectively, and avoid sudden changes in priorities (which are really disruptive to teams).
• Tasks for the Quarter. This is the nitty-gritty prioritization of problems we want to solve in a given planning timeframe to achieve our goals for the year. The visual planning and delivery/execution of these tasks happen in Productboard and JIRA, but this single view keeps us honest about what we’re working on. (See the next section for how we populate this column)
• Issues List. This is a core component of the EOS system, and is an ongoing list of concerns, things we’re worried about, obstacles or impediments that we have to address, etc.

An essential component of making this approach a success is that we review the Vision & Focus Plan every week in our leadership meetings. We review business metrics, we talk about our progress, where we might be off track, what needs to change, what issues we need to add, how we are doing in addressing the issues, etc. That way we have a weekly check-in where we can adjust our plans and solve problems together1.

One really important part that I skimmed over in this section is describing how things make it onto the “Tasks for the Quarter” list. That’s where W planning comes in…

Planning using the W Framework

As I mentioned earlier, the original article does an excellent job of explaining the W Framework, and it should definitely be on your reading list. But in the interest of time I wanted to provide a short summary of how it works here. The gist is that planning is most effective when it is a collaborative effort between Leadership (senior/executive leaders of a business unit) and Teams (people executing the actual work). This makes it a particularly appropriate framework for empowered and autonomous teams. The framework looks like this:

The four stages are described as follows in the article:

Context: Leadership shares a high-level strategy with Teams.

Plans: Teams respond with proposed plans.

Integration: Leadership integrates into a single plan, and shares with Teams.

Buy-in: Teams make final tweaks, confirm buy-in, and get rolling.

So when we go into our quarterly planning we use our Vision & Focus Plan along with W planning to come up with our tasks for the quarter.

Phase 1: Context

As a leadership team we review our annual and quarterly goals as laid out in the Vision & Focus Plan, and make sure we are still focused on the right things. We ensure that the entire team has the strategic context they need to successfully enter the planning phase.

Phase 2: Plans

Teams take the goals and strategic context, and create project plans as bets on how they would like to achieve those goals. Note that at this point the “Tasks for the Quarter” column in the Focus plan isn’t filled out yet—that comes from the teams based on how they believe we can achieve our stated goals. In the words of Father Cagan:

Instead of being given a roadmap of features, an empowered team is given a problem to solve and they get to figure out the best way to solve that problem.

We use our Project Plan template for this part, which you can see on Github. The plan does not have to have every detail figured out. We view it as “a road sign into the fog.” We make sure the direction and first few steps are known, then add and edit as the fog starts clearing down the road.

We then share the plan with everyone in the DACI section of the plan by posting a link in Basecamp and requesting feedback form the team. We discuss comments asynchronously in Google Docs, or synchronously on a Zoom call if a decision can’t be made quickly in the comments.

Phase 3: Integration

Once the team planning phase is done the leads team gets together again to discuss the plans, how it all fits together, and any trade-offs that need to be made. This is where we fill out the “Task for the Quarter” section and make sure we are not taking on too much work for the quarter.

Phase 4: Buy-in

As a team we then get together to finalize the project plans, discuss any final questions/feedback on our priorities, and move individual tasks to Basecamp/Asana (for non-dev projects) or the appropriate JIRA Epics (for dev projects).

Once we finish this process our teams are ready to execute on their projects with clarity on how each project aims to influence our goals. This includes essential engineering scaling and reliability work—for instance, if our goal is to significantly increase the number of messages sent, we’re going to have to make sure that the platform can scale with that!

---

So there you have it—a way to combine two different frameworks to create a seamless goal-setting and prioritization process for empowered teams. Admittedly, I left out quite a few details in this post—there are lots more to discuss in this process, such as how we track progress, how we adjust based on new information, how we aim for “healthy pressure” within teams using high-integrity commitments, and so much more. But I am hoping that this brief overview sparks some ideas for teams who might have been struggling to make other frameworks work in the context of their own teams and culture.

Like all things related to software, planning and goal-setting require discovery and experimentation to get right. Even this article should be viewed as a snapshot—capturing a moment in time that describes our planning process. But we are also still constantly evolving the process as we get feedback from our teams and learn what works and what doesn’t. So try this one out, and let me know how it goes if you do!

---

1. I plan to write more about the structure of our weekly meetings in a future post. ↩