On May 1, 2010, Avantica acquired Open Mountain. The Open Mountain blog officially became the Avantica blog.  You can read more about the acquisition here.

In the coming months, you will see a new blog emerge with more content and contributors.  Maybe you’ll even appreciate some new opinions having read mine the last few years.  In honor of the change over, let me finish off the Open Mountain blog with this final post.

Why did we do it?  Why sell the company to our top development partner Avantica?

First, let me dispel any concerns.  We didn’t need to sell to survive this economy.  We created a profitable and growing business in one of the toughest economic climates in recent history.  Our friends and family are happy we survived as well.  Take a look at this post about different ways to start a company and you’ll get a sense for how we managed our bottom line.

Earlier this year we began to consider how we could achieve our next set of goals for the company.  Not just financial goals but goals for expansion, for enhancing our services and really for becoming a leading company that start-ups call the second they need a team.  On our own, we knew we could get there.  As part of Avantica, we decided we could get there sooner.

That’s it.  No smoking gun.  No definitive reason that forced our hand.  Really, not a bad set of choices.  Stay the current course and have nice stable growth. Join Avantica and engage with a larger base of customers and a broader set of opportunities.  Joining Avantica was really about what we could do together by sharing our knowledge and resources.

Of course, we had our fair share of sleepless nights wondering if we were doing the right thing.  Letting go of the first company you created is a bit like sending your kids away to college.  There is some pride at what you have done and remorse at watching it go.

You wonder about the terms.  Is the valuation fair and the employment agreement reasonable?  What if we don’t like it? This is just the kind of thought to wake you up at night.  Multiple nights actually.  But if we we didn’t have any trepidations, odds are we wouldn’t have created something of any value in the first place.

The decision was grounded in one simple objective that we feel we can continue to meet as part of Avantica.  We started Open Mountain because we truly wanted to help start-ups and companies bring new products to market.  The energy of new projects is exhilarating.  The creativity from figuring what to do and how to do it, often starting from scratch, represents the most fun you can have on a project perhaps except for astronomical success.  That’s the way we see it and our experiences at start-ups like Ariba, Arbor Software and others represents some of the most fun and rewarding work we have done in our careers.

Over the last few years, we created a lot of products and technologies.  Open Mountain worked with clients to do interesting projects like the community we created for students preparing for college or the community we did for cancer survivors to share their experiences and connect with others.  We built a site that provides education around corporate benefits.  We worked on technology to support small business payroll and technology to provide up-to-date information to doctors. We worked on a site for CEOs to discuss the challenges they face with their peers.  We even did our own project to help consumers manage their home inventory and worked on a site to help consumers buy comfortable organic cotton products at a reasonable price.

Do you now see why we like this type of work over working on the same product for several years?  Man, this is a great job!  We definitely look forward to doing the same type of work on a larger scale as part of Avantica.

Thanks for supporting Open Mountain all these years,

Bob & Tom

You’d be surprised how many issues you can resolve over a good bottle of wine!

Our high-tech revolution has plunged us into a state of continuous partial attention.

iBrain by Gary Small, M.D. and Gigi Vorgan

- A typical Monday starts by pulling my canoe out into the various communication streams.  Logging on to Skype is the watershed event.

- Skype is running.  Firefox is open with tabs for email, calendar, several Google docs, WordPress for this post and YouTube for a side project I am working on.

- I check in with my lead on Skype.  I have the same guy across a few of my projects.  This certainly streamlines the communication.  He’s in Costa Rica.  When I worked at Adobe, we used IM all the time as people worked on different floors and at different locations.

- I am acting as the product owner for one project and I clarify something about a feature we are implementing.

- On another project, our client provides detailed specifications and we review the documents to make sure we are in sync.  We are, which is good.

The new promise of collaboration is that with peer production we will harness human skill, ingenuity, and intelligence more efficiently and effectively than anything we have witnessed previously.

WIKINOMICS by Don Tapscott and Anthony D. Williams

