Mike Zornek

Stabilizing Inherited Software: My First-Week Checklist

mike@mikezornek.com (Mike Zornek) — Wed, 01 Jul 2026 11:17:33 -0400

Not every consulting engagement starts with joining a team that’s humming along. Sometimes it starts with a handoff: the developers who built the software have moved on, but the software itself is still live, still has users, and still needs to keep working. There’s no team culture to learn – there might not be much of a team at all. This is how two of my recent client projects went.

The goal in week one on these projects isn’t to improve anything. It’s narrower than that: get to a place where you can react safely if something breaks. Everything below is in service of that one goal.

The Previous Developers are Long Gone: This is our problem now.

Get the app running locally

You can’t safely change what you can’t run. This sounds obvious, but on inherited software it’s rarely trivial.

Get repo access (GitHub or wherever the code lives)
Reproduce the dev environment exactly – asdf-pinned versions, a Docker Compose setup, whatever the project actually uses
Make sure you are using specific database versions, not just “latest.” You’d be amazed what little bugs show up from a minor version mismatch

Run the app as a user

Before touching the code, build a real domain understanding of what the software actually does for the people who use it.

Take lots of annotated screenshots, ask questions as they come up
Put those questions (and their answers) in a shared, durable place – a Google Doc or, better, GitHub Issues/Discussions, so there’s a paper trail and other people can chip in beyond whoever you happened to be on a call with
Use this discovery work as an opportunity to create valuable artifacts: your questions, improved onboarding docs, etc. Future developers (and AI tools) benefit from the knowledge extraction you are doing
Be deliberate as a team about where knowledge goes and why. I tend to prefer GitHub Issues and Discussions as they live next to the code, and are less likely to disappear. Also, searching a term in GitHub surfaces the related conversations, not just the code

Explore the codebase

Pick a feature and trace how it’s actually implemented, end to end
Document your questions as you go, and circle back to capture the answers
If you have a peer or time with the previous developer available, have them walk you through their recent work

Understand how the app is deployed and how releases work

This is the highest-stakes item on the list, and on adoption projects it’s the one I prioritize most. If something breaks in production and you don’t understand the release process, you can’t react – and reacting safely is the whole point of week one.

Make a small, low-risk change and push it through the full release cycle yourself, start to finish, as early as you can
Once you’ve been through onboarding yourself, look back at what you just did. What would have made it faster or clearer for the next person? Contribute that back to the docs

Create learning projects

This project will almost certainly include some technology you’re less experienced with. Name it explicitly rather than quietly muddling through. Ask others on the team (or in the broader community) for advice on a skill-up path, and give yourself room to actually follow it.

Meet your peers

Set up introduction calls – try to talk to everyone, even if it’s a short, purely social call. You’ll be working with these people for a while; it’s worth actually getting to know them
Ask two questions in particular: what’s working well on this project, and where are the opportunities for improvement

Re-sync with whoever hired you

By this point you’ll have a much more detailed picture of the environment you’ve stepped into than you did on day one.

Set up a follow-up conversation with the person who hired you, or whoever you ultimately answer to
Get your open questions answered
Reaffirm and evolve a clear list of expectations and responsibilities. On some engagements I own the full stack end to end; on others I’m explicitly scoped to a specific area and asked not to touch the rest. Make sure that scope is actually agreed on, not assumed

Why all of this, before any of the fun stuff

None of this is glamorous. It’s not refactoring, it’s not new features, it’s not the kind of work that makes for an exciting commit history. But when it comes to inherited software, confidence comes first. You earn the right to improve something by first proving – to yourself and to the team – that you can be trusted to react safely when it breaks. Everything else follows from that.

Fresh Eyes on a Cucumbered Team

mike@mikezornek.com (Mike Zornek) — Tue, 30 Jun 2026 10:43:44 -0400

I once did some subcontracting for Test Double (wonderful consultancy btw, really good people there). While there I picked up a term for what happens when you’ve been inside an organization so long you stop noticing its quirks: you’ve been “cucumbered.” Left in the brine long enough, you become indistinguishable from the brine itself.

It’s a good metaphor because it isn’t unkind. A cucumber doesn’t do anything wrong by becoming a pickle. It just sits in the brine, and the brine does what brine does. The same is true on a team. Nobody decides one day to stop questioning the workaround that’s been “temporary” for two years. It happens gradually, as a side effect of being close to the work.

