Building the Best Software Services, can you find the secret guild?

I have been the bay area for the past two weeks for business meetings before I head back to Redmond.  Actually haven’t been here for two weeks straight, taking two trips.  I’ve lived for 22 years in Redmond, and before that spent 32 years in Silicon Valley.  I go back and forth often enough that I have an office space in both locations.  How Silicon Valley works is different than Seattle/Redmond, but there is a common trait.  The guys who belong to the secret guild of low level programmers who can build services that scale and run like an energizer bunny.  Working on OS at Apple and Microsoft got me used to working with the developers who belong to the secret guild.

What is the secret guild?  Here is a post that tells the story.

the secret guild of silicon valley

A couple of weeks ago, I was drinking beer in San Francisco with friends when someone quipped:

"You have too many hipsters, you won’t scale like that. Hire some fat guys who know C++." 

It’s funny, but it got me thinking.  Who are the “fat guys who know C++”, or as someone else put it, “the guys with neckbeards, who keep Google’s servers running”? And why is it that if you encounter one, it’s like pulling on a thread, and they all seem to know each other?

The reason is because the top engineers in Silicon Valley, whether they realize it or not, are part of a secret Guild.  They are a confraternity of craftsmen who share a set of traits:

...

Read the post to get the rest of story.

For those of you too lazy to click on the link, here is the closing paragraphs.

Finally, the implicit compact that the Guild makes with a company is that their efforts will not be in vain.  The most powerfully attractive force for the Guild is the promise of building a product that will get into the happy hands of hundreds, thousands, or millions.  This is the coveted currency that even companies that have struggled to build an engineering reputation, like foursquare, can offer. 

The Guild of Silicon Valley is largely invisible, but their affiliations have determined the rise and fall of technology giants.  The start-ups who recognize the unsung talents of its members today will be tomorrow’s success stories.

The Power of Visual/Spatial Thinkers, Temple Grandin's Story

I’ve written a few posts on the importance of Visual/Spatial Thinking.

Do you think Spatially? A neglected skill is becoming a hot talent

Journal Entry by Dave Ohara on October 5, 2013

HBR has a post on Spatial Thinking. The Importance of Spatial Thinking Now by Kirk Goldsberry  |   1:00 PM September 30, 2013 Comments (31)                           …

Problems with adding Supply Chain people, thinking like procurement instead of spatialintelligence

Journal Entry by Dave Ohara on August 4, 2013

How many of you are frustrated with your purchasing department?  I had a short stint at Apple in the Purchasing group.  The purchasing group had a staff of technical project managers who would work with the product development teams on peripherals for Apple products.  During this time is when I got …

Are Spatial Skills one of the under valued skills of a data center engineer?

Journal Entry by Dave Ohara on October 9, 2012

Designing a data center is a skill that you don’t go to school for and learn from a book.  Book learning works for math, science, english and of course reading. So, what kind of skill is needed to design a data center.  One of the challenges is trade-off of getting things just right to reduce or eli …

I”ve watched Temple Grandin’s Ted Video.

But, it took the movie on Temple Grandin to understand Temple Grandin’s story and what she went through to develop her skills.  Here is a behind the scenes movie that gives you some of the feelings behind the movie.

Some good lessons from Pixar CEO, Ed Cutmull

I just got the book Creativity Inc to read which is the story of developing Creativity at Pixar by the CEO Ed Catmull.

From Ed Catmull, co-founder (with Steve Jobs and John Lasseter) of Pixar Animation Studios, comes an incisive book about creativity in business—sure to appeal to readers of Daniel Pink, Tom Peters, and Chip and Dan Heath.

Creativity, Inc. is a book for managers who want to lead their employees to new heights, a manual for anyone who strives for originality, and the first-ever, all-access trip into the nerve center of Pixar Animation—into the meetings, postmortems, and “Braintrust” sessions where some of the most successful films in history are made. It is, at heart, a book about how to build a creative culture—but it is also, as Pixar co-founder and president Ed Catmull writes, “an expression of the ideas that I believe make the best in us possible.”

WSJ wrote a review with some good lessons.

Here is a good one on why many technologies fail.  The technology is not embraced by the users.

Recruited in 1979 by George Lucas to help work special-effects images into live-action footage, Mr. Catmull, who had studied computer graphics in graduate school, soon found himself up against a problem that would yield one of his early lessons. The film editors at Lucasfilm resisted working with a computer. They didn't think it would do much more than what could already be done by snipping filmstrips with razor blades and gluing them together. The editors didn't realize that, for a new level of creativity to happen, they would have to embrace change. Relatedly, Mr. Catmull realized that a transformative idea, no matter how good, was useless unless the people who had to implement it fully embraced the concept.

Do you have good project stories to tell? Most likely not

I have been studying storytelling, trying to figure out how stories can be used to better communicate.  Here is a Pixar story during the production of Toy Story 2 they lost all the files when a command was run to delete files mistakenly.

The above video was posted on June 30, 2011.    The next web posted a story of the Toy Story 2 files deleted May 12, 2012 that goes into more detail.

When listening to this story it reminds me of the Back-up Disaster that killer the Sidekick.  The Toy Story 2 story had a better message.

“I’ll never forget ever being a part of Toy Story two. I was very lucky,” says Jacob. “I had that chance to work on a level of impact that helped keep Buzz and Woody, and “Toy Story” and the franchise, and Pixar all be a thing we talk about today.”

...

The thing about  a disaster like this one is that the technical directors and staff at Pixar had to trust one another to fix the issue, even though there were several mistakes made and one of them was responsible. “If you can’t sit down and calmly engage that meeting, you can’t be in that meeting with them,” says Jacob. ”Because the circumstances were so incredibly unusual. Black Swan events do occur.”

Instead of dwelling on pinning the blame or lamenting the loss of time and effort, the team made sure to alter the backup strategy so that something like that didn’t happen again, and it went about making up for lost time.

How many IT/DC problems are caused by the mindset of Repairing vs. Fixing the problem

The wise can see the difference between repairing a problem and fixing a problem.  A repair is many times temporary whereas a fix can take more time, resources, and money.

Here is a story about a simple problem of transporting a crane across a bridge.  When I read this story it reminds of the problems when people don’t understand the difference between a repairing vs. fixing a problem.

The story begins with a company that makes very large and very heavy pieces of equipment. 

They had a special order for an especially large piece of equipment. They completed the piece of equipment and got it ready to ship to the client. In order to ship it to the client it had to pass over a bridge that was located very close to the plant where the piece of equipment was built. 

As the piece of equipment was passing over the bridge, the bridge collapsed and the huge piece of equipment fell into the river. The company quickly went into action and rented a crane that was used to extricate the piece of equipment from the river and place it safely on the plant side of the bridge. 

The city which owned the bridge quickly went into action building a new bridge relying on the assumed knowledge that the company would never try to go over the bridge with another piece of equipment that weighed so much.

...

Click this link to read the whole story.