OpenCO 2013 – Why we love SF, how we work, and our world of content in 2023


OpenCo is the city’s answer to the question: “What makes San Francisco – San Francisco?” Instead of trying to explain the nuances to the culture here the founders of OpenCo decided the best way to describe it is by opening the doors to as many offices as possible within and allow people to come in and see for themselves. At OpenCo attendees sign up for a free pass to any of the over 100 SF offices, from theater troops, to restaurants, to tech startups and more. During the event attendees tour around the city walking into offices to check out their space and take part in an interactive presentation about what that company is doing to try to make an impact on the world. It’s not a lecture, nor a sales pitch, nor is it focused on recruiting, but instead it is a presentation that takes a look into what a company is thinking and how they work. Now expanding into NY, London, and Detroit, the OpenCo movement will be an exciting one for those interested in peeking into to the companies that make a city tick.

This year ShareThis was proud to be invited to host the second annual OpenCo event and we were excited to open their doors to their San Francisco office. There Sean Shadmand talked about the difficulties companies in the industry of social/tech are faced with and how they plan on innovating in the years to come. Check out a video of the presentation and slide decks below.

Video on Vimeo

Slides recorded by Penxy

What a company manifesto means to me and what I would expect it to accomplish

A Manifesto reveals the strengths and values within a company, and does so in a way that decreases the number of complex decision making hurdles for its employees in the day-to-day.

The manifesto will be “the bible” (though only a page) of reasons that lead a team without a need for individual leaders to be present, and can help create the next generation of leaders to form in the same vein.

It relieves people from the stresses and distractions inherent to complex (or seemingly complex) decisions, in the middle of the workday, while fighting in the trenches.Screen Shot 2013-05-14 at 12.22.05 PM

Picture this: A team of army rangers are falling back in the middle of an amazonian battlefield. They realize one of their platoon members went missing while under fire. What do they do? Unorganized soldiers may scatter under this pressure and lose their head. Should the next step be “Every man for themselves!”, or “Let’s hide it out until morning”? Luckily this group of rangers knows that there is one core value that prevails in situations like this: “never leave a soldier behind”. – Boom, decision made. They spend their time devising a plan to find him first and foremost  (no matter the hurdles – it will be resolved).

Values help form a strategy. Most importantly, when things go wrong, values help keep the bigger picture moving tactically. Especially when “fires” make decision making  difficult. Plans fail, but values do not.


bf3-jungle

More practically speaking, the battles on a tech company’s floor may be less tragic, but are battles nonetheless. Imagine there is a team developing a widget. It is done so with poor (if any) design, but  is backend-ready and functional. A discussion may come up around the pros and cons of deploying something that doesn’t look good but is ready to ship for testing. The debate could rage on, but, with a core manifesto that decision is already made: if the core value says design is key to our tests – then the decision is made to implement a design before deploying. If the core value says release when ready and iterate – again the decision is already made.

 

Those decisions shape a company and should not change week-to-week, problem-to-problem, or day-by-day from department to department. They shape outcomes and the character of a company through a decision tree that is easy to repeat. Consistent and efficient decision-making is more important than re-assessing the perfect decision for the situation each and every time it comes up. The written word is amazing at facilitating that.

 

Of course, we all have great thoughts and your company has awesome values already, but having them written down is the difference between an interesting legend shared by some and a religion followed by many.

Documentation, although necessary, does not substitute for a short list of values. Documentation is rarely re-read, and often forgotten; we remember “Go when green” not “Statute 32 Section 5: All those that use public road shall obey stop lights based on the following color …..”

Finally, it is extremely important that your list of values are glossed over. One lazy move away from following your values can easily turn into a utter mess over the years. That does not mean you can’t change your values. If a situation comes up, and your values does not represent how you want to act two things MUST happen: 1) You re-examine your values and change them accordingly or 2) You adjust the situation to fit your values. Period.

As for my suggestions regarding the setting for how a document can be built  as a team here are some thoughts.

 

  1. Make sure people feel heard (i.e. right down every idea)
  2. Help filter outlaws that promote restrictions (which end up being things people feel reprimanded for doing)  and turn them into the concept that create direction and productivity to help people grow, expand, and focus. It is a document of supportiveness.
  3. Use it to help give people clarity in situations that need tie breakers, or rules of thumb. For example, “future value does not trump current value” has saved our team from missing out on what we have while over planning for something we do not.
  4. Be clear on what an item suggested means when it is written (often times one person’s perspective on what “awareness” can be, for instance, is different than another’s) Be descriptive.
  5. Find a/the person that matches the essence of what a manifesto item describes. They will most likely be the champion of that thought and help keep it alive and well. Find the passion in the people and you will also find the strength in the doc.