Why it happens to good teams

Cucumbering isn’t a sign of a bad team or a lazy engineer. If anything, it tends to happen to the most embedded, most trusted people on a team – the ones who’ve been there long enough to know where all the bodies are buried, which also means they’re the ones least likely to ask why there are bodies there at all.

Proximity is what makes someone effective day to day. You learn the shortcuts, the unwritten rules, the “oh yeah, just ignore that error, it’s always been like that.” That knowledge is valuable. But it’s also exactly what makes the weird parts of a system invisible. You stop seeing the thing because you’ve stopped looking at it – you’ve just started working around it, the same way everyone else already does.

What a consultant actually brings in week one

This, I think, is one of the real values of bringing in outside help. Hiring a consultant is usually framed in terms of technical skills: bring in a senior person to solve a specific problem or boost team velocity. Sometimes that’s true. But more often, the most useful thing I do in the first week or two on a project has nothing to do with technical chops. It’s that I haven’t been pickled yet. I get to ask “why do we do it this way?” about things that everyone else on the team has long since stopped seeing as a question at all. And because I’m new, that question doesn’t carry any history or political weight – I’m not implying anyone made a bad call, I’m just genuinely asking.

That question, asked plainly and without an agenda, is sometimes the most valuable thing a consultant can offer.

The guardrail

Here’s the part that matters most, though: there’s a fine line between asking why and trying to remake a team in your own image, and you should be careful not to cross it.

The practice of asking why isn’t an opportunity to slide in your own preferred workflow because it’s what you’re used to. It’s about creating space for the existing team to have their own introspection. If that leads somewhere – great. But what that somewhere should be needs to come out of team review and discussion, not the whims of a single person, even if that person is me (and I’m pretty great).

So, what’s gone unquestioned on your team?

You don’t need a consultant to ask “why do we do it this way?” Anyone can ask it – it’s just easier for someone who hasn’t been in the brine as long.

So: what’s something on your team that’s survived purely on “that’s how we’ve always done it,” that nobody’s actually re-examined in years? It might be worth asking the question out loud, even if the answer turns out to be a perfectly good one.

Using Google Sheets to Catalog Expenses for Budgeting Considerations

mike@mikezornek.com (Mike Zornek) — Sat, 19 Apr 2025 11:07:02 -0400

I try to revisit my budget every six months or so, and having just wrapped up my taxes, which provide helpful totaling of where the money went last year, it was a good time to rebuild the numbers.

In the past, I’ve used Soulver for some of this, and while I still like that app, this time, I took a shot using a Google Spreadsheet.

I liked how the expense spreadsheet came out and thought there would be value in sharing a demonstration of it.

I’ve recorded a video of its creation to help those who might not be spreadsheet experts and to capture my thought process regarding cataloging expenses for future scenario experimentation.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4 Watch on YouTube

Video Summary

Track each expense with a Description, Cost, and Occurrence (Monthly or Yearly).
Mark each expense as Hard, Medium, or Soft to express the importance of this expense to you (how hard would it be to live without).
Use bank and credit card statements to help you capture all things.
Use a column to convert Yearly costs into a Monthly equivalent, the base time unit we work with here.
Add a Scenario checkbox column to help you experiment with what expenses can be removed to reach your target goal.
Utilize features like share, comments, and versioning to work with others.

Resources

The Google Sheet from the video
Previous blog: Budget Revisit 2022
Previous blog: Self Employment Estimate Numbers

On Asking Multiple Questions

mike@mikezornek.com (Mike Zornek) — Sun, 05 Jan 2025 13:20:55 -0500

On the socials @jerzone shares:

My super power is carefully combining a number of relevant questions in the same message so the person doesn’t have to spend a lot of time going back and forth with me on individual questions.

Everyone else’s super power seems to be picking out the least relevant of those questions and responding in an oblique fashion.

In general, I prefer asynchronous communication. The freedom it gives the participants to contribute to the conversation at a time that best works for them can be helpful and sometimes outright required if you are collaborating with folks outside your time zone.

That said, the delay in getting a proper answer can be frustrating.

