RSS Feed

‘Process’ Category

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

    May 14, 2013 by sshadmand

    Screen Shot 2013-05-14 at 12.22.05 PM

    When creating a Manifesto for your company the goal  not to “create a manifesto” but to reveal the strengths of the values within the company in a way that decreases the number of complex decisions needing to be made day-to-day.

    The manifesto will be “the book” (more or less a page) of reason that can lead a team without the need for specific leaders to be present (and even help prep the next generation of leaders to form in the same vein.)

    It relieves people of the stresses and distractions of complex (or seemingly complex) decisions while in the middle of the workday, 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 battle field. They realize one of their platoon members went missing while under fire. What do they do? Less organized soldiers would scatter under this pressure and lose their head. Should it be “Every man for themselves!”, or “Let’s hide it out until morning”. Luckily this group of rangers know 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) and work out the other tangentials for the mission based on that ad-hoc plan.

     

    Values are great and help create strategy, but as importantly when things go wrong values help keep the bigger picture moving along even when the current battles make that difficult to understand. Plans fail, but values do not.


     bf3-jungle

    More practically speaking the battles on a tech companies floor are less tragic, but battles nonetheless. Imagine a moment where a poorly designed widget is backend-ready and functional. The discussion comes 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 and the time is spent planning on executing that value; if the core value says release when ready and iterate – again the decision is 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.

     

    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 out laws that promote restrictions (which end up being things people feel reprimanded for doing)  and turn them into 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 manifiesto item describes. They will most likely be the champion of that thought and help keep it alive and well. Find 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 debate over the items presented, and debate is good. As such, it may also be a good idea to nail down some key words 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.

    Category Business, featured, Philosophy, Process, Style | Tags: | No Comments

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

    September 5, 2012 by sshadmand

    rube

    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

    Category Code, Feature Tech, learning, Philosophy, Process, Technology | Tags: ,,,,, | No Comments

  3. What does coke, the bible, and good business gut all have in common?

    June 19, 2012 by sshadmand

    gut

    On the car ride up from a meeting on sand hill, Daniel Odio interviews me in “the hot seat” on how process plays a pivotal role in your startup’s business success.

    Category Business, Feature Concepts, featured, Philosophy, Process | Tags: ,,,,, | 2 Comments

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

    December 8, 2011 by sshadmand

    images (1)

    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/

     

    Category Business, Feature Concepts, learning, Philosophy, Process, Technology | Tags: | No Comments

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

    December 8, 2011 by sshadmand

    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.”

     

    Category Business, Philosophy, Process, Technology | Tags: | No Comments

  6. Short Cycle Scrum: A leaner, meaner, scrum.

    August 14, 2011 by sshadmand

    Scrum_256x256

    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.

    Category Process, Technology | Tags: ,,, | 2 Comments