Artsy Engineering Radio

Better Ways To Think About People & Teams

December 02, 2021 Artsy Engineering Season 1 Episode 42
Artsy Engineering Radio
Better Ways To Think About People & Teams
Show Notes Transcript

Sarah Weir, Luis Gualberto, and Steve Hicks talk about better and more modern ways to think about people and teams. Rather than defining engineers as back-end or front-end, developer archetypes better capture the value an engineer brings to a team. And when scaling teams, Team Topologies provide a model to escape Conway's Law and build for user needs.

Notes

* Team Topologies book
* Conway's Law

Steve Hicks:

Hey friends, welcome to another episode of Artsy Engineering Radio. This is your obviously favorite podcast about engineering at Artsy and other things at Artsy. I'm Steve, your host today, and I'm here with a couple of directors at Artsy which is cool. I have with me, Sarah and Luis. Sara, do you want to go ahead and introduce yourself?

Sarah Weir:

Sure. I'm Sarah. I'm on our engineering team, currently the Director of Engineering for our core marketplace area.

Steve Hicks:

Very cool. That's a pretty recent title for you. Congratulations again. Thanks, Luis, do you want to introduce yourself?

Luis Gualberto:

Yeah, for sure. So yeah, Hello, my name is Luis. And yeah, this is my favorite podcast about engineering, and I am director of Agile coaching at Artsy. Also for the PDDE team. I'm not sure if I can say PDDE here but yeah, so it is the engineering product teams inside Artsy. And yeah, pleasure to be here.

Steve Hicks:

Yeah, we've talked a little bit about PDDE. And in fact, we have an entire episode that talks about it if people want to go back and listen to that. Okay, so this is cool because, Luis, you have experience in the world of agile coaching outside of Artsy; Sara, you have a lot of experience at Artsy. And so it's cool, because I think we'll get a little bit from Luis about how the theory works for these things. And Sarah, you'll get to talk lots about the application and how we do these things at Artsy, how we think about them. But what are we going to talk about? There's a couple of things. But it really comes down to better ways to think about people and teams. The idea for this episode started a while back, when we were thinking about how, you know, it's easy to describe engineers as well, they're front end or they're back end engineers. But that's not always a useful way to think about people when you're building a team. Because even when you mix, if you put a front end engineer on the team and a back end engineer on the team, like they might have other other skills or other ways of approaching problems that makes them not actually work that well together. Or you might put two back end engineers on the team and no front end and then be able to solve all the problems because of the way that they they work together. And so I think if we start this conversation in terms of the people, there's a concept of something that I've read about, not until I was at Artsy, called developer archetypes. I don't know, Sara, can you maybe give a little bit of a description of what this means?

Sarah Weir:

Yeah. And I'll also sort of preface this by saying, we're at Artsy at a stage where we're thinking and talking about developer archetypes, but it's not yet fully integrated into our career ladder or anything else. So I am not an expert, but I am very interested in this topic. So yeah, the archetypes are essentially ways to classify engineers that are not just skills based. So like you said, front and back end, some common examples you can...if you search for developer archetypes on Google, you'll find a ton of blog posts, etc, that sort of define them. Some common ones between these different articles are code machine, which is basically someone that loves to write code, that we all should love writing code, but you'll probably notice these people as the ones that are making tons of pull requests every day, like way more than anyone else. They probably don't love being slowed down from doing that. So they might not enjoy meetings or email or you know, anything other than sort of writing code and shipping things. Another one you'll hear a lot about are fixers, or optimizers. And those tend to be the people that, you know, maybe there's an incident that happens and they're not even on call, but they're jumping into try to figure out what the issue was, or they tend to be the people you might want to put on a team that is tackling a complicated sort of technical problem that maybe other people haven't been able to figure out before. There are product engineers, which are people who are so excited about the product and business impact and probably like to work super closely with pm and design. There are a bunch, but those are few.

Steve Hicks:

