I've hit a bit of writer's block on this blog recently. Or more honestly, I hit a bit of fear. I have some drafts of posts, some ideas I've noodled on. But recently I hesitate to post them because of one firmly held belief/instinct I have: do not argue with strangers on the internet. I love to exchange ideas. I love to say "hey this has worked for me, you should try it". What I loathe is prescriptive posts of you need to X this way or you're doing it wrong. As a result I've been reluctant to share my experiences and things I've learned. I've been afraid to be shouted down with "No! You're wrong! You don't know what you're talking about." The hilarity of that notion is two fold - (1) nobody reads this site anyway and (2) that's not really possible because I'm sharing what's worked for me - maybe it will work for you, maybe it won't. Your mileage may vary.

So let this post be a primer for all my past and future postings on the internet. This one line holds true in all cases I can currently conceive of: All advice is terrible unless it works for you.

A quick story about running. Broadly speaking if you want to become a better runner the best way to do that is to run more. If you run 2 days a week you will improve if you run 3 days a week. If you run 3 and bump it to 4 you'll get better and so on. Broadly speaking this is sound advice. To the question "how do I become a better runner" the answer "run more" is sound advice. You could go from couch potato to marathon athlete following this advice. If you currently run 20 miles per week and bump it to 50 next - you will quite likely get injured. There is some small percent of the population who can tolerate a dramatic increase like this. They will likely see massive gains in fitness. All advice is terrible unless it works for you. The key of course is not in the advice - it's in the nuance, the subtlety. How can I take the advice "run more" and make it work for me and my goals?

All of my writings should be considered strong opinions weakly held, a concept I first learned about from Jeff Atwood of Stack Overflow fame. In short - this is my opinion on this topic right now based on my current understandings and experience. I'd love to hear about different views or experiences and might change my opinion based on future learnings. I might write or speak passionately about a subject. But please don't mistake that passion for rigid authority. Every piece of advice should be taken in the same vein as "run more". There is always subtlety and nuance. There are few/no one size fits all answers to anything.

With all this said, I will try to unblock my writers block backlog and publish some more things soon. Until then remember - my advice is terrible, just like everyone else's. That is unless, of course, it works for you.

If you work for a company of any reasonable size the following scenario probably sounds familiar: You're in a conference room. There's 3, 4 maybe 5 or more of your colleagues gathered. There's a polycom device in the middle of the table. On the other end of that polycom is a remote teammate or 2 or maybe it's another team of people at a partner company or customers you're trying to demo to.

There's an echo'd conversation that goes back and forth. People are often asked to repeat themselves. Every once in a while someone new connects to the call or disconnects causing a disruption. There are side conversations going on. Nobody knows how to mute that polycom and half the time it's a challenge to even dial a number or conference in a 3rd party.

Is there anyone who thinks this is the ideal experience? In 2019 we can mine for fake currency in the cloud but somehow are incapable of executing the elusive three way phone call in some kind of reasonable manner? I think often times when people don't think remote teams can work this is why. This is their experience interacting with people outside of their office and it's awful.

At Litmus we're a remote first company. These kinds of conferences calls just don't exist for us. Here are some tips to fix your "conference" calls calls by using remote work best practices.

1. Go back to your desks!

If anyone on a call is not physically in the same location as you - go back to your desks. Let every person dial into the call separability. Speaker phones are terrible - they have echo and you can never tell who's talking. Also the people in the conference room are having one experience - an in person conversation - and the person/people on the other side of the phone are having a different, degraded experience.

Level the playing field. Go back to your desks! If you want/need to have a side bar conversation you can do that via chat (Slack, Hipchat, etc). Litmus founder Paul Farnell recognized this difference early on - "Unless every person is in the same room, all meetings are held over video conference. This is absolutely essential and was a game-changer for us."

2. Turn your video on.

If there is an option to turn on video - do it - every single time. A face to face conversation is 100x more effective then a phone call. You can always tell exactly who is talking. Research indicates video calls can take half as long, improve understanding and increase alignment.

3. Record it for the record.

