Objectified

Posted on Leave a commentPosted in management

Watching objectified film generated lots of insights for myself about product design – https://youtu.be/HlT611TFJvk objectified

People are talking about physical objects, but lots of good things can be applied to software development either.

Here is the definition of a Good design provided by Dieter Rams:

  • must be innovative
  • must make product useful
  • is aesthetic design
  • will make product understandable
  • is honest
  • is unobtrusive
  • is long-lived
  • is consistent in every detail
  • is environmentally friendly
  • is as little design as possible

Also during a film you notice such repetitive behaviour of those who design products:

  • how much time they spend on prove of concepts, so it would be possible make changes easier and cheaper, try things out and gather feedback
  • keep asking the question if this is going to solve the problem of the user
  • desire to design things that get better with use
  • desire to create products that reflect users behaviour, not trying to change it
  • desire to understand users context. getting out of the room concept

Question on errors and randomness?

Posted on Leave a commentPosted in management

Is it possible to build an organisation which benefits from uncertainty, errors and randomness?

reality

  • How small should be the teams? 
  • What should be minimum process?
  • What is the level of centralisation/decentralisation?
  • How often achieved agreements must be reviewed?
  • What behaviour is needed?
  • What is the ratio between explicit and self-discipline?
  • What is the level of autonomy?
  • Can growth be the target?
  • Should it reflect value delivery?
  • Should org. look different depending on the context?
  • Should unstable be new stable?

Those are curse words for any member in a company. Often companies are designed as if for any non-repetitive task it is exactly known what is going to happen and what is the most efficient way to do that.

Planning vs Plan

Posted on Leave a commentPosted in management

We always want to know future especially when it’s related to delivery of complex software projects.context-matters I personally failed in making plans almost always in my career, but improved myself in planning: setting boundaries, watching trends, adjusting often, planning very little ahead, changing direction completely and more…

Also realised that creating too much overhead in formalizing plans and decision making slows you down and reduces motivation in making changes in the plan. We need to change fast and often (at least in certain types of activities) for the following reasons:

  • uncertainty
  • variability
  • imperfect, incomplete knowledge
  • chance
  • chaos
  • volatility
  • disorder
  • entropy
  • time
  • the unknown
  • randomness
  • error
  • variety of outcomes
  • unknowledge
  • simplification of activities
  • optimism

Probably any person who wants to have a very good plan
must have some checklist with things mentioned above which helps to evaluate context. And the more “yes” you have for you context than less formalised plan you should have, adjust it often and shift faster towards network organisation.