Rogish Reading Writing

Companies, people, products.

Technology Leader Mentorship Program

Yesterday I was talking with a CTO colleague and we were lamenting the lack of educational or support resources for technology leaders (CTOs, CEOs of tech cos, etc.) on the “softer” side of the job (people management, group dynamics, process selection, etc.)

I realized we could do something about it, so I decided to organize a technology leadership mentoring program where technology leaders can connect 1:1 with mentors and discuss the challenges of working with the software of our greatest assets: our people.

The format is simple: you’ll either be a mentor or a mentee (or both!) and I’ll connect you with the requisite partner.

We’ll have periodic group events where mentors will present a topic (google hangouts on air) that focuses on the people side.

The mentorship program will run 3 months, although there’s no need to stop if you find that you’re working well with the other person.

If you’d like to be a mentor, or connect with one, please register your interest here:

Powered by Typeform

I’m going to keep it small to start, so sign up quickly!

A Modest Proposal: How to Replace Semver

I was browsing the Twitterscape and saw this tweet:

Mercifully I’ve been able to ignore Semver for a long time, but all this bru-ha-ha got me thinking about how we solved it in a previous open-source project (years ago).

APIs/libraries/projects/etc. need two versions. No, wait – don’t go. It’s pretty simple and looks something like 3.2.1-44 (marketing release-API version).

Marketing release: Major.minor.patch

API version: monotonically increasing integer

Whenever you introduce a breaking change, no matter how small, increment the API version to communicate that someone will need to do something to upgrade. At the same time, increase the marketing release to communicate the expected impact. I’ve found these work well:

Major: A really really big release. Likely you will have to change many things. Rails 2 to Rails 3 would be a good example.

Minor: It breaks some things, but should be migrateable in under a few days to a week.

Patch: Something small is broken. Likely you realized that some method had a security hole and now you have to patch it by changing the semantics. Intent is that upgrading to this release is doable in under a day.

Drop-in change? Leave the API ver alone. Adjust marketing however you want to communicate whatever you want.

That’s it! Super simple. Let the marketing version communicate the magnitude of the change and let the API version let someone know if they need to fix anything. Works for both people and machines!

If your project follows this, someone could even write a simple little status page that would give you rough estimates on how long it would take you to upgrade your app.

Maybe even integrate it into something like bundler

> bundle update --estimate

lib: current marketing version - API version ->
     latest marketing version  - API version ::
     effort estimate

rails: 4.1.1-4003 -> 4.2.0-4003 :: no breaking changes    (0 days)
rspec: 2.2.0-300  -> 3.2.0-433  :: major breaking changes (1+ weeks)
pry:   1.2.0-13   -> 1.3.0-14   :: minor breaking changes (2-5 days)

how far behind: 2 gems, 1-2 weeks est

Note: if you are concerned about the API version growing annoyingly big and “looking weird” then you are sort of missing the point. I concede you could reset it when you increment the major ver, but then you run the risk of automated systems failing to report a version conflict if they just do a simple check, e.g. upgrade gem unless my API ver < your API ver. Better to leave it alone, the API ver is primarily for machines anyway.

How to Make Remote Teams Work

274 years

The population of Manhattan is roughly 1.5 million people. On the weekend. On a weekday, the population doubles to 3 million people. Almost two million people commute from outside the city. Each work day.

Their commute time is, on average, 48 minutes each way.

For 1.5 million people, who spend 96 minutes a day commuting, that’s 144,000,000 total minutes. 2,400,000 hours. 100,000 days. 274 years.

274 years spent commuting to/from Manhattan each work day

Of course, many of these are retail, service, or support staff who need to be physically located here to perform their job.

What about the rest?

82 years burned every day

Of that number, from, we can estimate that roughly 30-40% of them are white collar computer users, or folks that support them. It’s not an exact number, but we’re talking napkin math here. Let’s be conservative and say 450,000 people.

That’s 82 years of completely wasted time every single day. For ~240 work days? A ludicrous 19,680 years every year.

Is this not insane? And this process repeats all over the country, as this chart shows:

There are other costs, too – building giant skyscraper office towers that aren’t getting filled, traffic from delivery vehicles and other support, and increased pollution. Not to mention you need to pay higher salaries to compensate for the extreme cost of NYC living.