If you're using Zoom, Bluejeans or any video conference tool that supports recording - mash that record button. Maybe there's a team member who can't make this call. Maybe right after you wrap you forgot the date your agreed upon. Having a recording allows all parties to stay engaged in the conversation without worrying about taking notes. It's even better if there is a demo or some other presentation involved. Now you can share that with others across the org and not just pass along a slide deck that lacks the full context.

Now what if you want to do this but the people your conferencing with won't play along? My advice is to model the behavior you want to see in the world. Countless times I'll hop on a call with my video turned on and the person on the other end is surprised and also turns on their video. And the call goes great! You can't force people outside your organization into this behavior - or possible people inside your organization for that matter. What you can do is show them a glimpse of how much better it can be and encourage them to adopt these patterns.

When you work at a remote first, remote friendly or fully remote company you forget sometimes how the other half or rather 90% of folks work. There are certain practices that we take for granted as remote friendly workers. Even in office workers can gain from these practices around conferences calls to make them more productive and better all around experiences.

Have you seen those commercials for Fank's Red Hot Sauce? In case you haven't the gist is that this old woman makes awesome food. Her secret? She puts Frank's Red Hot Sauce on everything. Or as she would say "I put that sh*t on everything". In engineering we often use the hammer and nail analogy. When you have a hammer, everything looks like a nail. This is meant as an anti-pattern. You shouldn't use the same solution to all problems. Maybe she shouldn't put Frank's Red Hot Sauce on everything? I don't know. I'm not sure that analogy applies here cause Frank's is pretty damn good. Is there an equivalent in engineering? Is there a hot sauce we should be putting on everything?

Writing software can be incredibly complex and difficult. Wrapping your head around a business problem and translating it into usable, testable, readable code is an absolute achievement.

Increasingly - being technically competent - being able to execute a product vision technically - is no longer enough. The best engineers I've worked with do more than that. They communicate.

Communication is key to any team environment. These days engineers are expected to engage via Slack, JIRA, GitHub, Basecamp, Trello, Asana, Google Docs, StackOverflow, and more. Oh, and also email and Twitter and LinkedIn and...and...and. What's the common algorithm to solving problems on these platforms? What's the common API? Writing.

Writing is harder. In code there is x==y. In writing there is nuance. There is opinion. It's a non-deterministic, fungible medium. It's exactly the kind of thing engineers historically avoid. But ultimately, writing is just a more verbose, round about way, of coding. You're translating ideas into language to solve a problem.

In an ideal world you might have a product manager who will write a user story. "As a user when I Click X, I expect Y to happen". That product manager will then take that story and create tasks for engineering, qa, product marketing, customer support and sales to make sure the task is (a) completed as intended and (b) all relevant stake holders are notified and documentation is updated. In my experience this can happen but this is the exception, not the rule. More often the product manager doesn't have enough context to interface with all of those groups. They don't understand all the implications of the changes being made.

In the truest sense, the engineer's role is to solve problems not just write code. The best engineers I encounter are the ones who can take that user story and of course solve it in code. But then they work with qa, product, support, marketing, sales. The way they do this is writing. It's writing a readme, a wiki article, updating a JIRA or GitHub issue or even something as simple as an email to the stake holders. They can communicate the intent and the output in plain, non-technical language.

When I see an engineer start with a user story and close the loop with stake holders - that, to me, is product-engineering nirvana. That engineer knows the business case so clearly they can communicate it directly to the relevant people across the organization. The product managers trusts engineering so implicitly they don't need to micromanage the process.

If you're an engineer looking to move up in your career, my advice is to write. It can be as simple as writing well rounded documentation to the work you're doing. The best tip - do it in advance. Write the doc, then write the code. If the code doesn't match or vice-versa then maybe you didn't understand the problem correctly.

Here's the thing. Today it feels like JavaScript is the hot sauce. Years ago it was SQL. Tomorrow it might be Rust or Elm or AI powered blockchain drones. Being able to communicate clearly, being able to write, will always be the hot sauce. Being able to communicate your ideas and your actions will always have value, no matter your role.

Writing is the easiest, most powerful way to make yourself more visible and more valuable in your role as a technical contributor. You can put that sh*t on everything.