I used to attempt to preload questions in my own emails/messages to people. Sometimes it would be as simple as a flat list of questions, and other times, I’d give them a logic path for if yes, then question x, or if no, question y. I have learned that this is a mistake.

My experience dictates many people do not work well with this complexity. They miss questions or details entierly. The eventual awkwardness of repeating questions is enough that I will do simple, single questions, one at a time.

This lack of comprehension could result from our distracted culture, which for many includes answering SMS messages and interacting with phone notifications non-stop. I feel disempowered to fight those winds.

Sometimes, I find a peer where multiple questions will work, but that is something that is earned and not assumed.

My Standup Format

mike@mikezornek.com (Mike Zornek) — Wed, 09 Nov 2022 15:00:32 -0500

I find async standups to be a productive and low-cost ceremony in my development teams.

An async standup, in short, is each day, typically in the morning hours, team members are asked to post an update about what is going on in their work. This post is not about time tracking or otherwise work inspection but more an opportunity to take a breath, celebrate your wins, acknowledge your losses, ask for help and share your plans. A good outcome of standups is ensuring you get the help you need from your team to be successful .

There is an async standup format I’ve been using for over a year now, and since it seems to be sticking, I figured I’d take a moment to share it and explain why I like it.

❤️ Feeling: …
✅ Accomplishments: …
🥅 Goals: …
🆘 Help: ….

❤️ Feeling is a great place to share your personal, human mindset. “Got limited sleep last night because the kid is sick.”, “Feeling anxious about the upcoming proposal deadline.”, “So happy that the Phillies won last night!” Being open and expressive about how we feel can, over time, help build trust within the team.

✅ Accomplishments is a place to document your day-by-day outcomes. Many of these might be traditional progress towards some new code, but it can be just as valid to share that you discovered a problem and documented an open question somewhere.

🥅 Goals is where you highlight your plan for the day. I sometimes get overwhelmed at midday and then return to my goals to recenter and figure out what I need to be focusing on. It’s okay if goals occasionally carry over from day to day, though if this stresses you out, maybe end with a stretch goal that is almost expected not to be completed today.

🆘 Help: is probably the most critical line. Need a PR reviewed or some open questions addressed? Don’t be shy! Be explicit and ping specific people, “Hey @jim, I really need your advice about this PR feedback from @pam.” If you have no help requests, an affirmative “No blockers.” is good to see. I prefer this than to omit “Help” entirely.

🚨 Awareness is a line I’ll sometimes add to spotlight information I want the team to see. “Going to be offline this afternoon for a dentist appointment.” or “I’ll be on vacation next week, work with @dwight during my absence.”

Many of my past teams have posted our standups in a Slack channel. In my newest team, we’ve been trying to avoid using Slack entirely and instead are using GitHub Discussions. We have a dedicated monthly standup thread, which works well since simple issue numbers like #123 will auto-link to relevant issues and pull requests, and you can still @ mention people to kick a notification.

Before I leave, I’ll mention that this is not a format I came up with. It was observed during my subcontracting with Test Double. They were a particularly empathetic company towards project process, ceremony, and developer happiness. This standup format was one small example.

Curious to hear how you and your team do standups. Let me know.

Recent Estimating Work Notes

mike@mikezornek.com (Mike Zornek) — Fri, 04 Nov 2022 13:12:04 -0400

This week I completed my third week with a new client. It was a notably challenging week since the main goal was to write up a significant project estimate, which was due by Friday. We delivered the estimate earlier this morning, and I think we did a good job. I’m sure the estimates themselves are WAY off from where reality will land, but that isn’t the goal as I see it.

The goal of this estimate is to, in a time-boxed format, create a framework for more meaningful discussions to happen. These numbers should not be looked at as facts but shape those first steps of discovery.

A few notes and observations:

