 going to make the AB guy freak out with how loud my voice is. So my name is Michael, as she said. My studies largely centered around music before I joined the Rails community. My undergraduate is in classical percussion and vocal performance. And while I was an undergrad, I fell in love with jazz. And for me, the appeal of jazz was it was improvisation, right? So we get to spontaneously compose music on the fly in the moment together. And they would like that immediacy of the connection to music and the moment, for me, is what was attractive. So I wanted to illustrate how some of the concepts of improvisation can be applied to the development team. But first, I want to show you some overwrought musician headshots. In being a musician, you have to advertise yourself. So, of course, I did that. So I call this one the Jazz Messiah Pose. You can see how it showcases my absence of a chin. This one would have called Cool and Continent or the Squatty Potty Pose. I'm not sure how this sold me as a musician, but that was pretty funny. Variation was the Jazz Fraud Pose, holding my mallets like a bouquet of flowers. And of course, the Fabio. I look more like I'm trying to sell jeans at a Gap ad, but hey, that was getting me gigs, whatever. So ideally, what we're talking about here is the people that I'm hoping are in the room. You guys are on a development team and you're looking for ways to be a leading force on your team. Maybe you're a senior developer who is trying to find ways of mentoring the more junior members of your team, right? You want to be able to coach the people on your teams so they can ultimately become better developers. Or perhaps you're a team lead. You're looking to improve the culture on your team. How can you get your team to work better together, to create more quantity and quality of committable code? So it comes down to what would an idyllic place to work look like. What would the idyll team be? You'd ideally have clear expectations, right? You'd know what you were doing on a given day. You would agree that what you're doing makes sense as far as the application or the business requirements concerns. You'd be like, I'm developing things that I know are gonna make a difference. You have a grip on the technical and business aspects of the thing that you're trying to create. So it isn't just simply here's a feature story that does some mysterious thing that the product owner wants. Like you have an idea of I know what this is supposed to do. Leadership is supportive ultimately. You have leaders that should work with you, not against you. So they're trying to support you in your efforts as a member of the development team and the development team as a whole. Conflict is resolved together, right? So people are not dictating to you like your code is wrong and you need to do blah blah and your attitude needs improvement young man and why are you acting like such a baby because you don't know what you're doing? Like you want people to resolve the conflicts that you have within the team and perhaps among the other teams and organizations that you work for, you resolve those things together. Then the values that your company holds and the values that your team holds are complementary. So if as you when you're working on a team, like you feel like the mission of the team is ultimately in alignment with the mission of the company. And ideally your work day is fun, right? You want to enjoy coming to work and doing what you do. You're free of unnecessary distractions or meetings that are not related to anything that you're doing at all and your work life and your personal life are complementary. So the values you have as a person line up with the values that you bring to work and the values that are inculcated to you on your team are somehow related. So what would it look like if you worked on a team where you wanted to find out what remove force all would look like on your GitHub repo, for example. So management. So you have little if any idea what you were supposed to do when you came into work. The user stories would be absent perhaps or you'd be thrown all around on any given day. When you ask for help or guidance from the management team, whether it's regarding your day to day work or working with other teams, you get meaningless platitudes or nothing at all. How many people work for really, really big organizations? Anybody? So have you ever seen those mission statements? This is our mission and it's like the vague business gobbledygook that really has no application to what you do. So we wanna sidestep all that. So leadership is also unsupportive. So it comes in two flavors. You're either a micromanaged, like somebody's over your shoulder trying to tell you what to do all day or there's no management at all. Like you wouldn't even know who to go to if you had a problem. Outside of your team, management does nothing to foster communication among other teams. So it's all like an episode of Game of Thrones or something, right? So your team is like the Lannisters and like they're fighting for turf with like this other team and like it's all about using you as a means to undercut somebody else. And it's not fun. Working in a place like that is not fun. You either have nothing to do and are just bored all day or there's too much to do, the deadline is too short and these requirements have seemingly manifested out of thin air. And the only real interest leadership has in you is in your ability to produce. So you have no life work balance. You come to work, they squeeze you like a turnip for all the code they can get out of you and throw you on the train back to your house. So we don't wanna work in a place like that. So what would be the ideal model for a development team? How could you have people that are actualized as individuals while contributing to a meaningful and productive team? Well, ultimately, that model could be the jazz band. So how does that work? So let's cover what a jazz band is in 60 seconds. You can think of a jazz band kind of like agile squads, right? You have the rhythm section that has their job and you have the horn section that has their job. There's three components really to music in general. So you have melody, harmony and rhythm. You can think of melody kind of like the core language, right? That is the meat and potatoes of what music is all about. It's like what you're using to communicate your message. Harmony is a lot like the framework, right? It's the thing that gives melody context. So kind of like Rails is to Ruby, right? You have a framework which allows you to communicate and interact with a user in this particular framework. Rhythm is kind of like DevOps, right? It's the thing that allows all of this to occur. So music is what we call a temporal art form. It happens over a period of time. So we have to consider time when we're being creative. The vast majority of jazz standards are using one of the three patterns I have there on the slide. So think of it kind of like convention over configuration. We have very specific templates that we use in jazz. Now, not all jazz music does this, but the majority of music that you're gonna hear in a particular, say, oh, Stan Kenton or whatnot, some of the great big band composers very much use templates like this. So typically you have a melody that's stated. People get to improvise on the solo. The melody is stated again. Everybody claps. Drinks are served. People dance, yada, yada, yada. Good times. So how can we apply this to our field, right? So company style guides. Now this goes not just beyond the style guides we have as a community, but like how many of you have style guides within your company? Are there particular, so we gotta show hands. We got some people that do that. So you have particular colors that you choose to use. There's particular, so there's a lot of different ways of getting work done, right? Maybe your team has picked one specific method, right? You use size over count or whatever you guys do. So I mean, I think we heard Justin mentioned it in the keynote today, right? That the idea of creating this level of consistency among our teams is going to ultimately, positively impact our work. So if I don't have to think about what colors I have to use or what particular way I have to do my job that thinking has been done for me, I can just focus on being creative and doing the things I wanna do. So you can think of it like freedom to versus freedom from. So I'm free from the decision making process now and I'm free then to be creative in my own way. And the idea behind that is as a group, we've all agreed upon kind of like we're all playing the same song. We've all agreed upon how we're going to move forward as a team and we all get to be creative in our own way to do that. So I think of it a lot like as a sandbox. Everybody playing a sandbox as a kid? My parents were very specific about the sandbox. You can do whatever you want, within reason, in the sandbox. You can play all day but here's the box in which you get to play. So company style guides are a lot like that. They provide that framework for us to be as creative as we want within a specific scope. Now, guidelines are not rules. There is a time and place to bend the guidelines. So like Charlie Parker said, you learn the changes and then you forget them. The idea being that guidelines are servants, not masters. We ultimately want to afford people the opportunity to be as creative as they can be but not stifle that creativity. So sometimes you gotta color outside the lines and that's okay if you have a good reason for it. Guidelines also serve as barriers to the unknown, right? So again, Justin had mentioned earlier in the keynote today, considering your future self. Like how can you be creative in a way where you're setting up the next developer or your future self, setting them up for success? So what do guidelines versus rules look like in the jazz world? Well this is what rules look like. You have very specific notes to play. You play them at a very specific time and this is exactly what it's gonna sound like which is very specific and rigid, right? So my attraction to the jazz world was I get to be creative and expressive right now in a very specific manner. So this is what guidelines look like in jazz. They provide you just the framework. Here are the chords that you are supposed to play within. You can play inside, you can play outside but ultimately this is the guide we want you to follow. So it provides just enough structure for us to be creative without stifling our creativity. So what do guidelines versus rules look like in development? So I would say this is what a rules-based user story looks like. As a user, given I'm logged in, I want to see our company logo as a 90 by 45 P&G file in the west pane of the nav bar with the nav bar color being this hex value with Helvetica font as the default text displaying the turn links in a highlight text which I've also provided the color for you with a maximum load time of 566 milliseconds. Who wants to develop a feature like that? I don't, namely because it's, I mean it's an exaggeration of course but it ties my hands as a developer because as far as I'm concerned like my job is to make the code serve the user. So if you look at the guideline-based one as a user, given I'm logged in, I want our company logo to display in the nav bar with highlighted links. So it's very explicit on the what I want to see which allows us the freedom in the how. How are we going to accomplish this goal? Because I would presume as developers we have more knowledge base when it comes to coding than our product manager does. They might disagree and that's okay but our job is ultimately to be caretakers of the code. So it provides less clutter and confusion, right? The guidelines base. I might have to make some choices while I'm developing that would might be contrary to a rules-based user story but if I have good reason I'm ultimately still serving the purpose of the user story at the end. So say you buy into guidelines, guidelines are great, Mike I think this is an awesome idea. How do I implement this on my team? Like what's the next step for us? So I would say we don't develop in a vacuum just like we don't solo by ourselves. So the key is be aware of your surroundings. Code to me is like a pebble in application lake, right? You drop your pebble in and it's gonna ripple through the whole application. So we need to be aware as we're moving forward how is my code affecting the ecosystem as a whole? So a great way to work with that is if you do TDD or continuous integration. Where I work, we're pretty stringent about anything you commit has to have a test. Anybody else work like that? Okay, a lot of us do. And continuous integration, well we use that too affords us the opportunity to I know I can submit my pull request and it gets peer reviewed and when it goes into the code base we have checks and balances that will make sure whatever I submit, whatever pebble I throw into the code base as it ripples through the application it's clear on how I'm gonna affect the rest of the ecosystem. Considering your future self, right? You can be very tempting to over develop things like if I'm thinking about the future maybe I'm gonna need this feature and if I need that feature I've gotta set up this module just in case and I gotta write this adapter in the event something else comes down. And we can tend to over develop in a sense. So to quote Russell Olson from Design Patterns of Ruby you ain't gonna need it. So the idea is you develop what you need right now because the freedom to develop also means freedom of being responsible for the next person in line. Again I think I heard Justin just say that very thing. While you're working are you considering the person coming up behind you? Are you considering your future self and try to develop in that manner? Listening is also important. So just like when I'm taking a solo in a jazz band I can hear the bass player, I can hear the keyboard player, I can hear the drummer and I'm aware of what's gonna be happening around me. So collective freedom means that the team awareness is even more important. Do you know what your coworkers are doing while you're developing? Are you aware if anybody else is touching the files that you're touching while you're developing your feature? So I know in my experience like I have come into conflicts when I'm not aware of a feature that somebody else is working on, we've both touched the routes file and now we have this like merge conflict we have to deal with which ultimately slows everybody down. So being aware of who is working on what among your team will also help you to be faster as a team and be considerate of those around you. So how does soloing work? So if I'm being creative in my environment what does that look like for me? So the soloist on their branch will say they would be driving the bus. They should feel as though the decisions I make will ultimately be supported by my team. Now that's not to say they're gonna cosine bad code but you should ultimately feel like I'm being supported by those around me. So you should also adhere to a style guide. Again this is where style guides can come very handy when it comes to your team. If I know ahead of time what the rules are or get more like what the sandbox looks like for this feature by the time my code goes up for peer review I've already answered a lot of the more nominal questions that would come up had I not done that in the first place. So comments on code. This can be a very touchy subject if anybody's ever committed PRs to open source. Feelings can get hurt sometimes. So how do we deal with that? I would say telling ain't selling. So we say that a lot in the education world. So as a teacher when I'm trying to get you to do something different I'm not going to tell you I'm gonna ask you the right question so you find the answer that I know is correct on your own. So how can we do that? So when we're peer reviewing each other's codes do you say to your coworker, no that method's wrong. Don't use a try block, use dig. Or do you say hey did you know that the method dig is around and maybe of a better use here? What do you think? Now we all, if you guys have ever worked with navigating objects dig is definitely a better solution than a slew of try blocks but the idea is you want your coworker to come to that conclusion on their own. To foster the creativity. Because creativity in itself is a very vulnerable thing. So time, how can we all be considered of the environment in which we work? So freedom implies vulnerability. Being creative is a vulnerable act. I'm taking this thing I made and I'm putting it out in front of all of you. So while we are working together in that manner it is important for us to be aware that there is some level of emotional attachment. Well I mean I'll say keep it for myself. I am attached in some way to the code that I produce because in some way I feel it represents me. So if people attack my code I can feel attacked sometimes. Now I know in my head my coworkers are not telling me I'm a bad person because I made some less than ideal choices in my poll review. But it can feel as though you're being attacked. So it's important for us to be aware of that when we peer review each other's codes. And then Vince won of course. Matt's is nice, so we are nice. Knowing your role in the ensemble. So if I'm the saxophone player I'm not gonna try to play a drum solo. Not my role. So what section of the team are you on? We all have our skill sets. Some of us are really good in the back end some of us are really good in the front end. So where do you naturally gravitate? So just like a big band there are particular skill sets we each have in parts of the stack where we gravitate. So you're encouraged to play to your strengths while you strengthen your weaknesses. So how can the leaders on the team how can your team lead or how can your manager encourage you to level up on some of the skills where maybe you're not as strong as you'd like to be and you can still make contributions to the code base in that way while capitalizing on what you're strong on. And then the contribution to your team has a lot to do with where you wanna go as a developer. Do you have any idea where you want your career to go? What do you wanna be doing next year? What are you gonna be doing three years from now? Five years from now? You what you do today and what role you play on your team today is ultimately going to be in service of those goals. Band leading. So one of my favorite band leaders is Duke Ellington. And the reason why is because when he wrote tunes he didn't write for trumpet three he wrote for Cootie Williams. So he wrote specifically for the people in his band. And that to me was a lot like servant leadership, right? I want you, I want your voice to be a part of the product. So how can we do that in our field? So we're leaders are very much stewards of the culture. So spotlight, so you ultimately want to spotlight your dev strengths and help shore up their less than strengths or their opportunities to grow. So potential and passion in my experience are far more important than skill. Skill can be taught. You can learn how to be a good backend dev. You can't really learn to be a passionate person. So passion and potential are important. Encouraging your strong players to mentor your greener players. This is a big tradition in the jazz field. The idea that I've been playing in the Basie band for 20 years and I'm rubbing shoulders with a guy that just got here. So how can we, the more senior members of our team be encouraged to mentor those that are younger and how can the junior devs on the team be open to that level of mentorship? That conversation has to happen because not everybody is welcoming to unsolicited feedback. I'm sure we've all been there once or twice. So encouraging that kind of culture on the team largely starts with team leads or with managers. How can you create a culture of mentorship on your team? So inevitably when we're working, things break, right? Creativity is a wonderful thing. The product of creativity isn't always great and that's okay. So how can we deal with failure? Part of dealing with failure is accepting failure. Now I'm not saying if you push a bad commit to prod and you break prod and we should be like, oh, you're learning, that's great. I'm not saying that. But the idea is creativity will yield failure sometimes and that's okay. Can you learn from the failed experience? You push code to a sandbox, you break sandbox. Okay, that happens. What did you do? How can you fix it and how can you learn from that experience? That means I'm not pointing fingers at you for breaking something. You did something bad. You made a choice. It wasn't the right choice. So how can we choose better next time? I think of it like ugly babies. Anybody ever seen an ugly baby? I know I'm not the only one that's seen an ugly baby. If you don't want to admit it, that's fine, it's cool. I'm sure you never, unless you're a jerk, you didn't say to your parents that baby, damn, that is an ugly baby. No, that's a hurtful thing to say, right? Now, that kind of relates to code. When you create this thing, sometimes the thing devs create is kind of ugly. It might work, but it's ugly. You don't say to that dev, man, that is ugly code. For the same reason why you wouldn't tell somebody their baby's ugly. It's something that they created. They think it's beautiful, they made it. So how can you deal with ugly babies? Kind of goes back to what we were talking about before. How, what questions can you ask about that ugly code that perhaps might bring that dev to a better choice? Say, oh, I see you used a beginning rescue end here. Why'd you do that? And let them explain it to you. And then maybe the explanation is they didn't realize there was a better way of doing that. So then we're back to asking again, did you know there might be a better way? How, what does that sound like? So I'm guiding the dev to the right decision without dictating what that decision is. Ideally, maintaining that spirit of creativity in the moment. My uncle Peter was an actor. And one of the most valuable lessons he taught me was you are not your work. And this kind of relates to ugly babies. I am not my code. So what that means is when I submit code and it's bad code and people tell me it's bad code, that's not necessarily a reflection on me or my abilities. It's a comment on the choices I made in that moment. Just like when you're taking a solo and you play some notes that are not even related to the song you're playing. You might get some hairy eyeballs from the band and that's okay. But there are choices you made in the moment. And as long as we realize that, we can be critical of the choices and not of the developer. Because when you criticize the developer that ultimately impedes the creative spirit of that person. So now you're getting less code and more timid code from that developer. Also, don't touch the keyboard. Any keyboard touches in here? No keyboard touches, okay. Band leading do's and don'ts. So you bind into the concept of yes, my team is like a band. I want everybody to be creative and feel the creative spirit and create really interesting and rich features. How can I do that? So it comes from managing from a position of trust. You need to trust that the people on your team have the desire to create the best features they can. People don't push bad code because they're like, ah, you know what today, screw this guy. I'm pushing this bad code. We don't do that by and large. So one must trust that your team has the best interests of the code based on mind. When it comes across less than performant code, again, how can you ask questions about why the devs made the choices they made? Each one teach one. It's key. How can you, as a leader, encourage your senior developers or encourage your more seasoned members of the team to coach and encourage the less than junior members? That idea being there's kind of like an attitude of Kaizen on the team, right? Or continuous improvement. We are all about getting better and part of getting better is making mistakes. You're gonna make mistakes and that's okay as long as you make them once and you learn from them. So things you don't do. Creativity, like I said, is a very vulnerable process. People are attached to what they create. So naturally they will shut down and get defensive if we attack instead of question and coach. Don't let your stars outshine the ensemble. This is key, too. We all have people that are very strong and can commit like the 10X programmer, right? We've all heard this legend of the guy that can push 10 times the amount of a regular programmer. There's stars out there and then there's people on the team that might habitually struggle. So make sure that you publicly praise and privately coach and kind of that is spreading love. Make sure everybody gets a chance to shine on the team in a way that they are capable of doing so. Creativity can also be messy and unpredictable. So we don't want to kill creativity with the sledgehammer of quality, right? How we wanna encourage people to be creative and make creative choices and make interesting code choices and features but we don't want to squash that while we inevitably have to kind of sand down the edges when it's required. So in summary, what can you take with you today? Trust, trust is a fundamental part of maintaining a creative atmosphere. I must trust as a team member, my team lead has my best interest in mind. I must be able to trust that my team member or my team leads and my senior developers are going to coach and develop me when I'm struggling. As a team lead, I have to trust my team is going to make the best choices they can with the information they have available to them and you should explicitly create that as culture on your team. Stewardship, so this talk is based on a book by a guy named Max Dupree and I'll put a link up somewhere called Leadership Jazz and he was a CEO of a furniture company for 30 years and he talked about steward leadership as a leader, as somebody in charge, the group comes first. It can be very easy for us as leaders to think about what's good for me. How can I run this team in a way that's good for me or feels good to me or provide feedback that I would want if I was receiving feedback? The concept is like the platinum rule. So I had a very brief career at Macy's. One of the things about being a musician is like you need a day gig to hustle all the time. So I was, I sold suits for like two days but through training they talked about this concept that I'll never forget, the platinum rule. We've all heard of the golden rule, right? Do you want to others as you would have them do you want to you? The platinum rule is do you want to others as you think they would like to have done. So what does that mean? So as a leader there are particular ways people want to be coached. Do you know what that is? Some people want to be coached like as if they're playing on a football team. That's very much my style. Like I was in the sports. Some people need a more delicate approach to that. Need a more consultative approach. And that's okay. As leaders we need to be aware of what those are. And then guidelines, style guides. I very much encourage this. Does your team have a style guide? Does your team know about the style guide? Do you regularly return to that style guide as a team to refresh yourself or to make different choices as far as the style is concerned? Do you have orientation for new developers? So that comes in two flares. I know when I started my new job they just gave me a laptop and said cool here's the app you're working on here's the list of features, go. I was like okay. And I just had to flounder until I figured it out. Which can be discouraging. So do you have an orientation process? Do you have a way of this is how our team does stand up. This is how our team works on features together. Do you, can you acclimate people on your team in that way? And this is all stuff that can be wrapped up through Kaizen. So thank you very much for attending. Very much appreciate your time. Enjoy the rest of your conference. What instrument did I play? So my undergrad experience was classical percussion and voice. So I was a opera singer on one side and I did all the orchestral stuff. When I went to graduate school I studied the vibraphone, which is what the flower of mallets in my hideous head shots was all about. So the question is if you're in a band setting a lot of times the lead singer gets all the credit and the backup band can feel some resentment. Is that right? Okay. So it kind of goes back to don't let your stars outshine your team. Same way you don't let your singer outshine the band. So I know when I've led bands that have had lead singers that get all the credit a lot of it is can you break off a chorus to let somebody solo? Can you drum solos do a lot? It's like 30 seconds and that drummer is gonna feel great for the rest of the night. So how does that apply to the team? You're gonna have people that have more of a supporting role on your team and people that are the seasoned rock stars. How can you offer the younger people an opportunity to shine? And then when they do their work, shot them out. That's like praise is free. It's free and it's one of the most valuable things you have as a leader. Hey, so and so just did this feature and it's great. Everybody check it out and then platform and stand up. That I'm telling you that has significant value. How the question is how do jazz musicians handle conflicts? Conflicts in what sense? Like personality or like while you're in the middle of making music? Okay, so personalities, right? In my experience, particular types of people, particular personalities like compliment or clash. So one of my heroes is a guy named Gary Burton. He's a jazz vibrato player. He told me once in a lesson there's a very famous jazz keyboard player, Kenny Barron. They just clash. The manner of playing just runs into each other. So a lot of times is can you, so for us, can you segregate the work in a way where maybe conflicting personalities or development styles don't bump into each other? So that's before the music starts. Say you're in the middle of playing and there's conflict. I want to play outside. The keyboard player doesn't want to support that. It kind of comes back to roles. So my attitude whenever I led a jazz band was the soloist drives the bus. If they want to play out, we play out. If they want to play inside, we play inside. So how does it relate to us? If it's my branch and my feature, I'm driving the bus. Now, we're different than music where it's very like ones and zeros. There's like better ways and not great ways. But it comes back to how do you, how do you bring that soloist back into the band? It comes back down to comments. Can you ask the right question to get them to make a choice that kind of gets back to where they need to be? That's kind of critical with junior devs, especially when they find a new method, right? I'll do this. Like where I work, we deal with a lot of APIs. So I found this method dig. Dig is great. I want to use dig everywhere. Well, maybe dig isn't the right choice for that thing at that time. So my team kind of had to like get me off the dig train for a second. And a lot of that was asking the right questions. You chose to use this method here. Why'd you do that? And normally when I find myself explaining why, I'll hear, oh, this isn't what I intended. Yeah, you're right, I should do something else. So the question is have I worked with either as a musician or a developer with somebody who doesn't seem to care about the dynamic of the team? Is that fair? The outcome. So they want to do whatever they want to do and whatever come out of the other side is like whatever. Okay. Musically, it kind of comes down to choice. I don't necessarily have to choose to work with that person, right? That's beforehand. Say we're in the middle of it. One of the most powerful things you can do in music to communicate, stop playing. So if somebody's taking a solo, I'm trying to interact and they're just not listening to what I'm doing, I'll just stop and let the absence speak for itself. Because if you find yourself playing all by yourself, it's just you and the drummer, you kind of have to ask yourself, well, what am I doing where everybody wants to stop? So how does that apply to us? If you're working with a developer that just doesn't seem to care about what anybody else thinks, wants to just push their code and bypass his peer reviews, is there a way where you can like quarantine that person? If you have that level of power or on the development team, maybe you don't comment on their code. So they're gonna find themselves like I feel very isolated from the group. Now, and that's just what happens. If you start choosing yourself over the team, you're gonna end up by yourself. And I don't know about you guys, but one of the attractions to this field for me was creating as a group. I'm a member of a team and as a team, we're building this thing and this thing is great. So if you find yourself no longer a part of the herd, a lot of people are gonna ask themselves why? And maybe that can be addressed. I think we are about out of time. So thank you again for coming. You'll see it on Confreaks and I would love to talk to anybody afterwards if you got any questions. So thanks again for coming.