As organizations heads into a future where cross-cutting projects are the norm, they face an intuitive question: should we align our teams around projects, or is there a better way?

The answer isn’t clear cut, but let’s dig in to the pros and cons, and how each of these models would look.

First, we’ll explore how project and domain team paradigms would work.

## Project Teams

Teams will be assembled to tackle projects for their duration. When projects are large, multiple teams may be assembled; those teams may be assembled based partially on rough domain / service boundaries, or based on tech stack horizontal (backend, frontend, etc).

![](../assets/post-images/project-teams.png)

As the diagram illustrates, teams will be dynamic and reallocated based on project demand. No formal team structure would map to service work; service work would be slotted in on an as-needed basis.

There are two possible reporting structures in this world.

**Project Team Structure, Option 1: Dotted line reporting (QB + people-manager)**

Engineers would have a dotted line reporting structure. Their primary people manager would manage individuals across multiple projects. Engineering managers may also be responsible for “QB”-ing an initiative, assembling the teams around a project and organizing the resources and timeline, etc. This QB role may instead be held by director-level managers. However, engineering managers may not be as involved in technical planning in this paradigm, as their reports are spread across many projects.

EMs might be aligned to one or more services, and engineers would still operate as codeowners over services or areas of code. The EMs would be in the know about their individual engineers’s projects, but are not necessarily leading those projects. A given EM may be a QB for a project where only one or two of their reports are working on that project. It is unlikely that an EM is a QB for a project where none of their reports are actively involved.

Performance management in this world can be a challenge; a given engineer’s people-manager EM would request feedback from the QB and other collaborators for that engineer’s work over some period of time, but direct observation would be a less common opportunity in this paradigm.

**Project Team Structure, Option 2: Agency Teams**

In this structure, teams will remain with the same manager, and the whole unit moves between projects. This is largely reflective of an “agency” model. Managers would not be tied to any domain or service necessarily, but teams would work quarter over quarter together on a variety of projects.

The concept of codeowners gets stretched in this paradigm, as a given codeowner may not be touching their “homebase” code for a long period of time. Thus this paradigm does not optimize for code ownership.

If there are multiple teams working on the same project, their may still be a project QB under this format.

Generally, teams would work in areas they are familiar with, but this is not a strict rule as much as it is a heuristic in this structure. Teams may be organized into multi-functional units (i.e. crossing skill boundaries), or could be grouped by skill (i.e. “backend team”).

**Service work and KTLO in a project-oriented environment**

Service work would be done as a secondary priority in this format. Because teams are assembled around projects, the incentive to focus on project work is implicitly higher than the priority of ongoing service work. Additionally, the resources available for a given service would be dependent on the project load share on the service’s codeowners. There is one exception to this rule: when a given project is entirely within the context of a single service (or close), the team, project, manager, and service all remain aligned.

## Domain Oriented Teams

In contrast to project teams, which are fully (or almost fully) focused on a single project crossing multiple services, a domain team would be responsible for projects as they impact a given domain.

Not all projects cross domain boundaries; it is also very rare that a project will cross _all_ domains at any company of reasonable size.

![](../assets/post-images/domain-teams.png)

In this paradigm, engineers allocate a percentage of their time to different types of work. The organization lays out the projects and the relative priority between them, and teams work to determine what execution ordering and structure would make sense based on dependencies, priority, and resource constraints.

As a general rule, assuming all things being equal, highest priority projects receive first attention. However, in reality, prioritization is not always as simple as “this project is top priority.” Some examples of how it gets complicated:

- Some work, though not necessarily urgent, is a blocker for other work that will _become_ urgent.
    
- Some work is unpredictable in its smallest form (though reasonably predictable as a collective whole) and critical for the company to survive (KTLO)
    
- A given set of work may be difficult or impossible to parallelize, thus two teams may simultaneously be working on things of different priority levels
    

Domain oriented teams are organized in an effort to retain some level of domain expertise across the critical areas of the company. However, sometimes in a domain oriented team, the cross-team coordination required to finish a given initiative quickly can be a challenge. This is when Tiger Teams might be useful.

Tiger teams provide an avenue to assemble a temporary project-oriented team to accomplish a given set of work. This temporary team looks very much like the previous paradigm - a project QB is leading the team through dotted lines, and each member has a people manager that they report to directly.

Tiger Teams should only be assembled for a clear and discrete scope of work, and should not become the “norm” in this paradigm, as this transfers the burden of the KTLO work onto fewer members of the team in addition to other ongoing cross-coordinated project work. If every project is “critical” enough to assemble tiger teams, then it would be better to align to a project-oriented paradigm all together.

