Team Architecture

Team architecture is one of the major concerns of any engineering group in tech companies. How do we arrange people in teams so that the best outcome is achieved.

Definition of a team usually makes sense in the context of ownership. What is it that a few people can own to form a team for? This is the first question you have to ask when forming a team. What they will own and what happens to the product when the team vanishes.

Another aspect that make a team more effective is the reporting lines, e.g. an infra team that does not report to engineering but reports to the operations is just waste of their potential. This is a different topic I will get to later.

Below are some thoughts on the subject (with focus on software products) that will hopefully spark more thinking and discussions.

Patterns of Team Structure

The definition of the following patterns is not rigid at all. They have a lot of overlap, similarities and some even come under hierarchies. Some teams have different names in different organisation. A DevOps team in one company might be the Infra team in another company. I haven’t made much effort to classify them into a better grouping or structure.

In reality we group teams together all the time, e.g. CloudOps consist of cloud team, DevOps team and operations team; or a commerce team may consist of billing team, ordering team, etc. Teams similar to software can have levels of abstraction and hierarchy.

These patterns provide tools to ask questions on why the teams are formed the way they have and if there is a better way to re-structure them.

Product Team

An organization may have one or more products, e.g. Kayo, Binge, etc. Products my be for internal or external customers, B2B, B2C, etc.

This pattern has some variations:

  • External customer: Product may be developed for an external customer. If the external customer has very tight timeline and budget constraints the long term support of the the products may face difficulties.
  • Internal customer: Product may be developed for an internal customer. The company owns the product and the team has a better sense of ownership. Internal products usually receive more care and longer term support. Internal products may be a revenue generating product such as Kayo for Foxtel or an internally used productivity or cost saving product such as bedrock vending machine.
  • Bundle of products: A team that works on a group of products.
  • Product variation: A team that supports a variation on a product, e.g. Android team, iOS team.

For a product team to be successful they have to be cross-functional and own all of product + design + engineering. Product team’s goal should be solely customer focused.

Feature Team

A team that supports or owns a feature or a process within a product. A feature team is usually across multiple domains or applications. When a process/feature/journey/aspect is big enough then it requires a team to handle it.

Example: signup team, purchase flow team, user journey team, search team, etc.

Feature teams usually have many communication points as they interact with many other teams and applications. 

Processes may have sub processes and that might mean sub-process/feature teams.

Feature team may be a short lived team and has similarities with project teams below.

Teams by Conway’s Effect

Conways law states that the communication structure of an organisation influences the systems they build. That means they architecture of a system is affected by the team structure.

The effect of team structure on system architecture makes team building an architectural concern not a management or agile activity.

As a rule of thumb remember the Reverse Conway which focuses on a team structure that matches the desired architecture we want.

If the architecture of the system and the architecture of the organisation, are at odds, the architecture of the organisation wins. Ruth Malan

Spotify Model

It’s a famous model you can read about here. Since Spotify announced this model it was adopted by many organisations some of which took it too seriously unlike the Spotify themselves (according to Kingberg and Ivarsson on the original Spotify blog they partly implemented the model!)

One major problem with the model is that there is no regards to the team size. You have to be careful otherwise the tribes will grow too big.

One important measure for a team size is team cognitive load which is the amount data, information, task and process a team is capable of handling. This imposes constraints on the software architecture too because there will be limits to the amount of components you can realistically place into an architecture that a team is responsible for.

Sometimes too many bugs in a system is an indication that the system is bigger than the cognitive load of the team and the team is having difficulty figuring things out.

Spotify model also doesn’t talk about the dynamic interaction of teams; it’s static.

Platform Team

A platform team in digital companies is a basis that provides self service APIs and reusable tools to other teams to perform their duties. Example is DevOps team that builds CI/CD pipelines, application templates, etc.

Platform team nowadays is a capability that gives companies an edge. As a rule of thump if a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team.

If a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team

On the other hand, if the platform team is not self service and automated enough it will eventually burn the team or grow it unmanageably large. It is just pulled in all directions by many teams. Self sufficient teams that have a member from the platform team (capability) take this direct pressure off the platform team. Ideally other teams should contribute seriously to the platform and the platform itself should be flexible and extensible to allow such contributions.

The concept of platform team paves the way to define capability teams. Teams that are specialised and take care of an speciality across the organisation such as Kubernetes team, Identity team, etc.

Some do not like the idea of DevOps team and would insist on merging Ops and Dev and define DevOps as only the concept of affinity between the two but I doubt this is true anymore. Nowadays DevOps is an abstraction layer on Ops teams where they stay on their hardware/network/storage realm and DevOps take care of the necessity for more automation, container orchestration, GitOps, CI/CD, etc. More on the later.

Project Team

A team that is formed for a project. These teams are usually short lived depending on the nature of project. Project teams usually have the role of project manager. Care has to be taken for the long term support, maintenance, ownership and upgrade of the created product or service when the project finishes.

As project teams are formed every time for a new project, they share the common problems of a new team such as personality clashes, etc.