Humans don't come with instruction manuals. I remember when my son was born. The hospital gives you some rudimentary demonstration on how to feed and change the baby. They make sure you have a reasonable car seat. And off you go - on your own - with a new born. Good luck! We did a lot of work preparing for this child. We read books. We talked to friends and family who were raising children. We even took a class. But in that moment I couldn't have felt less prepared or less qualified for the task at hand.

Let's pivot to career talk. Imagine you start a new job. You've done your homework. You met your new boss during the interview process. You probably spent - what, a few hours with them at best? You read the glass door reviews and chatted with people who work there. You show up bright and early on day one. You get your shiny new laptop, maybe an American Apparel tee. Now what? You feel incredibly unprepared and unqualified for the task at hand.

This is where - if you're lucky - a first class on boarding plan comes in. This is a combination of efforts between your manager and HR to get you up and running as seamlessly as possible.

As a manager, I've be thinking a lot about my role in this process. How can I ease that transition. Wouldn't it be great if there was some kind of manual. Here's how you can work best with me. Here's what I expect of you and what you should expect of me. Hat tip to my colleague Eddie for introducing me to the concept of the Manager ReadMe.

The origin of the ReadMe file in software goes back to at least the late 1970's. The ReadMe is that brief one page synopsis that serves as the intro/guide/documentation to a piece of software. The rise of git and Github have elevated the ReadMe to an even higher status. When you create a new empty repo in Github it doesn't give you an empty repo. It gives you one file - the ReadMe.md. Surely you didn't really want an empty repository. Surely you will need a ReadMe.

By default humans don't come with instruction manuals. As a manager you could help your new and existing team members by writing yours. The Manager ReadMe is that quick intro or guide to a key person you'll be working with - your manager. For the employee it can break the ice, ease nerves and level set expectations. For the manager it's a great introspective exercise. How do you work best? What do you expect from your team? What should they expect from you? Tell them to hold you accountable to these expectations.

Beyond this if you make your ReadMe public it can serve as an excellent recruiting tool. Read about me, what I'm like, what I expect - does this sound like someone you'd like to work with?

If you're a manager I'd encourage you to create your own ReadMe. You don't need to use a SAAS app - you can just do it in a Google Doc or really whatever format works for you and your team. As I wrote in my ReadMe - "Writing software can be really really difficult. Let's not compound that complexity with uncertain expectations and the uneasiness that can arise from working with new people."

What is your why?

More and more you hear companies talk about alignment. I think the most overused paradigm floating these days is finding your "north star".

Broadly speaking it makes sense. At Litmus we talk about our unofficial mission to "make email better". We want everyone to think about that as they work on product or talk with customers.

When I saw this quote by 2018 Boston Marathon champion Des Linden - it reminded me of this. What is your company's why? What is your team's why? When things get hard will people bail or will they rally around this why?

What if my why isn't your why?

At Litmus we've had great success with a core group that is passionate about email and the email industry. We surround that group with others who love solving hard problems and creating a first class user experience.

Which I guess brings me to a question I've had recently. Does everyone in the company need to rally around some kind of common mission?

For example, you could be a killer accountant. You could be really passionate about accounting, GAAP and balance sheets, etc. And any company would be lucky to have you. But you don't care about software or widgets or whatever the company's mission is. Is that ok? What if that person were an engineer or a product manager? What if they were a Director or VP or C level employee? Is there a level at which you need that passion for your company's mission?

Are missions just marketing?

You could argue that the mission statement is more for external audiences than internal ones. It's a way of broadcasting the core intent of your business. And it may attract some employees who are passionate about that specific space. And you do really need a core group of those people.

In the for profit, at will employment, world of software I suspect that even your most passionate employees would stop coming to work if you stopped paying them. Even if they felt strongly about the mission.

More than just a mission

In the competitive marketplace for both employees and customers you need to have more than just a "mission". At Litmus we talk about our values and printed up these beautful cards to share them.

Front:

Back:

What's missing? There's no talk about email or our products. There's no corporate goals or strategy. Ultimately, for our team, this is our why. Caring, being considerate, acting humbly and with confidence, collaborating and being active in the world beyond just our company. If we can all align on these - the corporate mission statement, the "north star" - becomes just another part of the story. No matter what your role is - tech support or ceo - you can align on these values. With every action you take you can look at these and say "does this align with how we want to work?".