As depicted in the diagram, there are also overlaps of collaboration topology that should be made clear when two or more teams are working on the same project.

When two teams are planned to work on a project, it is useful to describe how those teams will interact during that project’s lifecycle. Is one providing a service to another? Are they collaborating on building a common codebase? Is one team facilitating another through mentorship or other kinds of help (knowledge transfer, for example)?

# What considerations should we make when picking between these paradigms?

Generally speaking, look at your intentions for the long run. If you are moving toward a service oriented architecture, the implications are very different than if you want to run a mono-repo or even a monolith.

Perhaps you are preparing for an exit - in this case, your focus likely will be on certain projects rather than creating long-lasting domain knowledge and org design.

Maybe your product is pivoting quickly, and you are building many POCs. This is another situation where a project orientation makes more sense.

Overall, the prevailing consideration is to understand what you are *investing* in. With a domain orientation, you are investing not only in the current ongoing new priorities, but in maintaining the existing surfaces and complexity you've developed in the past.

If you're in early startup territory, you may not even *know* what your domains *are.* That doesn't mean you can't start doing some kind of domain modeling, but at that stage your org design is probably limited more by resources and lack of scale than anything else; project orientations actually serve to extend domain knowledge out of individual silos in this case.

In *most* cases, however, the paradigm of domain oriented organizational design is a reasonable default.

Finally, it's reasonable to consider the ownership model your organization currently has. In most organizations, domains emerge either within a singular (or many similar) contexts that combine multiple domain concerns into a single codebase. Ownership is mostly dependent on the conceptual domain, but is not clearly delineated in the actual code.

![](../assets/post-images/provider-owned.png)

In a service architecture that aligns ownership with services, the calls tend to look more separated, and the caller owns the call locations themselves.
![](../assets/post-images/caller-owned.png)

In this case, the caller would be responsible for whatever integrations they have with other services. This model fits generally better with domain oriented teams than with project teams.
# What type of team approach makes the most sense in a service-oriented architecture?

> Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
> 
> —  Melvin E. Conway, How Do Committees Invent?

As a broad-strokes assertion, most service-oriented architectures lend well to domain-oriented teams, in part because of Conway’s law. If the organization of people matches the system they tend to create, our organizational structure matching our SOA is a reasonable starting place.

And, this may also help us describe why project orientation is tempting in the first place; with our current monolithic structure, it’s a reasonable expectation that you might touch _any_ part of the codebase, so why would we draw boundaries that don’t exist in our system? (This might be a sort of a reverse version of Conway’s law, that we might design our communication structures in a way that fits the system.) And if we had plans to double down on keeping the monolith, this recommendation would be a fairly clear frontrunner.

Let’s explore the pro’s and cons of each approach in the context of service oriented architecture.

## Project Oriented Teams: Pros + Cons

|**Pros**|**Cons**|
|---|---|
|Efficiency of focus|KTLO becomes far less structured without supplemental organizational planning|
|Staffing based on skillset becomes only a matter of prioritization|Domain expertise may falter as projects jump across domains|
|Consultant capacity is easier to scale-in / out in project oriented work|“Projects” become products; teams that work on a project may disband (depending on squad cohesion strategy). The product then does not have clear ownership, and the distributed ownership problems of the monolith are perpetuated|
|Encourages individual responsibility|Codeowner strategy becomes thin; easy for code to accidentally go unowned or abandoned, hidden risks when the only codeowners of a given area depart the company|
|Provides variety to engineers who may tire of working on the same domain service for an extended period of time|Can result in many different paradigms / technical approaches that compete with each other. This can be messy and inconsistent, creating a “stack of projects” rather than a coordinated set of services, resulting in more information silos|
||Ownership set at project boundaries would passively encourage the whole tech stack to be homogenous.|

## Service Oriented Teams: Pros + Cons

