The Agile Architect: Turning Followers into Leaders

"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

An Architect garners a high level of authority by being an expert. People will follow their lead. But what if the Architect is wrong? They will follow right off a cliff.

How do we get people to think like the Architect? Use the principles of Intent-Based Leadership to decouple the success of your project from the personality of the architect. By creating clarity around architectural goals and by engaging people in problem solving rather than defining rules and standards we can divest control and create an organization of leaders.

 
2 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This talk explores how leadership skills in an architect are essential. The traditional model of command-and-control design authority leads to an organization that is heavily dependent on the architect. The leadership model taught in David Marquet's book shows how we can enable agility by moving authority to those doing the work. This creates tighter feedback loops that detect problems faster and detect flaws in assumptions.

In Marquet's model, the two pillars of giving control are to develop Technical Competency and Organizational Clarity. I will touch on both in this talk, however this is not a technical talk and the focus will primarily be on the latter.

This talk is based on an experience report I gave at Agile 2015. The backbone of the talk is the story of how we tried and failed and various models for the Architect role. Each model is used as a lesson to teach something about leadership and how it relates to the Architect role.

Details of the talk:

Brief story – The danger of trusting the expert – I had a trip to the doctor for some allergy tests right after donating blood. The doctor knew I had just given blood. I get woozy with needles and the allergy test involved many pin pricks. I became woozy and had to lay down. The doctor came in to take my blood pressure. She put her stethoscope right on top of where I had recently donated blood. I remember thinking “That really hurts. Its ok. She probably has a good reason for doing that”. In hindsight, it is clear that she just didn’t know that is the spot I had just had my blood drawn, so why was I so ready to offer up total control to the expert?
"The higher you go in an organization, the more your suggestions become interpreted as orders." - Marshall Goldsmith

Intro:
Is an Architect at odds with Agile values? The manifesto talks about self-organizing teams producing better architectures and designs. I believed that the best thing we needed to do as leaders was to get out of the way and our teams be successful.

Model 1: Lassaize faire

  • We want to empower teams to self-organize - Hands off, let the team decide
  • This model was successful on small projects that a single team could consume and the skills were already present.
  • Greenfield project – Required skills and experience that were not present and required coordination of multiple teams. We struggled to get started. Multiple false starts. Project was at risk and this was demotivating.
  • Realized that empowering people is more than just taking your hands off the wheel

Model 2: Architecture Scout

  • Architect was nominated to research and find an initial approach
  • Goal was to avoid becoming dictator. Just scout ahead and report back. The teams own the designs!!
  • Project got moving, but we had problems: -> Architect becomes bottleneck – Have to be everywhere at once to find mistakes, can’t take a vacation -> Dysfunction between teams - -> Problems go undetected

Inflection Point – Our approach was flawed, and some people knew before the Architect, so why didn’t they bring it up sooner.
“You’re the architect, I thought you knew something I didn’t.”

I’m a technical guy. I was giving technical solutions to what I perceived were technical problems. This is a people problem!

Leadership model up until now:

  • 1 dimensional – Take your hands off the wheel or tell people exactly what to do.

I knew things were better with my help, but I needed an approach that didn’t involve me just providing solutions to people.

Introduce Marquet –Without the technical competence or organization clarity, people will struggle. This opened a new dimension to how I viewed leadership. Not just how much autonomy people have, but also how much they understand and are aligned with the architecture goals. So how do we get people to think like the architect!

Model 3: Architect as Coach – Marquet

  • Leaders are rewarded for how well their team performs while they are there, rather than when they walk away.
  • Why don’t we trust people? What is missing?
  • Rather than moving the information to those with authority – move the authority to those with the information. But first we need to put two pillars in place: o Technical Competence – Do they know how to do the job? Do they have the skills to make decisions? If we want maintainable designs, do they know how to create them? o Organizational Clarity – What assumptions are built into the architecture? What are the motivatiosn behind the architecture approach? When I have to make a tradeoff, should I be sacrificing performance or maintainability?

Methods for Organizational Clarity:

  • Resist the Urge to Give Solutions – partner with people to arrive at solutions
  • Open ended questions –> What solutions have you already considered? -> Which one would you chose and why?
  • I Intend To…. -> When you use this approach for awhile, you notice that people don't bring you problems anymore, they know what you're going to ask already. "I have a problem. Here are some options I've considered. The pros and cons of each are.... I intend to implement this one because .....". After awhile I could respond with "Very well"
  • Create a framework for resolving conflict – Architect is often expected to resolve conflicts between teams by enforcing rules and standards. Pull people out of positional arguments and get them to solve the problem. Ask them to give situations where their solution may not be the best. -> Physically separate people from their ideas by writing them on the board. As a team, objectively dissect the pros and cons of each solution. Every engineering decisions is made by considering tradeoffs, we just have to reveal them. Tradeoffs help reveal assumptions and disagreement on tradeoffs can help reveal misalignment.
  • Disagreement is a mechanism for organizational clarity – The moments where people disagree the most are the best opportunities to delve deeper into the WHY. -> Story: Disagreement on implementation. One team was implementing logic in the database while everyone else was doing it in the domain layer. Architect to the rescue! My impulse: Tell them to get in line with the architecture! Looking at this through my new lense of leadership I realized that they were missing one of the two pillars: Organization Clarity. We used this as an opportunity to delve deeper into the reasons behind the architecture. Over the next couple of weeks, we met regularly between teams to explore the reasons and assumptions that went into the architecture. We weighed the pros and cons of different approaches. We realized that on this team there were two people with a very strong database background. They felt strongly that data integrity should be valued above all else. When weighed against the other tradeoffs, we realized this wasn't the most important thing to consider. Ultimately the architecture approach was upheld, but what we achieved was a deeper understanding of the architecture by multiple people.

