Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Use spacebar or arrow keys to navigate, 'esc' for overview

Management - chaos and countermeasures

Johannes Mainusch / @docjoe

Use spacebar or arrow keys to navigate, 'esc' for overview


Because I learned a lot as IT-Manager in different companies and I like to improve the world, I like to help to change things for the better, I am very critical of conservative management in this rapidly changing IT-world, I observe, analyze and describe problems, I like to find creative solutions and I like to share, what I have learned so far...

chaos, complex, complicated and simple things

  • Simple: easy to understand
  • Complicated: understandable, brain hurts
  • Complex: not fully deterministic, but reasonably predictable.
  • Chaotic: neither deterministic nor predictable.

  • search wikipedia for stacey matrix or cynefin framework.
    I read it once, but it did not fully convince me...

    chaos & resonance catastropy

    I think, we are living in a chaotic ocean with islands of relative stability. Resonance catastropy happens, when a complex system has absorbed too much energy and needs to ged rid of it somehow...
    example: Tacoma Narrows Bridge Collapse
    The ideal world
    • Teams of decent size,
    •    something like 6-Dev, 1 QA,
    •    some OPS, Product and UX
    •    plus SM and Team Architect...
    • defined company values and goals
    • an innovation programme
    • management with verve and dedication
    vertical user recommend purchase search
    actually a team could host N verticals

    know and provide
    what users want

    if you have an UX-Team, at least you might not be toast!

    a product
    that is easily adaptable

    a minimum viable product has just those core features that allow the product to be *deployed* and no more

    Teams that strive
    to become better each day

    Teams of decent size, something like 6-Dev, 1 QA, some OPS, Product and UX plus SM and Team Architect...

    that is easily changeable

    Software Architecture Prime Directive:
    The ability to change the software (the product) with ease at any time

    automated deployment
    with fast and easy chains

    the fastest team checks in and deploys in <5min with all tests through the whole chain.
    The slowest teams still needs ~4hours.
    If you are still in the two weeks deployment cycle your product is most probably dead or dying.

    Space, time and environment
    for your teams

    your staff: highly educated and probably already applying at another company. Treat them with respect and like grown up people!

    Servers, Databases, Routers,

    ...they setup and kill thousands of VMs per day. If providing this kind of infrastructure worries you at all, you are toast...
    The Chaos


    Chaos is a state, where you cannot predict the future from the present.
  • Wheather can be chaotic,
  • growth can be chaotic if too fast,
  • management decisions lead to chaos, if they happen more frequent than the body of the company can react.
  • Chaos Example:

    YoY growth of frogs in the pond.
    To predict the number of frogs next year, we measure the density (N) of frogs in the pond this year.
    Brilliant mathematicians say, next years density of frogs (N1) will be calculated by

       N1 = λ*N*(1-N)

    Where λ is a growth factor, that relates to the food and subsequently frog reproduction rate. Basically λ has to do with the frogs sexlife.
    The curious incident of the dog in the night-time
    by Mark Haddon!

    Chaos Example: N1 = λ*N*(1-N)

    This can be done with a simple excel table
    stable growth growth with resonance chaos
    1 < λ < 2,4 2,4 <λ < 3,8 λ >3,8


  • A little change (λ) might get you into chaos.
  • don't grow too fast.

  • JM: "I think in IT we have all grown too fast and thus it's now chaotic."

    stable growth

    Growth is never exponetial!
    This looks like XING or StudiVZ in 2007


    this happens when change is initiated too fast for the system to stabelize.

    avoid chaos!
    Because in chaos

    avoid chaos!
    Because in chaos

    Symptoms of chaos in IT

    as manager do not
    induce chaos!

    Teams dynamics, communication and structure

    relationships are difficult!

    with each new person... add more relations

    #relations = N*(N-1)/2

    11 people have 55 relations,
    180 people have 180*179/2 = 16110 relations.

    so if you have 44 people

    you have 44*43/2 = 946 relations.
    Split them in 4 teams and you have to manage only 226 relations.
    ==> teams are a great idea!

    team: more than 4 and
    less than 20 people

    more than 4 because
    you want to learn and profit from each other

    less than 20 because
    at 20 team dynamics grow unstable

    some say, avoid team sizes of 8 people

    Nonlinear effects of group size on collective action and resource outcomes, Wu Yang et al.,

    Colquitt, J.A., Lepine, J.A., Wesson, M.J. (2015). Organizational behavior: Improving Performance and Commitment in the Workplace. New York: McGraw-Hill Education.

    Kozlowski, S.W.J. und Bell, B.S. (2003). Work Groups and Teams in Organization. In Borman, W.C., Ilgen, D.R. und Klimoski, R.J., Comprehensive Handbook of Psychology: Industrial and Organizational Psychology. New York, Wiley.

    Stewart, G.L. (2006). A Meta-Analytic Review of Relationships Between Team Design Features and Team Performance. Journal of Management, 32, 29-54.

    xls team size simulation

    I rather like bigger teams

  • they are more stable with respect to holidays & illness
  • they allow for pair programming
  • they allow for self organization
  • they can prepare their own split
  • Growing Software and Architecture

    software starts small

    ...and grows on you was intershop enfinity, called "Pyramid" from ~2004. It had about 750.000 additional lines of code plus a lot of grown "architecture". But why?

    we all learned to build software in layers

    but this model results in chaos

    graphics by P. Wolter

    Specialized divisions
    manage each OSI-Layer

    technology meets organization


    Thus complex systems evolve

    Software-Architecture of LH*** in 1999.

    note: the systems in black have the language "unknown" in the legend


    Software-Architecture is missing a prime directive!
    Wikipedia says:

    Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures. ...

    Software Architecture:
    old men draw pictures of old IT!

    we need a new direction!

    Prime Directive: 
    make IT changeable! 

    The ultimate goal is the ability to change software without efford at any time.

    start focussing on your deployment!

    How often do you deploy? go life 24.10.2013

    7 deployments that day...

    1000 years ago found out that he can submit only a small number of other people. Modern research says, about seven. Creative minds combined that with a kind of pyramid selling power system and thus invented the modern organization.

    In the center of
    the organigramm

    ... that is me between other department heads. Favors and information are traded like on a bazar. The system is ruled by the law of the fastest and everybody's aim is the top. As top managers, we would be free...

    Communication market example

    Communication market example

    in organizations lame. The channels are thin and unreliable. Sometimes I thing, cigarette breaks communication through the grapevine are the true glue of modern companies. That might sound funny, but it is not.
    Communication between customers and technitions is largely done via (MS-Word) documents. Created by people who are amateurish authors and consumed by non-enthusiastic readers. To simulate the difficulties, we played a telephone game 2.0. Here are the results...
    proverbial knowledge travels easy own the communication chain.
    "Die faktische Kraft des sprich-wörtlichen..."
    "What, if the starting idea is not proverbial?"


    if there ever was an explanation why
    it got lost over time.

  • stop telephone games
  • start cross-functional work
  • delegate decision making to the working level
  • Change - from chaos to ideal

    but why change?

  • is expensive
  • needs orientation
  • takes time
  • so, why change?

    7 reasons that require change

  • your customers leave you
  • your business has grown fast
  • you cannot change your product easily
  • you have no idea how to hire experts
  • high fluctuation of staff
  • you have a big and unsuccesful IT-project
  • your competitor has a better product
  • Step 1: your true north

    The true north defines you values
    in an easy an understandable way.
    I worked for 12 months a voluteer in the Corrymeela Community. They do reconciliation work in Northern Ireland since 1965. Their true north is on a sign at the parking lot for everybody to read when entering.

    Step 2: form guidelines

    ideal guidelines
  • are simple and few (5)
  • leave lots of space for team autonomy
  • are agreed upon
  • give people a safe framework
  • Step 3: agile/crossfunctional

    Start working across department boundaries,
    SCRUM is an easy choice.
    We started in 2007 at XING with our first SCRUM teams. You have probably already tried it and now you have
  • some agile teams
  • or you have proven yourself that agility does not work (in this case, try again or die but don't complain.)
  • Step 4: let your teams excel

  • autonomous teams, share nothing principle
  • is larger than 5 people
  • works together for longer than 5 months
  • has specialists for the complicated things
  • developers, QA, OPS, product and UX
  • lead tech person - team architect
  • lead product person - PO
  • method guru - scrum master, Kanban coach
  • then stop micromanagement!

    Step 5: Vertical architekture

    vertical user recommend purchase search
    Build independent Teams that run independent systems. Share nothing between these teams. Intergrate the product only at the surface. Use RESTful architecture.

    Step 6: change organization

    because communication has become the bottleneck.
    to care for many agile teams we need a different approach to company organization:
  • no silos
  • specialized communication
  • generalized teams
  • Step 7: focus on delivery

    The prime directive of software architecture
    changing software has to be simple!
    You should be able to deploy and chang your life software within 5 minutes.
  • all QA for the release is automatic
  • zero bugs
  • autonomous vertical teams
  • Step 8-99: find out yourself
    or call me

    Johannes Mainusch / @docjoe
    +49 151 17967995