Kris, Toran, and Brandon discuss what a cross functional team is and how to get the most out of the team setup. They cover team composition strategies that improve the flow of work and how crossing boundaries can increase throughput.
ReferencesDownload MP3 (34 MB)
Toran Billups - 00:04 - You're listening to Developing Fatigue. I'm Toran. Today, I'll be joined by my two cohosts, Kris Van Houten and Brandon Williams and today on the show we're going to be talking about cross functional teams. So Kris, what does a healthy cross functional team look like anyway?
Kris Van Houten - 00:20 - so this is a topic that I will admittedly say that I was not super well informed of about a couple of hours ago when I first started deacon gain to what this actually means, but a kind of find out I actually do it at my job just without knowing that this was the term that defines it. So essentially a crossfunctional team is a team that is not just one department. It's not just the this group of developers. It's not just this group of designers or these QA people. It's a team that is comprised of all those people from various departments, from different specialties. So maybe you have a team that has a designer on there. Maybe you have a back end developer, maybe have someone from Dev ops or a couple a front end engineers with some QA people or a business analyst and a product manager, like all these people working together, sharing information, giving feedback in an effort to, uh, improve or make their, their feature or their part of the application or they're part of the product that you're building as good as it can possibly be.
Kris Van Houten - 01:23 - And so the theory or the idea behind it is that by bringing in people from different backgrounds, different specialties, different areas of expertise, that they can have a more balanced in a, I guess just a better result by having all these different people will give their input based off of their life's experience.
Toran Billups - 01:43 - Yeah. Uh, definitely killed that
Kris Van Houten - 01:45 - for sure.
Toran Billups - 01:47 - No, I liked your, your, what you started out with especially saying that you're admitting, I'm kind of new to this word or this, this topic, but realizing that you're already on a healthy crossfunctional team right now. So one of the things I wanted to ask is like, you know, when I think of cross functional, there's obviously pros and cons. You know, you're working with other people, so communication is, is a factor, but in your role right now, what are you, one of the water, one of the special things about you in particular that has made this cross functional thing, healthy and productive. Is there anything about you in particular or the people you work with?
Kris Van Houten - 02:26 - I guess to back it up a little bit, you know, I have a lot of experience in, you know, website design, software design, art in general, and then, you know, I became a front end developer later on and so we're, that's benefited me if based on my team is that our designers feel comfortable coming to me and asking me about showing me. They're designed to be like, hey, like what input do you have about this or what are your thoughts on, you know, these mockups that I'm, that I have for you. And so I feel like they're able to trust me and feel comfortable with me to them and saying, hey, we can't do this or we need to reapproach how we implement this designer, this feature A. I guess an example of that would be, you know, just last week I was in Austin, I was working with a team on site and I was given an updated design for part of the feature that we've been working on for the last eight or nine months and as soon as I saw the designs I'm like, yeah, this isn't gonna work. And the designers, like what, why? Like I put a lot time into this.
Kris Van Houten - 03:25 - I was like, well, you know, and we all came down to accessibility in contrast ratios, which is a whole other area of passion for me. And you know, as explaining like, hey, because of how these colors are overlaid over the top of each other, like certain people with various visual impairments will not be able to see these colors period and be able to see, you know, what this part of the design is trying to convey to the user. And so I had to sit down and work with them and show them my kid, like why don't we do this instead? And there's like, oh this is perfect. Okay great. And you know, because I have that biggest cross discipline experience, but also because I'm working with the designers face to face, uh, you know, we're able to make their product better because, you know, there are certain things I know that they don't and there's certain things that they know that so we can kind of share our brain, our brain meld and that way.
Toran Billups - 04:14 - So Brandon, you've been mighty quiet so far and I'm a little curious, like, have you, in your experience, have you seen whether in this role or previous, previous jobs or roles, have you seen teams that are cross functional?
Brandon Williams - 04:29 - Yeah, actually, um, the last, uh, last place I worked, I was on a consulting team and we did this really well where we had a very high functioning cross functional team. We had everybody now just working in the same room. It's not just an open office that contributes to a cross functional team, but everybody had brought their own specialty into the team. Uh, we, we reached across those boundaries and helped each other out when needed. Um, sometimes the CIS CIS admins would need help with us, you know, a certain piece of software or the developers would need help configuring the system a certain way and we would pull each other in, um, and then you know, that middle ground of the release team and working with both the CIS admins and the developers and it was just very, it was very fluid being able to um,
Toran Billups - 05:22 - pick up the thinking. That word. Yeah, we were the whole time you were saying I was like, this feels too magical. I want to say the word fluids. So like these conversations, were these things that came up like in a standup or is it truly just ad hoc where like you bumped into a deployment issue like configuration or something and you're like, oh, I don't even know how they're going to deploy this now. I better go better talk to those guys. And you would just drop over and have a chat or.
Brandon Williams - 05:46 - Yeah, absolutely. I mean sometimes it would. Somebody would say unblocked by this at standup and as you hear that you, you offer up your, your time and your expertise and sake, I will come over and help you with that after stand up today or somebody just a is working through a problem. They're saying, Hey, I saw this isn't deploying quite right. I, you know, I need your help figuring this out. So we just sit down and work through the code together. Um, either point them in the right direction or take on that work. Um, you know, figure out who, who's the best person to get that work accomplished to get that roadblock removed.
Toran Billups - 06:20 - Interesting. So unlike Kris's story, I was reading something very different from yours that I think maybe you could speak to that is there's gotta be some kind of special ingredient between you and all these people you're talking about, right? Some kind of trust bond or something between you that you felt like you could safely go talk to them and admit like, Hey, I don't know how this front end thing or I don't know how this deployment thing works. Helped me understand it. Was there any conversations like that? Do you feel like you have to be a little bit more vulnerable in that role or.
Brandon Williams - 06:53 - The main thing is you have to be willing to say, I don't know everything. I can't know everything.
Toran Billups - 07:00 - So scary though.
Brandon Williams - 07:01 - Yeah, it is. You know, there was a day when I used to know a lot about the front end. I don't know that much about the front end anymore. I mean, I can still do
Toran Billups - 07:12 - love your brand.
Brandon Williams - 07:12 - I know you guys put up with me. I can still debugging the browser with chrome if I needed to, but man, I'm. I don't want to do. They'll that async debug team bucking again. I'll let you guys do out of that.
Toran Billups - 07:25 - We ain't got time for that. One thing I did want to talk about though that I think we all three have experienced is this idea that Kris was alluding to when he gave this definition where we all come together and form really kind of a product team often and the development world where we're building features for a software product and what's kind of struck me lately is really the conflict that you have in bigger organizations. So a little context. This isn't usually your two person startup where you had the CEO and you and the goal is ship. Before we run out of money. We're obviously talking a little bit more about enterprise or bigger teams and in this example I'm talking about you might have a QA team or or a quality engineering team alongside the DEV team, alongside the product teams and they all have their own management objectives and philosophies, but they come together on this product team and one of the things I'm kind of struggling with right now is, for example, like the Dev team.
Toran Billups - 08:25 - You can imagine what developers are tasked with crank out features like yesterday. Get her done. You know, and that that's sometimes is at odds with maybe the, the work that the QA department is tasked with. So for example, the QA departments like maybe they're being told by their management, oh you guys aren't finding enough bugs, you know, you're not doing your job now. That's, that's our metric is bugs found and it looks like based on last year, you know, year to year, you guys are finding less bugs now, which no thought as to if that's the developers just getting better. Instead it's like, well we're not finding bugs. That's just our fault. That's our problem. And so have you guys ever experienced something like this where you see a conflict either on the team or you actually feel conflicted coming to the team because you're saying, you know, I think we come together to help build great products for the customer, but we have all this baggage and that baggage really is from the teams that we come from. Engineering or quality product. You guys ever experienced this?
Brandon Williams - 09:25 - So I think, I think maybe what Toran is asking, and correct me if I'm wrong, but it feels like we're talking about identifying, identifying bottlenecks in your system, elevating those so that they become extremely apparent and just really improving the flow through the entire process. So let's say you've got developers and they can produce three features a day and you've got a QA team members and they can test and validate to features a day, so therefore you can. You can ship to have those features all the way to production after a week, five working days. You've got five features now that are sitting waiting for the QA team members to validate them and test them before you can ship them to production. So you really want to elevate and say, hey, we have a QA problem here where it's not that they're not working hard, they're not working fast enough. We just, we're lacking the re, the number of people here, the resources to be able to get all those features to production and what you're really trying to improve with a cross functional team is the flow through that system to get things out there faster and improve on things.
Toran Billups - 11:33 - And I thought like why am I not helping? Like I'm such a scumbag right now, you know, like I'm not reaching out to, to offer and why is that? And in truth I think it comes down a little bit to this specialization idea where I didn't really actually understand what the QA and QE people do every day. And so I was a little bit intimidated. I'm like you were saying earlier, Brandon, I was actually too afraid to say I don't know. I don't know what you need me to do. I don't know what your job is. So have you guys ever run into that experience where actually the team has, has sort of cried out for help and said, no, we need to be cross it. Can someone help even if you are totally not equipped and it's not your normal job. So Kris, you're being Mr. Silent one experience that you have with this, like trying to really bridge the gap and be cross functional.
Kris Van Houten - 12:22 - Yeah. No, I think this is a great question because we actually have something like this happen I think three weeks ago on my team where we were trying to wrap up this future that we've been working on for the last several months and like we were coming up to the deadline but we were having some massive delays because our QA environment was having some, some issues. Uh, it was constantly, you know, basically crashing or falling down and it was just taking a long time for QA to test tickets because the QA environment was unstable and so it got to the end of art getting towards the end of the sprint and made us had something like 18 tickets or something like that that they just, they did not have the bandwidth to test. And so that's where they were asking us to basically kind of like, you know, developers, you guys crushed it. Like, but we need some help testing this stuff. And so we got input from our QA department or our QA guys on the team and just say, hey, how do we do this to meet your guys's criteria?
Kris Van Houten - 13:20 - And so that's really the communication obviously came in and they were saying, hey, test it like this, test it on these devices, tested in these environments, so on, so forth, take screenshots, do videos if you can, and then, you know, all the other rules that we were not allowed to QA our own work. And so yeah, so like of course my stuff works, I'll just pass it off as, you know, it's good to go. And so by doing that we were able to help out the QA team, get their stuff pushed through so that way we actually deploy our feature, uh, even though I'm not an expert QA person, uh, but I was able to go through and, you know, check all the boxes for these tickets that we can get this, this whole feature deployed, which was, you know, a stressful time for everybody involved.
Toran Billups - 14:01 - That's really cool, man. It's like a real success story for crossfunctional were all hands on deck. We're behind developers help us out. You, you guys did. Were there any developers that were like, Nah, that's not, that's not good.
Kris Van Houten - 14:14 - No, I mean everybody was really into helping and it wasn't just a developer so we had a, our product manager, she was helping out. We had our designer, you know, she was trying to help out in between all her meetings she had and you know, and we couldn't devote 100% of our time to it, but you know, and basically whenever we weren't, meetings are being pulled away to have other conversations. We were working on helping out QA get their stuff so that we could ship this product. And so yeah, it was, it was, I enjoyed it honestly. It kind of gave me a breath of fresh air to kind of get my head out of the, the editor for a bit and actually work on and even empathy for this other team and how they have to work. And I think over time this helps you build collaboration between these departments that you can help make the, uh, the process more fluid. Like Brandon was saying about, you know, how do we get from point a to point b the most efficient way and I think doing stuff like this actually contributes to making those improvements to improve that process.
Brandon Williams - 15:14 - I was just going to say like, I want us to make sure that we're talking about cross functional teams, but we're also talking about cross disciplined teams where people are able to cross the boundaries of kind of your core responsibilities.
Toran Billups - 15:28 - Yeah, that's a great point. I wanted to kind of transition as using that word. Kris mentioned empathy as. Let's, let's talk a little bit about the upside. You know, this is kind of like a glorified idea right now. Kind of like agile was years ago. Like Oh, there's another silver bullet. It's called crossfunctional teams is going to save us. And so when I think about an honest benefit, something I truly believe in, when I think about cross functional teams, that is what you just said, Kris, where I now have to think about the people testing my code from the quality side of the story. Think about how that impacts them when I do a crappy job or if I have a really hard feature to test and I thought nothing about it when we pointed the story originally and then they are sort of stuck holding the bag with a bunch of complex test scenarios and you kind of get a different look at it.
Toran Billups - 16:20 - For example, I'm on my team right now. There are situations where we need different types of data to flow through the system and of course you know developers like, oh, you guys probably just have that laying around. No big deal. And depending on, you know, the user story or the defect that might be non trivial. It might be like, actually it's going to take me two days to curate this data from a real almost customer like environment and then scrub it and then get it down to test this. But as a developer, unless you experience that by either getting very involved and doing the job like like Kris is saying, or if you actually have to take that role on whether you're a pairing or mobbing to actually experience a day to day. You just simply don't think about the other team members. Um, I think a lot of us, I guess I should speak for myself, I think a lot of developers, um, but me in particular don't do this very well when I'm thinking or considering the product people, you know, a lot of times it's like, oh, you just give me the product and then I'm going to go crank out some Java script or some backend code, whatever.
Toran Billups - 17:20 - And I think I've just done such a bad job of that my whole career and I'm seeing sort of the opposite side of that now where I'm actually really interested in the product. And so I have engaged a lot more cross functionally with my product people because I just loved the product and honestly that I think they're probably sick of me because I'm like, I'm in their face, like I'm going to do this now. And they're just like, stop this. Like, quit working on this stuff. Like go do what I told you to do. I'm just like, oh, but this feature is going to change the game. You know, like I'm actually thinking in my head like the customers who use my software because it's so interesting to me and so that's been kind of neat for me is it's, I don't think it just QA and Dev. I think there are situations where you as a developer can get to know your product and your product people to have a little more empathy from, from where they're getting pressure. Right. Because what we're talking about when teams come together is everybody's feeling pressure from somewhere else. That's what I was kind of alluding to earlier in the product people. They really feel a lot of direct pressure from their customers.
Toran Billups - 18:17 - Which as your developer on that team, it happened to me, the people paying your salary, you just don't often think about it. So something to think about. I like the empathy argument, but what about you guys? Do you have in particular other upsides or other benefits that come along with either the mindset of cross functional or really crossfunctional in practice day to day?
Kris Van Houten - 18:37 - So one thing I started doing, parties probably started doing this a year and a half, two years ago because I was getting a lot of comments, are a lot of, uh, messages from our QA people saying like, hey, how do I get the application in this state so I can check out what you did or, you know, like I have a question on how you implemented this, you know, a design update or what have you. And so it actually started doing was because for programmers and we have, you know, some tricks up our sleeves, you know, on our Jira tickets, we have a little section for testing notes. Uh, and so what I started doing was actually just dropping in some of the scripts that I would use in my browser to get the application to a state to where they could just drop those into the console and see exactly what it was I did without having to click through several pages or several workflows. Uh, I know in some cases that's kind of like giving them cheat codes, but uh, it, it dramatically improved their time spent on testing or the time they were spending on testing some of the tickets and, you know, and I've asked them like, do you guys use that?
Kris Van Houten - 19:39 - Do you guys appreciate that? And like, no, like that is awesome. Like we love that kind of stuff because it helps us speed through our job, uh, in a more efficient manner. And so I think that's, that's one thing that comes to mind, uh, but with the particular feature that I've been working on at my work, we have like our own release cycle or our own versioning system that's totally separate from our, our primary product that I work on a typically. And so, uh, it just got allocated to me that I'm responsible for all releases on my feature. And so now I'm having to work with release management. And so when I was in Austin last week, I had a, the woman who involved with, with managing all the releases sit down at my desk and she was like, alright, we need to have a chat. And I'm like, am I in trouble? What did I do wrong? She's like, nope, I just need to like do a brain dump with you to let you know, like, this will be expect from you. And so I'm sitting here like taking notes and say, well, how can I make this the most efficient for you in the most easy for you? So that way I don't have complaints coming against me.
Kris Van Houten - 20:39 - And so we just had a whole conversation and we're able to, you know, make some suggestions like how this can be the most efficient process going forward. And so it's just like you're working across different departments, which, you know, take her to leave it. But it's been nice to see how other teams are using, trying to utilize the code that I've written or my team has written and trying to consume it for their own purposes. So,
Brandon Williams - 21:03 - so, uh, maybe shifting gears a little bit, something we haven't really talked too much about is the world that I live in the Dev ops world where Dev meets the operations of the software, um, that, that kind of a, in some teams I've seen the developers own the build and release step and then the CIS admins own the whole operators, uh, operations of the operation of that software in production. And then I've seen other teams where the CIS admins are more in charge of the build release and the operation. So just thinking about that and those interactions between the teams, how do you do that? Um, that's just something that I've been, that I'm a part of that I think about a lot. And how do we, how do we improve the flow there for those teams?
Toran Billups - 22:03 - Yeah. One thing I do in particular, it's not quite as close as what you're saying Brandon, but one of the things I noticed other team members were doing that was like, it wasn't really a developer job was to actually do the deployment of our software so that the QA team could test it. And you know, I, I feel like I used to be full stack, maybe I've forgotten what it actually is to do front and back end deploy, all that. But I asked the people that were doing these deploys, I was like, Hey, I really want to help out, you know, I was trying to actually be more crossfunctional and say, this isn't just a QA or deployment says add sis admins job, this is something I can do. They're like, Oh yeah, let me just run this script and then you install this. And I was like, Oh yeah, I can do that. So then what I started doing was actually taking that responsibility from them and just making it part of my job. And that doesn't completely alleviate like you don't have a dev ops or a deployment person now. But what it got us in the habit on my team was we began to share some of these responsibilities. So it's like learning about docker.
Toran Billups - 23:02 - Well that's not just Brandon's job. You know, I, I use docker as a development tool. I use docker at work to deploy things. But I think when you sort of lead by example, we always talk about this on the show, but like one of the things I wanted to do was just take on this responsibility as a way of signaling to the team, hey, this isn't my day job. I know this isn't my normal responsibility, but isn't it cool I can just pick it up and help out. And one of the upsides I think that comes out of this is, you know, we all love learning. Why would we turn down the opportunity to learn on the job? You know? And that's where I think cross functional as a really big upside has for everyone involved, is you get to learn about other people's jobs. Are there other types of tech, all kinds of other things, including the product that otherwise you kind of just sit pigeonholed in your little area. It's like, oh, Brandon just does docker, you know, Kris, he just writes front end code. And to be honest, that's kind of sad. You know, I kinda liked the idea. It's just like, yeah, right. Some front end code, but then I can deploy it and I'll do what I want.
Toran Billups - 23:59 - So I think that's one of the upsides we haven't talked about and I don't know if that solves the riddle that you were throwing at me, Brandon, but I think it's cool to learn about deployment, learn about docker, learned about the command line if it's, if it's not your thing, um, to just become more crossfunctional every everyday. Be a little bit more actively involved in that.
Brandon Williams - 24:17 - Yeah, absolutely.
Toran Billups - 24:19 - So silver bullet, I mean, Brandon's given me a thumbs up, so pretty sure cross functionals the new agile. That's what I heard. So, no. All seriousness this, this can't be perfect. There are tradeoffs. And so one of the things I was going to transition us to is just kind of some of the downsides that you guys have either experienced that are just struggles when you're more crossfunctional or when you're trying to be. And one of the issues that I talked about earlier is truly just specialization. Software is not becoming less complex or simpler everyday. In fact, it seems like it's becoming more complex and the examples that we all talk about, you know, there was a day when we did front end development and it was like one file. It was like, Oh yeah, you got the index html done and now you know, just just showing that the front end has grown in complexity. The front end has now become very specialized depending on the stack you're in as well. That's very specialized depending on the build tool for your front end, your back end, depending on the testing library, the test runner using for both your backend or your front end.
Toran Billups - 25:20 - Those are all very specialized things and I think that is one of the issues I see on any team I joined is as we try to become more cross functional, it's actually really hard for me to be cross disciplined. As Brandon said earlier and let's say, you know, Java and Spring boot. As much as I want to be an expert in ember and view and react all at the same time. The bottleneck there is my time. It's going to be really hard for me to be truly cross disciplined and an expert in all things front end all things back in all things deploying as well as knowing the product and everything else that we do at our day jobs. So that's one of the issues I struggle with is teams that are just hyper specialized. It, it is hard to break in, to cross functional. So what about you guys? Any other downsides you've seen day to day?
Kris Van Houten - 26:03 - I think one thing that comes to mind for me when I think about, you know, downsides to working in this manner and it's not just exclusive to who to the cross functional methodology is that is getting input from everybody and because I think on every team you tend to have those who probably talk too much and those who don't talk enough and and often like when I asked you to reach out to those who are a little more hesitant to share or to give their input at times, they usually have gyms that are just stored in their brand that they're just like, well, I don't want to like look dumb. I don't want to like, uh, I dunno if this is a good idea or not, but I think also a lot, a lot of times when you, people who tend to talk over people or people whose to to share perhaps too much or too often people just want to get out of the meeting and they just want to get on with their day. And so it's hard to kind of get them to want to share because you know, they're trying to get on with what their task lists.
Kris Van Houten - 26:58 - But I think, you know, encouraging them and perhaps you know earlier on and those meetings, pulling them out or calling them out and ask him to share what initial thoughts they have. And I also think that it engages them by doing that. It engages them to be more active listeners because I think sometimes if that's your mentality, you can also just kind of passively checkout of meeting. Like what are we going to get a lunch later? Because I'm really striving at this point.
Toran Billups - 27:22 - And so I think you see that all the time right where you started talking about let's say the x, y, z thing that we all know Kris is working on. Everyone else just kind of shuts their brain off. It's like, Oh, let Kris talk to the scrum master about that. I'm kind of done for 20 minutes I guess. And then like you said, I'll pipe up when lunch is involved.
Kris Van Houten - 27:40 - Hey, let's be honest. I've been that guy who's like checked out of the meeting and then I have a manager like, Kris, what are your thoughts? And I'm like, yes, that is a great idea. And so, I mean I've, I've been guilty of this as well. I'm not saying that I'm like some stellar person, but um, but yeah, no, I think by if you let people know that they might read them and get called on to ask for input, it's going to make them pay a little more attention.
Toran Billups - 28:03 - Cool, man. Brandon, what about you man? Are there downsides you've actually experienced either past jobs or current situation that just makes you skeptical that cross functional is the new agile?
Brandon Williams - 28:15 - Yeah, so I think the main thing is that you have to have, it can be lonely. So if you think about it, if your team is not big enough to support, um, to awesome front end developers like Kris and Kris is all alone and he doesn't have anybody. Yeah, it doesn't have anybody to talk to you. It doesn't have anybody to bounce ideas off of. He's just on an island that can be lonely. It can, um, you know, there's just because we don't have a big enough product jet or whatever, he, he can get into maybe potentially a rut. Um, so I, I can see that being a potential. So as, as we're building out these teams, whereas maybe, you know, a smaller company has a two front end developers that work on the four or five products that they're responsible for. Instead of having one, um, one developer for each of those products and they're isolated, they don't get to talk to each other type of thing.
Brandon Williams - 29:17 - And they're like, no, you only work on product x and Kris, you only work on product y. I'm just that kind of that kind of sharing. Um, the other thing, other flip side of that, the cons that I've seen are asking people to have responsibility for things that they don't necessarily have authority to do. So for example, we um, we have repositories for our infrastructure code and I say, Hey guys, you know, I want you to contribute to the infrastructure code, but then I don't give you permissions to get pushed or get pole or whatever it is. So therefore I'm asking you
Toran Billups - 29:56 - to troll ever needed submit and kill their acts.
Brandon Williams - 30:01 - So you guys, I need you guys to help me out, but I don't give you permissions to do that. Like that. That doesn't seem fair. And then the same goes like this is because I'm very focused on operations. Like um, you know, we want developers to have more, um, what's the word we say skin in the game, right when we're on call for things. Um, and so if we were to give them on call, we'd also have to give them permissions to go fix that stuff. Well, there's a lot of, there's a lot of knowledge that goes into, hey, this is how the system operates and when we give you this permission, can we give you just granular enough permissions just to affect your application within the greater scheme of the whole environment? You know, I don't want you accidentally messing something up for another product team over here. And so figuring that, you know, isolating the permissions and that kind of stuff, that's, those are some of the downsides that I see with the authority and the responsibility of making sure that you, if you ask them to have the responsibility that you also give them the authority to do that.
Toran Billups - 31:02 - Awesome. I want to wrap up on my soapbox with, uh, the, the one downside is, you know, making sure you understand how to incentivize the team and that you're not treating people differently. Like incentivizing back to this QA example. You don't want to incentivize QA for get as many bugs open as you can, um, because that can be in conflict with the product team that they joined or they come to be a part of. And so I think that's kind of where I'm, I'm trying to figure out how to work around that because oftentimes in bigger organizations it's really hard to get directors have all these different departments together and say, Hey, we're, we're maybe using Jira in all good ways, but the incentives that we're deriving or the metrics that we pull out of it are not always helping the end customer. And so some of the things I'm trying to help do internally right now has really pushed that agenda of what is the success metric for our team, making people awesome, making our customers awesome.
Toran Billups - 32:02 - And that kind of comes from modern agile if you've seen that from Joshua Kerievsky. But that idea is something that we are. And I don't say just me, I think actual real leadership in our company has been saying this and it gets me excited because that is what a product team should and can rally around is the customer. So we're no longer talking about your team. Brandon, on the ops side, you've got too many tickets open that aren't closed and Toran, you're not getting all those features done in QA. You just not getting enough bugs opened, so you guys are all in trouble and it's like, yeah, but to our customers love this stuff to the developers and the teams. Do we love working together? Those are the metrics that I care about. So
Brandon Williams - 32:38 - sorry, one more thing. You just, you talking about this. We had a senior. We have a senior leader that said there's really had this really awesome quote. I'm collecting metrics not to weaponize them, but to gain an understanding about the system, so don't weaponize metrics.
Toran Billups - 32:56 - I love that man because yeah, what's the first one? We always get weaponized code coverage. That's a rant for another day. Okay, well we'll wrap it up here. I think I'll jump into my big win, uh, which is really kind of an interesting one. A, I had this friend of mine, Joe, I'm brilliant designer, a front end engineer and I actually might buy big win is literally outsourcing some slides for a presentation I'm doing to Joe and it's not just that outsourced it and I'm lazy. I mean, that's a big win in itself, but it's actually been that I'm sort of cross functional or I'm, I'm getting a better presentation as a result because Joe is also, it turns out an excellent consultant. A interesting. We should do a show on that, right consulting. He's an excellent consultant on putting great presentations together. So a great side effect of using him to design the slides and do that slide deck work is, he's really good at kind of guiding me through, hey, this doesn't really make a lot of sense. So outsourcing. Thanks Joe. What do you got? Kris?
Kris Van Houten - 33:56 - My brother in law invited me to this fitness camp thing, uh, last week, but I was flying out to Austin and basically every morning in our city there's this group of dudes who meet at various schools around the city and they just do like crazy workouts. It's like military style workouts and so I went yesterday and like it was good but then I went today and today was like exponentially harder and I know for people who are Uber fit, like Toran, uh, running three miles might not be no big deal, but for me like I'd never done something like that. And the nice thing is this group, like they, they pushed you, they, they urge you in the act like brothers, like a, they partner with you. There are whole motto is like no man left behind, you know, kind of mentality to where like if you're last in line, they're like, come on Bro. Like we got you, we got you. And that was just, it was just really cool. I'm really looking forward to going back to this a few times a week to kind of get my butt in gear and get it into shape at the same time, but a really been enjoying. It's this group called F3. You can check them out at f3nation.com. But yeah, really digging it. What about you, Brandon? What you got?
Brandon Williams - 35:03 - So over the Labor Day weekend, played board games and card games with some friends, so that was really fun. Just some guys hanging out and um, having, having some shared experiences.
Toran Billups - 35:14 - All right guys. Well we're all going to be cross functional now.
Brandon Williams - 35:17 - It's the new silver bullet, right?
Toran Billups - 35:19 - That's right. See you guys
Brandon Williams - 35:21 - later