The Right Way to Deliver Software

This evening I attended a Tech talk at’s HQ in Los Altos. Not only is Box a great product, they will be our neighbor in Redwood City soon as they build their new HQ by the Caltrain station.

Driving up to Box HQ

Driving up to Box HQ

The topic of the evening was near and dear to my heart. “The Right Way to Deliver Software”. The speaker was Jocelyn Goldfein. She led the engineering team at Facebook that created news feeds and photo and then headed up their pivot to mobile. She was an early engineer at VMWare so she understands enterprise software sales. She was a CS geek at Stanford. So I figured she’d be someone I could learn from!

Box’s Office:

I parked underground and then walked up to their version of the “Lair”, which is what we call our common space in Equilar’s offices. It’s where we hang out, have lunches and coffee, and do company meetings. Box’s Lair had a cool tablet wall that was interactive.

Interactive tablet wall

Now their Lair was a little larger than ours. Here’s the view of the space from stage left. There were some nice moleskine notebooks on the table and a buffet at the right as you came in.

A Nice Industrial Chic place for a meeting.

A Nice Industrial Chic place for a meeting.

The Presentation:

First, here’s a spoiler. There is no panacea for creating software there are tons of dependencies to consider. Everything is a tradeoff and you have to understand the market you serve and the product you are trying to deliver. This is where experience and understanding comes in .

Jocelyn kicks off the presentation

Jocelyn kicks off the presentation

It’s all a TradeOff:

You have to prioritize and decide what is most important to you. In this slide she lists some pretty high level items.

  • Features – this one is self explanatory I think.
  • User Experience – wonky or slick and modern?
  • Performance – how fast must it respond?
  • Reliability – are we talking five 9’s or is it ok to have intermittent outages?
  • Breath of Platforms – she was referencing the Facebook mobile app here.
  • Schedule Predictability (“Ships on Time”) – believe it or not, this isn’t so important in FB’s case.

The last one was particularly interesting to me. Facebook (Web) ships 9 times a week! Twice daily and once on Tuesdays. Since they test and iterate so much, there isn’t a set feature release target.

Things that factor into a product release.

Things that factor into a product release.

Underlying Principles:

Cost is dictated by the tech stack. If you are deploying on your own hardware or data center, it doesn’t cost so much to get your application to the customer. If you are deliver a mobile app, there are a lot of steps before it gets into the hands of your customer. This takes time and time is money. What about the environment stack? It costs a lot to test multiple platforms and hardware configurations. This is one of the things we love about web apps.

Benefits is dictated by the business model. If you sell a high dollar product, then you must have a more reliable and predictable release cycle. It also better be available at all times. Surprisingly, the more consumer and free it is, the UX becomes more important for retention.

Cost of a Mistake:

This was a very interesting concept. Depending on the product you are creating, the cost of doing something wrong can vary widely. Let me explain the diagram. The vertical axis is “Enterprise $$$” on the bottom and a “Free / Ad Supported” product at the top. On the horizontal axis we have an “operating system” (think Windows or VMWare) on the left and “Web” based app on the right.

Beware if you are in the bottom left!

Beware if you are in the bottom left!

If you have an enterprise based OS to sell (think Windows or VMWare), your release cycles are long and having to do it over because of a mistake could cost you 100X the cost of shipping it right once. On the extreme opposite is a free web app. If you screw it up, many folks won’t go crazy, users will not lose money and doing it again only cost 1X. Then we have the two other quadrants at 10X. My company’s products fall in the lower right quadrant at this time. Because of this we cannot just release whenever we want, but we must test and have a pretty predictable cycle. This of course implies increase cost as compared to a quick web based startup.

Another way to look at the diagram is to compare it to a release process. The star in the middle is a reminder that no matter what you do, you must beta test.

Length of release processes

Length of release processes

The FaceBook Mobile Transition – a Culture Shift:

Facebook started in mobile creating a completely web based application. They thought that this would give them the fastest release cycle at the lowest cost. They soon realized that the best experience could only be achieved if they went with a native mobile application.  It took them years to make the transition because of a culture divide. Web(HTML5) developers went fast and iterated often. They could get feedback in hours and release again. There was not release cycle set in stone.

Initially they thought that going to native would be the same. Bad mistake. A cycle in mobile took 8 weeks from creation to final delivery to the user and then acting on the feedback received. It was a culture shock to the mobile team. In fact, most members couldn’t make the transition. Facebook hired new developers and had a few “acqui-hires” instead. It was a hard lesson. Each group thought the other group did things wrong. If you need to make a radical shift, be ready to change the team.

In the end, the “North Star” was focusing on what the users need and not what the employees needed. The focus on the best thing for the user dictated how and what was built.

Now What? 

So how do you apply the things learned. Jocelyn wrapped it up with a few key takeaways.

Take Aways

Take Aways

  • Understand your priorities before you optimize the release process.
  • If you have to pivot, be prepared to address culture issues.
  • Take advice with a grain of salt. Each product is a little different. It’s not one size fits all.
  • Hire for experience? Conclusion was that this is important if you know exactly what you are going to do. Otherwise, hire for the right DNA that fits with your company.
  • Onboard thoughtfully – know what culture and processes will be needed and train early.

The best people are those who are malleable and do not have absolute dogmas. You need people who are willing to learn and change. These are the best hires.

Here’s my favorite quote of the night.

“All adult learning comes from pain.”

What you say? The premise is that when you are a child everything is new and you just accept it and learn. As you grow up, you start to gain opinions and internalize data and experiences. Everything starts to get measured against that. The only thing that can really change your attitude and what you have learned is if it was painful when you didn’t change.

Oh, and it wouldn’t be right if I didn’t post a food picture. Box served us Chicken, sauteed vegetables and rice. I washed it down with and Indian Ale.


One of the things I love about the valley is that there are so many great people, places and opportunities to learn. I really encourage you to find the meetups in your area and network! You get free food, meet new friends and sometime even learn a thing or two!

And speaking of meetups, our company ( is sponsoring a meetup on April 9th in San Jose California. Here’s a link below to all the details. I’ll be there so come find me if you are in the area.

Tech in Motion: Social Tech Mixer


About song

Tech guy in the silicon valley. If you need anything else, look on the blog. It's all there.
This entry was posted in My Rants and tagged , , , , , . Bookmark the permalink.

Leave a Reply