Cool, thank you. I guess when I when I hear what you're describing, the couple of things that I think about for myself are, I feel like I described the same things over and over whenever I'm on this podcast, but like, I think of myself more as like a finish carpenter than a rough carpenter. And I think that translates to what you're describing with like, maybe an infrastructure level of person, I'm thinking about someone at Artsy like Chris Pappas, who has been on the podcast a couple times, that's a person who's really strong at making these sweeping infrastructural changes, not necessarily my skill. And so I think the two of us approach problems from a different angle and work pretty well on a team together. It is maybe a little bit hard for me to pinpoint which one archetype I might be. Do you have any thoughts on, like, is that normal? For me to feel that way?

Sarah Weir:

Yeah, I think so. I mean, I also, when preparing for sort of this podcast, and revisiting the stuff, I was asking myself, oh, "Which am I?" and I have no idea. And I think...I will also say that I think that the archetypes and mostly the language that they provide for talking about this is so powerful. And we can go into that. I also am a person that hates being put into a box and defined so I would never want to be like labeled as "Sarah, you are a code machine." And then that's how I'm always thought of and kind of the organization. So whenever I think about these things, I'm mostly trying to figure out, what are the important pieces that we can use, but also not worrying too much or going too deep down them? So yeah, I think it's totally fine. I also think probably for different projects and different teams and different points in your career, you will probably be different archetypes. I've definitely seen that overtime.

Steve Hicks:

Yeah, that makes sense. I think it speaks a little bit to also, what you just described, I think there are some of us who are also like the people who want to fill the gaps and who are going to adapt to whatever team we're on. And that may be an archetype in itself, that allows you to shape shift into each of these different places. You said the language that describes these is really powerful. Can you maybe explain to me what you mean, there?

Sarah Weir:

I can think of sort of an example is...I think that sometimes when people are feeling either burned out or just unhappy on their team, and we're trying to figure out why and how can we help them, I think sometimes it can come down to these archetypes. So for example, if you are, say, code machine, I think is one of the easier ones to sort of wrap your head around. So let's say you're code machine, and all you want in your day is to get into this flow state where you're just writing code and shipping stuff and don't want to worry about too many distractions. If you're that type of person, meaning that's what you really enjoy at that point in time, then if you're on a team that, say, doesn't have a fleshed out backlog, it's not clear what they want to do next, and you're always kind of waiting to know what to do. So...there's something preventing you from getting into that flow state, I think that would be a really bad fit. And I could totally understand why you might not be happy, even if you are otherwise, you know, you're like a senior engineer, and you're expected to be able to find work. Of course, we all can do that. But it just might not be that fun. And you might not enjoy it. The label is helpful, because you know, not that you will be sad like you are a code machine. But if you talk to your manager about, hey, I want to get into this flow state. And this is why I think...then, you know, we can more easily find the right team for you, which is probably some team that has a million things that they know they want to do. And you can just sort of check them off super quickly and keep working on the backlog.

Steve Hicks:

Thank you. Luis, could you maybe talk about how you see...So you're also a pretty recent addition to Artsy, which we're really excited to have you, can you maybe talk about how you've seen these kinds of things play out on other teams or other in other places? Or maybe even just in the abstract?

Luis Gualberto:

Yeah, for sure. I mean, it is interesting this idea, as Sarah said, of course, it's not to label anyone, I mean, we don't want to put people in buckets. It is about preference, right? That people have and they prefer to work more in the product, they prefer to work more with some tools that are related to infrastructure and so on. I think it is interesting... people of course, once you find some work or some job that they see that they have impact on right? So, they want to have this even if they are like the heavy hitters or the cold maniacs like they want to see if their code will produce some some results, right? And I think for some ones, Yes, will be directly in the product, but for other ones who will be directly in the infrastructure that they are working. I think for agile, when you mix different archetypes, this can result in better ways. I mean better solutions, right, because as I think you Steven mentioned before, okay, there is one person that will look more in the angle of the code, right? But there is another person that will counterbalance this and say, Okay, we should also, of course, provide some results not only technology by technology, right? So I think this kind of competition in this kind of conflict that you can have inside the team, because these different archetypes will go in different directions, but they will need to conflict and have one common goal, could be super beneficial for any team. Not only, of course, here at Artsy, but for any teams in any company.