I believe once the fundamental concepts are solidified into the manifesto it becomes a spine for current, and as importantly, new employees that come in so they can quickly latch onto and adopt the companies process/thinking as it expands in size.
There will be the debate over the items presented, and debate is good. As such, it may also be a good idea to nail down some keywords that keep the conversation on track to what we believe the manifesto points should adhere to.

The words I propose are:

  • positive
  • smooth
  • friendly
  • helpful
  • productive

If an item does not instill many of these words, for instance, then the item may be off track.

Efficiently Inefficient: Processes that can improve quality and quantity of life

For our latest project at Socialize Isaac and I are going to increase the release cycle even further and go from a few releases per group per week, to a few releases per day. I find moving more efficiently and quickly over the years always takes a few non-intuitive jarring mental steps. (If they didn’t we would have been way more efficient as a society way earlier on in history).

Here are a couple things that always seem to be the foundation of inching your way up the efficiency hill.

1) Get to a point at which you truly trust your results, not just feel good or secure about them, but quantitative based results that have a quantitative “I trust this” number. This is what I call the “don’t look over your shoulder moment”, because if you’re looking over your shoulder to make sure nothing has gone wrong, you are not looking forward to make sure new things go right. This accomplished with unit/itests tests, or in our everyday lives marking your calendar or adding a reminder. Even at managing people in the office, time and time again setting up employees to be trusted and autonomous, with a simple audit system to make you aware only if something is wrong, has proven time and time again to produce happier, more creative, more productive employees in a company that can scale. Basically every one wins big when you make sure you create process that handles things that are set to let you know if you need to take action, and quite %100 otherwise.

2) Really reconsider what you’re are willing to bare in mistakes. This is usually a major brain switch moment. Sometimes people can work 100x more efficiently and productively if they just allow themselves to be wrong for a totally fixable 1 minute per year. Yes your server may go down once a year, but instead of working hard to make sure that never happens (which is impossible), work hard to make sure systems are in place to recover super quickly. The funny thing is when you accomplish #1 above, mixed with this #2 item, you start performing better than you could have imagined.

3) Remove process that is there to support the more intuitive faux “warm and fuzzy” feelings that keep 1 and 2 from happening.

4) Always push yourself, and those around you, to test process that offer efficiency gains even if you don’t feel comfortable at first. Comfort is often the foundation of slowness, and trying new things even against your “better judgement” are the only ways to break free.

 

For you nerds out there, here is the article from github Isaac passed on to me that sparked our latest evolution in product releases. Although this post and its sentiment are, in my book, universal throughout life and business and not code.

http://scottchacon.com/2011/08/31/github-flow.html

Deciding on a new feature: An Insta-Test-market. (AKA: Ghetto Testing)

I love making a decisions tree as efficnet as possible, especial around discussion that steer the business or the product within a business. Or in another words, I HATE “tough decisions.”

Here is another addition to the decision tree to make life easier, it is called “Ghetto Testing” and coined by the founder of Zenga.

How do you figure out if you should go with a feature with minmal disruption to the company or its engineers, and how can you invest in it with the highest posible certainty of success? Ghetto Testing a feature. The concept is there are a wide range of data points you can aquire to guage interest on an idea before the idea is fleshed out. At the “Ghetto” stage, it sint so much a test of the product value or feature set itself, as much of a servey to see if the concept will get clicks or interest by the public. It’s basically an adhoc test market. If you think people will love feature x for instance, create a google adword promoting the vapor-ware concept and run it for 5,10,30 mins.  The resulting page of the ad could technically go to a 404 page, and although that would be a horrible experience it still wouldbe a valid ghetto test.

From there you can invest incrementally into how deep of a gauge you want to testing of the idea i.e. a pretty landing page with feature highlights, a download, or a purchase wall.

http://grattisfaction.com/2010/01/how-zynga-does-customer-development-minimum-viable-product/

 

“Should I add x to my product line?” litmus test

For small startups it is essential to decide what not to do as much as what you decide *to* do. As new technologies come and go, ideas for change could cripple a companies productivity or ability to reach any single objective (AKA Distractions.)

