CIIC, 16 June 2018, Melbourne

Participants quickly determined that everyone was interested in exploring all submitted problem statements. The discussion proceeded in the following sequence:

Short-cycle methods
Exploitation of autists at work
Supporting the Dandenong Mechanics’ Institute with capital and skills

Short-cycle methods

Problem: Reflecting on the strength and resilience of modern short-cycle methods in research and solution design and development.

Generally speaking, at least in Western cultures, there appears to be a global focus and growing social pressure on methods for cyclic work within collaborative teams (agile and iterative). That focus tends to be characterised by simplification, efficiency and optimisation: GTD (Getting Things Done), minimum viable outcomes, the customer as the paramount stakeholder etc. It can be argued that (a) some work isn’t suited to this approach, and (b) value can’t exist in isolation for a single stakeholder: it’s exchanged in some way.

A. Deep work

In what ways might we incorporate slower, purposeful work (personal flow/ hyperfocus, deep thinking time, reflection and foresight research, architecting for growth and change) to support cyclic work methods?
What relationships – touchpoints and interactions – does deep work have with cyclic work?
If deep work needs its own approach, what factors are key to success?
If deep work is in some respects orthogonal to short-cyclic work, can it be incorporated effectively with short cyclic work? If so, how?

B. Customer Value

What are the strengths and weaknesses of “Customer Value” as a primary focusing lens for products and projects?
How can sustainable value be created in contexts where a primary focus on customer value is mandated? What key elements need to be balanced to achieve customer value and address the broader set of contextual concerns?

The discussion started by observing that most of the work performed with short-cycle (agile) methods is organised in terms of projects and programmes, with a focus on performing a specific set of rituals within a framework of fixed monetary budget constraints. Many organisations are entirely consumed by (a) project work and (b) operational “busyness as usual” work, leaving no room for any other activities that may be in the interest of the organisation and or organisations that it interacts with (customers, suppliers, researchers, regulators, etc.).

Asking the question of which other perspectives beyond projects and operations may be relevant surfaced the following viewpoints:

Projects and programmes work – relying on agile rituals to uncover needs and to validate assumptions about scope and risks
Research and exploration – development of hypotheses and theories
Operational work – busyness as usual, often unstructured and event driven
Architectural work – addressing [anticipated] changes in context and needs
Knowledge distillation – making available tacit and explicit knowledge ready for creative (re)use
Deep work – to determine purpose and direction

Projects and programmes are often structured based on the recipes and rituals dictated by a specific short-cycle methodology, based on the implicit assumption that the specific characteristics of customer needs and corresponding architectural cornerstones of a potential solution have a lesser influence on the organisation of work than generic project management principles.

A significant limitation of the project viewpoint is that it provides no guidance on how to economically manage many tens, hundreds or even thousands of products or product variants.

The nature of research and exploration may vary significantly from domain to domain. For example it does not make sense to organise genetic research in the agriculture sector in terms of weekly sprints. Some form of research and exploration require a long-term government sponsored and mission driven approach that far surpasses anything that any individual company can ever achieve in terms of research and development.

Innovations such as the internet, satellite based global positioning systems, etc. are the result of long term efforts that involve a combination of government support, academic research, and industrial product development.

Operational work is often driven by events that are perceived as unpredictable and ad-hoc. By virtue of the observed ad-hoc nature of events, they can’t be addressed effectively via the project viewpoint. A closer examination and systematic knowledge distillation however is often able to identify different categories of events, and patterns that involve specific categories of events and related resources and agents.

Whether such patterns can be identified and exploited for further automated decision making depends on the level of available tacit and explicit domain knowledge.

Architectural work is only possible based on a reasonable understanding of current operational work practices in combination with relevant domain knowledge. These conditions are often not met at the start of a project, which explains why many project management approaches rely on a phased approach, so that an architecture can be developed incrementally as the understanding of the operational context and of relevant domain knowledge grows.

However this does not necessarily mean that all architectural work can neatly be fitted into the project viewpoint via specific slots in the project plan.

Knowledge distillation involves the surfacing of tacit knowledge to drive the SECI knowledge creation cycle. It relies on trusted relationships between the people involved and on the commitment to openly share knowledge, unknowns, open questions and risks. The inputs and outputs of knowledge distillation are tacit and explicit knowledge. The value of knowledge distillation is characterised by the qualitative difference between inputs and outputs. Often the level of complexity of the outputs is an order of magnitude lower than the level of complexity of the inputs.