- Our newest client jumps on Skype to validate the release, our testing and the schedule.  There is a lot to discuss so we move to a Skype call. He does a good job managing his business to create an active and valuable community.

- Another issue comes in about how a feature should work that requires some thought.  I ignore chats and emails for the next 30 minutes and open specifications in Google docs and mock-ups in Preview.  We clarify the issue.

- By late morning, the major communications have been completed.  Projects are moving forward and our teams seem to understand what needs to happen this week.  I am responsible for a couple of releases that are in full swing.

No matter how clever the idea or great the implementation, an invention typically lives or dies depending on how well it can be integrated into a larger social or technological context.

Juice by Evan I. Schwartz

- The marketing text for our Web site update is long overdue.  Some tasks on the docket this week are for corporate business.  But I decide to focus on that side project and YouTube.

- I started a project called ReachGivers.org to help charities and non-profits get their message out over the Internet.  ReachGivers.org uses Ruby on Rails and has Twitter integration.  I added a poor man’s blog a while back as well.  This week I want to add video support.  Side projects help me stay connected with technology.

Economics is above all a science of measurement.  It comprises an extraordinarily powerful and flexible set of tools that can reliably assess a thicket of information to determine the effect of any one factor, or even the whole effect.

Freakonomics by Steven D. Levitt and Stephen J. Dubner

- Off to Starbucks for a Mocha and a blueberry scone.  This happens so often that people know me by name there.  The Ethos water billboard reminds me I wanted to blog about that on ReachGivers.org after finishing the video work.

- My brain stumbles on some concepts for the marketing text and I jot down some ideas.

- I was working on a product a while back and was not that impressed with the end user documentation.  I sent a book proposal out to a technology book publisher, which turned into a series of titles, and I have been writing every since.  I love it, I really do.  I even enjoy working on marketing text and ads.

Execution is not a one-time event.  Nor is it a process where you check off goals as if your sixth-grade teacher were looking over your shoulder.

The Art of the Start by Guy Kawasaki.

- Shorty before noon we get a curve ball. Mid-cycle, our client needs to shift direction on a project to change the prioritization and the release date.  I’ll spend the next few days updating user stories and validating the new plan. Sometimes I feel like we’re actually better at hitting a curve ball.

- The Agile software process, which is intended for flexible development, actually advocates against this type of mid-cycle change.  Release cycles are purposely shorter so that a direction shift simply influences the next cycle.  For start-ups, next month can be years away.  We have to be more flexible.

- A site we monitor generates an alert right before I can escape for lunch.  I used to get a little rush on these mini-emergencies like working as an EMT. Now I am the ambulance driver who knows that most pick-ups are not at all like the show ER.  Still, up-time is important and so we resolve the issue as quickly as possible.

- It occurs to me that this post demonstrates why people Tweet.  Expressing myself effectively with 140 character didn’t work well for me.  I decide to try it again because I am enjoying creating this running dialog.

- We’re trying to send large Photoshop files with mock-ups.  Some days technology just seems to work against us.  We’re hitting proxy issues and time out issues.  Eventually we solve the problem and remind ourselves yet again we should standardize on an approach.  Problem is, email and Skype are so convenient and work well enough most of the time.  I guess this would be one of those warts.

Agile software development methods should be able to survive in an atmosphere of constant change and still emerge with success.

Agile Management for Software Engineering by David J. Anderson

- After 40 plus years of eating sandwiches, I still love a good sandwich.  The best sandwich in town is from the deli in Vallergus and the people at the cash register all know me by sight.

- I never get back to the post after lunch.  Clients and partners all eat at different times and issues were waiting for me when I got back.  That is definitely a typical Monday.

- I didn’t finish the marketing text either.  The text I came up with was not remarkable.  I made some small updates to our corporate site instead and also finished my changes on ReachGivers.org.  Perhaps I will think of something while winding down for the night.

- My iPhone sits by my bed.  With several releases in play, there is always a chance a developer is still working and will fire off a question.  Of course, I can’t just let the device sit there, now can I?  I pull my canoe back out into the stream and see what else I might have missed during dinner.