If your objective is to build an awesome product, and work hard at solving a problem that others may not have been able to solve yet, then here is a “is this a distraction right now, or a need for change?”  litmus test for small startups.

Test:

Do I believe we should *only* do [new idea] and grow the company out from from there?

(i.e. stop focusing on the other thing you had previsouly decided was *the* way to grow the company from.)

If you find yourself getting to a strong yes, then the convo to get into the new idea may be ripe for discussion, and it may be time to focus energy on a new strategy and to pool your resources to build a world class product. I’ll go into what you can do to break the new idea down further from there, to see if it makes sense in your business in other ways, in later blogs.

Side notes as to why this problem may often come about:

For one, the grass is always greener. So you need to be carefull when shifting towards an idea that is not on your mind every hour of every day…There will often be different problems, not less, to overcome when you switch.

Second is brain time. The amount you spend on solving a problem has some (not sure yet what amount yet) relation on the lack of time you have spent thinking about the new thing. All the litte details that are reflex knowladge for you for is lost with a new idea and direction.

Analogous Exmaples in life:

For a simplified abstract example, you spend a few hours packing the night before a trip. Last minute the morning of the flight you realize, “Hey, I can just take the smaller bag! How much smarter of me, I can save much space!” So you do.

At the airport you realize that one of the side reasons you wanted the bigger bag was not just to carry more, but to so your friend could but his shoes in it. Damn! You over looked ne of the many small details that led to the dscisoin to pack the big bag in the first place, but the new idea that came to mind, that you took action on in a shorter amount of time, did not allow you to consider all the many reasons why you made the decisions you did the night before.

A more common example: “Ughhh, I left my wallet in my other pants pocket!” You look better, and it’s a good thing too because now you need to find someone to pay for your dinner :p

Closing

You may not be able to avoid these smaller mishaps, but you definitely have the power to minimize disrupting a company by paying attention to these business distractions vs changing directions type decision points.

Remember: A small comapany needsto solve *a* problem, focus on it, and when they get their fit and a few wins the grow into more spaces. Here is a great article on focus as it pertains to Product Market Fit and MVP:

http://www.svproduct.com/mvp-vs-product-vision/

“…But of course that was just the beginning of the product line and not the end.”

 

"Should I add x to my product line?" litmus test

For small startups it is essential to decide what not to do as much as what you decide *to* do. As new technologies come and go, ideas for change could cripple a companies productivity or ability to reach any single objective (AKA Distractions.)

If your objective is to build an awesome product, and work hard at solving a problem that others may not have been able to solve yet, then here is a “is this a distraction right now, or a need for change?”  litmus test for small startups.

Test:

Do I believe we should *only* do [new idea] and grow the company out from from there?

(i.e. stop focusing on the other thing you had previsouly decided was *the* way to grow the company from.)

If you find yourself getting to a strong yes, then the convo to get into the new idea may be ripe for discussion, and it may be time to focus energy on a new strategy and to pool your resources to build a world class product. I’ll go into what you can do to break the new idea down further from there, to see if it makes sense in your business in other ways, in later blogs.

Side notes as to why this problem may often come about:

For one, the grass is always greener. So you need to be carefull when shifting towards an idea that is not on your mind every hour of every day…There will often be different problems, not less, to overcome when you switch.

Second is brain time. The amount you spend on solving a problem has some (not sure yet what amount yet) relation on the lack of time you have spent thinking about the new thing. All the litte details that are reflex knowladge for you for is lost with a new idea and direction.

Analogous Exmaples in life:

For a simplified abstract example, you spend a few hours packing the night before a trip. Last minute the morning of the flight you realize, “Hey, I can just take the smaller bag! How much smarter of me, I can save much space!” So you do.

At the airport you realize that one of the side reasons you wanted the bigger bag was not just to carry more, but to so your friend could but his shoes in it. Damn! You over looked ne of the many small details that led to the dscisoin to pack the big bag in the first place, but the new idea that came to mind, that you took action on in a shorter amount of time, did not allow you to consider all the many reasons why you made the decisions you did the night before.

A more common example: “Ughhh, I left my wallet in my other pants pocket!” You look better, and it’s a good thing too because now you need to find someone to pay for your dinner :p

Closing

You may not be able to avoid these smaller mishaps, but you definitely have the power to minimize disrupting a company by paying attention to these business distractions vs changing directions type decision points.