As knowledge is an increasingly relevant prerequisite for deep work and architectural work, and as it often holds significant potential for significantly improving the level of understanding of operational work, it is best seen as a tool that can be deployed at any level of abstraction for better understanding an organisation or a system and its current limitations, and hence as a tool for defining and prioritising sensible programmes and projects that are associated with objectives that are meaningful to the stakeholders involved.

Deep work relies heavily on creativity and conceptual blending; it can be seen as a foundational form of architectural work.

The architectural viewpoint and its relation to other viewpoints can also be conceptualised and illustrated using the language of domain engineering / product line engineering:

Timeless design principles and thinking tools remain stable over time irrespective of the specific context.

Platform engineering concepts tend to be domain specific, and only change very slowly within a given domain. Platform engineering work can be organised and coordinated as a dedicated sequence of long-running projects, using processes that are highly optimised for the specific domain, resulting in a sequence of platform releases.

Product engineering is always domain specific, but takes place in the context of concrete customer needs and related time constraints. Product engineering can be organised and coordinated in terms of short dedicated projects for each specific product/solution. The work is best addressed by an intelligent combination of (a) domain specific techniques enabled by a domain specific [product] platform and (b) agile project management techniques for incorporating customer feedback into the product design.

Systematic experimentation and related product ideation is triggered on demand, when platform engineering activities run into problems that require the acquisition of knowledge in domains about which nothing or only very little is known.

Some experiments may justify the initiation of a dedicated project, whereas other experiments are so small that they can be performed by a team of one to three people without any project management overhead.

Product line operations encompass all the operational work and related monitoring of ad-hoc events. In a mature product line organisation, operations are highly automated, requiring minimal manual intervention. In contrast, in an immature organisation that does not actively perform knowledge distillation, architectural work and related deep work, most of the people in the organisation may be occupied with operational work.

Over the last ten years, some organisations developing software intensive products have rediscovered important product line operations principles under the heading of DevOps.

Exploitation of autists at work

Problem: Organisations are using autism as an excuse to legitimise their approach of confining autists to specific roles and areas within the organisation. Along the way they reinforce stereotypes about what autists can or can’t possibly do.

brains3

Some of the big companies are starting to pay lip service to neurodiversity. “… The program has been such a success, SAP is currently working to expand it, with the goal of having 1 percent of its total workforce”. I cringe when I read these statements and absurd goals.

The marketing: Autism at Work. Can you imagine the same organisation labelling other diversity programs as “female brains at work”, “homosexuality at work”, “blindness at work”? Somehow autism can be “celebrated” as a subhuman category and no one bats an eyelid.

The reality: SAP, Microsoft et al. make a big deal out of aiming at 1% of “proper, certified by the autism industry” autists within their workforce, whilst at least another > 9% of their workforce don’t dare to openly identify as autistic, because they know what it would do to their career prospects.

Judy Singer (who coined the term neurodiversity in her thesis in 1998): “Could not agree more, especially in the middle of 3 generations of women on the spectrum. Saw exactly this at the APAC 17 recruiting stalls. Reckon corporates would be happiest with autie techies in cages pecking code 24/7 with a chute in for pizza. And if you are not a techie, go volunteer at a library!”

Nick Walker (transdisciplinary neurodiversity scholar): “I was hired to be a keynote speaker at the Autism at Work Summit at Microsoft HQ earlier this year. When the organizers found out I planned to speak about integration of autistics into all levels of organizations, they cancelled my talk.”

Ryan Holtz (software developer): “I’ve worked for Microsoft in the past, and have literally been trying to get the word out about their heartless, bigoted attitude towards #ActuallyAutistic people for the better part of a year, to no avail. Set the Wayback Machine to circa 2015 or so. In that time frame, Microsoft were trying to promote themselves as some amazing place for #ActuallyAutistic people to work by making us out as little more than robots with all the personal agency of a fucking house pet. ‘We love autistic people,’ said their PR barrage, ‘because they’re too socially inept to realize when they’re being taken advantage of! We can demand that they work no end of unpaid overtime, and shaft them with inequitable social treatment, and they won’t know any better!’. That’s literally what Microsoft’s attitude towards #ActuallyAutistic people is: That we’re an asset who’ll work burdensome hours that would burn out allistic people, ‘cos we’re clearly all a bunch of losers with no social lives and fucking nothing better to do with our time.”

