$30 off During Our Annual Pro Sale. View Details »

Breaking down silos

Breaking down silos

My Tech4Africa 2011 talk on collaborative software development.

Rian van der Merwe

October 27, 2011
Tweet

More Decks by Rian van der Merwe

Other Decks in Design

Transcript

  1. Rian van der Merwe
    twitter: @RianVDM
    web: elezea.com
    Breaking down silos
    Building better software through
    collaboration

    View Slide

  2. Siloed software development
    Isolation
    Lonely silos Functional silos

    View Slide

  3. Today’s topics
    What are the consequences of lonely silo development?
    What are the consequences of functional silo development?
    How can we do it better through collaboration?

    View Slide

  4. Today’s topics
    What are the consequences of lonely silo development?
    What are the consequences of functional silo development?
    How can we do it better through collaboration?

    View Slide

  5. The idea of minimum viable product is useful
    because you can basically say: our vision is to
    build a product that solves this core problem
    for customers.
    So, the minimum viable product is that
    product which has just those features (and no
    more) that allows you to ship a product that
    resonates with early adopters; some of whom
    will pay you money or give you feedback.
    Lonely silos

    - Eric Reis
    1. MVP madness

    View Slide

  6. Lonely silos
    1. MVP madness

    View Slide

  7. Lonely silos
    1. MVP madness
    [Color founder Bill Nguyen]
    outlined an ambitious plan to
    compete with Apple, Google
    and Facebook by tying
    together group messaging,
    recommendations and local
    search, all while making
    money through advertising.
    http://www.nytimes.com/2011/06/20/technology/20color.html

    View Slide

  8. Lonely silos
    1. MVP madness

    View Slide

  9. View Slide

  10. Lonely silos
    1. MVP madness 2. No significant design focus

    View Slide

  11. Lonely silos
    1. MVP madness 2. No significant design focus

    View Slide

  12. Lonely silos
    1. MVP madness 2. No significant design focus

    View Slide

  13. The floor of Silicon Valley is
    littered with the crumbling husks
    of great ideas—useful products
    and services that died in the shell
    before they hatched out of their
    impenetrable engineering-
    specified interfaces.

    - Erika Hall (Mule Design)
    Lonely silos
    1. MVP madness 2. No significant design focus

    View Slide

  14. Lonely silos
    1. MVP madness 3. Endless cycles
    2. No significant design focus
    “Are we done yet?”
    “Maybe.”

    View Slide

  15. Lonely silos
    1. MVP madness 3. Endless cycles
    2. No significant design focus
    Wave is a case in point. Wave started with some
    fairly easy to understand ideas about online
    collaboration and communication. But in order to
    make it more general and universal, more ideas
    were added until the entire thing could only be
    explained in a 90 minute mind blowing demo that
    left people speechless but a little later wondering
    what the hell this was for.

    - Douwe Osinga

    View Slide

  16. Today’s topics
    What are the consequences of lonely silo development?
    What are the consequences of functional silo development?
    How can we do it better through collaboration?

    View Slide

  17. Functional silos
    Global  Header  team  
    Daily  Deal  
    team  
    Marke2ng  
    Finding  
    team  
    Merchandising  
    team  
    Product!  
    1. Org structure design

    View Slide

  18. Functional silos
    1. Org structure design

    View Slide

  19. Functional silos
    Global  Header  team  
    Daily  Deal  
    team  
    Marke2ng  
    Finding  
    team  
    Merchandising  
    team  
    Product!  
    Umm…  no  one?  
    1. Org structure design

    View Slide

  20. Functional silos
    It needs to be a little more Web 2.0!
    The font should definitely change back to Comic Sans
    2. Design monkeys
    1. Org structure design

    View Slide

  21. Functional silos
    2. Design monkeys
    1. Org structure design 3. Tired developers

    View Slide

  22. Functional silos
    “Hmm, this is a non-trivial problem.” *
    Since no engineer is going to admit something is
    impossible, they use this word instead. When an
    engineer says something is "non-trivial," it's the
    equivalent of an airline pilot calmly telling you that
    you might encounter "just a bit of turbulence" as he
    flies you into a category 5 hurricane.
    - Charles Miller
    *
    2. Design monkeys
    1. Org structure design 3. Tired developers

    View Slide

  23. 2. Design monkeys
    Functional silos
    1. Org structure design 3. Tired developers 4. Design by committee
    First rule of design feedback: what you’re
    looking at is not art. It’s not even close. It’s a
    business tool in the making and should be
    looked at objectively like any other business
    tool you work with. The right question is not,
    “Do I like it?” but “Does this meet our goals?”
    If it’s blue, don’t ask yourself whether you like
    blue. Ask yourself if blue is going to help you
    sell sprockets. Better yet: ask your design
    team. You just wrote your first feedback
    question.

    - Mike Monteiro

    View Slide

  24. The sensible
    answer is to listen,
    absorb, discuss, be
    able to defend any
    design decision
    with clarity and
    reason, know
    when to pick your
    battles and know
    when to let go.
    Respond to every piece of feedback
    Note what feedback is being incorporated
    Explain why feedback is not being taken
    Use the UX validation stack
    Functional silos
    2. Design monkeys
    1. Org structure design 3. Tired developers 4. Design by committee

    View Slide

  25. The user experience validation stack
    http://www.uxbooth.com/blog/winning-a-user-experience-debate/

    View Slide

  26. Today’s topics
    What are the consequences of lonely silo development?
    What are the consequences of functional silo development?
    How can we do it better through collaboration?

    View Slide

  27. 1. Make sure everyone
    understands
    the problem
    Collaborative software development

    View Slide

  28. Many senior leaders recognize the silo
    problem, but they solve it the wrong way: if
    one hierarchical approach to organizing
    their business doesn’t work, try another
    hierarchy. Don’t like the old silos? Create
    new ones. This dark tunnel leads to an
    even darker pit: the dreaded — and often
    horrifically ineffective — reorg.
    - Louis Rosenfeld
    Collaborative software development

    View Slide

  29. 2. Empower teams to do
    great work
    Collaborative software development

    View Slide

  30. Maker

    View Slide

  31. Manager

    View Slide

  32. Collaborative software development
    The Maker’s Schedule
    When you're operating on the maker's
    schedule, meetings are a disaster. A single
    meeting can blow a whole afternoon, by
    breaking it into two pieces each too small to
    do anything hard in. Plus you have to
    remember to go to the meeting. That's no
    problem for someone on the manager's
    schedule. There's always something coming
    on the next hour; the only question is what.
    But when someone on the maker's schedule
    has a meeting, they have to think about it.
    - Paul Graham

    View Slide

  33. Collaborative software development
    Chasing the Two Highs
    When the nerd sees a knot, they want to unravel it.
    Complete knot domination
    Chasing the Second High is where nerds earn their
    salary. If the First High is the joy of understanding,
    the Second High is the act of creation.
    If you want your nerd to rock your world by building
    something revolutionary, you want them chasing the
    Second High.
    1
    2

    (From “Managing Nerds” by Michael Lopp)

    View Slide

  34. Collaborative software development
    How to help your nerd achieve the Second High
    Obsessively protect both your nerd’s time and space.
    The almost-constant quest of the nerd is
    managing all the crap that is preventing them
    from entering the Zone as they search for the
    Highs.
    Every single second you allow a nerd to
    remain in the Zone is a second where
    something miraculous can occur.
    1
    2

    View Slide

  35. Collaborative software development
    Start with two questions
    What is missing from your environment?
    How can we improve our culture?
    1
    2
    (tip: start with meetings and email)

    View Slide

  36. Collaborative software development
    [As] a programmer you must have a series of
    wins, every single day. It is the Deus Ex
    Machina of hacker success. It is what makes
    you eager for the next feature, and the next
    after that. And a large team is poison to small
    wins. The nature of large teams is such that
    even when you do have wins, they come after
    long, tiresome and disproportionately many
    hurdles. And this takes all the wind out of
    them. Often when I shipped a feature it felt
    more like relief than euphoria.
    - Dhanji R. Prasanna

    View Slide

  37. Collaborative software development
    A final note on developers
    Resource Person

    View Slide

  38. 3. Create a better design
    and development
    cycle
    (or, everyone gets a voice)
    Collaborative software development

    View Slide

  39. They are the developers who can design
    enough to appreciate what good design
    can do for their product even if it
    sometimes means having to deviate from
    the framework and put a little extra
    effort into customizing certain
    functionality.
    images: http://bit.ly/war-developers
    And they are the designers who learn how
    to think like a programmer when they
    design and develop an aesthetic that is
    better suited to deconstruction rather
    than composition.
    - Thomas Petersen

    View Slide

  40. Collaborative software development
    Two more questions
    How would you like to contribute to the
    product development process?
    What information do you need to start
    coding?
    1
    2

    View Slide

  41. Collaborative software development
    The goal:
    Right-fidelity specifications

    View Slide

  42. Collaborative software development
    Great idea
    Product Council
    (Intergalactic Product Force?)
    High-level
    prioritisation
    Product Manager
    ownership
    CEO
    CTO
    Head of Product
    Engineering Manager
    Head of Merchandising
    Head of Marketing
    Support Manager
    Head of Finance

    View Slide

  43. Collaborative software development
    Nothing is what happens when
    everyone has to agree.
    - Seth Godin

    View Slide

  44. Collaborative software development
    Product should be a dictatorship, not
    consensus-driven. There are casualties,
    hurt feelings, angry users. But all of those
    things are necessary if you’re going to
    create something unique. The iPhone is
    clearly a vision of a single core team, or
    maybe even one man. It happened to be a
    good dream, and that device now
    dominates mobile culture. But it’s
    extremely unlikely Apple would have ever
    built it if they conducted lots of focus
    groups and customer outreach first. No
    keyboard? Please.
    - Michael Arrington

    On the one extreme
    (and I don’t agree completely with this statement):

    View Slide

  45. The Product Manager
    is
    The Decider

    View Slide

  46. To deliver measurable business
    results through product
    solutions that meet both market
    needs and company goals.

    View Slide

  47. Product
    Planning
    Product
    Marketing
    Strategic Product
    Management

    View Slide

  48. Collaborative software development
    Product
    Manager
    Developer
    Visual
    Designer
    UX Research
    Interaction
    Designer
    Content
    Strategist
    Developers

    View Slide

  49. 4. Document thoroughly
    Communicate widely
    Collaborative software development

    View Slide

  50. Collaborative software development
    Roles and responsibilities
    Roadmap and Prioritization process
    Product development process
    Goals and success metrics
    Talk to people about:
    1
    2
    3
    4

    View Slide

  51. View Slide

  52. Publish everywhere, invite anyone

    View Slide

  53. 5. Prove that it works
    Collaborative software development

    View Slide

  54. Collaborative software development
    Share case studies
    Define a project to improve:
    Acquisition | Activation | Activity
    Benchmark and set goals
    Measure religiously
    Publish results, and don’t hide the failures
    Show how your efforts are making a difference
    1
    2
    3
    4
    5

    View Slide

  55. Collaborative software development

    View Slide

  56. In summary
    What are the consequences of siloed development?
    Low quality software
    Less money
    How can collaborative software development be encouraged?
    Build the right environment
    Create the right amount of process
    Identify the decision makers
    Be as open as possible

    View Slide

  57. Rian van der Merwe
    twitter: @RianVDM
    web: elezea.com
    Breaking down silos
    Building better software through
    collaboration

    View Slide