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.