While it brought on a bit of anxiety in the early part of the week, I think we greatly benefited from the time-boxed nature of the request. We knew we had to deliver something on Friday, which influenced how much fidelity we could give toward specific feature estimates.
We used typical Fibonacci story points for each fundamental feature/focus. We had a base point value and then a high point value. We also labeled each estimate as Low/Medium/High risk, which was meant to signal that, should the fidelity of this range be too large to make an informed business decision, we could do more discovery and sharpen those numbers.
This was tough for me since I am still new to the codebase. I was able to partner with the previous tech lead, and that helped a ton, but my number ranges were still significantly larger than if I had been on the project previously with a known team.
Once we had the base and high points, we totaled them and crafted some team scenarios. This was the worst part. Usually, I’m able to gauge a team point velocity based on historical observations, but this would be a team who would be new to a codebase and each other, so the numbers are very suspect. We did our best and tried to document uncertainty as transparently as possible. We noted that should this proposal be accepted, we should set up regular check-in against these numbers and adjust the team/scope/timeline as necessary.
We worked in an onboarding penalty to the team velocity, spread across many months. I think this was a good move and made the scenarios more realistic.
In our recommendations for team size, we noted the risk that an individual contributor may not stay on the team for the entirety of the project. Adding an additional contractor is not about a 1:1 increase in velocity but risk management. We want to maintain domain knowledge through expected staff changes.
In our scenarios, we did not document time towards routine platform maintenance (this is in production with real customers) or personal vacation time. We did document our non-documentation so that when it comes time for realistic scheduling, these can be considered.

For what it needed to be, I think the outcome document of the week will help the stakeholders.

It is by far not my favorite way to approach projects. For that, I’d probably lean toward something like Shape Up.

The Importance of Side Project Tiny Tickets

mike@mikezornek.com (Mike Zornek) — Fri, 30 Sep 2022 14:12:39 -0400

If you have an active side project, I highly recommend you invest some of your valuable and limited time into ticket/issue creation to plan out your work. Specifically, you should build up a collection of ready-for-work tiny tickets in the 10-20 minute time completion range.

So often, we look forward to long “deep work” programming sessions to make meaningful progress on our side projects, but they are few and far between. We have tons of other life responsibilities from work, family, and friends that will have priority on our time. If we wait for perfect work sessions to make progress, our side projects will take much longer to complete, and the risk of failure (due to personal distractions or loss of motivation) increases drastically.

You need to find ways to move your side project forward during the cracks of daily life, hopefully setting up the foundation of a productive habit loop. Have a little time before bed; here is a tiny ticket to do. Have time to kill waiting for a zoom meeting to start; find a tiny ticket to knock out. Many will be mindless dependency updates or small refactors but little by little, your project will grow.

If you have an active side project, I’d love to ask you some questions to help me with my research. Grab some calendar time here: https://savvycal.com/zorn/chat.

Budget Revisit 2022

mike@mikezornek.com (Mike Zornek) — Sat, 02 Apr 2022 15:37:36 -0400

The last time I wrote about my budgeting habits was back in September 2018, and the last time I looked over my numbers was in 2020 when I had just lost my active contract due to the beginning of the COVID pandemic. Today as I look ahead to the summer and the future completion of my current contract gig, it was a good time to revisit my numbers.

Like last time I’ll share how I collect and organize my numbers, and hopefully, it will inspire you to revisit or improve your budgeting solution.

First, I collect a categorized list of expenses. I tend to use my credit cards, bank statements, and my recently completed taxes as a source of truth. Over time you can even use your historical budgets.

For my personal and business expenses, I create a list of monthly and yearly costs. Inside each of those, I break things down as hard costs and soft costs. Hard costs are those expenses that would be difficult or dangerous to change, such as apartment rent or health insurance. Soft costs are those expenses that I could sacrifice if needed, such as Netflix or charitable donations. I’ll share some examples of my categories at the bottom of the post.

To organize these, I use an app called Soulver. It is an impressively clean but powerful way to collect line items and generate totals without the heaviness of a spreadsheet. I also appreciate how I can use programming-like comments starting with // to document my thoughts.

My goal is to generate an overall monthly total for both hard and soft costs (averaging the yearly as a generic monthly cost). I can then use that against my expected monthly income and available savings to help generate burndown charts and scenarios like:

If I were to completely pause consulting and focus on a personal project how long could I last comfortably on my available savings.
If I wanted to work the absolute minimum number of hours to pay for my unadjusted monthly costs (remember to consider taxes and savings goals), what hour total would I need?
- What if I raised my hourly rate by X percent?.
- What if I was willing to remove some of those soft costs?
If I wanted to have X amount in cash available for a house or car down payment in X years, how much extra would I have to work?