Remember: A small comapany needsto solve *a* problem, focus on it, and when they get their fit and a few wins the grow into more spaces. Here is a great article on focus as it pertains to Product Market Fit and MVP:

http://www.svproduct.com/mvp-vs-product-vision/

“…But of course that was just the beginning of the product line and not the end.”

 

Short Cycle Scrum: A leaner, meaner, scrum.

Here is a summary of how we implemented a leaner, more efficient Scrum at Socialize coined Short-Cycle-Scrum. We have added some rules of thumb, and processes around ou Scrum to deliver stories with a surprisingly good amount of efficiency. This is a style we have specially tuned for short sprints (usually one week.)

Short Sprints Cycles
Sprint plaanning meetings can go long. They should definitely go as long as the need to, but no longer. One of the main reasons to have a sprint planning meeting at the beginning of yur sprint with the whole projects team members is that having a system that relies on having meetings throughout the week are like death by a million paper cuts for each developers time. Many times, those metings throughout the week are unfocused, not involving all the members of the team needed, and breaks up a developers day. most likley one devlopers need for a quick meeting means another developers inability to focus on delivering their story. So, with a single, team wide, sprint planning meeting you take care of all the discussions scheduled for your sprint as a team, all at once, when every one is in “meeting mode”. The goal is to get as many questions out of the way as possible. By the end of the meeting all your developers should be confident enough to solve their own questions or problems, as much as they can, throughout the sprint. If your sprints are short enough, and your stories are as atomic as possible, your devs will never truly implement something so wrong, due to a quick judgement call, that can truly ruin your the product. They must make judgement calls on their own to get the story delivered, this will get features out, allow for interative improvements, and avoid analysis paralysis.

A good rule of thumb is: If you can’t do it in a week (or your sprint’s time span), it is a sign that the story should be smaller. This takes a little convivcing when going over new features or stories with your team, but for us, even if at first it does not seems so, it ends up being the case time after time.

This and Next Sprint Need Only Apply

Another way we have made our planning meetings even more efficient is by asking the team to only address issues in terms of “this sprint” or the “next sprint”, every other situation can wait. People have a tendancy to use planning meetings, their PM tool, and stories to “remember” things that are”needed”. We have found that things that are truly needed are rarely forgotten and adding them to the plan do nothing more then create noise. If the concept or feature will take more than 1 sprint or is something that needs to be done, or done at a later sprint, then create a thread or discussion abut it, but do not take up sprint planning time, or your queue with it.

Asynchronicity and Simplicity

Using sharable threads (for us we use basecamp) for asynchronous conversations helps us hash out discussions, and preserve the sprints for only things that are ready, or close to being ready, for implementation. This helps your team sperate planninng and ideas, from implementation and delivery. A good tip for a synchronouse discussions is to make sure new threads are created for new topics and that the title of the thread is the topic to close and focus on. Again, only after there is a clear concept formulated and ready/need to be implemented in tis or the next sprint, should it be added the icebox or queue.

Planning Meeting Agenda

So how do we set up the agenda for the next sprint so we know what to talk about? We create a sharable doc that devs can add the link to a story they want to delve into, or they want moved from the ice box into the backlog or sprint. Again, only things that need to go into the next sprint are added here. At the sprint planning meeting we go over the sprint we are starting, and maybe a few stories into the backlog, just incase we have a high velocity week, and then links added to the sprint planning doc. This keeps the sprint plannig meeting tight and focused and works very well for short sprints.

Tools

We use pivotal tracker and google docs to manage all this, and base camp for discussions and group notifications. I will go more into the use of these tools in subsequent posts.

Summary

The main take sways: if it is not for now then it does not exists in the panning world. And discussions together things onto the planning world should be as asynchronous as possible. Finally, completely sperate high goals with systems that are used for accomplishing the next step.

My greatest life lessons from Computer Science

I really appreciate  my education in Computer Science. The most valuable mental shift I gained was the understanding that there are no “hard problems.” To recognize that even extremely difficult problems were easily solved once you were able to deconstruct them into smaller more simple ones. Problem-solving is about figuring out how to simplify, dismantle, and rebuild toward solutions. Simplifying is all about getting good and asking the right questions.

For instance, playing the guitar is hard, playing chords with rhythm is easier, playing chords is even easier, playing a note is more easy – and so on and so forth.

Just breakdown what you want to accomplish and get great at each little piece of it. Then, get great at putting each individual piece together and your problem isn’t all that bad.