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 Cottrell and you're listening to Developer Tea. And 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? But 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 role? 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, Linode. With Linode, you can get a server in the Linode Cloud running in just a few minutes. Linode offers cloud computing plans for every workload, from simple web hosting to heavy CPU-intensive needs like video encoding or machine learning. Linode offers a balance of power and performance. You can get a free trial of the Linode Cloud and a free trial of the Linode Cloud. And as a developer T listener, you can get $20 worth of credit if you're a new customer on Linode. We'll talk about how in just a moment. Linode features native SSD storage. The hardware that Linode 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 centers. 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 Linode is built for developers. For this reason, they have an API and a CLI to manage, provision, secure, and monitor and monitor your data centers. And even backup your cloud. They also have a new cloud manager. Head over to cloud.linode.com to find that. But about that $20 worth of credit. To get that, head over to linode.com slash developer T and use the code developer T 2019 at checkout. Thanks again to Linode for sponsoring today's episode. That's linode.com slash developer T. 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 content. For example, in most company cultures, most software engineering culture, 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 kind of 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 game, 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 clickbait episode, because there is no single answer to this. 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, maintenance, 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 decisions, 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 kind of 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 week, or, 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 area of responsibility is important. 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? And 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, and how you're going to be doing that. And then you can start to think about how you're going to be doing that. And then you can start to think about how you're going to be doing that. Thank you so much for listening to today's episode of developer T. 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 topic. And 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 Linode for sponsoring today's episode. Head over to linode.com slash developer T to get $20 worth of credit as a new customer on Linode 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 Cottrell, and until next time, enjoy your tea.