Steve Hicks:

Yeah. It's interesting to think about this whole conversation in terms of conflict and like healthy conflict, and having these people pulling in different directions, but in a healthy, positive way. That is definitely something that I think we do well at Artsy? I don't know.

Luis Gualberto:

I think we do well, I'll say yes, I can say as a new joiner with fresh eyes. Just to save you, Sarah and Steve. We do well in terms of conflict.

Sarah Weir:

I think that it has taken us a while to...and this might relate also to the team topologies type of concept. But it's taken us a while to recognize that there are different types of engineers. In particular, we can think about like a product type engineer versus an infrastructural type engineer. And, you know, historically at Artsy, I think a lot of startups begin with a web team and a back end team and a mobile team. And then you start to shift into, we shifted into business unit, engineering teams that fit directly into your business unit. Then we sort of switched into more of a current classical style product organization where we have these streamlined teams, Luis, you can talk more about that. But I think in doing so we did...a lot of the same people went through all those transitions. And so at some point, we kind of had to figure out or ask people like, Hey, do you want to be on our platform team? That is much more infrastructural. Do you want to be on a product team? What do you enjoy? So it's been interesting to watch us do that. And also watch people adapt to these different teams situations.

Luis Gualberto:

Yeah, I think to just to reinforce this concept of, of Team topologies, right? Like, yes, before was like these, right? These individual teams full of front ends, or full of backends. And then you have one team, just with the database administrators, right, really the good old times. And then arrange to see the systems, you have three different systems that right, talking about a little bit of Conway's law, where it states your systems will represent the way that you are organized. So those teams will be completely separate systems. So the idea is, how we can invert, or how we can trick the Conway's law? So you think, and you do an approach, think about in the team first, right? So you think first, okay, what are the needs here for this team? What are the boundaries for this team? What are the kinds of services or apps or systems that this team is able to handle? And then you build the team, hopefully to invert the Conway's Law. So that's the idea that starts like, Okay, how about we try with cross functional teams instead of those siloed teams, just with one type of engineer like back end or front end?

Steve Hicks:

Cool. So we mentioned here a couple times this idea of Team topologies which is just maybe something we haven't defined. Before we do get to scaling this into multiple teams conversation, I do just want to kind of close the loop on the individual developer archetype conversation. And Sara, I wanted to ask you if you have any examples or thoughts about when we've had teams that weren't balanced, and where we didn't maybe didn't think about the different types of people who were going to be on the team, or we thought about it, but kind of missed the mark a little bit and found that things weren't working out well?

Sarah Weir:

Balance is one way to look at it. I think the other is in terms of that conflict we mentioned and whether it's healthy conflict, or someone is just sort of frustrated and becoming burned out. And I think these are all related. So I was thinking about this too. And you know what...balanced means a different thing depending on which team you're on. So for example, when we talk more about the team topologies we started this team to rebuild one of our crucial backends for auction experience. And that's an example where the people that we choose for that team, I think, have to fit certain archetypes, it's the type of thing that is very ambiguous at first. And it's a hard technical problem. And so, probably someone who's more of a fixer/optimizer might be a good fit there, because they're going to have to dig into all these areas we don't even know are going to occur yet. Probably someone who's more into infrastructure and low level systems would not be a good fit there. Because they just are not solving that particular problem. So that's one I think, on one interesting angle, I think is...so one of the archetypes that we didn't mention is team lead. And we talk about, you know, all of our teams have a tech lead, which I think generally should fit that sort of Team Lead archetype. So you imagine every team needs one of those. But then that person is also going to have different strengths. And so thinking back to that example of a code machine, I think that person probably needs someone who's really excited to define work, and also care about making sure that this person has enough to do, so balancing that out, either with the team lead or someone else is really important. Yeah, it's so easy to look forward on a team's roadmap in general and be like, okay, they're gonna do a lot of API work, they probably need some back end people. I think it's a little bit harder to do that with archetypes. And I think we sort of take an easy route, which is saying, Okay, some of these are engineers, our product engineers, and they'll probably end up on the product teams; infrastructure will be on platform team. But I would say we're not that advanced yet identifying these different archetypes when actually balancing teams, and it ends up being a little bit fuzzier.