Project teams are usually more constrained with time and budget. From personal experience showing a project plan or timeline to developers just makes them miserable! Just shield them from it as much as possible!

Component Team

A team that is responsible for a component (part) of a product or feature. This could be a considered as a variant of a product team as well. Component teams of function best as cross functional teams.

Example: backend team, front end team, watchlist team.

Even though a component might be a feature and vice versa but component team focusing on one well defined part of a system is usually the opposite of feature team working across many components.

Domain Team

If you have defined boundaries for each domain in your business context you can have domain teams, e.g. commerce team, content team, billing team.

Domain teams usually map to the capabilities of a business. A business with capabilities such as sales, marketing, streaming may have teams with the same names.

Each domain may have a manager and/or architect. Domains are hierarchical in nature hence this pattern has a logical variation of sub-domain team.

Cross Functional Team

This type of team has at least one member for any capability they need to make them self sufficient and to reduce cross team communication and dependency. It is also called self-sufficient team. These teams seem to be high performing teams due to less external communications and better internal communication (cohesion).

One problem with this type of team is that they might diverge from the standard architecture of the overall system that organisation follows and there should be ways to align and enforce such standards, e.g. using a self service platform.

HBR says that 75% of cross functional teams are dysfunctional. Read here why.

Functional Team

If cross-functional team is a thing then we should have a definition for a functional team as well. A functional team is responsible for or corresponds to a function unit or domain of an organisation.

A functional team has a lot of similarities with domain team and component team, e.g. accounting team, IT team, platform team, development team, billing team, test team, architecture team, call centre team may all be called functional team.

Technology Team

Specialised teams that build or maintain a piece of technology or a group of technologies. Example: Kubernetes team, front end team, backend team, UX team, Java team, etc. These teams are not self sufficient and many depend on them. They also usually do not map directly to an organisational value stream.

Consulting (Enabling) Team

Specialised team that is formed internally or hired externally for specific purposes, i.e. something that organisation has no knowledge of or does not want to spend time on. Example: cloud migration team. This type of team usually has a short life span and require close management to make the best out of it.

Outsource and Offshore Team

Many businesses nowadays outsource part of their workloads to onshore or offshore teams. Common problems include: culture differences, timezone differences and lack of present management. You organisation also loses the knowledge of that team when their contract finishes.

Matrix Organisation

This form of organisations are a combination of functional and project teams. An individual works in a project/product team and at the same time part of another functional/domain team, e.g. an architect is part of the architecture team and also works on a project.

Matrix organisations or teams is an old concept and is the basis for the Spotify model.

Temporary Team

A team that is formed for a short period of time in order to handle a time bound task. Care must be taken in terms of the ownership of end product once the temporary team ceases existence. Examples are project teams or task force teams. They have a limited life span.

Team Dependency Patterns

Teams depend on each other for different reasons. This is where team boundaries have to be defined and as said above as part of Conway’s Effect, the team boundary should ideally be dictated by system architecture.

  1. Knowledge dependency: A team needs the knowledge of another team e.g. the billing team needs the DevOps team to setup CI/CD pipeline for them.
  2.   Task dependency: A team’s output is another team’s input, e.g. a team is waiting for an API to be ready for consumption.
  3.   Decision dependencies: A team’s decision affects the tasks of another team. Example: the way front end team wants to consume APIs will affect how backend team creates those APIs in terms of technology and granularity.

Team Communication Patterns

The teams communicate in many different ways. Remember that teams are made up of people and even though with teams we create boundaries but people are still free to talk to each other and this opens unlimited communication paths.

Ideally we want less communication across teams (low dependency) and more communication within the team (high cohesion).

  1. Formal communication – collaboration based on their org structure, reporting lines and formal team boundaries and communication tools (chat, email, etc.) This type of comms usually include hand offs.
  2. Informal communication – collaboration based on interpersonal and friendship relationships or how people influence each other beyond the formal titles and org charts in a personal level. Even though this sounds cheesy but a lot of tasks in organisations are actually performed via informal interactions. Sometimes this is an indication of wrong team boundaries, missing capability in the team or incorrect org charts (people are not where they should be)
  3. Communication by Service – based on services provided by another team. A team provides a service (e.g. payroll or platform) and another consumes
  4. Communication by API – based on an API provided by another team.

Benefit of communication by service or API is reduced human interactions or hand offs.

Local Environment Kubernetes Options

It is always fun to have a local Kubernetes to try new things on but there are a few different options with varying capabilities that might look confusing at first.

Some of the following products are also useful for setting up a home lab, home server or even production grade IoT.

In this short summary which is basically a copy-paste of my personal notes, we look at different options that will help developers work with local Kubernetes clusters.

This is obviously ignoring cloud providers. If you have access to a cloud provider they all now provide k8s as service or you can set it up yourself on their VMs.

Disclaimer: These tools evolve too fast hence the validity of this material might be short but I try to keep it up to date!

