How do titles and roles function on a team? And how can they lead us astray? That's what we're talking about in today's episode. Specifically, we're talking about roles on software development teams. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. So what exactly is a title or a role? Well, the official titles that we have in our jobs may describe some level, some kind of seniority level or experience level, but they may also describe our functional purpose, our functional reason to be on the team. This is hinting at what we are responsible for as a team member. And this can be really useful. Clarifying the responsibilities of each person on a team is necessary to be able to set expectations with each other. So it's important for you to know, for example, who to direct your questions to? What domain of responsibility does each person have? What where this can go wrong is when it's unclear what the title actually means. And there's a lot more that can go wrong, but we're going to start in this arena of trying to understand what the title actually means. For example, what does it mean to be a senior software engineer versus just a regular software engineer, whatever that title is? And what does it mean to be a program manager or a product owner or a stakeholder? And what if there are two people with the same kind of role, the same title? Do they play the exact same role on the team? And if not, how do we know the difference? We're going to talk about all of these problems, right after we talk about today's sponsor, Lenoad. With Lenoad, you can get a server in the Lenoad cloud running in just a few minutes. Lenoad offers cloud computing plans for every workload from simple web hosting to heavy CPU and sensitive needs like video encoding or machine learning. Lenoad offers a balance of power and price for every customer use case. And as a Developer Tealistener, you can get $20 worth of credit if you're a new customer on Lenoad. We'll talk about how in just a moment, Lenoad features native SSD storage. The hardware that Lenoad has is industry standard top of the line, the fastest processors, a 40 gigabit internal network. And you can pick from any one of the 10 worldwide data center. So it's not just internal latency that they've solved. They've also solved geographic latency, the literal physical distance between you and the data center. They have the newest data centers that have just launched this year in Toronto and Mumbai. You only pay for what you use with hourly billing across all plans. And there's one price add on services as well. You can deploy and maintain your infrastructure simply and cost effectively. And Lenoad is built for developers. For this reason, they have an API and a CLI to manage provision, secure and monitor, and even backup your cloud. They also have a new cloud manager head over to cloud.linow.com to find that. But about that $20 worth of credit to get that head over to linow.com slash Developer Tea and use the code Developer Tea2019 and check out. Thanks again to linowad for sponsoring today's episode that's linowad.com slash Developer Tea. If you've been listening to the show for very long at all, then you should know that humans like labels. We like being able to compress information into small heuristics, pointers that tell us a lot of information with very little effort. And so a title, a role name, these are ways that we can compress a lot of information that we would otherwise have to retrieve, which is mentally expensive. We can compress all that information into a few words. And a lot of that information is carried through cultural context. For example, in most company cultures, most software engineering culture open open source culture, a senior software engineer is a role that has some level of peer leadership involved with it. Now, this isn't always true. And this is why roles and titles can be a little bit confusing with any kind of model where you compress information. What gets compressed may be important. Now it may not be important for every single day you're functioning. That's why these heuristics tend to work decently well, but it can be important for understanding the nuances of the role. And it's especially important for the person who has the role. This is why most mature software engineering organizations have a better description for what these titles and roles are. There's certain criteria that a given developer might need to meet to be able to have the role of senior software engineer, for example. And these criteria can be used to incentivize growth for the given engineer and the criteria are going to be specific to the values of that engineering organization. But roles and titles don't exist in a vacuum. When you have two people with the same role or the same title on a given team, how do you know who's responsible for what and what role they play on that team? We know what their responsibilities are in kind of an abstract way, but how can we figure out how to organize around our roles and responsibilities when they collide or when they seem to be overlapping? Here's the spoiler and unfortunately we're not going to make this a click bait episode because there is no single answer to this question. How we figure out what our different roles and responsibilities are is incredibly individual on each team. What a given person's strengths are, what their interests are. Additionally, it's not going to be static for a given project, a senior software engineer might have a heavy testing role or a heavy mentoring role. But then that role might shift as the software moves into maintenance phase. But here is what is incredibly necessary for teams to work well with each other. For a given period in time, maybe one sprint, maybe for an entire quarter, it's important that these roles and responsibilities are discussed out in the open that no assumptions are made about who is responsible for what. In particular, think about your responsibilities and your roles in terms of decision making. Who makes the decision about what to do? And these decisions can cascade into responsibilities for other people as well. So a product owner, for example, may have the responsibility of making a decision about what features to prioritize over others. And a software engineer may have the responsibility of collaborating with that product owner to discuss the costs or the level of effort necessary for those particular features. A lot of conflict occurs in this area when people are not clear on their personal area of responsibility, but also the areas that others have, the things that they are responsible for. And again, remember that this happens both at the macro or consistent level where a company culture may have certain expectations of given roles and titles. But then it also happens at the micro level on a given day or a week or quarter. And these responsibilities are always shifting. Once again, this underscores a common theme that we talk about on the show. And that is that collaboration is incredibly important. It's critical to your success as a team. So the homework, quite simply, is for you to sit down and write out what you understand to be your own responsibilities. You don't have to be perfectly articulate about every single responsibility, but your areas of responsibility. And then take this to your teammates. Take it to your manager and ask, is this complete? Have I included things that I've been carrying the weight of responsibility for that is actually someone else's responsibility? Have I been missing out on things that are actually my responsibility, but I didn't know it? In the best case scenario, this will spark a discussion on your team about clarifying responsibilities for everyone. Thank you so much for listening to today's episode of Developer Tea. This is a very rich topic and we certainly can't get to all the nuances. For example, how do we treat external roles and responsibilities? People who are interfacing with our team from other teams or from entirely different companies, different firms outside of our own company? So this is a topic that really justifies much more discussion, but this is a good starting point to try to articulate your own responsibilities as they relate to your team members' responsibilities. Thank you so much for listening to today's episode. Thank you again to Leno for sponsoring today's episode. And over to Leno.com slash Developer Teato get $20 worth of credit as a new customer on Leno today. Today's episode wouldn't be possible without spec.fm. Spec is a network for designers and developers who are looking to level up in their careers. Go and check it out spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.