&yet

If you haven’t heard yet, we’ve recently started publicly offering a new assessment based on feedback from our clients and readers.

As I mentioned in our newsletter on looking for that first tiny sign:

It’s funny that the service we’ve actually been selling isn’t even one we have on our website… The reason this is so funny to me is that the process of selling a new offering always seems to happen this way. We launch with something we think is going to be the right solution, but when we get to talking to folks, the needs are different and we adjust. We learn way faster than we can implement. Sometimes it takes a while for the website to catch up.

Well, our website has caught up, though we’ve already been using a new approach to help our clients get clear on objectives, key results, and priorities that I’m noticing needs to be added. (Which I wrote about in last week’s newsletter on goal-setting and stewardship. Seriously, you should probably just subscribe to our newsletter to know what’s actually going on lol.)

I was a guest speaker for a program that a friend was facilitating last week, and she asked me what motivated me to write the first version of Gather the People (what was it, 5 years ago now?). I started telling the story of getting laid off from &yet and having 60 days until the money ran out, and suddenly it hit me how surreal it is to be CEO of the company I was previously laid off from. Sure, it had occurred to me, but it hadn’t really sunk in until talking about it with someone who was looking at it from the outside.

From the inside, it makes sense. Before &yet, I was founder and CEO of a strategic web firm for over a decade. During my tenure at &yet, we’ve needed a more predictable sustainable pipeline, but it has been so hard to shift a team skilled in solving a variety of hard problems into one committed to solving a more specific one. We’ve tried a few different directions over the years, sometimes giving in to being extremely veteran generalists, other times testing the waters in a specific direction. But it felt impossible to find the one thing that was a common denominator for the whole team.

Last fall, we started doing this magical thing called “annual planning.” (I’m being intentionally facetious because we’ve historically avoided anything that faintly smells of hierarchical management, though good folks like Sally Mohr and Mark Brault have pushed for planning more intentionally in the past.)

Anyway, through that process, we were able to see just how many competing priorities we had as an organization, and that we needed to stop testing the waters and actually commit to one specific direction. We took stock of our resources, including our past wins, our strengths as a team and as individuals, the problems we cared about and were interested in solving, and most especially how we could best help our clients grow and get to where they want to go. We worked with a consultant to add some objectivity to the mix and ultimately decided to focus on building strong customer relationships through creative technology.

We’re making a change in our organization and roles that I’m really excited about.

&yet is spinning off Talky, inc. as its own company, with Talky and SimpleWebRTC as its products.

Ben Zemel will become CEO of Talky, inc. Lance Stout and Heather Young both have put considerable technical effort into building, maintaining and supporting SimpleWebRTC and they will join Ben as technical cofounders of the new company, with Lance as founding CTO. It has a been a privilege to work with all three of them as well as the many current and past contributors to getting SimpleWebRTC to this point, including Henrik Joreteg, Philip Roberts, Jon Hjelle, Amy Lynn Taylor, Diana Perkins, Lynn Fisher, Terry Carter, Elliott McNary, Luke Karrys, Dylan Staley, Jenna Tormanen, Jaime Robles, Audi Long, Kate Farrar, Nathan Fritz, Gar, Marcus Stong, NLF, Karolina Szczur, Sally Mohr, Chris Koehncke, Bear, Adam Baldwin, Jenn Turner, Isaac Lewis, Aaron McCall, Peter Saint-Andre, Xander Dumaine, and Philipp “Fippo” Hancke. It has taken a village, to put it lightly. Exceptional people, one and all.

I’m really excited for the coming year in watching the continuation of the growth that the SimpleWebRTC team and product have experienced since launching paid signups earlier this year.

I don’t think I need to convince anyone that having another person review your work is a good thing. It’s probably already built into your teams and processes. Programmers pair up and build a feature together, bouncing ideas off one another. Code reviews are required before new work can be merged into our apps. Design teams hold critiques where the work is examined and people provide feedback.

In most of these cases, the people reviewing the work are our teammates or clients. Let’s say they’re “People who get you.”

We’ve previously talked about corporate swag being broken. “Thanks for this bag of trash” is an absolutely fair response at a lot of conferences. You might be familiar with this sight: tables of tote bags filled with brochures and trinkets no one really wants.

