Defining system boundaries for clear handoffs | Ramblin' & Amblin' | Oct 23, 2026

• UGtastic Archive

Defining system boundaries for clear handoffs | Ramblin' & Amblin' | Oct 23, 2026

Loading this player connects your browser to Youtube.

Full Transcript Available
LIVE CC UGtastic Archive

Press play or click any turn in the transcript to start real-time synchronized playback...

Ramblin' & Amblin' Field Notes with Mike Hall (Staff Software Engineer) Recorded on the move: engineering observations, systems architecture, and software craftsmanship reflections. • Series Playlist: https://www.youtube.com/playlist?list=PLNtb969T2-l0 • The Sound Above Curriculum: https://www.just3ws.com/series/the-sound-above/ • Canonical Profile: https://www.just3ws.com Spoken Overview: "So there's this thing I did called Panoramic View, and that was a name after the project, but in a nutshell I joined, it's on my resume, and it was an organization that had a long history,..." Recorded: October 23, 2026
The Interviewer

Mike Hall

Host, Ramblin' & Amblin'

The Presentation


Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
So there's this thing I did called Panoramic View, and that was a name after the project, but in a nutshell I joined, it's on my resume, and it was an organization that had a long history, so don't worry I'm not going to be negative here if anybody happens to be listening to this from OMF, it is a common problem that is going to be even more common in the face of AI, and that is that we have a system that the people who built it no longer exist, or in the case of AI never existed at all, now it's real, it's in production, people depend on it, the business is depending on it for something, but we're really not sure exactly how it works, because this is a system that has been developed over the course of acquisitions, I mean, you know, corporate acquis itions, teams merging, organizational restructures, boom and bust cycles, different teams, different organizational leadership, and I always look behind me because I want to just make sure I'm not blocking somebody. I was in one of these cases where there was a period of transition, new leadership, new organization, had recently started slightly before I joined, and there was massive changes in the organizational structure, which meant that where I was hired in the office was being closed, which meant that where I was hired in, the office was being closed, or had just been closed, and there was an exodus of people. So, these are just facts, there's nothing, like, statistically, this is all verifiable, and again, it's not negative, it just happens, there was major change, a lot of people left, because they didn't like the change. Well, you know, that happens.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
My opinions of it notwithstanding, what I was faced with, though, is I'm in a new organization, and I'm quickly realizing that I'm the senior most engineer in this particular space. And this particular space happened to be the customer facing surface for loan acquisition and higher and orig ination flow. And the challenge was, because of all this attrition, because of so much turnover, that when I would be on incident calls, it would be real clear that we didn't know who was responsible for a fix, or where the issue might reside. So, I said, "What can I do to ensure that when it's my space's responsibility that we are able to act quickly and target the problem quickly and efficiently with the least amount of stress?" Or, be able to understand that it was, in fact, not in our wheelhouse.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
And it's not a hot potato thing, it is a "put the potato in the right chef's hands and work with them." So, it was about, you know, triage and who is required for this situation. Is this something that was within my space, my area of responsibilities, technical responsibility, affected? Or, do we need to call somebody else from another team? Okay, so, in order to do that, I need to know a few things.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
I need to know what the boundaries of my system are. Okay, and in order to know the boundaries where it is a handoff to another team, I'm going to have to be able to identify when an error has happened after. Or, as a result of that boundary, or whether or not the error was on our side in either our handling or sending of the request, of the interaction. Okay, so, outer boundaries.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
So, map those out. So, finding all of the egress and ingress points of the system was critical. And that was a technical thing I could do, largely off of even logging. And just knowing rails and having enough experience in the system.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
I've got the boundaries. So, now we know where the handoff is. And this even requires sitting down with the other teams that are responsible for the handoffs. And saying, is this, in fact, where you think the boundary is?
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
Is this accurate? So, what we get out of there is, one, not just I feel better, because now I know. But we have a documented agreement. And we have a shared, improved shared understanding, not just the team, but with our collaborators.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
The people on the other team who are responsible. And this helps with rebuilding collaborative relationships when context has been lost. So, I did that. I worked out.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
And I even made some friends along the way. Alright, so, step one. Define your boundaries. Define all your ingress and egress points.
Mike Hall Host, Ramblin' & Amblin' ▶ Speaking
Alright, next one. And another. Alright, thanks, bye.