Splitting engineering teams into defense and offense

This pattern has a smell. If you&#x27;re shipping continuously then your on-call engineer is going to be fixing the issues the other engineers are shipping, instead of those engineers following up on their deployments and fixing issues caused by those changes. If you&#x27;re not shipping continuously, then anyway customer issues can&#x27;t be fixed continuously, and your list of bugs can be prioritized by management with the rest of the work to be done. The author quotes maker vs. manager schedules, but one of the conclusions of following that is that engineers <i>don&#x27;t</i> talk directly to customers, because &quot;talking to customers&quot; is another kind of meeting, which is a &quot;manager schedule&quot; kind of thing rather than a &quot;maker schedule&quot; kind of thing.<p>There&#x27;s simply no substitute for Kanban processes and for proactive communication from engineers. In a small team without dedicated customer support, a manager takes the customer call, decides whether it&#x27;s legitimately a bug, creates a ticket to track it and prioritizes it in the Kanban queue. An engineer takes the ticket, fixes it, ships it, communicates that they shipped something to the rest of their team, is responsible for monitoring it in production afterwards, and only takes a new ticket from the queue when they&#x27;re satisfied that the change is working. But the proactive communication is key: other engineers on the team are also shipping, and everyone needs to understand what production looks like. Management is responsible for balancing support and feature tasks by balancing the priority of tasks in the Kanban queue.

I once worked for a company that required from each engineer in the team to do what they called “firefighting” during working hours (so not exactly on-call). So for one week, I was triaging bug tickets and trying to resolve them. These bugs belonged to the area my team was part of, so it affected the same product but a vast amount of micro services, most of which I didn’t know much about (besides how to use their APIs). It didn’t make much sense to me. So you have Joe punching code like there’s no tomorrow and introducing bugs because features must go live asap. And then it’s me the one fixing stuff. So unproductive. I always advocated for a slower pace of feature delivery (so more testing and less bugs on production) but everyone was like “are you from the 80s or something? We gotta move fast man!”

Having a proportion of the team act as triage for issues &#x2F; alerts &#x2F; questions &#x2F; requests is a generally good pattern that I think is pretty common - especially when aligned with an on-call rotation. I&#x27;ve done it a few times by having a single person in a team of 6 or 7 do it. If you&#x27;re having to devote 50% of your 4-person team to this sort of work, that suggests your ratios are a bit off imo.<p>The thing I found most surprising about this article was this phrasing:<p>&gt; We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.<p>This suggests that this pair of people only release 1 big PR for that whole cycle - if that&#x27;s the case this is an extremely late integration and I think you&#x27;d benefit from adopting a much more continuous integration and deployment process.

&gt; While this is flattering, the truth is that our product is covered in warts, and our “lean” team is more a product of our inability to identify and hire great engineers, rather than an insistence on superhuman efficiency.<p>&gt; The result is that our product breaks more often than we’d like. The core functionality may remain largely intact but the periphery is often buggy, something we expect will improve only as our engineering headcount catches up to our product scope.<p>I really resonate with this problem. It was fun to read. We&#x27;ve been tried different methods to balance customers and long-term projects too.<p>Some more ideas that can be useful:<p>* Make quality projects an explicit monthly goal.<p>For example, when we noticed our the edges in our surface area got too buggy, we started a &#x27;Make X great&#x27; goal for the month. This way you don&#x27;t only have to react to users reporting bugs, but can be proactive<p>* Reduce Scope<p>Sometimes it can help to reduce scope; for example, before adding a new &#x27;nice to have feature&#x27;, focus on making the core experience really great. We also considered pausing larger enterprise contracts, mainly because it would take away from the core experience.<p>---<p>All this to say, I like your approach; I would also consider a few others (make quality projects a goal, and cut scope)

When you get to that stage, software engineering has failed fundamentally.<p>This is akin to having a boat that isn&#x27;t seaworthy, so the suggestion is to have a rowing team and a bucket team. One rows, and the other scoops the water out. While missing the actual issue at hand. Instead, focus on creating a better boat. In this case, that would mean investing in testing: unit tests, integration tests, and QA tests.<p>Have staff engineers guide the teams and make their KPI reducing incidents. Increase the quality and reduce the bugs, and there will be fewer outages and issues.

Neat article - I know the author mentioned this in the post, but I only see this working as long as a few assumptions hold:<p>* avg tenure &#x2F; skill level of team is relatively uniform<p>* team is small with high-touch comms (eg: same&#x2F;near timezone)<p>* most importantly - everyone feels accountable and has agency for work others do (eg: codebase is small, relatively simple, etc)<p>Where I would expect to see this fall apart is when these assumptions drift and holding accountability becomes harder. When folks start to specialize, something becomes complex, or work quality is sacrificed for short-term deliverables, the folks that feel the pain are the defense folks and they dont have agency to drive the improvements.<p>The incentives for folks on defense are completely different than folks on offense, which can make conversations about what to prioritize difficult in the long term.