A better option is spending a bit more for actually useful objects. The problem here though is even useful objects can create clutter. How many bottle openers, battery packs, and steel water bottles can one person really use? T-shirts can be useful, but not if they don’t fit properly and there definitely is such a thing as too many shirts.

We do understand it though. Conferences are a chance to get your company in front of people. It’s low-risk marketing, can help with brand recognition, and is a major recruiting opportunity. But dollar for dollar, how effective is it really? Do we even know? Unfortunately, swag can sometimes cause a negative effect for your product (especially if it’s just more of the same stuff along with twenty other companies’ swag).

We recently released face.camp, a Progressive Web App (PWA) that allows you to take animated gifs of your face and share them with your fave Slack channel. We’ve also open sourced the code on GitHub.

It was the first project I worked on when I (also) came back from a three-month sabbatical. I had previously burned out on coding and I found myself for the first time getting excited about having the freedom to go down rabbit holes to solve even the smallest of problems. Most of these problems weren’t even practical to solve, but I had a good time solving them.

Preact

Knowing that the site was going to be a PWA, I wanted to keep the frameworks used as small as possible and take advantage of any tooling that would allow me to do that. preact and preact-cli seemed like a perfect fit.

Hey friends with faces! We just launched a little app called Facecamp over at face.camp. With Facecamp you can share short, animated gifs of your face within your fave Slack channel.

There’s not much to it. You sign in with Slack, capture a gif of your mug, add a message, and share directly into your org’s Slack. You can share to public or private channels and direct messages (if you choose to). You can sign into multiple Slack orgs too and swap between them (I know you have a bunch you belong to).

How to be unopinionated about process, but still keep things on track.

Lately I’ve settled into a role where I act as project manager on a regular basis. This role kind of evolved organically, and I didn’t come into it with a formal project management background, but rather a design background. To me, project management just feels like another creative problem to solve.

At &yet we tend to work on projects that are outside of the box, both creatively and technically. Whether this be internal projects or consulting work, each project has different goals, unique contributors, scope, constraints - you name it. Because of this, there’s really no one-size-fits-all project management process that works for every project. I tend to reinvent the wheel (er, ‘process’) with every project. Sure, there are some basic approaches that I’ve noticed work really well, but I still see every project as an opportunity to evolve and iterate on project management as a practice.

Let’s talk about project retrospectives! Project retrospectives (sometimes called post-mortems) are pretty loosely defined as a meeting held after the completion of a project during which you discuss your achievements and what the team can do to make improvements in the future. ‘Project’ could mean a contained project that is completely wrapping up, or it could be a phase or major milestone within a larger project.

Sounds pretty great, right? BUT…Is it possible to love figuring out how to improve as an individual and team, but still not love doing retrospectives? That might be me (and maybe secretly everyone).

Though retrospectives may seem simple in concept, they can also bring with them a few challenges to navigate.

Over the past several years, static sites have had a bit of a rebirth. Heralding back to the days of FTPing plain HTML and CSS files to a webserver, static site generators like Jekyll along with static hosts like GitHub Pages and Netlify have brought the power of plain HTML, CSS, and JavaScript to a newer generation of web developers. One particular area that static sites have excelled at is for generating blogs, like this one! In lieu of complicated setups like WordPress that required setting up a PHP environment along with a database, static-site blogs are meant to be simple to get up and running and simple to maintain. Being a forward-thinking group of folks, &yet has used a static-site for our blog for quite a while now. However, getting it up and running wasn’t exactly as easy as the “Getting Started with Static Sites” tutorials would have lead you to believe. At one point the initial setup was so complicated, and so unreliable for our developers, that we encapsulated the entire application inside a Dockerfile to make development easier. And I don’t know about you, but I don’t think a static-site generator should be so complicated as to require Docker to get up and running.

How’d you manage that?

Our previous site was built using a Python static-site generator. It was incredibly well-featured, and allowed us to do virtually everything we wanted to do. However, that power came at a cost. The code only ran on Python 2, so when macOS updated the system Python from 2 to 3, the Makefile that built the site suddenly stopped working for those working on the site (that was assuming you’d managed to properly install the dependencies the site required in the first place!). While these hurdles are easy to solve for lightly-seasoned Python developers, they were difficult roadblocks for our JavaScript-focused developers (which is the vast majority of our team). Adding Docker support was a bit of an improvement, but it was still asking a lot of our team, especially for something that was supposed to be simple and straightforward!

So how did you fix it?