Carragee Consulting

Inexcusable mistakes | Fast & Slow Dev Cycles | Centralized or Distributed Data Teams

I was listening to Benjamin Rogojan’s interview with Ethan Aaron on data team structures.

Ben asks which model Ethan supports, centralized vs embedded in business units and Ethan explains the pros and cons of each.

One of the points Ethan made was that some centralized teams makes themselves organizationally redundant and irrelevant by following a long and robust dev cycle for every type of data request, even ad hoc / one time data pulls.

This strict adherence to process “best-practices” may be a good CYA strategy and it’s critical for SOME reporting and analytics, but when the data team can’t deliver fast enough the business still needs to make decisions and either goes with their gut or finds a way to the data themselves — spreadsheets!

If this cycle happens repeatedly individual groups train up their business folks to be more self-sufficient and eventually hire on people to improve their data infrastructure and bring in new tools.

Some cases when you really need a robust testing process are when you do external financial reporting, when you’re developing anything medical, and when you are handling payroll and major financial transactions.

I’m not sure yet if it’s the fault of U.S. Bank who processes Ramsey County’s online property tax payments, or the County but somehow they drafted my biannual taxes twice (once when I paid in Sept and this morning).

It’s also possible I’m the only person affected and/or it’s somehow user error, but I doubt it. [UPDATE: I spoke to the County. It’s not just me, it’s an issue which impacted 678 Ramsey County tax payers]

When developing payment processing, pricing systems, payroll and financially reporting — consider that you should take the slower but highly tested dev cycles.

https://www.linkedin.com/feed/update/urn:li:activity:7108599586918699009/?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3BIyWxOSSFT4m1%2F69R6Iw2lw%3D%3D