Steve Hicks:

Yeah, when I think about in terms of the interviews that I've been in, in terms of hiring people, it's the thing that I have in the back of my head, Oh, I wonder what kind of place this is going to fit. But I think that that's about as far as it goes, for me, at least in that context is, it'll be interesting to see. And, yeah, I hope that we get some opportunities to think about this more deeply and figure out how to mix and match these different things. But obviously, it is a lot more thinking, it's a lot more effort that goes into it when...you know, the categories are a little bit simpler when you're talking about back end versus front end versus infrastructure. When you start to add a whole bunch of more variables to it, it just gets more and more complex to figure out how to arrange those people.

Unknown:

Yeah, just to add on on this, of course, you need to look for soft skills as well, right? Sometimes there are some soft skills that you need to complementing inside your team. Right? Maybe I had read some teams that there was a person that would help in terms of conflicts, for example, and would be something that is not in the description of the of the role, right? So yeah, but for sure, the person wouldn't need to do that.

Steve Hicks:

It sounds like we need to just come up with some sort of deep learning solution to figure out all these variables and put all these people together for us, because it's gonna work out a lot better than people trying to do it. Cool. I'd like to move on to this idea of scaling it bigger. So instead of talking about the individuals on the team, thinking about teams, and how the different teams fit together, and Luis, you started talking a little bit about this idea of Team topologies. Could you maybe circle back on that and give us a quick definition of what that is and description?

Unknown:

Yeah, definitely. So first of all, to mention Team Topologies is a book w th...from two authors, Man

Luis Gualberto:

We'll find out who and put it in the notes. el Pais, and I don't remember th other author, but anyway, ju t to give the credits.

Unknown:

Yeah, thank you. But just to give the credits for the person that owns the idea. But of course, as I said before, the teams used to be sealed, so like a team of backhands a team of front end and maybe a team of database right and of course, if you do this, probably you end up that they will do three different systems right. And Team Topologies is also one of the great reaches of this book is that they take in consideration the Conway's law. So that basically states that your system will mirror your organizational structure. So there is a really curious study about this from 1999, about webpages at the time. That is saying like exactly, due to the example of Conway's law, this is how it happens, that most of the web pages at this time, and maybe nowadays still, they don't solve user needs. They don't solve user problems. Usually they are results of internal concerns. And a good example of this is when you access a web page of any company, and instead of it having the services that they provide, you're going to see their history, you are going to see their organizational chart, you're going to be able to see the board of that company? So it's actually Conway's law in practice, right? So to avoid this, the idea is, Okay, how about we build teams around the value streams? So instead of to think, separately, front end and back end, how about we identify the value streams inside the organization? Value streams are the sequence of activities that you exchange value with your end user. And then you see what are the skills needed to manage that value stream? So what kind of engineering skills? And even once we have this deep analysis, even some soft skills, but essentially, what are the skills that we need, so we need someone that probably knows about the product, maybe someone that knows, of course, about coding, someone that knows about user research, and so on. So how you build a cross functional team, that is able to provide services to this value stream, right? But then Team Topologies goes a little step further. That's about...it's a huge amount of work, right? If you think nowadays, what a team needs to know -- so you need to know about operations, you need to know about architecture, about security, about how to test, about how to deploy, about infrastructure, continuous integration, continuous delivery, and so on. And also you need to know about product, right? So Team Topologies, what they do, they kind of play Tetris with the knowledge that you need. And then distribute this knowledge in different teams that will work together. So they describe four kinds of teams. And then three kinds of interactions that they can have between those things. So in an idea to reduce the cognitive load, of all of those things, and then they can really own their service end-to-end, for a specific value stream inside your organization.