Keep in mind that you won’t work full time every week/month. Make sure to account for expected vacation time off and some sick days.

Budgeting like this is a great way to get clarity on your spending and hopefully nudge you to cancel or otherwise lessen the spending on things that are not a fair exchange for the level of enjoyment you get or just plain forgot about. Furthermore, learning to build up that savings pot can be incredibly empowering, allowing you to be much more selective when deciding what’s next.

Sample Expenses and Categories

Personal Hard Costs Monthly

Rent
Renter’s Insurance
Electric Bill
Gas Bill
Car Payment
Car Insurance
Car Maintenance
Car Fuel
Health Insurance
Vision Insurance
Dental Insurance
Prescriptions & Copays
Life Insurance
Grocery Store Food
Haircut

Personal Hard Costs Yearly

Sleep Apnea Equipment
Bank and Credit Card Fee
Healthcare Lab Fees

Personal Soft Costs Monthly

Eat Out Food
Netflix
Hulu
YMCA/Gym
Video Games
Music Subscriptions
Charitable Donations

Personal Soft Costs Yearly

Vacation
Clothes
Shoes
Gifts (Christmas and Birthdays)

Zorn Labs LLC Hard Monthly

GitHub Membership
Linode Hosting
Google Apps
CircleCI
Backblaze
1Password
Bank Fees
Amazon Hosting
Verizon Phone
Verizon FIOS
Zoom
Dropbox
SBA Loan Payment

Zorn Labs LLC Hard Yearly

Tax Preparation
Hover / Web Domains
Network Security Software

Zorn Labs LLC Soft Monthly

Coworking Membership + Parking
Various Software
Various Podcast/Books/Education (This is one of my biggest categories!)

Zorn Labs LLC Soft Yearly

Various Software
Professional Memberships
Office Supplies
Professional Conference Budget
Content Licenses
New computer every other year: $4000 × 0.5
New iPad every other year: $1100 × 0.5
New iPhone every other year: $1000 × 0.5

I tend not to budget for new hardware purchases like computers or phones every year, but it is great to keep those purchases in mind.

Don't Waste My Time (Video 2m)

mike@mikezornek.com (Mike Zornek) — Mon, 07 Sep 2020 13:17:43 -0400

I love the enthusiasm and energy of this video.

A few thoughts on cutting to the chase in videos for an online audience.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4

A Screencast about Building Screencasts: How I Built the Guildflow 70-second Introduction Video

mike@mikezornek.com (Mike Zornek) — Thu, 03 Sep 2020 12:12:44 -0400

I’m a big fan of screencasts. I generalize the term screencast here as any video where you see primarily a computer or user interface, with a voice and optional video feed of a person doing some kind of demonstration.

You’ve seen lots of screencasts here on the blog and I’ve even done a few professionally as a consultant, using real voice-over performers.

In today’s video I’ll recount how I built the recent 70-second introduction video for Guildflow with specific demos and discussions of the tools I use including:

Bear to write a screenplay in Markdown.
Keynote to build a presentation of screenshots.
Screenflow to record my desktop and edit the capture.
QuickTime and Acorn to build thumbnails.

Your browser does not seem to support the video format. You can download the MP4 file directly.

Download MP4 Watch on YouTube

Thanks for watching!

Video: How I Use OmniFocus to Track Tasks (12m)

mike@mikezornek.com (Mike Zornek) — Wed, 10 Jun 2020 09:59:22 -0400

OmniFocus is a task manager that was built around the concepts of Getting Things Done, a popular action management system by David Allen.

I’ve been a fan of Getting Things Done and a casual user of OmniFocus for years, mostly focusing on long term projects. For weekly stuff I used to do a manual list in Bear but a few weeks ago I took the time to see if I could make OmniFocus work for my weekly list, and so far it’s working out great. This video is a review of what’s changed.

PS: One things I forgot to mention in the video is that for my side project I use Pivotal Tracker for actionable technical tasks and keep the marketing and general business tasks in OmniFocus. I am also experimenting with a public project roadmap but that is more experimental.

My Favorite TextExpander Shortcut Snippets

mike@mikezornek.com (Mike Zornek) — Mon, 27 Apr 2020 14:52:36 -0400

I’ve been a long time TextExpander user. You don’t know of TextExpander? Shame!

