AlexHopmann.com

Brad Feld posts about Office hours during college and how he tries to do similar things now at their TechStars incubator. We have a different take on office hours at DeepRockDrive but so far it works out really well and I thought it would be interesting to share.

When I started working with DeepRockDrive the technology folks up here in the Seattle area didn’t have a real office at all yet. Folks just met most days in a coffee shop and would hang out and work on the code. There were a few contractors scattered off around various parts of the world and people would often work at home. Everyone would log in to Skype all day in a common chat room so you get the similar concept to shouting over to the guy at the desk near you.

We have had an office now for several months, but its over in Bellevue. Our staff is all over the Puget Sound area and traffic isn’t so wonderful around here most of the time. I was hoping we could maintain some of the culture of being able to avoid wasting 40-60 minutes a day in traffic plus the advantages of being able to concentrate at my home office (not to mention reducing the environmental impact of all that driving especially in stop and go traffic). At the same time to act as a well oiled agile startup we need to have great communication with each other and it was sometimes really difficult to find a time when all the right people were around to discuss a given topic.

What we came up with was the concept of “core office hours”. This is roughly Monday, Wednesday and Friday from 10am to 3pm. During those times people are expected to be in the office (with the obvious exceptions for vacation, travel, important appointments, etc). Those are great times to schedule a meeting, plus you can usually pull together the right people for an impromptu meeting for just about anything. But, with the limited hours this also helps prevent our schedules from filling up with constant meetings so we have solid times to get code done, tested, write important documents, etc. On Tuesday and Thursdays I can avoid getting in the car at all. On Monday, Wednesday and Friday when I do need to go into the office I can do it at a time when traffic is WAY better (20min vs 40-60) plus its a nicer time if you want to bike too.

So far overall I’d say this system is working great, but I do have a few thoughts about some considerations that are necessary to make it work-

• It is not going to work for all job roles. Some types of jobs require you to be at the central place where people can be there together. And the job needs to be something where the output is pretty measurable- if you can’t tell if someone is goofing off, its going to breed ill-will. If the job is something where the results speak for themselves (amount of code written, bugs found, etc) it is a good fit.
• It is not going to work for all people. To make this work you need people that are very self-motivated and self-starting.
• The Skype thing helps us a ton (although any other form of live chat-room with presence information also works). It helps both give us that ability to communicate and get problems solved with colleagues in real time, as well as helps people be visibly “on the job”.
• It helps to have good network resources. We rely on a combination of the Skype stuff, as well as GMail, Google Docs, Basecamp, and an SVN and Trac server that we have deployed in our data-center. I’d also point out that all of those services are accessible without VPN so our staff can easily work on stuff from home / a cafe / vacation / the road. In theory having to VPN shouldn’t matter but I’ve always found it to be a big barrier to getting real work done.

Another big link today, this time from the folks at Ajaxian. I sit here wondering
if saying thank you for a link makes me not cool. Kind of like the person who is over star-struck meeting a famous person or something. Personally
I’m not terribly fond of the automated trackbacks (plus, spam has limited their usefulness) and it’s the interconnectedness that makes the web work so I’m
going to do it anyway. Thank you Dion!

The combination of the new interest in that write up and a conversation with a client yesterday of course reminds me of another good story. As we
were developing Exchange 2000 / Outlook Web Access we would meet with Bob Muglia pretty much every week. At the time Bob was our senior VP and was
running a pretty huge organization (I think including all of Office). The amazing thing was that despite the size of his organization he managed to
still be very involved. Execs that combined the ability to get it when they saw something important and at the same time inspire people to drive
hard made that a very exciting place to work.

Outlook Web Access was very much a “catch up” project. We started about halfway through Exchange 2000, and were working very quickly to build as
much functionality as possible. Outlook has an incredibly deep feature set including tasks, this thing called the Journal, and of course tons of
contacts and calendar features. At this point we had gotten the basic mail part working but not much else.

I don’t know how he pulled it off, but when we showed Bob a demo of the mail stuff, he managed to do this really cool thing. He managed to show
how enthusiastic he was about what we had pulled off so far. And at the same time somehow he challenged us something along the lines of “of course
contacts are hard, you probably can’t have contacts working quickly”. The next week we demoed the contact list and again, he was enthusiastic, but of
course the “card” view would be tricky. We managed to go for quite some time and every week Jim and Bob somehow managed to pull off a whole major
section of the application into good enough shape for me to demo it.

I’m pretty sure that Bob and Gord Mangione (our GM) knew the difference between getting something to the point where you can demo it vs. shipping
to enterprise customers. Getting this stuff polished and out the door was a huge effort and considerably less glamorous than those rapid development
days, but I don’t think we would have made it to there without the special kind of encouragement we had at the outset. There is a special balance
you need to strike as a manager to create the right atmosphere so that people feel challenged but not overburdened.

Too often the relationship between a development team and their management is some adversarial one where the development team feels
they need to push back on schedules and challenges. I think one of the sources of this problem rests in our assumptions that software
like other engineering disciplines should be something you can accurately schedule. Developers that can come in on time are thought of
as more professional. Plus, I get how difficult it can be to plan a marketing launch or other business issues that need lots of advance
notice when your developers can’t predict how long it will take to finish.

The sad fact is that as a developer I really dislike being pushed to make an accurate estimate of how long a project is going to take,
and as a program manager I dislike having to push my development team for accurate estimates. It takes the right developers, but if your
business and team can support it, you can get lots more done by not having a fixed schedule, tackling projects incrementally with nice
bite sized steps, and just driving hard to get them done as quickly as possible. Sometimes you will hit roadblocks and something will take
longer than expected, but this model doesn’t leave you feeling guilty for missing some arbitrary schedule and encourages people to think
of different ways around the problem.

In other news I’m thrilled to see that the new version of Prototype, 1.5 is now available. I’ve
enjoyed using this library quite a bit to make Javascript much easier to deal with. I haven’t seen any good summary of what has changed
in the new version yet, stay tuned.