Steve Hicks:

Cool. So I guess, in this conversation, when I think about how we do teams at Artsy, I feel like, one of the things you described was that our teams should better reflect the users and the users needs, than the needs of us on each team and how we can do our job. And I feel like that's a that's a pretty good step here towards what you're describing. Sarah, do you have any thoughts about that? Do we think about this, does leadership think about this kind of stuff as you structure the teams as you plan out the teams? And do you think that this is something...where on the spectrum of getting toward Team Topologies do you think that we are, if at all?

Sarah Weir:

Yeah, Luis might have a good assessment to your latter question. But we do think about this. So since we organized into our current product team structure we have been thinking about our users needs. And often we think about it in terms of, you know, where is the user in our funnel, so top of the funnel, being our Grow team, which handles marketing outreach, and SEO and things like that, all the way down to our Transact team, which is now working on our payment platform. So at Artsy, we've made an explicit decision to invest in a platform team that will then enable our product teams, which I think in the topologies book is called stream-aligned teams. The platform team basically allows product teams to move faster. It also allows us to change our product teams over time, which we've done many times. And mostly because we've actually changed our strategy. And so either we're targeting a different set of users, or we find that a certain step in the funnel is now much more important than it was. So I think what's really interesting -- not to take us down a totally separate route, but in terms of how we actually design our teams and architect systems, I think we're consciously trying to fight a little bit against Conway's Law in that we want our product teams to be able to make decisions, but we also want them to be able to change and so that's why we have this sort of platform layer. So yeah, Steve, I would say we're always figuring it out. And that feels like a sort of constant tension at Artsy. But given where I've seen us be in the past and where we are now, I think we're actually doing a much better job. I don't know, compared to other places, Luis may know.

Unknown:

Yeah, definitely, as a good agile coach, I can see we are uncovering better ways to work together. We are not done. So we are in the journey. Yes, definitely. And yeah, I mean, how can I disagree with her? Yes, I mean, it is the same estimate that I have, right, like, I see the product areas as the value stream alignment teams, that we have. And currently, we have two platform teams, maybe three, that enable those value stream-aligned teams, that are focused only to provide value to our end user in the different areas. And the platform teams for sure, handle those platforms as an internal product, trying to make the engineers happy. I'm curious about these platform teams that, I mean, we talk about archetypes and say, okay, there are people that like, for example, to work with infrastructure and so on. But platform teams also are internal products. So you will have someone to make happy, right? It's not like we will only code and then don't talk to anyone. No, you're going to talk to your fellow colleagues, engineers and ask them, Is it easy to use my platform? It's being helpful for you, and so on. So I think the great idea of the Team Topologies is that also they provide you the interaction mode between the teams. You're still seeing your value there inside of the company?

Steve Hicks:

Cool. Luis, Sarah, is there anything else that you think we should talk about in this conversation that we haven't yet touched on? That you think is important?

Sarah Weir:

Yeah, I had one thing just about actually more about the archetypes, which is something that I think is important, if you're a developer thinking about yourself and your own growth is also to not worry about specializing too early. And I think specialization, it's really easy to think about it in terms of, you know, am I a front end engineer that wants to go into front end infrastructure, or start contributing to a React Native project, things like that, or you know, am I into something else? At Artsy, we talk a lot about the T shaped engineer, I don't know if that's been discussed in previous podcasts, but essentially allowing for some breadth and also some depth. And the archetypes I think, are just another angle of that. So I think, like the way I think about them in terms of helping to understand what might be frustrating someone or how, or what might be the reason why someone is super happy on their current team, and better able to understand that as a manager can help you better guide people. I think that's important. But I also think that we do adapt and change depending on our team. And especially if you're earlier in your career, you're going to be trying different things out. Like I spent a lot of time on our platform team. And that was super fun and interesting getting to know a little more about the infra, also doing more product, Luis to your point, you are an internal product. So you're also dealing a ton with people that you're sitting next to and trying to help their lives be better. So yeah, I guess I wanted to say for these archetypes, you should use them as a tool for better understanding yourself. And as managers, we can use them for understanding. But for us, on our career ladder for example, I think we wouldn't really talk about an archetype as like a specialization maybe until the staff engineer level. So I think at that point, you know, once you're really specialized, I think it might be a lot easier to sort of define, this is the type of developer I want to be. But just to kind of put that in perspective of, it is a really long journey. And in the beginning, it's just about a tool for understanding, I think.

