4 ms·

> Another thing they did was disband the regular meetings of all of the senior engineers, and even told us to stop collaborating with each other a few times. I'

> Another thing they did was disband the regular meetings of all of the senior engineers, and even told us to stop collaborating with each other a few times. I'm not 100% sure I can pin this one on Team Topologies, although it the book does promote the idea of trying to control communication between teams. Someone at your company got a mandate to change the culture, and with such a mandate power gets shuffled around. The power was taken away from engineering teams that needed it. I wouldn't say they were doing it wrong, just two things were happening simultaneously and the politics of power weren't paid attention to. I read team topologies and found it to lack any novel insight but given its popularity I just took it as a presentation of the current jargon. It presents a sort of model for thinking about the organizational structures that you may already see popping up. Depending on your organization, you may end up with a unit of DBAs, the original enabling team. If they are doing their job well then they ignore the teams that have services with ordinary database usage and spend a lot of time helping teams with heavy db reliance optimize their usage. If they are pathological, they claim ownership of the entirety of database usage over an organization and everybody suffers. If a stream aligned team has to ask permission to do anything with a db, with a message broker, with a queue, with firewalls, with deployment, with testing, then congratulations, you built multiple walls of confusion. Enabling doesn't mean dictation. And as pointed out by others here, the lines between the enabling team, the complicated subsystem and the platform teams are not bright, they are blurry lines. Team topologies are somewhat orthogonal to power topologies. Every organizational structure can be subverted to take power away from those that need it.

denton-scratch 3y ago
> a unit of DBAs, the original enabling team My experience of DBA teams (at a bank) was that they were desperately slow at approving anything (and all changes had to be approved by DBAs). We had a DB query in the software for the Fraud Department that was very slow - it was taking several minutes to run, leading the fraud team to take frequent coffee breaks. I added an index to the schema, which led to a 1000x improvement in performance. It took 4 months for the DBAs to approve putting it into production. Sure: adding an index could have hit performance in some other system; and the index was on the main Customer table. The change did need wider testing than I could do myself. But 4 months? That's not an "enabling" team, that's an "obstructing" team.
- willcipriano 3y ago
  If you take 4 months to approve a change of mine beacuse you need to "test it" you'd better be prepared to explain how any issues that might crop up got past 500+ man hours of testing.
- BlackFly 3y ago
  Right, so your experience was that the dba team wasn't an enabling team but instead a complicated subsystem team. I would argue, and you seem to agree, that streams need to own their own database, some dbas don't want that and they get caught up performing all the toil on the databases instead of solving just the interesting problems that require their skillset. Yes, these things happen. You should be calling the dbas in (for example) when you need help configuring autovacuums because you have so much load on the db during ordinary operations that a poorly timed autovacuum can cause massive service disruption. Inevitably, some banks will come to view their accounting database as a complicated subsystem in and of itself possibly to the chagrin of the accounting application engineers. A DBA performing execution of an index migration is usually not a good use of their expertise.
  - denton-scratch 3y ago
    Yeah. But no vacuums; this was Oracle (I think) 7 or 8. The database I was messing with was THE corporate database; and the table I wanted a new index on was THE Customer table. They had every right, even responsibility, to make sure I hadn't broken some other system. But they were so SLOOW. My suspicion is that they didn't like it that someone who wasn't in the DBA club had found an improvement to their schema. They definitely had a walled and moated fortress.
robertlagrant 3y ago
> Team topologies are somewhat orthogonal to power topologies This is a great summary.

denton-scratch 3y ago

> a unit of DBAs, the original enabling team My experience of DBA teams (at a bank) was that they were desperately slow at approving anything (and all changes had to be approved by DBAs). We had a DB query in the software for the Fraud Department that was very slow - it was taking several minutes to run, leading the fraud team to take frequent coffee breaks. I added an index to the schema, which led to a 1000x improvement in performance. It took 4 months for the DBAs to approve putting it into production. Sure: adding an index could have hit performance in some other system; and the index was on the main Customer table. The change did need wider testing than I could do myself. But 4 months? That's not an "enabling" team, that's an "obstructing" team.

willcipriano 3y ago
If you take 4 months to approve a change of mine beacuse you need to "test it" you'd better be prepared to explain how any issues that might crop up got past 500+ man hours of testing.
BlackFly 3y ago
Right, so your experience was that the dba team wasn't an enabling team but instead a complicated subsystem team. I would argue, and you seem to agree, that streams need to own their own database, some dbas don't want that and they get caught up performing all the toil on the databases instead of solving just the interesting problems that require their skillset. Yes, these things happen. You should be calling the dbas in (for example) when you need help configuring autovacuums because you have so much load on the db during ordinary operations that a poorly timed autovacuum can cause massive service disruption. Inevitably, some banks will come to view their accounting database as a complicated subsystem in and of itself possibly to the chagrin of the accounting application engineers. A DBA performing execution of an index migration is usually not a good use of their expertise.
- denton-scratch 3y ago
  Yeah. But no vacuums; this was Oracle (I think) 7 or 8. The database I was messing with was THE corporate database; and the table I wanted a new index on was THE Customer table. They had every right, even responsibility, to make sure I hadn't broken some other system. But they were so SLOOW. My suspicion is that they didn't like it that someone who wasn't in the DBA club had found an improvement to their schema. They definitely had a walled and moated fortress.

robertlagrant 3y ago

> Team topologies are somewhat orthogonal to power topologies This is a great summary.