how we work at egghead.io in 2018

egghead.io is a platform to empower humans, built to challenge the status quo of how we work and learn new skills.

We produce high quality, concise web development screencasts created by expert open-source contributors and other talented professionals. While we offer a lot of this content for free, there is a membership fee to access exclusive content.

As a business, egghead.io serves as accounting, marketing, and delivery platform for technically minded content creators. We enable creators to distribute short-format educational videos and various supplemental materials. We pay instructors monthly royalties that are a percentage of membership dues collected and the relative time spent by members viewing their lesson videos. To accomplish this, we build software with two primary goals:

• Create badass content with egghead instructors to help them focus on the creation of content so that they can earn royalties and not worry about the rest of the process.
• Deliver badass content to egghead members to improve their technical skills and stay up to date with the latest and greatest the web development world has to offer.

The two are related and overlap quite a bit, but are also very different business tasks with two distinct groups of customers.

We are confident that our best work has yet to come.

We know this because we are agile.

For us, agile means "incremental, iterative, and collaborative"– not Agile™ Certified Scrum Master. Our goal is to make sure everybody building egghead is well challenged and interested while growing value for our customers (members & instructors).

We believe that process evolves through discussion, experimentation, and lightweight documentation.

The idea of small improvements applied consistently over time is etched into the foundations of our business model. From the videos that we create to the software we deploy.

We work remotely. Official business hours are 9ish-5ish Pacific.

Written communication is vital for a remote business, which means both reading and writing. Everybody works whenever and wherever so we end up typing at one another quite a lot.

Tone, context, intent are essential when we write. We have to respect one another as humans, give people the benefit of the doubt, and also respect everybody’s finite amount of time and attention. We don’t have standing meetings or follow a strict process for checking in. We have a devoted channel in Slack that we regularly share what we are currently working on.

Slack is instant, but transient. Slack is a great tool for at the moment collaboration. It’s the water cooler, or often like knocking on somebody’s office door. Conversations in passing and the moment. It’s often a very real distraction. Almost a hindrance.

Email is often better when you need something. It’s asynchronous, and a well-titled email can be the start of valuable threaded conversations that persist and are easy to find later. Email is immutable, searchable, and functions well as an extension of our brains.

Code reviews on Github, documents in Dropbox Paper, and InVision comment conversations continue alongside the work that we are creating. Persistent, well maintained, living documents that describe the work that we are doing in detail.

The component is our fundamental “unit of work” that we focus on for both design and development. We are building complex structures out of modular components. The component first approach is heavily inspired by “Thinking in React.” Often this means we are working with related sets of components, which we often refer to as pages or screens.

We try to get our work into the hands of our users, both paying members and instructors, as early as possible. We intentionally avoid big releases with a lot of fanfare, instead of pushing early and often as close to continuously as possible.

We are not a feature factory.

We want to measure impact. We don’t mind “throwing away” work or admitting “failure.” We work using themes, and we aren’t obsessed with deadlines or estimates. In fact, we don’t use either timetables or forecasts as a development tool.

We tweak what is there, and try not to use the past as a significant constraint of the future. We take time to improve work that is “done” because it is never “done” and we can always get better. The mechanics of how we accomplish this will evolve to meet the needs of the team. The designer/developer workflow is always a challenge, and we will attempt to bridge that gap and keep agile principles at heart. That workflow might look something like this:

1. handful of current themes are identified and agreed upon
2. user stories are created to describe the functionality and impact of improvements based on those themes
3. Initial constraints and goals get established
4. Low fidelity wireframes are shaped to define structure and feature set
5. Development begins using the wireframes as reference
6. Higher fidelity comps get designed, generally using the essential established components
7. Components that aren't created yet get identified and receive design focus
8. Individual components are developed and deployed as soon as viable
9. We stop, take a breath, consider thoughtfully before returning to step 1 above

When work has commenced, we continue to discuss the design work. The design remains open to enhance and iterate as development exposes questions or edge cases.

During work, we identify major/primary components. Important “linchpin” components will receive attention and become part of the overall inventory of components assets.

Design begins with simple wire-frames that represent the structure of screens and components. These UX focused wires are presented and discussed before being implemented.

The wires make the process of designing components more focused on behavior, and less on visual aesthetic. We can quickly “make the designs go” to gain an understanding of how they feel to use.

The functional wires can them then be deployed to share, test, and discuss before high fidelity finished design work occurs.

The finished designs are implemented in code on top of the functional wires, adding consistent style and interactive flourish.

We want to experiment and play. Keeping it our work small reduces risk and allows us to try more things. Most of the time this works great, but sometimes we will admit when something isn’t working, learn our lessons, and move on.

Code review is a requirement for (most) code that deploys to production.

We embrace that the value of code review is sharing knowledge.

The code creator is the first person to review the code, adding comments that inform the rest of the team of the “what, how, and why” of the code they have written**.**

Reviewers ask questions so that they can understand the work. Code review is a form of critique, but the goal is to learn.

“Done for now” is perfectly fine.

Finishing is important. If things are going well, we will never be “done,” but we aren’t seeking perfection. It’s better to release our creations than it is to hold them back until they are utterly polished. Continuously publishing our work helps to ensure that we build the right things that match what people expect and need instead of guessing.

We are still putting out excellent work, but just that we understand that as a business we are here for the long haul and that working small gives us the ultimate flexibility to create something spectacular over time.

Like everything we do, this approach documented here is subject to change as the business changes. Opportunities appear and disappear all of the time, and we want to be open to exploration.