Kind – Started in 2019, Kind is a mini Kubernetes on Docker by the Kubernertes developers. The cluster is basically a docker container running on docker runtime

  • Pros: Very fast startup
  • Cons: high memory usage, not a fully compliant Kubernetes
  • MultiNode: yes – 1 master
  • MultiCluster: yes
  • Min Memory: 8 GB

K3s and K3d – Lightweight, fully compliant ks8 which is best for IoT, ARM and edge developed by Rancher. k3d is a lightweight wrapper to run k3s in docker.

  • Pros: fully compliant, production grade, very light
  • Cons: Not on Windows yet
  • MultiNode: yes
  • Min Memory: 100 MB

Docker Desktop – If you use Docker desktop on Mac or Windows you get a k8s cluster for free. It runs on docker.

  • Pros: Images are readily available, comes as part of docker desktop
  • Cons: high memory usage
  • MultiNode: no
  • Min Memory: 4 GB

Minikube – Mini k8s by the Kubernetes developers that can run on a VM (e.g. VirtualBox) or even docker. It started as early as k8s itself around 2012.

  • Pros: Simplicity, add-on based for adding extra functionality as needed e.g. loadbalancer
  • Cons: Running on VM is slow
  • MultiNode: no
  • Multicluster: no
  • Min Memory: 2GB

MicroK8s – Fully compliant k8s by Canonical (Ubuntu folks) that is supported on ARM, Windows, Mac, etc. It was previously only available with Snap package manager but it has improved much.
It’s lightweight and great for IoT similar to K3s. It also supports a number of extension add-ons similar to Minikube.

  • Pros: Runs on any platform, production grade, has extensions
  • Cons: On Windows/Mac need a VM
  • MultiNode: yes
  • Min Memory: 4GB

FireKube – This is opensource by Weave that runs on VMs. Haven’t tried yet!

Virtual Machines

If you want to setup a multi node clusters in a home server you would need VMs and this discussion will not be complete if we don’t talk about different ways of spinning VMs.

This is in my order of preference:

LXD, LXC – This is the fun one. Runs only on linux but it’s the fastest and lightest approach since it uses userspace concept of linux. All VMs share the same kernel as host though. LXC/D runs the full OS system and provides an environment similar to a VM but docker runs an application process in a container.

Multipass – By Canonical, runs on any platform, good startup time, nice command line. On Windows/Mac needs a hypervisor such as Vbox or hyper-v or even docker which is faster.

Vagrant – By HashiCorp, runs on any platform, ok startup time, good command line. Needs a hypervisor such as hyper-v, vbox or docker (faster)

Virtualbox/Parallel – Simple to use, UI based, command line sucks. Need to tweak for best memory usage, etc.

From Shiny OneNote to Boring Plain Text

I have been taking notes since I remember. We all write to keep things for later, gather and keep information, remember and remind things, catalogue our thoughts, etc. Everyone has their own style or reason for taking notes.

I also use notes as my short term and long term memory as my biological one is a bit faulty!

I take notes on the latest books or articles I read, how to do things at work, processes, discussions with people, how-to’s, project notes, meeting notes, tasks lists, todo items, etc.

Many years ago when I started taking notes seriously it was all on Evernote. After a few years I moved to the shiny OneNote as it had more features and better abstractions for organisation (folders, notebook, sub page, etc.). Recently I even used to write hand written notes on my tablet with a pen. It has served my well but I wasn’t entirely happy! No particular environment or program is best for any one person.

One weekend with the help of some buggy VB script I converted most of my notes from OneNote to plain text. BOOM! You might be asking why?

I have to stress that this subject is highly preferential. Every one’s style and needs of note taking and expectation of tools is different. Plain text is not for everyone.

Why plain text

Short answer:

I get distracted on busy, mixed formatted text with colours, multiple fonts, menus and different options! I also want full control over my notes (where they are, how they look, what structure, what format, etc.)

Long answer:

  • Nothing can beat its simplicity in terms of aesthetic and structure of your choice (main reason)
  • It’s not limited to any text editor or tool. You choose your tool or change tools easily. You can read and edit on a shiny MacBook pro as well as Windows 98 VM or command line. They all show the same thing. (second reason)
  • Plain text is flexible. You can convert it to any format you want. You can apply formatting to it as you want: Markdown, asciiDoc, reStructured, etc. but still the raw content is yours.
  • It’s fully searchable. I hated search function of OneNote! I can even search faster in command line.
  • As developers we deal with plain text all the time in code, in command line and everywhere so why not note taking?! You can version control as well 😀
  • Full control of where notes sit (which note provider or cloud server or version control)


Now that all the notes are in plain text I can organise them in folders, some that are more important or permanent become Markdown otherwise it stays .txt. Images have their own folders. For now everything is in a Github private repo and I use VSCode with a bunch of command line aliases for quick access to certain notes and searches (you can also auto commit if you want but I do not)

For plain text or Markdown you probably still can use EverNote and there are many many other options such as  SimpleNote, iAWriter, Notion or native apps in different platforms (e.g. Apple Notes) but the above simpler approach keeps me happy for now.

P.S I still use Google Keep for quick notes when not behind a laptop.