| **Pros**                                                                                                                                                                                                                                                                                                                                         | **Cons**                                                                                                                                            |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Long term stability of domain services                                                                                                                                                                                                                                                                                                           | Split focus situations when projects don’t perfectly line up with a full team’s capacity                                                            |
| Identification of outlier concerns with new implementations; as projects are executed, teams ask “how should we integrate this new concern with our domain”                                                                                                                                                                                      | Success for the team may be hard to define, as the business cares less about individual team deliveries and more about project deliveries           |
| More traditional approach to enable SOA. Services can differ from each other, and this differentiation may align with squad skillsets. For example, a given service may be written in a completely different tech stack than another. Having squad ownership lines drawn at service boundaries rather than project boundaries allows for this.   | Onboarding into a domain takes longer than onboarding on to a project, as the history of decisions for the service lay across many past “projects.” |
| Business effort should be allocated based on business interest; domain oriented teams allow organizations to directly invest in ongoing work on areas of the business that are useful, and reduce in areas that are not. This is a forcing function to reduce complexity in unimportant domains / cost centers, and invest in important domains. | Domains are not always “team-sized” - thus a given domain may require multiple teams in tandem to cover the breadth of the problem.                 |

# So what should we do?

No matter which direction your organization goes, the answer to this question is complex and opinionated, and might not be as clear cut as this document proposes. However, based on the assertion that our organization will move towards a service-oriented model, and we want to create a sustainable architecture and teams that can support that architecture in the long run, **this document proposes a domain-based model of ownership and planning with a percentage allocation to tiger teams.** The percentage should be something decided on an ongoing basis, with an ideal maximum threshold set around 15% of resources dedicated to tiger teams. That would translate to 3 engineers per four squads, based on 5-person squad size. Anything greater than this begins to erode the sustainability and predictability of team structures.

Project or Domain Teams?

**Correct focus outpaces brute efforts and long hours.** The perennial problem of productivity is almost never solved with "more." It's easy but incorrect to imagine that our productivity is based solely on our ability to drive output. More correctly, it is based on our ability to develop laser focus on the right things. Thus the vast majority of my management style is not focused on driving people to "work harder" (which almost always roughly translates to "more hours"). It is instead pointed at generating the clearest possible focus. The marginal gains in productivity seen by driving more hours are almost never worth the damage done to peoples' mindset and feeling of buy-in. If your team can't be successful within normal working hours, one of a few things must be true, in order of most to least likely.

- You are not focusing on the right things
- You are not planning effectively
- You have a talent or capability issue
- You have a motivation / willingness issue

How can it be that these are in this order? Based on pure statistics and reasoning we can arrive at this conclusion.

Focusing means finding the right problems to solve; this could be a problem that goes as high as the fundamental market positioning of your company, or as low as a ticket prioritization issue.

Focus Beats Effort


On the 4th of July this year, I almost died. I think the most important thing for you to know, out of the gate, is that it wasn't fireworks. The second most important thing for you to know is that I'm fine now, physically speaking.

### How it happened
You may or may not already know that I am a powerlifter. Well, I usually am a powerlifter.

Right now, I'm injured, so my lifting is limited. (Pre-existing condition to the almost-dying incident.)

To say I'm a powerlifter is to say I'm a programmer - I haven't written much code as a manager. I start to feel some impostor syndrome after a while; is the cure to remind yourself you can do the thing, or to become capable at doing something else? Can I be comfortable with saying "I have done some programming" or "I have done some powerlifting"?

Anyway, I was adjusting my power rack. It was an 8-post rack, I decided it was time to change it to a 6-post rack. My goal was to remove the front two posts, take the connections from those and put them between the back two and second pair of posts. (These details are mostly for my memory and are not particularly germane to the story.)

I had successfully removed the front two posts and extenders, and had disconnected the back to posts. So now we have a two-post and four-post structure. The two-post structure also has a lat-tower attached to the back. (The important thing there is it had "feet" on the back side that I assumed made the whole thing stable.)

I was up on the second step of a two-step stepstool when I felt the lat-tower two-post structure tip onto my shoulder.

Now, as the astute reader will note, if I pushed against this tower, the step stool would buckle under me. If I didn't push against it, the situation would eventually resolve itself anyway. At first I was able to hold it up, to try to figure out what to do.

I realized the gravity of the situation... no pun intended.

In no uncertain terms, I screamed for my life in the most guttural fashion. I screamed for Lauren, my wife, to come help me. She arrived to the room moments later, yelling at me asking for instructions. A handful of choice words later, she was pushing on the two-post structure, but considering the structure held a combined weight of something around the one-ton mark, she was unable to push it.

It's a bit blurry, but eventually there was no choice but to go _with_ the rack to the ground.

### Part Two: Better Than The Lottery
I laid on the ground stunned at first. The fall was oddly slow - I guess because it wasn't like something falling straight down off of a shelf. I was convinced that my legs would both be broken at least, and much more grisly at worst.

My wife still screamed at me, "are you okay!?"