TextExpander lets you instantly insert snippets of text from a repository of emails, boilerplate and other content, as you type – using a quick search or abbreviation.

My common shortcut snippets include:

Email: z@zl into zorn@zornlabs.com and m@m.com for mike@mikezornek.com.
Date: ddate
Time: ttime – very handy while testing UI as a piece of dynamic content, yet descriptive and ordered.
Common Google Terms: -ep into Elixir Phoenix.
Phone Numbers: cphone and hphone into the real phone numbers.
Support Email Replies – when I did a lot of that thing.
URL to my meeting calendar: -meeting into https://savvycal.com/zorn/chat
Common Xcode Comments: -mark into:

// MARK: - Outlets
// MARK: - Properties
// MARK: - Life Cycle
// MARK: - Methods
// MARK: - Private

SwiftLint Disables:

// swiftlint:disable rule_name
[CLIPBOARD]
// swiftlint:enable rule_name

I added a new one today, for the common need to convert a title-like string into a filename-friendly one.

"%pasteboard".toLowerCase().replace(/ /g, "-");

Thus expanding -urlp into “Nurturing Your Community During Lock Down” (the clipboard) into nurturing-your-community-during-lock-down.

I’m on the hunt for more too. Let me know if you have any recommendations!

My New Experiment: Journaling All the Things

mike@mikezornek.com (Mike Zornek) — Tue, 13 Sep 2016 21:34:36 +0000

At CocoaConf I attended a session from my fellow Big Nerd Ranch coworker, Mark Dalrymple. In this session he explored the questions we ask when looking for bugs — or more specifically their solutions.

At one point Mark showcased a text document that in glorious detail documented the assumptions, questions and answers he was going through to solve a problem. Now, this wasn’t a document Mark made for the talk, it was from a real journal entry he had. He was Rubber Ducking but documenting the discussion like a court reporter.

If you ever work with Mark you’ll quickly discover he is a relentless notetaker. This is just one more example of how it can pay off.

Need to step away to work on something else, here is a document to reload your context.
Need to invite someone else on to help solve the problem, here is your knowledge transfer.
Want to write up a blog post to help others in the future, here is your draft.

I left the session very inspired. As a result, for this week, technically my vacation week but I’m working on side projects, I’m starting an experiment where I try to emulate Mark’s journaling habits as best I can. I have 3 documents at the moment:

Daily Journal — Mostly flat list with GOALS for the day and then ACCOMPLISHMENTS of what actually got done at the end. If something in the list has notes in and of itself, it’s hot-linked to those on their own wiki page.
Company Journal — Documenting the efforts I’m putting into my side project and the company that encapsulates it.
Tech Journal — Starting with Apple, here is where I’m collection my thoughts, issues, and bugs relative to Apple technologies. I expect to make more for other stacks like web in the future.

I’m using VoodooPad for the actual files/wikis themselves. It works well letting me organize like a wiki and can handle screenshots too.

We’ll see how I hold up. I want to give it my all for at least a week and then will do a retrospective as to how it’s working out. There are challenges (like my current typing speed) but lots of potential benefits too.

Update: More from Mark’s own blog.

Do you journal like this? Any tips or other feedback? I’d love to hear it. Message me on Twitter @zorn or via email: mike@mikezornek.com.

Managing Remote Teams

mike@mikezornek.com (Mike Zornek) — Thu, 28 Jan 2016 21:25:28 +0000

Local company Wildbit has been nice enough to host a running series of meetup events focused on running a software business and all that it can entail. Last night we discussed Managing Remote Teams and as a remote employee myself I was interested to hear what others people had to share. Below are some of my notes.

Context

In attendance we had about 12 or so people. Many from Wildbit (many of their remote people were in town), but we also had a pair from another small (6+) local software company, one from a local company researching coworking and myself, whom works remotely for the Big Nerd Ranch, down in Atlanta.

General Observations

Running an all in-person office has unique organization challenges and benefits.
Running an all remote office has unique organization challenges and benefits.
Running a hybrid in-person and remote office has unique organization challenges and benefits.
Even still, things vary based on the size and work of your company.
No rules are true for everyone so be flexible.
Be prepared to spend time and energy on this.

Why Consider Remote Employees

