 Good afternoon. I'm going to talk about manifestos in tech, which of course that's not controversial, right? This is the agile manifesto, by the way, the agile manifesto. How many of you have never heard of agile software development? Raise your hand. It's okay if you haven't. You can be honest. Okay, everyone. All right. Well, then I'll go through a certain part of my presentation very quickly. How many of you lead technology teams in any capacity? Okay. I see a scattering of hands. How many of you want to lead a technology team at some point? All right. Similar number of hands. All right. I think we're all in the same place. So that's good. So I want to talk today about my journey as a technical leader. And a lot of my journey has been around the idea of trust. But it took me a while to understand that. And my journey really goes back to when I was young. And I remember I'm a big science fiction fantasy nerd and played Dungeons and Dragons. And I really loved the exploration aspect of when I was a kid. But when I went to college, I discovered that someone named Joseph Campbell actually put together a structure that was called by others, The Hero's Journey. And so there was this actual academic study of the journey that almost every, at least man is seeing, a lot of sci-fi stories and other genres have heroes go through. And the book is titled The Hero with a Thousand Faces. And it is often subtitled by others, The Hero's Journey. And the introduction from the book goes like this. A hero emerges from the common world and enters in this fantastical world where that hero encounters wondrous fantastical things, is changed, and then returns to the real world with some knowledge or perhaps some magical item that that hero can use to make the real world better. That magical item is often called a boon in Campbell's language. And I really liked how Campbell used this cycle to show common threads in every story. And, you know, being someone who likes fantasy and science fiction, I was always drawn to heroes. And I was amazed that someone had actually put rigor behind the idea. Now, I did not know it at a time, but Campbell's cycle, Campbell's Hero's Journey, would become a key part of my leadership style. Not every story follows Campbell's cycle exactly. Some omit phases, some may change the phases, but there are four major parts. And so there is first the call to adventure, right? You're in the common world and you have this call to adventure. And then you go through some extreme trial that you have to overcome. And then there's the transformation that you go through after going through that trial. And then finally, every hero has to go home. And so you make your way back on the road to where you started back in the common world. And I'm not going to go through every step in the journey because I could do a series of talks on this. But you have different parts of the journey from the call to the initial refusal to meeting a mentor. I'm going to talk about that mentor relationship in a slide. But I really like the idea of this journey, of having this road that the heroes have to go through to really find their destiny. And I think I like it so much because my life in technology also has two worlds. You have the personal world and then you have the programmatic world, right? You have the world that's analog and the world that's digital. And I found that as I began to learn about programming and, you know, I had my trials. I took a class called Data Structures in C, almost took me out. But I made it through, made it through. And so I persisted. And so by going through my journey in programming, I began to see that I had a boon. I had something that I could offer to the real world. As software developers, you have to think in a very structured manner. You have to think logically. And the ability to think logically is really powerful in a world where often a lot of illogical things happen. And so I felt that this journey really matched my journey through programming. But how does the mentor relationship work? How does someone choose who to mentor them? And really it was this mentor aspect that drew me to the world of heroes. And, you know, a mentor is simple. A mentor is someone who simply has completed the hero's journey and is helping someone start their hero's journey. And so I began to see the link between the journey you're and the journey you're and the journey guide. Because that's what it technically does, right? When you lead a software team, you're guiding your team through a journey that you've already traveled yourselves when you were an individual contributor writing code. But I really didn't understand what would cause a new hero to follow an experienced hero. And I didn't know it, but I began to see that trust. Trust was a very key ingredient. Now, one of the most popular myths of our time is Star Wars. And it really showed how this mentor hero mentor hero cycle works. In fact, George Lucas has said on many occasions that Campbell's book was a big inspiration for Star Wars. And we see this cycle where Quingon mentored Ben, who mentored Luke, who mentored, we'll see, Ray. And so you see this journey, this cycle happening. And keep in mind that along the way, every mentor has to earn the trust of the next person in the cycle. Now, I don't own any of these images, by the way, so you don't have to get that disclaimer. Well, I think we all know this story. And I thought, that's cool. I get it. There's a problem, though. It seems like a big part of this requires passing on a lightsaber. And I don't have a lot of those. So I began to think about, well, is there more academic study? There's someone like Campbell put rigor around leadership and around leading teams. And I found a couple of examples. So when I first became a tech lead, when I first started leading software teams, no one gave me a manual said, this is how you lead. If you find that book, let me know. But I didn't get a copy. But I found a book by John C. Maxwell, which is called a 21 Irrefutable Laws of Leadership. And I really love this quote from the book, which is the law of influence. The true measure of leadership is influence. Nothing more, nothing less. And so I saw that influence is really powerful. And it really resonated with me. Maxwell made a distinction between people who lead by their titles and people who lead by their influence. And I can tell you that people who lead with influence are a lot more effective and get a lot more done. There's someone who just says, do what I say because my title says that you should do what I have to say. Because just because you have a title, that does not make you a leader. And really all a title does is buy you time while you build your influence. So I realized that influence is a key part of leadership and a key part of influence is trust. You can't influence people who don't trust you. But were there other aspects of leadership that would come into play? And I found another book by McGregor Burns on leadership. And so one quote that I like from this book is this one. You have two types of leaders. There's a transactional leader, right? We all work with this type of leader. If you do what I say, I'll give you good things. If you don't do what I say, I'll give you pain. And I don't know about you, but I don't like working for transactional leaders. I think that you can get things done with this method, but I don't think you get them done well, nor do I think you get them done for long. What I like is to be a transformational leader. And that is someone who uses their charisma and enthusiasm to influence their followers. And there's that word influence again. And so I realized that influence is a big part of leadership, and I've been wrapping my leadership style around influence ever since. And so I began to think, well, I get influence, and how can I detect how my influence is doing? How many of you have heard the term cold smells? You know, aspects of cold that you just look at, and you're like, ah, something doesn't seem right? And so I realized that, okay, cold smells in my team, and I've identified cold smells, and every team has different cold smells based on the language you're working on and the practices that you employ. And you may see, okay, this is a really large class. We don't need to break this up, or there might be some other way that you have a cold smell. Well, is there a way to have influence smells? You know, are there trust smells? How can I get an intuition that something may not break right now, but it's probably going to break in the future? And then as I began to progress in my career, and I'm old, y'all, so I also began my career in the 90s, like someone else said, I think. And so, no, I think Amy was saying this was before her time, before your time. That was my time, by the way. But in the 90s, when Amy was probably in kindergarten, or if she was even alive, I began my career, and I did big waterfall, we've all seen kind of big bang upfront planning that you plan two years, that you hope that, you know, time freezes and nothing changes, and it always changes, which is why waterfall projects often fail. And I began to learn about Agile, and so about ten years ago I learned about Agile, and I thought it was just, you know, oh wow, we stand up during meetings, and I thought that was it. And over a time I was like, oh, there's actually more to this. And I became a certified scrum master, and I began to look at the Agile Manifesto, and so these gentlemen gathered in a place not too far from here, at a ski lodge, and they were there to vacation, but they were also there to try to figure out, how can we make software development better? We've all seen these huge projects fail spectacularly. Is there a better way? And these people all came from different backgrounds and different ways of doing programming. They also were having a diversity and inclusion conference there. Obviously not. So they came from extreme programming, they came from scrum, they came from different backgrounds, and so they began to, like all people who want to do a revolution do, they wrote a manifesto for what they learned. And this was, can be known as the manifesto for Agile Software Development. So most of you have heard of this, but I'm going to roll through these, right? So we are uncovering better ways, and I want to pause there, because people forget the uncovering. They forget that they weren't saying that this is Bible, that this is forever. We are uncovering better ways of developing software, and they uncover by doing, and that means that all of us are also engaged in this uncovering aspect of developing software. So we can take part in this as well. And so there are some principles that are some values that they came up through this manifesto. I'm going to roll through these. And so these four values I think were extremely, extremely powerful. And the way that is structured, it means that the values on the left just simply have more value than the ones on the right. And I go through a few more examples as I continue through this. And so I'm going to go through each Agile value and show the leadership lesson that I've distilled by using that value in my daily work. So individuals and interactions over processes and tools. Now, this doesn't mean that you don't have tools, but it does mean that you can only have tools because you build software, not with tools. You build software with people, at least for now. And so if you have people involved in software development, then you have to have a team where these people and their interactions are optimized. But not just any people. We need to have people who are motivated, people who are interactive. And there are a lot of ways to optimize the interactions of a software dev team. And I've seen a lot of them. I've seen the open space concept where we all sit in a pit and we see everyone. And it's meant to open the communication flows through the team. Or we've all seen people put in pool tables or ping pong tables. And all these ways are popular in a lot of ways. They're all really bad for productivity. And a lot of studies are showing that. But there are also other ways that you can motivate a team. Daniel Peak wrote a book very well known that said Autonomy, Mastery, and Purpose are better ways to motivate teams. However, I thought a very simple way to motivate my team and that's this, preserve dignity at all costs. This is the way that I apply this agile value to my team. And that just means that I preserve the humanity of everyone on my team in every interaction. That means that even people who I don't lack on my team, I still preserve their dignity. It's easy to dignify allies. It's easy to dignify the people who do what you tell them to do. But as a leader, as a transformational leader who wants to foster trust, you have to dignify everyone on your team. And by honoring the dignity of everyone on your team, that's how you build influence. That's how you build trust. Now, I've learned this in a couple of ways. And one quick example is a couple of companies ago, they were on a team and does anyone here use Slack? Everyone, alright. So you guys know what Slack is. So I came to the company and they didn't really have, they used Skype, which nothing against Skype. I wasn't a fan. And so I said, you know, there's a tool called Slack. And so I introduced Slack to the team and we began using the Slack channel. And then over time, more people from my company joined the Slack. And I thought, this is great. You know, I love this. Well, after a couple of months, a co-worker came to my desk and said, you know, in the general channel, someone made a joke about bacon. I was like, well, does everyone love bacon? Bacon, there's nothing, there's never anything wrong with bacon, right? Well, this co-worker was from a Muslim country. And she explained to me that making this kind of joke was very insensitive. And she said that, you know, while people are joining this Slack group, then we might want to be very careful and a little bit more prescriptive in managing the conversations. So I was like, you know, in my head I was like, well, you know, I would rate this person and it's not a big deal. And at first I kind of blew it off. But then I realized that, you know, this Slack channel, this Slack team is a community. And in a community, everyone needs to feel welcome. And so I eventually went to this co-worker and I said, you're right. I want to make sure that everyone feels welcome in every part of this company, including this Slack team. And so I just pinned a note to the general channel saying, please be respectful of other people's beliefs and perspectives and worldviews when you post. I think there might have been a, you know, brief dip in activity when I did that, but it was worth it. It was worth making sure that everyone felt that their dignity was preserved, working with me and in this company. And so preserve dignity at all costs is an extremely important, agile value if you want to be an influential leader and that one, one that builds trust. Now there's this one which is working software over comprehensive documentation. Now I always tell people this doesn't mean that we don't document. A lot of people say we're doing agile, no more documentation. That's not true. We do lots of documentation and as we document the sprint backlog, we document the product backlog. We create user stories. So it doesn't mean that we don't document, but it does mean that we try to do as little documentation as we need. And my general rule is if someone new joined the team, what would they need to know to get up to speed? Well, then that's what we write down. And so it doesn't mean that we don't document, but it does mean that we really try to optimize getting working software to our customers. And I always tell people that, you know, nothing against prototypes and I know that there are a lot of envisioned ninjas who can create really high-fidelity prototypes, but the only way to know how our customer is going to use software is to just ship it to them, all right? Ship it and then hear it back from their experiences and then bake that into the next version of your software. And so by focusing on getting things working, by focusing on making sure that you are known for getting things working, then people are going to trust you with the product. And so that's that lesson. The next agile value is working always ships faster than perfect. And I'm sorry, that's the lesson for this, is that working software, working always ships faster than perfect. And by that, I mean, you could spend a lot of time trying to make a feature perfect. And you're never going to get there because perfect software never ships. But if you get a working version of your software, then you'll be able to get influence for your customers because they know that, you know what? I'm going to get working software that I can look at and actually get feedback on and then this team's going to make it better. And so this is how I learned this story. A few years ago I was working for a global company and one of our European offices had customers in each Asia. And the problem was that our support team was in the U.S. and there was a problem with getting support during late hours. And so, you know, we had this long drawn out discussion. We drew all the trust about time zones like the American time zone and the European time zone and the Asian time zone. And we were going to put together some big long document. I was like, hey, guys, chill. Let's just give it a try. Let's just say this is the number for support. Let's get this person who sits in India a phone that when that person supports called, that phone rings. Let's just see what happens. And so I just cut the meaning short. Because I want to get something working. Let's get something working and then see what happens. And I guess what? A month with the buy, we had no calls. And then over six months we had maybe two calls. And so we could have spent hours on that system but we eventually got it working and realized that, well, that's good enough. And as developers, you're going to not just build software. Or as leaders, you're not going to build just software. You're going to build schedules. You're going to build productivity plans. You're going to build a lot of things. And so working software doesn't just apply to code. It applies to anything that you have to build to make your team successful. All right. So the next value is customer collaboration over contract negotiation. And again, this doesn't mean that we don't have contracts. I write statements of work pretty much all day long in my daily job. And that statement of work is a contract that outlines what we're going to provide to the customer. And so it doesn't mean that we don't have contracts but it does mean that we don't focus on contracts as the basis of our relationship with the customer. And so the leadership listed is this. Customers trust colleagues, not contracts. If the main mediator of your customer relationship is the contract, that's not going to be a very rich relationship. You have to work side by side with your customers in order to get their trust. And to be honest, customers don't read contracts anyway. And I've learned this many times. I was like, well, did you see on page 89, section two, subsection B? Like, no. And so treating customers like colleagues instead of contracts will get you the better outcomes and it will increase the trust that your customers put in you. And the way that I learned this is that I was working with an outside company to build an interface between our product and their product. And we began to try to work separately where my team would work on the feature and then we would have a weekly call and then they would show what they had been working on. And we kept on diverging because this interface, either they were missing fields in the interface or there's something wrong with their code. And I was like, well, wait a minute. We're operating as two teams separated by companies. Let's create one team that spans both companies. And so I set up our sprints so that we all went through the same sprint calendar, the same sprint cadence. I set up our daily standards so that they called in two. So instead of working separately and meeting weekly, we worked collaboratively. We worked side by side. We were doing that by treating that partner as a colleague instead of a customer, instead of just letting the statement of work mediate that relationship. We got a lot of things done. We actually shipped that integration earlier, much earlier than expected because I decided to treat this customer like a colleague and not like a contract. Responding to change over following a plan. Now again, this doesn't mean that we don't have plans because a lot of people after they say, we're not going to document anymore. They say, we're not going to plan anymore, right? No, no. There's an agile, there's a scrum event called sprint planning. It's called that because that's where we plan. So it doesn't mean that we don't plan, but it does mean that we acknowledge that the future is notoriously hard to predict. I'm not sure what's going to happen tonight. How can I put a plan together to account for what's going to happen in six months? So we break time into slices called iterations. And then we set up those iterations or sprints so that we do work that we think is valuable. We learn from that, then we bake that learning into the next iteration. And so that's how we create time slices. Now the lesson that I want to share with you guys is this one. Don't fear surprises, fear and flexibility. You're going to get surprised when you start leading teams. These are going to happen. People are going to leave your company and therefore leave your team. There might be some major break the build bug that your team, instead of working on the next feature, they have to work on. And so I tell people, accept that surprises happen and then plan for them. And by building flexibility in your planning, then you'll be far better able to handle surprises. And so the example that I give is that I was involved in this WCAG. This might do WCAG, the accessibility requirements. I don't know what that is. Okay, so I was on a WCAG project where we had to remediate some of the findings of an audit. And so we were going to put out this long plan of, okay, we're going to spend six weeks working on these findings and then we're going to meet a week before it's due and then hope it works. Or that's basically what we were going to do. I was like, well, wait a minute guys, why don't we simply set this up? One week sprints, we do the findings that are the most urgent, that have the most value and then we remediate those. And so I set up this cadence where I built in a schedule of sprints where we did the findings and then we learned every sprint something that we built into the next iteration. And by doing that, we actually ended earlier than planned. And so by building flexibility into the schedule, by building the ability to react to changes, by building an ability to direct to surprises, my team was much more effective. So these are the four leadership lessons from the Agile Manifesto that I want you guys to take away. And I think that you'll see trust running through all of them. Preserve dignity at all costs. That's people trust. Working always shifts faster than perfect. That's product trust. Customers trust colleagues, not contracts. That's customer trust. Don't fear surprises for inflexibility. That's schedule trust. And so by operating in these lessons, you're going to build several layers of trust, not only in you, but in your team. And I think that these are very powerful ways to build your influence smells. I think that when you're making decisions, you can kind of run them through this matrix. If I make this decision, will this hurt my influence with the team by not preserving their dignity? And by team, I just don't mean the people who report to you. I mean everyone who's involved in the project. Or let's say that you have this 10x engineer, we talked about that earlier, who is really, really talented, but every now and then they harass certain people on your team. They write manifestos and they publish them. Well, you know, is this person really someone, I should keep on my team, right? Am I hurting the dignity of my team by keeping this person on my team? Or what about a product feature that you know is actually going to hurt your customers? Well, should I implement that product, right? This product may make my boss happy, might make my company happy, but what about my customers? And so by having this matrix of leadership lessons, you'll be able to make better decisions as a leader. And I've really used these lessons as I've grown as a leader, and I've noticed when they've worked for others. So no matter where you are on your journey in Ruby, whether as a developer or as a leader, if you optimize your influence with your people, your build and your customers and the schedule, then that will maximize the trust that people put in you, your team and your products. And you'll soon move from a transactional leader to a transformational leader. So the next time that you face a leadership decision, or the next time you face a decision that requires leadership, when in doubt, I highly recommend that you look to the manifesto for what to do. All right, that's my time. Thank you. Letting go of making things, right? Trusting my team that they'll, they're the people now really primarily in charge of making code, shipping product. And so understanding that my contribution was optimizing the people and the environment that they worked in. So the question to make sure that you guys heard that is what was the biggest challenge going from being an individual contributor to a team lead, team manager, and that's it. That is stopping and letting go of making things, stopping having an opinion on how things should be built and totally trusting my team. And that's trust, right? Trusting them to come up with the best solution and then creating an environment where they can be successful as they build that solution. Great question. So the question is a con man or can man, I've heard people present it different ways or both ways. So can man, if you don't know, so you have the can man board that you are really flexible in doing. You have velocity and things like that. And can man, you basically measure flow and you know, cycle time and all that stuff. And so the idea is that you have a board that work flows across. And so the idea, usually if you're the team lead is to optimize flow, which is usually removing obstacles from your team. So that's kind of can man versus scrum. I in general feel that and so, and again, this is my certified scrum master hat kind of putting on is that, you know, whenever I come into a team is really important that I tailor the agile practices. And so there's can man, there's scrum, there's XP streaming programming to the reality that that's on the ground. And so a large part of what I do in the first few weeks is understanding the developers, the customers, the product, and then I tailor the appropriate agile method to what's happening. In general, this is a broad general, I guess, rule of thumb. I usually find that scrum is really good for like new development, right? We're like, we're on the enterprise going to a new planet. You know, we're building something totally new. It's usually not totally new, but you think it is. But we're building something totally new, then I think scrum is great. Can man, I think it's usually more for maintenance. If you have a product that's been in production, you're doing either break fixes or small features. In general, I like can man for that type of work. Yeah. So the question is how do you balance pragmatic versus dogmatic approaches? So I've never worked in a team that was pure scrum. Like all of the canonical definitions of scrum in terms of the iterations, and when a sprint starts, the team doesn't do anything until it ends, right? I mean, stuff happens, right? So the way that I manage it is that I'm a very practical team lead. That means that with a few rules that I never break, I'm very flexible to reality. And I think that that's actually very agile, right? Agile builds in the ability to respond to changes and expectations. That's why it's called agile. And so, you know, in general, I set up when I'm doing the scrum, the sprints and make sure that the scrum ceremonies are in place and that we do sprint planning and that we take, I was at the back log, we always involve the product owner in our sprint planning. So there's something that I do, but I realized that, you know, life is very rarely perfect. In fact, it's never perfect. And so, for example, if the product owner is new to the role that I know that, okay, my role is going to be more product owner rather than just scrum master. And so I flex my role based on that. Or if the team is more junior, then I think it probably needs to be, then I flex based on that. I say, well, let's try to lower the number of story points we're going to try to get done because of what's happening. And so, if you're going to be, especially an agile leader, then I think being flexible is very practical. And it actually leads to better results because you're about to respond to reality. One more? Okay, thank you everyone. I appreciate that.