How do you know for sure we are as integrated as we say?  Have a look at the photos below from some recent trips with us going to Costa Rica and our partner coming here.  Open Mountain and Avantica work well together because we make the effort to become familiar with each other.  We know the teams in Costa Rica and nearly everyone in the Avantica has been on one or more of our projects.

The leadership of our partner Avantica at the Golden Gate Bridge.

The Avantica team at Rubicon in Napa.

Open Mountain showing Avantica engineers one of the oldest wineries in Napa.

One of our newest clients meeting with Bob and the team in Costa Rica.

Where Bob and Tom stayed over the weekend in Costa Rica.

Avantica and Open Mountain enjoyed wine over lunch with this view of the vineyards.

After you look these over, you’ll have to tell us who visits the better location.  I do like my Costa Rican beaches and Imperial beer.  But how about the Golden Gate Bridge and wineries of Napa?  It’s a tough call that I am glad that I don’t have to make.

Thanks to all the travelers who donated images for this post! – Cheers.

We can’t discount the impact of having big name success in your company pedigree.  We see it all the time at Open Mountain as we work with start-ups and investors.  We had one prospect use the pedigree of advisers to a consultant he briefly hired in his pitch.  Sort of like his company hired the guy who dates the sister of the guy who walks Steve Job’s dog if you know what I mean.  Another case the person with the pedigree had joined one of the Internet giants after the battle had been won and during the time the business plateaued.   In both cases, we observed first hand that the viewing audience accepted the pedigree on face value.

Remember Webvan?  Webvan was one of the high flying companies of the first Internet boom that spent obscene billions on grocery delivery infrastructure only to go belly up at first sign of trouble.  Who would ever hire a person with that on their resume?  If you were to hire that person, the first thing he or she would tell you is don’t over build and make sure you have ways to reduce  costs during economic down turn.  That seems like really valuable advice to me.  If you hired someone who had been at Amazon, he or she might tell you to build like crazy and run up huge debt because it’s a land grab and we’re playing for keeps.  This is exactly what Amazon did and it certainly worked for them.  Which approach would be better for a start-up in today’s market?

Let’s dispel a few myths of our own.  With the exception of the leadership at the top, the job done by most people at say etoys, Webvan or uBid was not much different than the same people at eBay, Yahoo or Amazon.   There were plenty of good people at the first three companies just as surely as there were bad people at the success stories.  We tend to assume that everyone who worked at a runaway success was a home run hitter.  Yet we all know many great lessons are learned by failure.  Your experts need to know how to succeed for sure, but they also need to know how to avoid failure.

Here are 3 tips on how to get the best people and avoid the glossy eyed acceptance from talking to someone who worked at a runaway success story:

1) Don’t hire anyone who doesn’t have at least one significant failure they are willing to talk about.  The failure means they have learned.  The “talk about” part means they are being as honest as reasonably possible in the vetting process.  Here’s an interview tip.  After hearing about the failure, ask them for the name of someone else who also went through the failure with them that they still like. Then ask the candidate to describe their impressions of the themselves from perspective of the other person.  In an excellent interviewing class I had a while back, the teacher explained that the possibility you may actually know or contact the third person increases the chance your candidate will give you an honest answer.

2) Go rent season 4 of the TV show House.  In season 4, House is forced to build a a new team.  The process is entertaining but also valuable if you are interested in characteristics of a great team.  You should probably watch some of the earlier seasons so you understand the show.  House understands that to build the best team, you have to hire people who compliment your skills, who are not afraid of failure and who are willing to look for the best solution no matter the cost or process.  Most importantly, don’t just hire people who think like you if you want to benefit from the unique experiences of individuals with different points of view.

3) Hire people with great pedigrees in their past too!  Yes, I know the focus of this post was about how not to let pedigree cloud your thinking.  Simply put, experience matters and working with people who have done great work and achieved great success makes a difference.  My point is that you need to look beneath the surface and make sure the experience is real.  That is also the point of Eric Ries in his post.  He provides all the ways people with pedigree experience may not have earned that experience or learned from that experience.  I would suggest you review the post before the interview and do your best to determine if the person in front of you fits one of his profiles.