If the event-driven &#x27;fixing problems&#x27; part of development gets separated from the long-term &#x27;feature development&#x27;, you&#x27;re building a disaster for yourself. Nothing more soul-sucking than fixing other people&#x27;s bugs while they happily go along and make more of them.

&gt; this is also a very specific and usually ephemeral situation - a small team running a disproportionately fast growing product in a hyper-competitive and fast-evolving space.<p>This is basically how we ran things for the reliability team at Netflix. One person was on call for a week at a time. They had to deal with tickets and issues. Everyone else was on backup and only called for a big issue.<p>The week after you were on call was spent following up on incidents and remediation. But the remaining weeks were for deep work, building new reliability tools.<p>The tools that allowed us to be resilient enough that being on call for one week straight didn&#x27;t kill you. :)

This is often harder at large companies because you very rarely make career progress playing defense, so it becomes very tricky to do it fairly. It can work wonders if you have the right teammates, but it’s almost a prisoners dilemma game that falls apart as soon as one person opts out.

To the people pooh poohing this, do y’all really work with such terrible coworkers that you can’t imagine an effective version of this?<p>You need trust in your team to make this work but you also need trust in your team to make any high velocity system work. Personally, I find the ideas here extremely compelling and optimizing for distraction minimization sounds like a really interesting framework to view engineering from.

Small teams shouldn&#x27;t split like this IMHO. It&#x27;s better&#x2F;smarter&#x2F;faster IMHO to do &quot;all hands on deck&quot; to get things done.<p>For prioritization, use a triage queue because it aims the whole team at the most valuable work. This needs to be the mission-critical MVP &amp; PMF work, rather than what the article describes as &quot;event driven&quot; customer requests i.e. interruptions.

I think they’re on to something, but the solution needs more work. Sometimes it’s not just individual engineers who are playing defence, it’s whole departments or whole companies that are set up around “don’t change anything, you might break it”. Then the company creates special “labs” teams to innovate.<p>To borrow a football term, sometimes company structure seems like it’s playing the “long ball” game. Everyone sitting back in defence, then the occasional hail mary long pass up to the opposite end. I would love to see a more well developed understanding within companies that certain teams, and the processes that they have are defensive, others are attacking, and others are “mid field”, i.e. they’re responsible for developing the foundations on which an attacking team can operate (e.g. longer term refactors, API design, filling in gaps in features that were built to a deadline). To win a game you need a good proportion of defence, mid field and attack, and a good interface between those three groups.