Steve Hicks:

I love that idea of the journey. I feel like, as engineers, especially, we're always trying to just give someone else a shortcut and say, Oh, you're like this kind of person. You should just jump all the way to here and we always discount the journey. Yeah, what it took for us to get there and recognize like, Yeah, I know that now I'm the kind of person who likes to do a lot of polish work and likes to be that finish carpenter, but think about all the things I did along the way that brought me to that point. I can't look at someone else and say, You're this kind of person. Just get there first without even going through the journey.

Unknown:

Yeah, totally, don't don't close yourself to a job description. Don't be in a box because of the job descriptions.

Steve Hicks:

Couple real quick questions I think for Luis. Luis, maybe along this line, do you think that there's a right time to think about team topologies too? In the sense like, does an organization need to be at a current state or at a specific state before they can start to think about how these different teams would fit together?

Unknown:

Yeah, usually it is because of the size of. When you are growing. Of course, when you start off with just one team with, I don't know, seven persons, you don't need to think about that. But once you reach a certain level, and scale, for sure, it is time to think how you're going to scale and how everyone should think those teams that the are contributing with each other, right? Again, you don't want to isolate them because they are going to create different systems. You want to create a kind of network that they can communicate with each other. And usually, there is this Dunbar's number, that is this anthropologist guy that says, Okay, you can take connections with 150 persons maximum, right? And then when you think about teams, usually it's nine persons to 12 persons per team. So this is your number when you should think, okay, let's now think how we can split the work and create those other teams to reduce the cognitive load of the persons.

Steve Hicks:

Awesome. My last question for you, Luis, is, I imagine that you have some sort of like X-ray vision superpower, where you're able to look at an organization and say, based on Conway's Law, which we talked about before, that you can look at an organization and say, Oh, this is what the structure of the team looks like. Do you see that when you look at Artsy? No pressure.

Unknown:

No, I don't have a superpower. No. Of course, I heard some some some people saying, I don't have a...I'm not here for so long. I don't have a conclusion yet. Let them see more. But for sure, other companies, you can see the Conway's Law there. And there is a famous company of streaming, or even the other sorts of when you access a web page, and then you cannot access their services, that maybe are there just to listen to music. It's Conway's Law there, right? Because you have the web page that is with marketing. You have the other page that you want to hear music that is with engineers, probably. So it's there and I don't need even to say the name of the company.

Steve Hicks:

Well, thank you for answering that question in a way that makes me feel like Artsy is a special beautiful unicorn.

Unknown:

Again. Again, we are uncovering better ways to work together. We are going to reach there. Yeah, of course. We have some issues to work, but we are going to get there.

Steve Hicks:

We're on the journey. Awesome. Sarah, Luis. Does anyone have anything else you want to add? Before we close this off? I see a head shake from Sarah. I see a head shake from Luis. Cool. This is really, really awesome. I'm excited that I got the opportunity to hang out here and talk to both of you. I feel a lot smarter, honestly, for just spending the last 35 minutes hanging out with you. But I'm gonna go ahead and say thanks for hanging out with me.

Sarah Weir:

Thank you, Steve. This was awesome.

Luis Gualberto:

Thank you very much.

Steve Hicks:

All right, thanks. Thanks, friends. Thanks for listening. You can follow us on Twitter at Artsy open source. Keep up with our blog@artsy.github.io This episode was mixed and edited by Alex Higgins. And thank you Eve Essex for our theme music. You can find her on all major streaming platforms. Until next time, this is Artsy Engineering Radio