I have to admit, at that moment, I did not know if I was okay.

Something had pinned my leg to the ground, but I was able to get out from under it. And, in a moment of absolute fortune, I stood up. Structurally, my bones seemed fine. I had some scrapes, but I was ok.

My whole family and I spent the next few minutes recovering emotionally from what happened. My children, 3 and 6 years old, hugged me before saying anything.

I surveyed what felt like the aftermath of a car accident in my interior gym, and realized there were about a billion ways this could have gone wrong.

I often think about alternative timelines and the "infinite universe" theory that inspired the movie Everything Everywhere All At Once. The tldr; - anything that could possibly happen is happening and has happened, because there is no known boundary on the universe... thus, all possible arrangements of matter are occurring in *some cosmic reality.*

I'm convinced that in almost every arrangement that was identical up to moments before that rack fell, the constituent parts of matter that make up my alter-egos are now in a grave.

That is, I did better than winning the lottery.

Winning the lottery is only applicable if you are alive. I guess if someone wins the lottery and dies, it passes on to their heirs or something - I imagine the lottery companies have a way of recouping if that person chose the lifetime payments over the lump sum. (Come to think of it, that's a mental model I should update; "consider the lump sum for reasons that go beyond the utilitarian calculation of the total amount.")

Anyway, I lived in this particular iteration.

Subsequent tests in the ER showed no major artery damage (which was a concern based on where my leg was pinned). Then, my calf started to get tight and red and warm... an indication of a potential clot. Another ultrasound later, no clot.

I escaped with just some very intense bruises. One was shaped, amusingly, like a t-bone steak.

### Three: Reflections
First, it's amazing how "narrowly escaping death" feels very much like a routine event. I don't know how much more it would have _hurt_ to die. Being an American citizen, after going to the ER, I went and ate cheesecake and watched fireworks that night at my sister's farm house.

It's odd to "get on with life", but the alternative seems worse: to bask in the nearness of death. And so things continue on with some regularity. I realized that people barely pause for you; and why should they? They themselves are living their lives, why should I take some of theirs?

I'd also like to say that the experience made me more patient, less easily frustrated, more grateful on a moment-to-moment basis. But, in honesty, I haven't noticed a major difference in that. Maybe it takes more near-death experiences, or maybe being frustrated sometimes is just normal.

I already think about death a lot. I have not yet reached the point in life where my fear of death is outpaced by my fatigue with living. I grew up in a (very authentic and loving) religious atmosphere. I make quite a few concessions about death to myself to try to deal with those thoughts: _there is nothing you can do, so why waste your time thinking about it? Millions have died before you. If you grieve what you will miss, you should also logically grieve what you missed before._

These thoughts masquerade as comforting, but are in fact distractions from the inevitable unknown eternity.

However, simultaneous to my darkest existential dread, I feel an overwhelming sense of gratitude. (Not in the every-minute, as I already mentioned... but in the reflective part of me.) For the confluence of factors that led me to where I am today, with the life I have to live.

### Four: Resolution

I'm convinced that part of our psyche is built to overindulge in what-ifs, and that it gets magnified in situations like this. I assume this is part of our natural survival learning so that these kinds of things don't repeat themselves. You see a tiger in that cave, you don't go back to that cave - that sort of thing.

The feeling was nothing short of anxiety-overwhelm thinking about what almost happened, what could have happened had any small variable been different.

The night after the accident I stood staring at the gym floor covered in haphazard, awkwardly balanced equipment laying everywhere. I stared mostly in awe. Every new glance, there was another reason or avenue for me to have been maimed or killed.

I think our brains don't really fully parse when a threat is no longer active. I don't know much about PTSD, but intuitively I imagine this is at least a component for some; even though the falling equipment was no longer threatening me, I still felt fragile.

And then it hits me: I *am* fragile. I make mistakes. In the grand scale of everything, this is just a whisper.

That feeling of fragility is at first uncomfortable. But then it becomes, in an odd way, comforting. We all are bound together by our fragility. Not just between life and death, but in everything we do.

I looked at the crossbar that saved my life; had it not been there, I wouldn't be here. The weights on the floor that could have fallen on my head. The bars horizontally that could have twisted and broken my legs like pieces of uncooked spaghetti.

Then, we cleaned it up.

My lovely wife helped me set the gym back up. We didn't just restore the functionality - we made it safer, and even upgraded it. Better space I've already gone back down to work out.

For me, this is resolution.

Jonathan Cutrell

Focus Beats Effort