The three autistic participants agreed that the needs of autists are much better served in dedicated teams with a neurodivergent majority that collaborate on neurodiversity friendly / autism friendly terms.

Following the workshop, in the light of the first topic discussed, it occurred to me that many autists will likely be drawn to work that is focused on long range goals and that is not organised in terms of short projects. Such long range work can give individuals or small neurodivergent teams a very high degree of autonomy, is usually tied to a clear purpose, and gives the people involved the chance to acquire extensive domain expertise over time.

A full appreciation of neurodiversity can be positioned as a key element towards the solution of the bullying problems encountered in many organisations and industries. Such an approach that is integrated into an organisation-wide anti-bullying initiative would lead to support structures and to opportunities for neurodivergent employees that differ markedly from exploitative, insulting, and ultimately counter-productive “autism as work” programmes.

Interested participants will explore this topic in more depth in the coming months and with the aim of introducing neurodiversity friendly work and collaboration practices into concrete anti-bullying initiatives in large organisations.

Supporting the Dandenong Mechanics’ Institute with capital and skills

Problem: The Dandenong Mechanics’ Institute currently has several capital attainment programs in operation centred around a new development of small frame jet engines of simple and rugged modular design. The Institute has a need for supplementary skill investment.

The initial application for this class of engine has been used in a high return/low investment application in the form of a family of high end boutique motorcycles. This application has limited market prospects, but a high public profile to showcase Institute and member ability and a high capital return per unit for small investment possibility plus access to other beneficial peripheral industries.

As a result of testing derived from the Jetbike, this family of engines is now to be applied to a small, low cost, easy to build and maintain, ultralight high performance aircraft. The market for this type of aircraft is very high based on those types currently in production which command very high prices and are much sought-after by private and commercial entities.

dmi

These engines are also to be used and marketed in a series of small, lightweight and powerful marine engines. The small marine engine has many benefits in recreational boating using more safe, environmentally friendly fuels with significant weight and space saving capabilities for power output, however, the market for this form of marine engine type would be difficult to break into due mostly to traditional viewpoints held within the industry.

Secondarily and because of the control requirements of these engines along with their subsystems, the PIC controller designed thus far for the task has many and varied control applications in other fields such as motor control, system control and interface, robotics, general automotive and many other applications.

The Institute has a need for supplementary skill investment specific to the current inter-exchange capital establishment projects now in development. These are for:

PIC programming and board construction specific to current project requirements in consultation with the current design team.
Aerodynamic design and structural design consultation specific to current project requirements.
Assistance in manufacture of some components needed to complete projects already in development and establish for multiple manufacture, post prototyping and testing.
Consultation on other uses or derivative programs for those developments already produced in current projects.
Marketing assistance for any collaborative and Institute benefit projects completing design, testing and prototyping.

Andrew Russell provided participants with an overview of the current situation at the Dandenong Mechanics Institute, as well as an overview of current state of design of the product ideas generated by the team (jet engine powered motorcycles, light aircraft, and boats).

We discussed how to best meet the needs of the current members of the Institute, and looked into possible organisational constellations for complementing experiments and deep work with commercial product development and sales activities, with external capital and skills, including external product development and engineering expertise.

Participants will collaborate further in the coming months. Jorn will explore whether there is an opportunity to connect the current activities and interests of Institute members with the mission of the Design Factory Melbourne, and Paul Szymkowiak may be able to offer insights based on his experience in working with Maker Spaces.

How important is expertise?

Problem: How important is expertise? How critical to success is expertise, and how can we determine what and how much is needed?

Can largely self-managing, open collaborations work in the absence of certain knowledge, skill, and skill competencies that many practitioners in the same field might deem important? If so, how and to what extent?
On a related note, can “unnoticed” or “unknown” issues – such as biases or fundamental errors (conceptual, logical) – be self detected and managed to resolution by the group itself in the absence of expert insight/ knowledge?
If access to specific expertise (knowledge and skill) is critical to some extent, how might the members of a collaborative work effort identify missing expertise within their work cycles, so as to minimise negative impact and identify ways to address that deficit?
How might members in a collaborative work effort determine what represents expertise in their context, and self-determine what constitutes sufficient improvement toward a useful level of expertise?

We did not have time to explore this problem in the workshop. Jorn and Paul S. will compare notes and share experiences between now and the next workshop in September.