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:
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).
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 ::
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.
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 minuteseach 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 labor.ny.gov,
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.
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
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.
The best managers figure out how to get great outcomes by setting the appropriate context, rather than trying to control their people.
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,
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.).
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).
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.
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.