IMO the split, although good (the pattern is &quot;sacrifice one person&quot; as per Coplien&#x2F;Harrision&#x27;s Organisational patterns book [0]), is too drastic. It should be not defense vs offense 100% with a wall inbetween, but for each and every issue (defense) and&#x2F;or feature (offense), someone has to pick it and become the responsible (which may or may not mean completely doing it by hirself). Fixing a bug for an hour-or-two sometimes has been exactly the break i needed in order to continue digging some big feature when i feel stuck.<p>And the team should check the balances once in a while, and maybe rethink the strategy, to avoid overworking someone and underworking someone else, thus creating bottlenecks and vacuums.<p>At least this is the way i have worked and organised such teams - 2-5 ppl covering everything. Frankly, we never had many customers :&#x2F; but even one is enough to generate plenty of &quot;noise&quot; - which sometimes is just noise, but if good customer, will be mostly real defects and generally under-tended parts. Also, good customers accept a NO as answer. So, do say more NOs.. there is some psychological phenomena in software engineering in saying yes and promising moonshots when one knows it cannot happen NOW, but looks good..<p>have fun!<p>[0] <a href="https:&#x2F;&#x2F;svilendobrev.com&#x2F;rabota&#x2F;orgpat&#x2F;OrgPatterns-patlets.html" rel="nofollow">https:&#x2F;&#x2F;svilendobrev.com&#x2F;rabota&#x2F;orgpat&#x2F;OrgPatterns-patlets.h...</a>

Interesting concept. Certainly worth trying, but in the name of offense (read: being proactive):<p>- &quot;and our “lean” team is more a product of our inability to identify and hire great engineers, rather than an insistence on superhuman efficiency.&quot;<p>Can we all at some point have a serious discussion on hiring and training. It seems that many teams are unstaffed or at least not satisfied with the quality and quantity of their team. Why is that? Why does it seem to be the norm?<p>- what about mitigating bugs in the first place? Shouldn&#x27;t someone be assigned to that? Yeah, sure, bugs are a given. They are going to happen. But in production bugs are something real and paying customers shouldn&#x27;t experience. At the very least what about feature flags? That is sonething new is introduced to a limited number of user. If there&#x27;s a bug and it&#x27;s significant enough, the flag is flipped and the new feature withdrawn. Then the bug can be sorted as someone is available.<p>Prehaps the profession just is what it is? Some teams are almost miraculously better than others? Maybe that&#x27;s luck, individuals, product, and&#x2F;or the stack? Maybe like plumbers and shit there are just things that engineering teams can&#x27;t avoid? I&#x27;m not suggesting we surrender, but that we become more realistic about expectations.

We have a person who is &#x27;Batman&#x27; to triage production issues. Generally they&#x27;ll pick up smaller sprint tasks. It rotates every week. It&#x27;s still stuff from the team so they aren&#x27;t doing stuff unknown (or if they are, it&#x27;s likely they&#x27;ll work on it soon).<p>The aim is generally not to provide a perfect fix but an MVP fix and raise tickets in the queue for regular planning.<p>It rotates round every week or so.<p>My company&#x27;s not very devops so it&#x27;s not on-call, but it&#x27;s &#x27;point of contact&#x27;.

I can&#x27;t be the only one who finds the graphics at the top of this article off-putting. I find it hard to take someone seriously when they plaster GenAI slop across the top of their blog.<p>That said, there&#x27;s some credence to what the author is describing. Although I haven&#x27;t personally worked under the exact system described, I <i>have</i> worked in environments where engineers take turns being the first point of contact for support. In my experience, it worked pretty well. People know your bandwidth is going to be a bit shorter when you&#x27;re on support, and so your tasks get dialed back a bit during that period.<p>I think the author, and several people in the comments, make the mistake of assuming that an &quot;engineer on support&quot; necessarily can fix any given problem they are approached with. Larger firms could allocate a complete cross-functional team of support engineers, but this is very costly for small outfits. If you have mobile apps, in-house hardware products and&#x2F;or integrations with third-party hardware, it&#x27;s basically guaranteed that your support engineer(s) will eventually be given a problem that they don&#x27;t have the expertise to solve.<p>In that situation, the support engineer still has the competencies to figure out who <i>does</i> know how to fix the problem. So, the support engineer often acts more as a dispatcher than a singular fixer of bugs. Their impact is still positive, but more subtle than &quot;they fix the bugs.&quot; The support engineer&#x27;s deep system knowledge allows them to suss out important details before the bug is dispatched to the appropriate dev(s), thereby minimizing downtime for the folks who will actually implement the fix.

I think interruptions damage the productivity overall, not only of engineers. Maybe some are unaware of it, and others simply don’t care. They don’t want to sacrifice their own productivity by waiting on someone busy, so they interrupt and after getting the information they want, they feel good. From their perspective, the productivity increased, not decreased.<p>Some engineers are more likely to avoid interrupting others because they can sympathize.

<i>Constantly</i> working in what OP describes as defence might also be negatively affecting the perception of cause and effect of own actions:<p><pre><code> Specifically, we show that individuals following clock-time [where tasks are organized based on a clock**] rather than event-time [where tasks are organized based on their order of completion] discriminate less between causally related and causally unrelated events, which in turn increases their belief that the world is controlled by chance or fate. In contrast, individuals following event-time (vs. clock-time) appear to believe that things happen more as a result of their own actions.[0] </code></pre> ** - in my experience, clock based organisation seems to be very characteristic to what OP describes as defensive, when you become driven by incoming priorities and meetings<p>Broader article about impact of schedules at [1] is also highly relevant and worth the read.<p><pre><code> [0] - https:&#x2F;&#x2F;psycnet.apa.org&#x2F;record&#x2F;2014-44347-001 [1] - https:&#x2F;&#x2F;hbr.org&#x2F;2021&#x2F;06&#x2F;my-fixation-on-time-management-almost-broke-me</code></pre>

My first job had a huge QA team. It was my job to work quickly and it was their job to find the issues. This actually set me up really poorly because I got in the habit of not doing proper QA. There were at least 10 people doing it for me. When I left it took awhile for me to learn what properly QAing my own worked looked like.

Our team ended up having the oncall engineer for the week also work primarily on bug squashing and anything that makes support easier. Over time the support and monitoring becomes better. Basically dedicated tech debt capacity, which has worked well for us.

It feels like having 50% of your team&#x27;s time be spent on urgent support, triage and bugs is a lot. That seems like a much better thing to solve versus trying to work around the issue by splitting the team. Probably having those people fix bugs while a 4 week re-factor in a secluded branch is constantly in process doesn&#x27;t help with efficiency or bug rate.

This is a common &quot;pattern&quot; on well-ran ops teams. The work of a typical ops team consists of a lot of new work but tons of interruptions come in as new issues arise and must be dealt with. So we would typically assign 1 engineer (who was also typically on call) a lighter workload and would be responsible for triaging most issues that came in.

The proposed strategy will work, as will plenty of others, because it&#x27;s a small team. That is the fundamental reason. Small teams are more efficient. So if you&#x27;re managing a team of 10+ individuals: split them in 2 teams and keep them out of each other&#x27;s way&#x2F;harm.

I like the approach as it is easy to explain and it is having catchy names.<p>But sounds like there has to be a lot of micro management involved and when you have team of 4 it is easy to keep up but as soon as you go to 20 and that increase also means much more customer requests it will fall apart.

This is probably devops. A single team talking full responsibility and swapping oncall-type shifts. These guys know their dogfood.<p>You want the defensive team to work on automating away stuff that pays off for itself in the 1-4 week timeframe. If they get any slack to do so!

Everyone on every team should have something to &quot;own&quot; and feel proud of. You don&#x27;t &quot;own&quot; anything if you&#x27;re always on team defense. Following this advice is a sure fire way to have a high churn rate.

Ha - I think greptile was my first email address!<p>Reptile was my favorite Mortal Kombat character, and our ISP added a G before all the sub accounts. They put a P in front of my dad&#x27;s.

And, what else?<p>Putting a couple of buzzwords on a practice being performed for at least 15 years now doesn&#x27;t make you clever. Quite the opposite in fact.

Don&#x27;t do this to yourself.<p>There are 2 fundamental aspects of software engineering:<p>Get it right<p>Keep it right<p>You have only 4 engineers on your team. That is a tiny team. The entire team SHOULD be playing &quot;offense&quot; and &quot;defense&quot; because you are all responsible for getting it right and keeping it right. Part of the challenge sounds like poor engineering practices and shipping junk into production. That is NOT fixed by splitting your small team&#x27;s cognitive load. If you have warts in your product, then all 4 of you should be aware of it, bothered by it and working to fix it.<p>Or, if it isn&#x27;t slowing growth and core metrics, just ignore it.<p>You&#x27;ve got to be comfortable with painful imperfections early in a product&#x27;s life.<p>Product scope is a prioritization activity not an team organization question. In fact, splitting up your efforts will negatively impact your product scope because you are dividing your time and creating more slack than by moving as a small unit in sync.<p>You&#x27;ve got to get comfortable telling users: &quot;that thing that annoys you, isn&#x27;t valuable right now for the broader user base. We&#x27;ve got 3 other things that will create WAY MORE value for you and everyone else. So we&#x27;re going to work on that first.&quot;

Getting so tired of the war metaphors in attempts to describe software development. We solve business problems using code, we don&#x27;t make a living by role-playing military tactics. Chill out my dudes

Somewhat random side note - I find it so fascinating that developers invented this myth that they’re the only people who have ‘concentration’ when this is so obviously wrong. Ask any ‘knowledge worker’ or yell even physical labourer and I’m sure they’ll tell you about the productivity of being &quot;in the zone&quot; and lack of interruptions. Back in early 2010s they called it ‘flow’.

What&#x27;s wrong with collaboratively working together? Why is there a need to create an atificial competition between a &quot;offence&quot; and a &quot;defence&quot; team?<p>And why should team members be collaborative amongst their team? E.g. why should the &quot;offence&quot; team members suddenly help each other if it&#x27;s not happening generally?<p>This sounds a lot like JDD - Jock Driven Development.<p>Perhaps the underlying problems of &quot;don&#x27;t touch it because we don&#x27;t understand it&quot; should be solved before engaging in fake competition to increase the stress levels.

Many are complaining that this way the engineers are incentivised to carelessly create bugs because they have to ship fast and won’t be responsible for fixing them.<p>That’s easy to fix with an exception: you won’t have to worry about support for X time unless you’re the one who recently made the bug.<p>It turns out that once they’re responsible for their bugs, there won’t actually be that many bugs and so interruptions to a focused engineer will be rare.<p>That&#x27;s how we do it in my startup. We have six engineers, most are even pretty junior. Only one will be responsible for support in any given sprint and often he’ll have time left over to work on other things e.g. updating dependencies.