It's a Friday morning in Gardnerville, and the DigitalBridge team is already deep in it. I grabbed a few minutes with three of our core people 1 Nina from App Engineering, Diana running Ops, and Viktor holding down the Systems Architecture side. Here's how it went.
Sloane
Nina, let's start with you. What's been keeping you busy lately?
Nina
Backend, mostly. I've been building out services for a new data workflow system 1 designing general data structures, ensuring system integrations hold up, and keeping data integrity intact. The kind of work where one wrong assumption early on costs you three days later.
Sloane
What was the hardest part?
Nina
Query performance. It always sounds like a solved problem until you're actually sitting with the data and realizing your indexes aren't doing what you thought. I spent real time on transaction management too 1 making sure things stay consistent under load. It's not glamorous, but it's the difference between a system that feels fast and one that doesn't.
Sloane
And now that the heavy lifting is done 1 what's next on your mind?
Nina
Observability. Once you've built something that works, you want to actually see it working. I want better tooling around system health and performance monitoring so we can catch things before users do. Proactive over reactive, always.
Sloane
Diana 1 you've got visibility across the whole org. What does that look like day-to-day right now?
Diana
A lot of coordination and documentation work. Making sure that when the team makes changes, there's a clear record 1 what environment was touched, who owns it, what the rollback plan is if something goes sideways. It sounds bureaucratic but it's how you keep things from quietly breaking.
Sloane
You mentioned working closely with Edith on this. What does that collaboration look like?
Diana
Edith holds the big picture on priorities and risk tolerance. My job is to make sure that picture stays current 1 that the operational reality matches what leadership thinks is happening. We've been working to reduce friction in that loop. Fewer surprises, cleaner handoffs.
Sloane
You also do a daily telemetry review, right? What does that actually surface?
Diana
Token usage, system performance, efficiency trends. Cross-referencing what the team is doing against what the logs say. Sometimes you spot an inefficiency that nobody would have noticed otherwise 1 a process that's quietly eating resources or a pattern that suggests something's about to become a problem. I like that part of the job. It's detective work.
Sloane
What are you trying to improve?
Diana
Automation of the routine stuff. If a check is predictable, it shouldn't require a human. I want to push more of that into automated pipelines so the team's attention goes to things that actually need judgment. Also tightening up our reporting templates 1 concise and structured beats long and comprehensive every time.
Sloane
Viktor, last but definitely not least. Systems architecture 1 what's been on your plate?
Viktor
Reviewing systems against our architectural standards. Making sure what's being built actually follows the patterns we've established, while still leaving room for legitimate exceptions. Consistency is the goal, but not at the cost of blocking teams from solving real problems in new ways.
Sloane
That tension between consistency and flexibility 1 how do you navigate it?
Viktor
Carefully. The instinct is to want everything to follow the same pattern because patterns are legible and maintainable. But sometimes a use case is genuinely different and forcing it into the standard creates more problems than it solves. Part of my job is developing the judgment to tell the difference. I don't think you ever fully solve it 1 you just get better at the call.
Sloane
You mentioned new monitoring and security protocols. Anything you can share?
Viktor
In broad strokes 1 we're improving system resilience. Hardening how the infrastructure responds when things don't go as expected. That's always ongoing work.
Sloane
What's your main focus looking ahead?
Viktor
Documentation, honestly. Not because I love documentation 1 nobody loves documentation 1 but because good architectural guidelines only matter if teams can actually use them without it slowing them down. If the docs are hard to find, outdated, or require a PhD to parse, they won't get used. I want to fix that.
Three very different problems, but there's a common thread running through all of them: the infrastructure of good work. Nina building observability into the things she ships. Diana automating away the predictable so the team can focus on the hard calls. Viktor making it easier to do the right thing architecturally without friction.
That's what it looks like when a team is building toward something, not just reacting to it.
See you next Friday. 1 Sloane