Any day of the week, I’ll take the person with substantial experience that includes brand names and failures over the person with only one great success story in their past.  I like to see some start-up experience, but I like that most when it is balanced with large company experience too.  After all, I’m not saving people’s lives like my good friend Dr. House, but I do want to have a team that can save a company in need and to do that they must know what to do when things don’t go as planned.

Ken described our leadership as “oversight services to ensure that all of the technical, architectural and operational aspects are synchronized.”  Mario Chaves, CEO of our development partner Avantica, described Open Mountain another way, “[Open Mountain] experts improve communication, refine requirements and ensure all parties work seamlessly as one integrated team.”  These explanations certainly help to clarify our duties.  Perhaps a metaphor might help explain things better?

Developing software is like shipping cargo

Developing software is like loading a ship with cargo and navigating calm or rough seas to get to a final destination on time.  The captain puts together his best crew hopefully using seamen he has worked with before.   The navigator is the architect planning the journey.  The helmsman is the lead engineer and has the best sense for how the ship is handling.  The crew maintains the engines, cargo and supplies.  The captain, of course, is in charge of the ship and crew.  Let me provide some examples of how this metaphor is useful.

I took over a project in trouble at a previous job and described the project like this.  The ship was on a trip from Hawaii to San Francisco and right now they’re half way to Alaska.  We need to make a hard right turn and we may lose some of the cargo and crew overboard to get there on time.  This translates to making some decisions to change the direction of the project and that may include changing the team and cutting features.

Prioritizing features is like loading cargo.  We need to be in San Francisco within 3 months and you still have cargo on the loading dock.  You need to make some decisions fast and get this ship going or we’ll have no chance to arrive on time.  Load the ship too full and the ship will travel slowly.  Let’s quickly decide what needs to be loaded and shove off.

Agile development is like using a small, fast ship.  The client need not decide all the cargo he wants right away because the ship will be back in a month to pick up the next load.  It’s easier to select some items to load on a ship returning soon than trying to decide the only cargo you can bring in one shot.  As you can see, shipping works quite well.

Engineering management is like being the captain on the ship

The job of engineering management is to act as the captain of the ship.  The captain’s first job is to get the ship underway.  He helps the client decide what cargo to bring while selecting the crew and loading supplies.  The captain reviews the plan with his navigator and helmsmen, and manages the team to get the ship to sea as quickly and efficiently as possible.

If your development leader is pushing you to decide what is in a release, that’s because he knows the decisions you make start the journey.  He still needs to navigate the boat out of the harbor and across the ocean.

A good captain watches the early part of the journey intensely to verify his decisions.  He makes sure everyone knows their job, that the course is clear and the weather is known.  Making major course corrections in the middle of the ocean is definitely more difficult.  He makes sure the cargo is tied down and the supplies are sufficient just to be sure.

The role of the crew is clear to the client.  The navigator did the navigation, the helmsmen steered, and so on.  But if you refer to my earlier comment about engineering management, the captain was in charge but the client can’t say for sure what he did unless he was on the ship or talks to the crew.

Most captains I know are fine with this.  If the cargo arrives on time, the client is happy.  A well managed crew walks off the ship content.  If a captain made good decisions early on and tracked progress with an experienced eye, then the job was well done and the cargo is on its way to the final destination.

Had enough of this metaphor yet?  How about one more time?

Weather is unpredictable

Like it or not, projects get in trouble despite the best laid plans.  You’ll find out the hard way if you have a good captain when this storm hits.  An ocean storm can loosen your cargo or create a leak in your hull.  At that moment, the captain is the only crew member not assigned to a specific task and this probably is not his first storm.

A good captain will know that the leak is the most serious.  He’ll make sure that the navigator and helmsmen have their marching orders and put his best men on the leak.  The rest of the crew will be assigned to battening down the cargo and doing other less critical tasks.

