Posted: 8 March, 2020
Link to source
I’ve been meaning to write something about this topic for two reasons: as a CTO in higher education, we see a well-established trend towards addressing inclusivity across the University, and as I talk with groups of architects in business, they’ve said this is an important cultural aspect their organizations are trying to tackle. So, what is inclusion? Informally, it is the feeling that all people in a team are appreciated, their backgrounds and experiences are respected positively, and that they have an environment where each team member can contribute. Why is this so important to architecture? I would suggest two reasons here: first, architects are seen as leaders and we have a responsibility to create a positive, inclusive culture. Second, architects are members of teams and specifically teams where we see roles changing – new ones being created like product manager, or DevOps engineer –, and different experiences and skills being required to achieve higher performance such as change management. This is the democratization of the team – no longer is the architect’s experience more important in direction setting, multiple roles now build consensus on the path forward. We’ve probably all seen cases where a team wasn’t able to achieve because one person, often an architect, monopolized the conversation, or team members were quieted and unable to bring their best questions, or decisions were made to through the lens of “safe-for-our-work-group” even when a customer’s needs might have led elsewhere. Inclusion fundamentally means the team is both built for and executes with better decision making – it’s easy to see why we would choose to be in a place that values us as such empowered individuals.
Architecture has some historical effects that mean this is an issue we need to tackle head-on. From a diversity perspective, we are simply not bringing forward traditionally underrepresented voices. As an example, the number of women architects has been growing slowly over the last decade but is below numbers of women in technology in general. The root causes of this go back decades into how many computer science graduates we had starting in IT 20 years ago (as a requirement for hiring) and that architecture as a profession is highly-experience based (how many years of experience and how many projects does an architect have to show on her/his resume to be highly respected?). There are in fact many inequalities in hiring; wage gaps, tokenism (or the idea that a team member does not have even one person who they can talk with in a safe space and feeling like they have to represent all of a particular class), minimizing differences – or feeling like you have to fit in – and even differing expectations, having to work harder to be seen as capable. Obviously, some of these are factors we cannot go back in time and change, but what can we do today to create our inclusive practice?
From a leadership perspective, it is about hiring and creating the environment – coaching for inclusion and inclusive behaviors within the team, -- and finding what gaps the team may have. Starting with hiring, we have learned that bringing in underrepresented voices simply by demographic profile may improve the perception (or metrics) of diversity but is about equally likely as not to improve the team’s actual diversity and inclusion from an innovation, experiences and decision-making perspective. Teams simply hire similar individuals to themselves unless they add techniques to intentionally broaden the search.
I’m going to summarize a technique I first used this year, which may help point the way to improving our hiring practices. Focus on what the team gains from a new person’s experiences - as you look at your team, identify the current mix of skills and characteristics on the team, then flip the model and see where the gaps are. I took one of my teams through this and looked at their customer service skills, managerial style, operational capability, strategic thinking, longevity with the organization, as well as demographic information. When I added up what I had in each category (most were on a 1-5 scale of maturity), I “flipped” the model and subtracted the value from 5 to see where my gaps were. An area for example where I had only people on the current team with internal experience for the last 7 years gave me a high score for internal decision making ability – and then I knew I had a gap in thinkers who had outside experiences on the team. This meant that the person I really wanted to hire should fill in some of those gaps – this would be the “gains” for the team by adding the individual. After we went through the hiring loop, we noticed two things: first that the pool of candidates was more diverse than we’d ever had, and secondly, the two finalists we invited back to final selection really filled a good deal of these gaps we had identified. Though the gaps were not specifically to hire from underrepresented groups, the experiences we wanted to add were found in the diverse group of candidates: both finalists were from outside the US and from demographic groups we did not have on the current team. So this strategy gave us two things – an increase in underrepresented demographics on the team and an employee who brought “out of the box” thinking to keep challenging the team with experiences which may have been in their blind spot.
As we talk next about the team culture, architects also have some ways of working which we need to own: have you ever run into the “biggest-brain-in-the-room?” Though it’s not in the DSM IV yet, we see very off-putting behavior by technologists to impress both customers and teammates about how excellent their personal credentials and technology choices are. I personally saw this at one meeting with an auto manufacturer’s executive staff where a consultant literally told them they were stupid and needed only to agree with his technical drawing and buy $100MM more of his product, or the whole project would go down in flames! David Slight (IASA Global) observed this to me as the transition from “biggest brain in the room” thinking, down to only spending 20% of our time as architects being clever, and 80% being a good teammate. Our discussion was on the subject of how to get teams to understand the human elements of Scaled Agile, a very current team methodology which many of us architects are familiar with and also see the human dynamics challenges. David followed up with some really points about what it means to be an architect in SAFe: we have the whole team participating in the deliverables we’ve seen previously from only the architect, and vice-versa, the modern architect does development spikes or change management, formerly reserved tasks for the developers or PMs and now part of this team working model where everyone contributes as needed. The architect’s own work becomes transparently a part of what the whole team comes up with – not a mine or yours, but something we both contributed to. Maybe we are now talking about a new way of work – evolutionary architecture, or co-work as opposed to creating deliverables and then presenting & reviewing (throwing it “over the fence” to the team). Within the team culture, it’s all about how we have the dialog (some might call this coaching but it’s important that each individual in the group sees this as a shared value). As you talk with your team, remember to emphasize the positive reasons why we want to have conversations and ultimately behavior which is inclusive: it makes us a better team, whether that’s in customer metrics or how we collaborate internally or the innovation and ideas that we bring to the work. All of us have biases – some known and some we may not realize ourselves. The important part is to have a regular discussion about how we bring these diverse perspectives together, create a sense of open communication, and look at examples where the team can do better. Maybe it’s also providing mentors for growing particular skills, maybe it’s structuring meetings in a new way so that everyone’s voice can be heard (link), maybe it’s thinking about how we can disagree with each other without being personal. The change to the architect is a whole team thing. It’s about how the architect fits into the team organically – how we work as a member of the team, not from the edges or an ivory tower outside.
For example, when we talk about personal soft skills, some of the most important ones to practice and mature with include communication (written, oral, online, small group, large group), framing of discussions and decisions, face-to-face meeting skills like facilitation and the right kind of persuasion, active listening, and networking. (And I do hate that term, soft skills, simply because it makes them seem less important than technical “chops” when my own experience supervising large teams actually shows that they are often more important to building solid customer relations and long term team performance, creating that culture where people want to work).
We’ve always considered other analogous professions for architects – what does a construction super or a doctor do differently? The doctor specifically is an interesting case, devoting much of their studies to bedside manner and checking their practice to make sure that the right outcomes are occurring regularly. I have worked with clinical doctors and was in a technology meeting with one of our doctors when I was surprised at how attentive, engaged, and open this one doctor was talking with – of all things – an IT automation tool supplier. I asked her afterwards, “How did you stay so focused?” She told me that it was their training: to see a patient, without knowing what kind of day the patient has had, how worried they might be, and having to get to a diagnosis quickly (even if it’s one the patient doesn’t want to talk about), the doctor has to leave all their own personal baggage outside the exam room so they can elicit the most important details, what the patient has to say. Though this may be a type of active listening you and I do not have to practice every day, it is a skill which can be learned and can fundamentally change the way another person participates in a discussion.
Hopefully some of these examples – gaps & gains in hiring, personal dynamics skills like avoiding the biggest brain syndrome, and having better meetings where we check for any questions – get you thinking of what diversity means in the context of the architecture profession. As an occasional writer of material within the IT Architecture Body of Knowledge, I’m changing my discussion from inclusion as an add-on module to a topic that really has a place in every aspect of our work. I would encourage you to look at your practice and find something that you can undertake to be more inclusive – you’ll be rewarded every day after making the change!
I would be remiss if I didn’t note that we have learned a lot about both diversity and inclusion over the last few years. We’ve found out that inclusion stretches from hiring practices into how the team operates technically and even to what sorts of soft skills we need to nurture in ourselves. Both diversity and inclusion are certainly not about checking a box, anymore. Baking this in to how we work every day ends up being more effective, because we’re personally committed.