00:00:14
Good afternoon. I'm going to talk about manifestos in tech, which is, of course, not controversial. This is the Agile Manifesto. By the way, 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.
00:00:42
Alright, 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? Alright, similar number of hands. I think we're all in the same place, so that's good.
00:01:06
So, I want to talk today about my journey as a technical leader. A lot of my journey has been around the idea of trust, but it took me a while to understand that.
00:01:18
My journey really goes back to when I was young. I remember being a big science fiction and fantasy nerd and playing Dungeons & Dragons. I really loved the exploration aspect of these stories. When I went to college, I discovered that someone named Joseph Campbell actually put together a structure called the 'Hero's Journey', which was an academic study of the journey that almost every hero in fantasy and many science fiction stories undergo.
00:01:51
The book is titled 'The Hero with a Thousand Faces' and is often subtitled 'The Hero's Journey'. The introduction describes how a hero emerges from the common world into a fantastical realm, encounters wondrous things, undergoes change, and then returns to the real world with some knowledge or perhaps a magical item that improves the world.
00:02:26
This magical item is often called a 'boon' in Campbell's framework. I really liked how Campbell used this cycle to show the common threads in every story. Being someone who enjoys fantasy and science fiction, I was always drawn to heroes, and I was amazed that someone had rigorously analyzed the concept.
00:02:50
I did not know it at the time, but Campbell's Hero's Journey would become a key part of my leadership style.
00:03:04
Not every story follows Campbell's cycle exactly; some omit phases, and some may change them. However, there are four major parts: first, the call to adventure; second, going through some trials; third, the transformation; and finally, the hero returns home.
00:03:32
I'm not going to go through every step of the journey today, but you have parts like the call, the refusal, and the meeting of a mentor. I'm going to discuss the mentor relationship later. I really like the idea of this journey and how heroes must traverse this road to find their destiny.
00:04:01
My life in technology has two worlds: the personal world and the programmatic world. You have an analog world and a digital world. As I began to learn about programming, I faced trials myself. I took a class called Data Structures, which was a challenge, but I made it through and persisted.
00:04:33
Through my journey in programming, I began to realize that I had a boon; I had something valuable to offer to the real world. As software developers, we must think in a structured manner, logically, which is powerful in a world where illogical things often occur.
00:04:57
Now, how does the mentor relationship work? How does one choose a mentor? It was the mentor aspect that drew me to the world of heroes. A mentor is someone who has completed the Hero's Journey and helps someone start their journey.
00:05:21
I began to see the links between the hero and the guide in this context. A tech lead, after all, is guiding a team through a journey they've already traveled when they were an individual contributor.
00:05:53
However, I didn't fully understand what would cause a new hero to follow an experienced one. I began to see that trust was a very key ingredient.
00:06:15
One of the most popular myths of our time is Star Wars, which illustrates how the mentor-hero cycle works. George Lucas himself has mentioned that Campbell's work was a big inspiration for Star Wars.
00:06:36
In the saga, Obi-Wan Kenobi mentored Anakin, who in turn mentored Luke, who later mentored Rey. Each mentor earns the trust of the next person in the cycle.
00:06:55
I don't own any of these images, by the way. Just had to put in that disclaimer, but I think we all know the story. The problem is that a big part of this process seems to involve passing a lightsaber.
00:07:11
I don't possess many lightsabers, so I began to think about other academic studies. I wanted to find someone like Campbell who had put rigor around leadership and leading teams.
00:07:35
When I first became a technical lead, no one gave me a manual on leadership. If you find such a book, please let me know. However, I discovered a book by John C. Maxwell called 'The 21 Irrefutable Laws of Leadership'.
00:07:59
I really love this quote from the book: 'The true measure of leadership is influence, nothing more, nothing less.'
00:08:06
I saw that influence is incredibly powerful and it resonated with me. Maxwell distinguished between those who lead by their titles and those who lead by their influence.
00:08:25
I can tell you that people who lead with influence are significantly more effective and accomplish far more than someone who merely commands because of their title.
00:08:46
'Just because you have a title does not make you a leader; all a title does is buy you time while you build your influence.' I realized that influence is a key part of leadership.
00:09:06
Furthermore, a key part of influence is trust. You cannot influence people who do not trust you.
00:09:29
Then I found another book by J. McGregor Burns called 'Leadership'. One quote I like from the book distinguishes between two types of leaders: transactional and transformational.
00:09:50
A transactional leader says, 'If you do what I say, I'll give you rewards. If you don't, I'll inflict penalties.' Personally, I do not enjoy working for transactional leaders. While they can get things done, I don't think it leads to well-executed or lasting results.
00:10:06
I prefer to be a transformational leader—someone who uses charisma and enthusiasm to influence followers. Influencing others is crucial in leadership.
00:10:30
I've been wrapping my leadership style around influence ever since. I began to think about how I could assess the effectiveness of my influence.
00:10:56
How many of you have heard the term 'code smells'? Code smells are indicators of something that doesn't seem quite right in your code.
00:11:09
So I realized, could there be something like 'influence smells'? Are there trust smells? How can I intuitively sense when something might not be broken right now but is likely to break in the future?
00:11:29
I started my career in the '90s, long before Agile became widely recognized. In those early days, I experienced big waterfall methodologies that saw extensive upfront planning—projects would take two years, and you hoped that nothing changed during that time.
00:12:01
However, as we all know, things always change, which is why waterfall projects often fail. I began to learn about Agile about ten years ago, and my initial perspective was that it was mostly standing up during meetings.
00:12:20
But I soon realized that there was far more to it. I became a certified Scrum Master and began studying the Agile Manifesto. This group of individuals gathered at a ski lodge not too far from here, where they were on vacation but also trying to figure out how to improve software development.
00:12:56
They came from different programming backgrounds, including extreme programming and Scrum. Together, they penned a manifesto outlining better ways to approach software development.
00:13:10
Most people have heard of this manifesto, but I want to go through its main points. It emphasizes that we are uncovering better ways of developing software.
00:13:22
It's important to note that the term 'uncovering' suggests that this is a continuous process, not a rigid set of rules to follow. This process of uncovering allows all of us to engage in developing software.
00:13:44
Through this manifesto, several values were established, and I will touch on a few key ones, each of which carries important lessons. The first value states: 'Individuals and interactions over processes and tools.'
00:14:06
'This doesn’t mean you don't use tools, but it emphasizes that you cannot rely solely on them since you build software with people, not just tools.'
00:14:29
When you have people involved in software development, it is vital to ensure their interactions are optimized. And not just any people, but motivated and interactive ones.
00:14:48
There are many methods to optimize a software development team's interactions. For instance, I’ve seen the open space concept, where team members sit closely to encourage communication.
00:15:10
However, some common practices, such as adding pool or ping pong tables, have shown to be counterproductive. Instead, one effective way to motivate my team is by preserving dignity at all costs.
00:15:29
This principle implies maintaining the humanity of everyone on my team in every interaction. Even those I don't particularly like or agree with deserve dignity.
00:15:45
It's easy to be respectful to allies, but as a transformational leader aiming to foster trust, it is essential to dignify everyone on your team.
00:16:12
An example of this occurred a few companies ago when I joined a team that used Skype. I suggested transitioning to Slack, which facilitated communication. As a result, more employees joined the Slack channel.
00:16:34
However, one day a co-worker approached me about a joke made in the general channel about bacon. She explained that it was insensitive to someone from a Muslim background. I initially dismissed her concerns, but later realized that creating a community in the Slack group meant ensuring everyone felt welcome.
00:17:07
I apologized, thanked her for her insight, and pinned a note in the channel encouraging respect for others' beliefs and perspectives. Though there may have been a minor dip in activity, prioritizing dignity was worthwhile.
00:17:35
The next Agile value is 'Working software over comprehensive documentation.' Some mistakenly think Agile means no documentation; that's not accurate.
00:17:55
We document sprints and create backlogs and user stories. The key is to minimize documentation to what's necessary. My general rule is to note what someone new joining the team would need to know.
00:18:20
Ultimately, it's about prioritizing working software and delivering products to customers. We've all seen that the only way to know how a customer uses the software is to ship it and gather feedback.
00:18:44
The next lesson is 'Working software always ships faster than perfect.' You can spend an inordinate amount of time refining features, but perfect software doesn't ship.
00:19:06
If you get a working version out there, you earn influence with your customers because they know they will receive functional software and feedback is welcomed.
00:19:31
A few years ago, I was part of a global company with a support team in the US and customers in East Asia. Communication was a challenge due to time zone differences.
00:19:54
Rather than get caught in long discussions trying to figure out the perfect solution, I suggested we simply try a straightforward approach. We provided a support number to a resource in India to field any incoming calls.
00:20:18
By the end of the month, we had a minimal number of calls, and we realized that sometimes less is more. Working software isn't just applicable to code; it pertains to any aspect of building success.
00:20:43
The next Agile value is 'Customer collaboration over contract negotiation.' This doesn't imply we ignore contracts, which I deal with daily, but it suggests we do not base our customer relations on contracts.
00:21:09
A strong relationship with customers relies on trust and collaboration. Contracts are merely a mediative tool, not the basis of a relationship.
00:21:36
For example, while working with an external company to build an interface between our products, we initially operated separately, but this led to miscommunication.
00:22:03
Instead of continuing this dichotomy, I proposed we create one cohesive team spanning both companies. We aligned our sprints, collaborated daily, and ended up integrating much sooner than expected.
00:22:31
The final Agile value is 'Responding to change over following a plan.' This doesn't suggest abandoning all plans; in fact, planning is fundamental in Agile through sprint planning.
00:22:53
Plans, however, are challenging to accurately predict. Therefore, we break our time into manageable iterations, allowing us to adapt and respond based on new information.
00:23:16
An example from my experience concerns accessibility requirements, which mandated specific findings from an audit. Initially, our plan was to work six weeks then meet right before a deadline.
00:23:42
I suggested one-week sprints; focusing on addressing the most urgent findings quickly. This flexibility in planning led us to finish earlier than anticipated.
00:24:00
Flexibility in your planning allows you to manage surprises. Those surprises are inevitable—people will leave, bugs will arise, and plans must adjust.
00:24:30
So, I encourage you to embrace surprises and build adaptability into your planning process. Today, I've shared leadership lessons drawn from the Agile Manifesto.
00:25:03
Each lesson centers around the theme of trust: preserving dignity at all costs fosters trust, working software prioritizes trust in products, customers trust colleagues, not merely contracts, and fear change whilst allowing flexibility builds schedule trust.
00:25:36
Integrating these lessons into your leadership approach will cultivate various forms of trust. You can assess your decisions through the lens of trust—will a decision preserve your team’s dignity?
00:26:06
As you navigate leadership decisions, examine if your actions enhance trust among your team and your customers. These lessons have shaped my growth as a leader, and I’ve seen their effectiveness in others.
00:26:32
No matter where you are in your journey in Ruby—as a developer or a leader—optimizing your flows with people, product, and schedule will enhance the trust others place in you.
00:27:00
The next time you face a decision requiring leadership, look to the manifesto for guidance. That's my time; thank you.
00:27:19
Finally, I reflect upon letting go of my need to make everything right, and instead trust my team. I understand that their primary role is to ship product.
00:27:56
To that end, I learned that my contribution involves optimizing the environment they work in. People often ask about the biggest challenge transitioning from individual contributor to team lead.
00:28:26
The challenge lies in letting go of my personal opinions on how things should be built and trusting my team to find the best solutions.
00:29:02
The question often arises regarding Kanban versus Scrum practices. In Agile, we measure flow and cycle time, and we strive to optimize it by removing obstacles.
00:29:39
As a certified Scrum Master, I prioritize tailoring Agile practices to meet the specific realities of each team and project. The techniques I implement must fit the cultural circumstances at hand.
00:30:04
In general, I find Scrum operates exceptionally well for new development, while Kanban suits established production processes dealing with incremental changes.
00:30:32
Adapting to the needs of a team ensures our approaches reflect the current project landscape. Thank you all, I appreciate your time.