Model 4: Architecting As A Team

  • Many people understand the assumptions and WHY behind the architecture
  • We have the skills to produce clean code
  • We are skilled at resolving conflict and navigating the complex tradeoffs of engineering decisions
  • We have the freedom to make design decisions
  • Are highly motivated and engaged – They feel ownership for their work.

Final note: Architect is a leadership role. We need to mindfully develop the leadership skills of our architects and the next generation of technical leaders. We tend to promote people primarily on their technical abilities. An Architect with both the technical & leadership skills has the potential to help transform an organization into a truly self-organizing team. One that can deliver better designs and architectures.

Learning Outcome

  • Drawbacks of leading with authority
  • Benefits and approaches to Intent-Based Leadership
  • Practical techniques of how to turn followers into leaders
  • How to help people think like the Architect

Target Audience

Developers, Architects, Managers

schedule Submitted 9 months ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Fincy Yousuff
    By Fincy Yousuff  ~  9 months ago
    reply Reply

    Hello Chris! 

     

    How are you doing! Happy to see that you have send in a proposal for AI 2017 :)

    Are you planning on having or do you think it would be good to have hands on activities as part of this talk? I have a feeling that 45 minutes talk would be difficult to convey. What are your thoughts?

    Looking forward to meeting you in March! Have a great day!

    Regards,

    Fincy

    • Chris Edwards
      By Chris Edwards  ~  9 months ago
      reply Reply

      Hi Fincy,

      I've given this talk a few times and 45 minutes seems to be a good length. I gave the talk at Agile 2016 and it was a 75 minute sessions which seemed to be a stretch. I did throw in a 10 minute exercise there which helped break it up a bit. I can consider doing it for this one as well, although the material fits well into 45 minutes on its own.

      The talk as been fairly well received when I have done it in the past. I did present it at Agile India last year, but it got a full room so I thought it might be good to give it again this year.

      Hope you're doing well!

      Chris


  • Liked Woody Zuill
    keyboard_arrow_down

    Woody Zuill - Mob Programming: A Whole Team Approach

    45 mins
    Talk
    Intermediate

    Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

    Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there has been a great deal of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

  • Liked Fennande van der Meulen
    keyboard_arrow_down

    Fennande van der Meulen - The Power of Purpose - workshop on How purpose drives employee happiness and company results

    90 mins
    Workshop
    Beginner

    Having a clear purpose in both life and work is essential to happiness. And, science and business support this view. Companies with a clear purpose perform better than companies without. Purpose is increasingly seen as the key to navigate the volatile and complex world we live in. And, people with a purpose in their live longer and are healthier. However, finding your purpose, your personal and companies purpose, is not an easy task. In this workshop we discuss what purpose means and key elements of a sustainable and meaningful purpose. We elaborate the four steps to identify the company purpose and how to build your business around it.

  • Liked Chris Edwards
    keyboard_arrow_down

    Chris Edwards - Agile Introverts, an Oxymoron?

    Chris Edwards
    Chris Edwards
    Senior Manager
    IHS Markit
    schedule 9 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Collaboration, collaboration, collaboration. This is probably the most used word you'll hear from agilists. It sits right at the core of agile principles. How do we reconcile this with the fact that 30% of the population is introverted?

    There has been extensive research around introversion that can help us understand this apparent contradiction better. This talk will explore the complexities of introversion, from the distinction between shyness and introversion to the complexities of pseudo-extroverts and "high active" babies. 

    Finally, what can we learn from companies like Menlo Innovations and Hunter Industries, where they have high collaborative environments with introverts that say they would not work any other way.

  • Liked Sean Dunn
    keyboard_arrow_down

    Sean Dunn - Scaling Your Continuous Deployment Using Docker and Containers

    90 mins
    Demonstration
    Beginner

    How can new tools and technologies shorten our feedback cycles, and reduce pain and frustration of deployment and maintenance of systems? How do you scale your continuous deployment system to support more developers? This hands-on technical session demonstrates how new containerization technologies like Docker and Concourse CI can be used to build deployment pipelines. Sean and Chris will show how to build a deployment pipeline, configuration-manage it, and deploy software through it. 

    No previous technical knowledge of Docker or Containers is needed. 

    This will be a 2 part. The first 45 minutes will go into the basics of docker. The second 45 minutes will show how to setup a Concourse.CI continuous delivery pipeline.

  • Liked Nayan Hajratwala
    keyboard_arrow_down

    Nayan Hajratwala - Refactoring Legacy Code Guided by Simple Design

    45 mins
    Demonstration
    Intermediate

    Are you frustrated by the many trivial examples that show up when you google "refactor legacy code"? How do you translate these examples to your real-world code base? Sometimes it's just easier to give up on the refactoring and increased test coverage, reserving these techniques for the ever elusive greenfield project. To help you with this dilemma, Nayan will walk through a real legacy Java code base, and perform some safe refactorings required to bring the code under test. All of this will be done under the guidance of the Four Rules of Simple Design (Pass the tests, DRY, Reveal intent, Minimize moving parts).

  • Fabiola Eyholzer
    Fabiola Eyholzer
    CEO
    Just Leading Solutions
    schedule 9 months ago
    Sold Out!
    45 mins
    Keynote
    Advanced

    There is growing interest in learning more about Agile HR and its impact on individuals, teams and organizations.

    It is important to separate fact from fiction: What are the real threats and opportunities of bringing Lean | Agile values, principles, and practices to HR? What can we expect in the future? Through anecdotal evidence and case studies, the session will explore the potential of Agile HR as well as provide guidance on how to approach the transformation.

     Issues covered in the presentation include: information on how to embrace the new talent contract, create inspiring, engaging, and fun places of work, shift to an iterative performance flow, take the issue of money off the table, support growth within an Agile enterprise.

  • Liked Ravdeep sekhon
    keyboard_arrow_down

    Ravdeep sekhon - Team Kaikaku (Revolutionary Change)

    45 mins
    Talk
    Beginner

    We had a small Dev & QA team, trying to adopt more Agile Principles, and aware of the growth we were going to face soon. Current setup & structure of the team required transformations so that we could scale, help improve low morale and disconnect within the team. Tried few changes but ‘flat’ with no managers didn’t work at all for us. Our talk will be about what we ended up doing that enabled us to get to a high energy agile team!

    Kaikaku refers to big revolutionary change whereas Kaizen refers to evolutionary change. The changes we did with our team with respect to the structure of the team and the development process, were big in magnitude and the requirement to change was big too. With this major shift, we could scale the team and take on big projects associated with new clients, could deliver quality product every release and changed many of our clients’ perspective to a positive one and could attract lot of good talent.

  • Liked Ravdeep sekhon
    keyboard_arrow_down

    Ravdeep sekhon - Kaizen in Hiring

    45 mins
    Talk
    Beginner

    Everything a dev team does can borrow from Agile Principles, including hiring great developers. We as a company are customers of our own hiring process, our requirements have changed significantly from once hiring 6 people in 2 years to hiring over 20 this year alone, and we have to experiment and adapt over time in order to hire the best people for the job. This talk is about how at Solium we realized the core Agile Principles can be applied to hiring and iterated the process during the last 18 months. During the course we got rid of some sacred recruiting beliefs (hint: "culture fit" means nothing!)

  • Liked Rajith Raveendranath
    keyboard_arrow_down

    Rajith Raveendranath - From Monolith to Micro Service - A Kick Start

    Rajith Raveendranath
    Rajith Raveendranath
    Director Quality
    SunTec
    schedule 9 months ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    [Update based on the panel review]

    Inspired by Martin Fowler's introduction to micro services (https://www.youtube.com/watch?v=wgdBVIX9ifA);

    The demo will introduce the "ABC"s of the transition to micro services. We will refer to the Hadoop Distributed File System open source and demonstrate to (re)design the NameNode module as a micro service. This will introduce the three primary challenges and their possible solutions as in;

    1. Componentize using Services instead of the conventional componentization using the design

    2. Data segregation using an event driven framework to separate the centralized data across services

    3. Accessing a micro service as a web service instead of an orchestrated access; the delegate & facade patterns will be demoed to loosely couple the interfaces

     

    The demo will conclude with a listing of the next steps in transition, which need to be considered after the primary challenges are addressed.

  • Liked Howard Deiner
    keyboard_arrow_down

    Howard Deiner - Legacy Code Retreat - Uncovering Better Ways of Dealing With Legacy Software By Doing it and Helping Others Do It!

    480 mins
    Workshop
    Intermediate

    In his book “Understanding the Four Rules of Simple Design”, Corey Haines lays out the basics for getting people together for a day and practice coding better. Unhappily, many of us have to deal with legacy code in our daily lives, and find ourselves frustrated when we try to make legacy code better. J. B. Rainsberger has started a variation on on Corey Haines’ code retreats, making them more practical for legacy code practitioners. I’d like to extend that pattern and have retreat for those of us who work legacy code in Java often.

    We will learn and practice the classic Michael Feathers dance of

    1. Identify change points
    2. Find an inflection point
    3. Cover the inflection point (break external dependencies, break internal dependencies, write tests)
    4. Make changes
    5. Refactor the covered code.

    By the end of the day, in addition to being tired and completely ready to put away our laptops forever, we will have gained valuable insights and practical experience with a topic no one likes to talk about - getting better working with legacy code!