By having the knowledge and leadership from experience, and the freedom to asses and assign, the captain is in perfect position to restore order and get the ship under control until the storm clears.  Most captains will simply confirm for the client they hit the storm and apologize for the damaged cargo.  He might ask for an extra long furlough for the guys.  And that’s really how you know you have a good captain!

So you see, a good engineering manager will do his best to create a project that runs on schedule and without hitches.  He’ll work with the team to define the work and make sure the engineers understand what needs to happen.  Throughout development, the manager tracks the progress of the team validating his decisions just like the caption of a ship checking in with his navigator and crew.  If things go awry, the engineering manager is the one team member with the experience, bandwidth and responsibility to get the project under control and manage it through to completion.

Three rules for selecting a good captain

Here are a few guidelines for helping you assess if you have an experienced and reliable engineering manager:

1) Has he been to many destinations encountering different weather patterns and obstacles along the way?  Is he an experienced manager and can he describe projects that were challenging to manage to completion?

2) Does he know how to build a good crew and does he bond with them and treat them well?  What does the team say about him?  Do they respect his experience and leadership?

3) Is he familiar with the most common and reliable boats used for shipping?  Is he familiar with the latest technologies?

These guidelines should help you select the best engineering manager for your project.  If you can’t find a sea worthy captain, a good leader will work provided you pair him with an experienced navigator and helmsmen.

Whatever you do, don’t head out to see without a captain.  If the ship hits rough waters, someone is going to have to step away from the job they are doing to get the crew under control and he may not have the experience to get the ship to port with cargo and crew intact.

Here’s to calm waters and white sandy beaches!

The picture below shows our CTO Tom Johnson meeting with the Avantica team that we have working with us on the solution for our client Brightstorm. I actually know all these engineers from a previous project, my last role as a company VP, and specifically requested them to work with Open Mountain.

We tell all of our clients they should plan at least one visit because meeting directly with the team enhances the understanding of the work and leads to a better unified solution. Ironically, clients take that part almost for granted and often ask us about the country and what we have seen. So far we have enjoyed the active volcano at Arenal, the wildlife of the Monteverde reserve and the warm beaches of Tamarindo (pictured below) among other places. But there is still more of the country we would like to see.

I have to admit that I didn’t start down this path of near shore development to see an exotic land. I just happened to have a long time friendship and rewarding working relationship with someone from Costa Rica. Mario Chaves, Avantica’s CEO, and I worked together at many different companies and even went to the same college although we graduated different years.

The first time I worked with engineers from Avantica was at a small startup in the advertising space about 10 years ago. The lead was an engineer named Henry who is currently the Director of Development at Avantica. Henry is as smart as they come. I went to San Jose once to meet with him and the team. We spent the entire day collaborating on different aspects of the product.

I knew then that Henry and the team were up to speed on the latest technologies and as capable as teams I had worked with in the US. I could describe a problem and know by their questions and solutions that they understood the essence of the problem. That to me is the difference between true collaborative development and remote outsourcing. I want my team to have a stake in the product, to understand what problem we are solving, because that will drive the best result.

This last trip, as always, I stopped in to see my friend Henry. He was playing with a new Google Android phone and we caught up a bit. Henry is in the picture below along with some of the others we have worked with at Avantica.

Had I not had that first positive experience, I might not have centered Open Mountain around near shore development. I had high expectations based on my experiences as a US developer. Software developers work fast. We like to throw our ideas and brain storm. Some of the best product ideas come from engineers discussing a problem and shooting off on a tangent. This type of collaboration happened on my first trip to Costa Rica and has become a repeatable experience throughout the years working with the teams of Avantica.

I go back again and again to the country for the purpose of direct team interactions. But I’d be lying if I didn’t say that I also go to see one of the most beautiful countries in the world. After all, who would you rather be? The person reading this blog or someone in the photo below? How about both? Cheers!

Click the photo so see more pictures from our trip!