Our twenty-fourth issue of the Architects’ Newsletter focuses on the topic of technical leadership and teamwork. We believe these topics are vitally important, and in our latest Architecture and Design InfoQ Trends report we’ve placed “architect as technical leader” in the early adopter phase. Therefore, understanding all the emerging leadership patterns, antipatterns, and techniques is essential for a modern software architect.

News

Ignite the Fire - How Managers Can Spark New Leaders

In the recording of this top-rated QCon NY talk, Nick Caldwell, Chief Product Officer at Looker (recently acquired by Google), discusses the three ingredients needed for inspiring non-manager leaders to emerge, and provides simple techniques that any team member can apply. Caldwell uses stories based on his experience to help illustrate how to inspire leadership at many levels in the organization, and e shares real-world advice for managers, individual contributors, and architects that want to inspire leadership and “ignite the fire”.

Q&A on the book Applied Empathy: The New Language of Leadership

The book Applied Empathy by Michael Ventura explores how understanding people and learning about their perspectives can help us to lead with empathy. Key takeaways are that questions are more important than answers; as leaders we should look for ways to connect with our customers and employees; and listen more and talk less.

InfoQ interviewed Ventura about the role empathy plays in leadership, empathic archetypes, tensions that can slow down change, getting insight into the inner workings of a company, building connections with customers, and developing skills with empathy.

From Chaos to Successful Distributed Agile Teams

Johanna Rothman and Mark Kilby have written a book titled "From Chaos to Successful Distributed Teams: Collaborate to Deliver". The book provides advice for anyone working in or with a distributed team on how to overcome the common (and some uncommon) challenges that distribution and distance bring to effective team collaboration. Key takeaways include: you need to adapt your approach to agile, as none of the agile brands work out-of-the-box in distributed teams; when adapting practices, go back to the Agile Principles to understand the intent behind a practice; and sufficient hours of overlap are necessary for distributed teams to be effective.

Rothman and Kilby took part in a recent Q&A with InfoQ and shared details of their core ideas about working with and leading distributed teams.

How Developers Can Learn the Language of Business Stakeholders

Anna Radzikowska, ACCA, KMP, product owner and project manager provides an overview of how engineers can learn the language of business stakeholders. She discusses core areas where she has observed the most tension when developers attempt to communicate with other stakeholders: talking about impediments and blockers, individual and team learning, real options, and risk management.

"If we look at different groups taking part in the software development process, we might easily see that they communicate on different levels in terms of language, using different dictionaries—sets of words, meanings and sentences—making it difficult to understand each other."

Case Study

The Agile Manifesto: A Software Architect's Perspective

In a recent InfoQ article, Ionut Balosin, a software architect and independent technical trainer, discusses that although most software development teams understand the "what" part described by the Agile manifesto, for a software architect, the challenge is in "how" to be agile. He also argues that some agile teams may perceive the software architect role as unnecessary, fuzzy, or even running against the principles of agile software development.

Although some agile frameworks try to create a definition for the role of a software architect, this can lead to some architects following the guidance, but not being as agile and pragmatic as they should. A good architect must continuously adapt their behaviour, not be biased toward one particular framework or methodology, stay relevant to the process, and provide the necessary guidance and vision for the team. When the right mental model is acquired, it implicitly leads toward a natural adoption of Agile Manifesto values, which are the pillars for all agile software development methodologies.

Balosin believes that the architect should not religiously trust or follow any methodology (e.g. SCRUM, SAFe, etc.), as they all have pros and cons and strengths and weaknesses, and are sometimes poorly applied in practice; "all methodologies are leaky to some extent." The agile architect is one who does not stick to any schema or dogmatic role. The agile architect must be pragmatic, flexible, and intensively involved in the software development lifecycle process. They must possess good communication but also negotiation skills, continuously search for improvements, and offer guidance and vision to the team.

He concludes his discussion by stating that the Agile Manifesto values are not binary. It is not only "working software," "individuals and interactions," "responding to change," or "customer collaboration," but rather a scale that an architect, in collaboration with other roles within the team, needs to properly adjust, whether more to the left or right, depending on stakeholders concerns, the development organization, the technical environment, and the architect’s expertise.

This is an excerpt of a full-length InfoQ article, "The Agile Manifesto: A Software Architect's Perspective."

To get notifications when InfoQ publishes content on these topics follow "Leadership" and "Team Work" on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

This edition of The Software Architects' Newsletter is brought to you by:

Architecting the Path To Customer Experience

While microservices architecture is enabling many companies to deliver a better customer experience in the digital age, it can also bring complexities and organisational challenges. From a people perspective, companies need teams that understand how to work independently and how to build and maintain contacts with each other.

Those teams also need to be able to understand how to uncover and handle dependencies that the individual services have with each other. There is a minimum level of security, control and authentication needed; the hygiene checks that must be completed in order to ensure every service is meeting the requirements of the business.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.