Export (0) Print
Expand All
Separating DSL Semantics from Implementation
Expand Minimize
5 out of 6 rated this helpful - Rate this topic
Bb402955.skyscrapr_banner(en-us,MSDN.10).gif

Human Dynamics

 

Miriam Grace and Sandra Y. Jeffcoat

March 2007

Summary: Being an architect is all about relationships, and one relationship for which you are responsible is the one that you create between leadership and learning. (3 printed pages)

Contents

Introduction
Facilitating Collaboration: Cultural and Specialty Diversity
Conclusion

Introduction

Our design team is professionally, ethnically, and culturally diverse. The human dynamics that we experience in our team interactions are complicated, as well as positively strengthened by the diversity of our team members.

First, consider that we—an African-American woman and a Caucasian woman—already are challenged in our work to co-lead a 60-plus-person design team through a multiyear enterprise-system design implementation that ultimately will serve thousands of people around the globe. Our interpersonal dynamics around the sharing of leadership responsibilities; collaborating on design decisions; overcoming cultural barriers that are significant between our two groups, in the context of American history; and just being two women in highly visible and stressful professional positions is significant, from a human-dynamics perspective.

Next, consider that yesterday, in the space of 3 hours, we had a frustrating conversation with a data architect from Kosovo (whose English was not much better than our Albanian) regarding how "conceptual" a conceptual data model should be. With a gentleman from Chennai, India, we had an enlightening dialogue about meditation and its benefits to the mind and body. We also had a spirited discussion with a computer programmer from China who believed .NET to be the answer to all of our development problems. And we didn't even have to leave our office!

On our design team, 40 percent of the people either speak English as a second language or were born outside of the United States, and come from very different cultural backgrounds from ours. The variety of professional backgrounds on our team includes technical writers, functional analysts, project managers, business analysts, engineers, both business and IT architects, data architects, business-process analysts, programmers, management, and the list goes on.

What is going on in your workplace? When you look around at work, does everyone look like you, or does your workplace resemble ours—humming with the sounds of multiple languages, bright with ethnically distinct faces and different modes of dress, while down the hall, from the kitchen, waft the mixed odors of curry, lasagna, and chow mein?

Even if your team is not as diverse as ours, one of your biggest challenges as a system architect is leading your technical team and understanding the human dynamics that either create problems or enable solutions within the unique culture of your workplace.

The study of human dynamics involves identifying fundamental distinctions in the way in which people function, as well as understanding the distinctions in how people naturally and inherently process information, learn, communicate, relate, collaborate, problem-solve, contribute, become stressed, maintain health, and advance along their paths of development.

The big question is: How do you go about this? How do you facilitate the cohesiveness and collaboration within your team, while keeping the focus on the task at hand?

Facilitating Collaboration: Cultural and Specialty Diversity

Ten years ago, a development team would have consisted primarily of programmers and a project manager (or a lead programmer who was pinch-hitting as a system architect and project manager). Today, development teams typically are made up of a broad range of technical specialists that include business analysts and other business subject-matter experts who are co-located with the IT professionals.

What is the impact of that change? On the one hand, it infuses teams with a broad range of opinions, knowledge, and skills, which enriches solution-finding. On the other hand, language barriers, cultural and educational differences, and other dissimilarities often frustrate collaboration and lead to miscommunications and misunderstandings. Do not forget: Research shows that (typically) IT professionals are more introverted than the average employee, collectively have lower needs for inclusion, and demonstrate higher levels of independent activity and objective decision-making.

Architects Are Leaders

These realities of the modern workplace have important implications on architects as leaders. As we continue to shift toward more team-based work, we must develop strategies to address effectively the human dynamics that are operating within our work teams.

What we have found helpful is to consider the use of informal power, which comes in the form of relationship-building. We can imagine what you might be thinking: Relationships? Informal power? What on earth does either have to do with IT system development? So, let us explain how informal power and relationship development are key to solving many issues that are associated with the human dynamics of a cross-functional, multicultural team.

Imagine being in our shoes and that you have on your team the lady from Kosovo, whom we will call Sue. She is your data architect—one of the most critical positions in the software-development team.

As we said earlier, Sue's English is broken, and she is very difficult to understand; yet, communication is key to her current role, as she must communicate with you, the development team, and also (often) customers about the vital data architecture of the system that you are building.

Relationship-Building: Getting to Know Your Team

So, where does relationship-building come into play? Just think about it for a minute. You do not want to insult Sue, and you are not really sure how to help her with her communications. You certainly do not want to continue asking her to repeat every statement, because you do not understand her.

Well, let us tell you what we are doing to resolve this situation. We invite her to lunch or dinner after work, or some informal comfortable setting. The conversation is "small talk" about family, friends, likes, dislikes, and anything that will help us get to know Sue. The idea is to get to know her and for her to get to know us. We schedule a few follow-up conversations with her to continue the formation of our relationship. As we get to know her and come to understand her interests, she becomes more comfortable with us and we with her. Out of this "comfortability," eventually, come trust and respect. This allows us to do two things. First, it helps us to understand how to give Sue constructive criticism without hurting her feelings or discouraging her. Second, this assures Sue that she is "safe" and has people around her who care. The process takes time. But the time is well-spent as, over time, we get used to the cadence of Sue's dialect and find that, when she is comfortable, she slows down her speech and we can understand her better. We also discover that she is having trouble understanding us, so that we also slow down our speech.

As our trust grows, we can teach Sue to read her audience, so that she will know when she is losing them. We teach her to present her information in the form of pictures and simple examples, to help with the understanding of concepts that she is presenting. Because Sue has a good relationship with us, she understands that we are trying to help her and will be more likely to be open to receiving our help. We get to a workable solution faster.

This example of relationship-building might seem a little overboard, but the intent is to present the message that relationship-building is essential to system development for an architect. This is especially true when you have no real power over your team or the situation. Even when you do have power over a situation or group, you are more likely to get more done through relationship-building. People, including technical people, want to feel needed and that their contributions are just as important as yours and those of other members of the team. By building relationships with individuals on your team, you as an architect can level the playing field and begin to reduce the negative impacts that might be caused by the human dynamics of your team.

Conclusion

Now that we have given you a key to working with the human dynamics of any team, we invite you to coffee with some architects. These architects will share some of their stories and experiences that hopefully will give you more insight on the human dynamics of today's technical teams.

 

About the authors

Miriam Grace is an Enterprise Systems Architect and a member of the Boeing Technical Excellence Fellowship. She has over 20 years' experience as a computing systems architect, with a specialty in business-process management systems. Miriam is a published author, holds a Master's degree in Systems Design, and is a Ph.D. Candidate in Leadership. She designed a learning system that has provided a curriculum of foundational skills for software architects at Boeing.

Sandra Y. Jeffcoat is a member of Boeing's Technical Excellence Program, a 2005 National Women of Color in Technology and 2007 National Society of Black Engineers (NSBE) Golden Torch awards winner, and a Ph.D. candidate for the Antioch University Leadership and Change Program. Sandra has more than 28 years of technical experience with such companies as the Boeing Company, Eastman Kodak, NCR, Mead Paper Corporation, AT&T, and various government agencies.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.