Products will change. The market will change. Today we might be focused on a specific customer persona and next quarter, next year, that could change. Values like these persist. When things get tough as they inevitably will - alignment on values will become more important than alignment on a specific mission.

I really identify with the mantra "move fast and break things". Everything in moderation of course - like don't move so fast that you break all the things. But as an engineer, I've had my greatest success by bringning things to the business/management and effectively saying: hey, I built all this cool stuff - do you think you can sell it?

Early in my career I was learning the ropes as a DBA at a financial company. I was working on a new data load that would create new Accounts in our database. To simplify things and protect the innocent this is how it went down: I was loading the data into an Accounts_Temp table and working in a staging connection string. I was writing some raw MS SQL to Truncate Accounts_Temp and do a BULK INSERT. Of course if you happened to forget that _Temp part and inadvertenty ran that against the wrong connection string...you just truncated the primary accounts table of a major financial company.

So yeah - a lot of things went wrong. I shouldn't have had truncate access to prod. I should have realized I was on prod. Lots of things should have been different. This isn't about all the things that went wrong. This is about all the things that went right that day.

It takes a few seconds. Then the realization creeps in. "That wasn't production...was it?" Followed quickly by, "I can fix this. I can fix this. I can fix this." You most certainly cannot fix this. At least not on your own.

In that moment you have choices. I paused, pannicked, and ran right into my boss' office. "I just dropped the accounts table, what should we do?!?". In the following 2 hours I learned more about being a DBA than in the previous 6 months. We did a partial, live restore of a single table with minimal data loss. It. Was. Awesome.

The things I learned that day:

Make tragic mistakes hard to do. Don't let people make drastic mistakes easily. Things like truncating data or deploying to master should have checkpoints along the way.

When you make a big mistake tell someone right away! Imagine if I hadn't. The team might have spent hours - or longer - trying to figure out what happened. Is there a software bug? Were we hacked?

Let people make mistakes. If I was afraid of getting fired or berated for my mistake - I might have acted differently. Because I knew my boss was supportive of me, I knew I could come to him. I could tell him what I did wrong. I didn't fear being mocked or belittled or fired due to this one mistake.

As I've progressed in my career I've found the first one is pretty easy. It's a computer problem - we have gotten pretty good at solving those. The tricky part is the balance. How can you protect your team from mistakes but still give them freedom to move quickly?

The second two are people problems. Those are more complicated.

Make sure your team knows they won't be dragged across the coals for their mistakes. When something does go wrong - focus on the problem - what happened, how can we solve it. Don't focus on who did it. Today it might be Developer A but tomorrow it could easily be Developer B. What are the processes and procedures that allowed the mistake to happen.

Any conversations about negative performance should be in private. Never call people out in front of their peers.

I try to emphasize to my team - I'm looking at the long view, not the short view. You're not getting fired for having a bad day. We all have bad days. What's your month look like, your quarter - I bet you've contributed significantly.

As a mistake maker - have some confidence along with your humility. Yes I made this mistake. But I had the right intentions. I was trying to do the right thing. I want to fix this. I want to get better. How can we all learn from this? Write up a retrospective. Reccommend policy changes to prevent this from happening again.

We've all made mistakes. Let's create an environment where the really bad mistakes are hard to do and mistakes are both forgivable and recoverable.

]]>We just wrapped our first ever engineering all hands at Litmus. It was an amazing opportunity for our mostly remote team to get together in person, reconnect and scratch some of our creative itches.

One of the important parts of the retreat was a series of lightening talks we did.

We just wrapped our first ever engineering all hands at Litmus. It was an amazing opportunity for our mostly remote team to get together in person, reconnect and scratch some of our creative itches.

One of the important parts of the retreat was a series of lightening talks we did. The premise was simple: 5 minutes on any topic you want to present on.

My talk was titled MALTT: Measure All The Things.

The inspiration

If you were a Litmus customer in 2014 or prior you probably recall the experience was, in a word, delayed. To get a full compliment of results could take upwards of 5 minutes.

