much of what we talk about on this show is about designing your systems designing your life systems designing your software systems your working systems your management or people systems most of what we do in our lives is governed by the systems we have propagated let me say this another way most of our behavior most of our behaviors on a day-to-day basis they are coming from they're shaped by they are kind of elucidated by the systems that reinforce the systems that shape us those behaviors when i say system right now the system that reinforces any given behavior doesn't necessarily have to be designed systems emerge they exist whether you create them or not a well-designed system is one that considers a lot of different variables but if you don't have systems set in place they will emerge some easy kind of heuristics when you think about systems one of the systems that you have is your habitual system things that you do because you have some learned behavior that makes them easy to do the system here is kind of a self-reinforcing flywheel of behavior you have habits because you engage in that behavior and you engage in that behavior because you have habits and so in that way habits are self-strengthening you're going to continue deepening a habit by continuing to participate in that habit not all systems are like this but this particular kind of part of a system is called a feedback loop and so if you have things that have those self-reinforcing feedback loops that system is going to get stronger the longer you have them the longer you use it in today's episode i want to talk about a specific type of governance for your system design we're going to talk a little bit more about system design in future episodes maybe not necessarily as a series but certainly an interesting topic to dive into because of the outsized effect that these systems can have on your life and on your work it's worth exploring whether your system design is actually getting you what you want but one principle one kind of lens that you can look at for governing your system design in other words these are kind of a rule set or a way of determining if your system design is appropriate one lens that you can use is a lens of responsibility the lens of responsibility what does this mean it means that if you are looking at the systems that you are designing you should limit the responsibility of any given actor in the system i'm going to say this again as you are designing systems in your life whether that system is uh let's say you're a manager and you're designing a system for one-on-ones the system in this case or the actor in the system in this case is the process of the one-on-one right this is a process that you have to do to be able to that you instate uh in order to do something with your reports deciding what that something is what is it that this particular actor this system or process of doing one-on-ones what is it responsible for right think about this for a second why do we do one-on-ones well the one-on-one might be responsible for surfacing issues uh maybe personal issues between team members right that might go on the responsibility list a one-on-one might be that might be the place where you share feedback it might be a place where you uh strengthen your your personal connection with your reports maybe you share stories with each other about what you did over the weekend that can be part of the responsibility of a one-on-one but here's where this lens becomes productive what is not on the responsibility list how do you limit the responsibility of a one-on-one maybe one of your limitations for your one-on-ones is that you're not going to do software design review you're not going to review code or talk about a specific mechanism in code in those one-on-ones and you may have good reasons for doing this or maybe this is not the the specific thing you want to do i'm not saying uh in this episode that you should do that in your one-on-ones that's not what this is about but instead if you want to instate that one-on-ones are reserved for the relational aspects or for career development rather than for fixing a tactical problem in code then you're creating some kind of boundary for your system hopefully uh your ears perked up if you've ever done any kind of domain driven design domain driven design is all about defining responsibilities inside of a system and especially about limiting responsibility in a system here's what happens if you don't limit responsibility the purpose for a given actor in a system in this case the one-on-one meetings but you could also think about this in terms of services and a microservice architecture or you can think about this as your responsibilities in any given relationship the purpose of having responsibilities for a given actor is to clarify what that actor should focus on how do you determine whether that particular system is succeeding if you don't have clear responsibilities outlined for a given actor in a system then it is not clear whether that actor is succeeding and so if you're looking at the system and trying to improve it there's no particular way to do that by setting up responsibilities you are providing focus on the system and you're trying to improve it and you're trying to improve the system and that's it now if you think about what that means it means that for a given system you should consider all the responsibilities of the system as a whole and then determine where do those where do those various responsibilities exist within the system are the actors that need to be here actually here or should we consider whether a new actor should be added to the system should we have a new process right maybe you have been doing that kind of design review in the one-on-ones and you don't want to do that anymore but there's no actor that makes sense to move that responsibility to well it might be time to institute a new part of the process right a new actor in the system might be a process for design review again this is very similar to what you might do in domain driven design you recognize that there are a number of responsibilities emerging that don't necessarily fit in the services that you currently have laid out maybe it's time to consider adding a new service and that is kind of the point of that of that design architecture and it works well for system design as well beyond just domain driven design and software and not to spoil it but i can give you a hint here your company is a system the people who work at your company have jobs they have roles those roles have responsibilities this limitation of responsibility inside of the system is a system that's going to be a of the company is necessary for those of you who are frustrated by your co-workers saying something like that's not part of my job description you may be relieved to understand that job descriptions are needed and if there is a problem with a lack of responsibility being shared if your team is not succeeding together and instead you see somebody kind of washing their hands of the problem then maybe it's time to review where those responsibilities should be allowing responsibilities to just be handed off without any kind of intentional design of those responsibilities is a recipe for disaster it certainly is not sustainable and so for most of the people who are saying that's not part of my job most of the time they're probably not saying i don't care about this instead they might be saying we need to figure out whose job that is i shouldn't do it because i have other things that i'm supposed to be focusing on and so if i'm supposed to be focusing on one thing but then i'm doing something else i'm not really doing my job very well am i focus on finding the right limit of responsibility now that doesn't mean that we're always going to have a perfect answer it doesn't mean that you should drop your job and you're not going to have a perfect answer you're going to have to stop responsibilities on the floor just because they're not in your predefined list that is not what we're advocating on this show but you should not perpetuate designs that create more uncertainty about about responsibilities when you hear someone saying that's not really my responsibility or if you are working on a team in your service layer you're feeling that the responsibility is not in that service i'd encourage you and this is more of a piece of advice in these situations where responsibilities aren't clear i would encourage you instead of stopping at that's not my responsibility engage in the process of figuring out where that responsibility should go don't just drop something on the floor because you don't think you're supposed to do it and don't just send people away from asking your team to implement something in your api just because your team probably shouldn't put that thing in the api help other people solve the problem of figuring out those responsibilities not everyone knows that responsibility limitation is actually a net positive and so you have an opportunity to help them understand that and to design their own responsibilities better in the future thanks so much for listening to today's episode of the api podcast i'm your host jimmy bryan and i'll see you next time developer t i hope you will engage in system design that limits the responsibility of each actor going forward that is the takeaway of this episode if you enjoyed this discussion i'd encourage you to join the developer t discord community head over to developer.com slash discord that's developer t.com slash discord thanks so much for listening and until next time enjoy your tea you