←back to thread

Splitting engineering teams into defense and offense

(www.greptile.com)
210 points dakshgupta | 1 comments | 14 Oct 24 20:07 UTC | HN request time: 0.253s | source
Show context
Attummm ◴[15 Oct 24 12:56 UTC] No.41848077[source]▶
When you get to that stage, software engineering has failed fundamentally.

This is akin to having a boat that isn'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.

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.

replies(4): >>41848735 #>>41849757 #>>41849885 #>>41852908 #
ericmcer ◴[15 Oct 24 15:56 UTC] No.41849885[source]▶
You are viewing it like an engineer. From a business perspective if you can keep a product stable while growing your user base until you become an attractive acquisition target then this is a great strategy.

Sometimes as an engineer I like the frantically scooping water while we try to scale rapidly because it means leaderships vision is to get an exit for everyone as fast as possible. If leadership said "lets take a step back and spend 3 months stabilizing everything and creating a testing/QA framework" I would know they want to ride it out til the end.

replies(1): >>41850704 #
1. Attummm ◴[15 Oct 24 17:10 UTC] No.41850704[source]▶
I think you're not following what I tried to convey.

It shouldn't have ever come to the point where incidents, outages, and bugs have become prominent enough to warrant a team.

Either have kickass dev(s), although improbable, thus the second level: Implement mitigations, focus on testing, and have staff engineers with KPIs to lower incidents. Give them them the space but be prepared to let them go if incidents don't go down.

There is no stopping of development. Refactoring by itself doesn't guarantee better code or fewer incidents. But don't allow bugs, or known issues, as they can be death by thousand cuts.

The viewpoint is from not an engineer. Having constant incidents doesn't show confidence or competence to investors and customers. As it diverts attention from creating business value into firefighting, which has zero business value and is bad for morale.

Thus, tech investment rather than debt always pays off if implemented right.