There were a lot of reasons for that. Some were super obvious like a delayed queuing system we had in place to ease pressure on the system during high usage periods. But even after ripping things like that out we couldn't get times on our servers anywhere near what they were locally.

So we started measuring.

Since then, you might say we've gone a little overboard. We measure everything - even apparently something that takes 0 milliseconds. I should probably look into that ¯_(ツ)_/¯.

The idea is simple - how can you improve what you can't measure. How can you know where the bottlenecks are? In the business and software worlds this is pretty tried and true. As Peter Drucker said - "You can't manage what you can't measure".

We measured and measured and measured again. Now a full compliment of Litmus results returns in just a few seconds.

What does this have to do with sleep?

I don't generally believe in things like New Year's resolutions. January 1 seems to be an awfully arbitrary time to make an improvement. But generally speaking I've been working on 2 personal goals recently: to get more sleep and to improve my overall fitness.

Having the experience of dramatically improving a software system through measurement and instrumentation I did a deep dive into how I could apply the same process to my personal goals.

Making the investment and getting the data

Being a pretty committed runner (2018 will be my 7th straight year completing at least 1 marathon), I was pretty familiar with most of the fitness technology that was out there. And if you love data like I do, there are a lot of choices.

After getting a reccomendation from a friend and doing some research on my own I invested in a Whoop. It's definitely not the low cost provider. But as a more serious athlete, for me, it felt worth it.

Now using my Whoop I track my sleep, recovery, heart rate and heart rate variability daily. By knowing these figures I can stay on track with my sleep and see how my excercise and other life choices affect my overall fitness.

Call to action

What are you looking to improve? It can be anything. Do you want to read more? Learn the piano? Approach it like you would a business or engineering problem. Find a key metric. Find a way to reliably measure it - even a paper journal can work. Get your baseline and get to work.

Really this post could have dozens of titles - Jira is not your problem, Trello is not your problem or even meetings are not your problem. For now - let's focus on Slack.

Say what? Who thinks Slack is a problem?

Since Basecamp (née 37 Signals) launched Campfire back in 2006 and probably before that even - teams, especially software teams, have been using group chat to collaborate. Slack is the latest and most successful itiration on this idea.

But there's a growing concern that maybe we've jumped to quickly into the deep end of group chat. Even Jason Fried has weighed in that perhaps group chat is problematic (Is group chat making you sweat?).

And I would agree with many of these points - I mean I do agree with some of them. If only the solution weren't so simple:

So what is the problem?

The problem at it's core is organizations and management teams that don't set their teams up for success. There's enough missives out there about why thought workers need quiet, uniterrupted time to work. I'd argue all workers need this. The uninterrupted time? That's when the work happens.

Slack is not forcing your team to be always on, always connected with a 5 second response time. Slack is not creating a toxic environment that's stressing people out and killing productivity. You are doing this. Let that sink in for a second.

Slack will amplify your culture. It will echo your values.

If you value uninterrupted quiet time for your team - encourage them to sign off of Slack for large blocks of time. Don't penalize them for "missing" messages. Some conversations need to be instant and syncronous - i.e. the service is down. Many conversations should be asyncronous and encourage longer more thoughtful responses - i.e. which of these features should we work on next. Use the right tools when appropriate.

At Litmus, we use Slack for the rapid fire sync communications we have throughout the day. And we use Basecamp for longer form asyncronous communications that require more thought and that we want to persist and be documented. This is what works for us.

What if you got rid of Slack and the problems persisted?

Don't scapegoat tools for what are essentially people problems. If your creative team is constantly interrupted via Slack, do we really think removing Slack will stop people from emailing, calling, popping by people's desks? If the CEO expectes a 5s response time via Slack, is the expectation different of an email or a phone call?

By all means use the tools that best suit your teams. But if something isn't working for your team don't rush to blame the tools. They're likely the symptom not the cause.

The future of group chat

Whether it's Slack or Microsoft Teams or Campfire, Hip Chat and on and on, group chat as a workplace tool is not going away. Organizations need to think carefully. What values are being echoed? What opportunities and risks do these tools present? And maybe most importantly, how can I use these tools in the best way to make my team more successful.