Why aren’t these people working from the comfort, quiet, and sanity of their home?

Bright, shiny, work-in-your pajamas future

Working remotely, building remote teams and companies – these are not the “default” ways we’ve been taught to work in companies. But, it’s increasingly the way that some savvy companies are beginning to think, and default.

But for those that aren’t, there are a lot of objections to remote work:

“How can you build culture without seeing everyone each day?”

“How will people communicate and collaborate if they are working from home?”

“How to you make sure people can get their job done from the couch?”

At a half-dozen companies I’ve worked or consulted with, we had high-performing remote teams (either partially co-located/remote, or completely remote). I do not believe that to be successful, you need to cram everyone in one giant open-office nightmare.

The first cut is the deepest

The first step is letting go. Letting go that people need constant oversight. That butts-in-seats-time has a correlation with output. And you have to trust your people to do the right thing.

If you start with this mentality, everything will go a lot better. And even if you don’t manage remote people, this is the right approach in management anyway.

The best managers figure out how to get great outcomes by setting the appropriate context, rather than trying to control their people.

Reed Hastings CEO Netflix

Fighting entropy through facetime

Did I just say facetime isn’t important for results? Yes. But, just like any garden, you have to tend it. Groups take time to gel and until that happens, you’ll have decreased performance. With co-located teams, folks are going to lunch, happy hours, and various other forms of casual interaction. This constant interaction allows people to get to know each other, know the personalities in the group, and helps smooth over any intra-work conflict.

Remote people don’t have that luxury. It’s hard to get to know someone over chat, email, and pull-requests. Without that periodic face-to-face interaction, the team might not ever “gel”..

I highly recommend periodically getting everyone together in one place and time. If you have the budget, fly everyone to one of the cities every 6-8 weeks, for a whole week. Yes, it’s expensive, but it’s necessary to shorten that forming-storming-norming-performing cycle. And, without paying big-city salaries and office rent, you generally still come out ahead.


I’ve found that it is a lot riskier to hire people who have never worked from home before. It’s a different work style that some might find uncomfortable or dislike.

You can encourage people to go to a coworking facility to help give them that human interaction if they need it, but some folks will simply not like working remotely.

For folks who have never done it before, I’d suggest starting out on a contract basis in case they find it’s not what they want to do (saves their resume from taking a hit, gives them a reasonable out without needing to quit, etc.).

Tools of the trade

The rest of the tools are pretty straightforward.

Default to asynchronicity in all things.

Don’t have a meeting to discuss something when a pull request or collaborative Google doc will do. Encourage rubber-duck debugging (or slow time).

Default to openness.

That means all conversations and meetings should happen out in the open – in the chat room or a recorded video chat (and the video pasted into the chat room or wiki). If someone happens to be asleep or otherwise not around, the recording or chat scrollback will allow them to get up to speed when they return.

Speaking of being away from the keyboard – communicate your schedule when you “start” work for the day, so I can plan anything I might need. If I know you’re seeing a movie with your family at 2PM, I can make sure to get what I need from you ahead of time. As they say, a failure to plan on my part does not constitute an emergency on yours.

Discourage 1-on-1 conversation

Provide for individual conversation (Skype, GChat, whatever) but only for highly specific things that are not appropriate for a larger audience. Hardly ever use email. Do not collect team member’s phone numbers or make available to the group (if you want to share your mobile # with the rest of the team, that’s up to them).

Checkin Periodically

We don’t want to silo person-to-person communication except for periodic one-on-ones. I like to do weekly (or bi-weekly) one-on-ones with each person in the team.

Automate everything

If there is any process that relies on a person doing it, find a way to automate it. This includes deployments, CI, new developer onboarding, test/staging server refreshes, etc.

Did I mention CI? You should have it, and everything should grind to a halt if it fails.

Centralize the centralizable

Any company assets should be centralized in something like DropBox, Google Drive, a git repo, or the like. If someone needs an asset (logo), they should know exactly where to look for it. Their inbox is not that place.

Trust the process

Lots and lots of people have made this work. You can do it, too! Individual tools may come and go, but enter remote work with the right philosophy, and you’ll very likely be successful.