Expands your potential hiring pool greatly.
Very helpful if you are using niche technologies where it can be hard to find experts (Closure, Rust, etc.).
Potential benefits in having time shifted work (but this can also introduce communication problems, lag).

How to Get Started

If you currently have a 100% in-person company, adding remote people will be a significant culture shift. Be prepared.
No one wants to be the first remote hire on a team.
Consider adding multiple remotes at once.
Consider offering work from home to current in-person staff to help the new culture work itself out.

Challenges

It can be hard for a remote employee to demonstrate what they are working on.
Being remote requires more thorough and regular communication than most people expect.
Lots of people romanticize remote work from DHH’s writings and don’t respect the real life challenges of it all.
Sometimes with a hybrid company, teams will be setup where you have two people “in office” and one person remote on a project. It can be real easy for the two people in office to share more face-to-face leaving the remote person feel left out.
If you have employees in different states / countries, you have to make sure you are following the approbate employment laws of those states / countries.
The whole “programming in your underwear” trope is really misguided. Most successful remote people have a schedule, take showers, get properly dressed and have a dedicated work spaces.

Face to Face Retreats

Everyone seemed to agree that it’s a bad idea for the remotes to never come together. Everyone benefits from real face to face time so plan for it early.
Wildbit has yearly company retreats, where they work, plan for the year ahead and otherwise define the goals and values that should guide all their decisions.
Other companies do more vacation oriented retreats to help connect people socially.
It was also suggested that depending on the size of the company it could benefit from have some company wide events and then some smaller more team focused events.

Things You Can Do to Help Remote Employees

Setup a Slack or HipChat for communication.
- Additionally try to have people communicate what they are doing. “Starting feature X”, Reviewing PR Y”, “Stepping out to get some coffee”, “Breaking for an hour to watch a conference talk” — sharing these can help people better understand what’s going on.
Consider giving them an annual office stipend to improve their workspace; equivalent to the money you’d spend giving them an office in your building.
Make sure all in-office systems are available to remote folks. Things like file servers, whitelisted IP API access, etc.
Prefer video chat over audio chat. Seeing human faces helps communication and empathy.
When running a video chat, consider having even the in-office people stay at their desk and connect to give every “virtual head” its own space. (I’ve also had everyone use their laptop for the video and a shared phone for the voice.
If you are presenting and the video is going out to remote people, don’t forget to ask them for questions and check the chat room.
If you are a manager and are set up to have 1:1 monthly meetings with in-office people, consider offering bi-weekly for remotes — since they might be more out of sync.

Equipment

Some people were enjoying the HighFive video conferencing hardware — though they needed more seats than the current solution offers for their company wide stuff.
BNR’s recently been using the YouTube Live service to stream and capture video with fair success for our larger meetings / internal educational talks.
One AV tool BNR uses is a toss-able chat box that contains a microphone so after large meetings, during Q and A, the remote folks can hear the questions being asked.
The Double was brought up reguarding its use as a virtual presence. It’s cool stuff but of questionable return value.

Hope you enjoyed my notes. If you have anything to share about your own remote work let me know.

Mike Zornek

Stabilizing Inherited Software: My First-Week Checklist

Get the app running locally

Run the app as a user

Explore the codebase

Understand how the app is deployed and how releases work

Create learning projects

Meet your peers

Re-sync with whoever hired you

Why all of this, before any of the fun stuff

Fresh Eyes on a Cucumbered Team

Why it happens to good teams

What a consultant actually brings in week one

The guardrail

So, what’s gone unquestioned on your team?

Using Google Sheets to Catalog Expenses for Budgeting Considerations

Video Summary

Resources

On Asking Multiple Questions

My Standup Format

Recent Estimating Work Notes

The Importance of Side Project Tiny Tickets

Budget Revisit 2022

Sample Expenses and Categories

Don't Waste My Time (Video 2m)

A Screencast about Building Screencasts: How I Built the Guildflow 70-second Introduction Video

Video: How I Use OmniFocus to Track Tasks (12m)

Links

My Favorite TextExpander Shortcut Snippets

My New Experiment: Journaling All the Things

Managing Remote Teams

Context

General Observations

Why Consider Remote Employees

How to Get Started

Challenges

Face to Face Retreats

Things You Can Do to Help Remote Employees

Equipment