Ways of Working

More than 50 years ago, Melvin Conway made an observation about software development which still holds true today:

“Any organization that designs a system […] will produce a design whose structure is a copy of the organization's communication structure.”

What does this mean for us? Relationships and processes that are inherent in the organisation will inevitably be reflected in the software system. For instance, an organisation with a top-down management culture and where a rather “monolithic” business controls an IT department structured along technical boundaries (frontend team, backend team, database team, testers, operations) is likely to produce a monolitic software which internally is structured along technical concerns.

With Conway’s Law in mind, it’s clear that good architecture and technology alone are not sufficient to build a successful e-commerce platform. Because, even the best architects and engineers will have to fight an eternal uphill battle against the inherent mechanics of the organisation.

Therefore, it is important to organise in a way that allows the products of our work to be aligned with our philosophy

Process

Besides a product-oriented mindset, we take a lot of inspiration from Agile principles.

Continuous Improvement

TUI maintains various activities in the spirit of the “Kaizen” principle which promotes continuous self-improvement in terms of skill, competencies and mindset.

Trainings

We give regular trainings of different size, scope and experience level, delivered by senior colleagues or guest speakers. This can be lecture-style sessions or hands-on workshops. Also, we grant access to a rich collection of self-training resources such as Udemy. We encourage and enable people to achieve certifications.

Open Source

The largest part of our technological ecosystem is open source software. We believe that sharing code not only makes the world a better place, but it also helps us to write better software and raise motivation. As TUI, we contribute to this ecosystem by publishing several tools and libraries under open source licences ourselves. Also, we allow developers to contribute to third-party projects on a case-by-case basis.

Collaboration

Besides the obvious organisational structures, such as development teams, that are mostly manifest through line management and explicit processes, we strongly emphasise horizontal collaboration. This means that we work together across teams and hierarchies to achieve goals that are beyond the delivery of individual artefacts.

Communities of Practice

A Community of Practice (CoP) is a loose assembly of people who are interested in a particular area. Typical goals of such communities are sharing knowlege, collaborating on common tools and libraries, receiving trainings from subject matter experts and organising one-off activities such as hackathons.

Communities can be persistent or transient, meaning that they are either long-lived and have a purpose in themselves or they are ephemeral and are broken up after reaching a goal. In other organisations, such communities are also known as “guilds” (inspired by the “Spotify Model”).

Working Groups

Working groups are expected to produce an outcome such as a strategy, a specification, a decision or a similar artefact. This can be a one-off or an incremental activity. Members are usually experts in their areas and/or equipped with a mandate to represent an area such as an organisational unit or function.

Working groups are an instrument of governance: Their outcome is binding in the scope of their activity. For instance, a protocol specification developed by a working group in an organisational unit must be adopted by all services in the scope of the specification. However, a working group usually doesn’t have authoritative power. Of course, it will usually be backed by the leadership in the given scope. But effectively, the legitimacy of a working group stems from the quality of its outcome as well as the degree of representation of its stakeholders.