One of those balancing acts is to combine confidence with humility. Going into a project as an IT professional requires the confidence to propose changes, even in areas that are not my core IT expertise. But it also requires the humility to listen, learn, and involve others in decision-making. What's more, both of those qualities need to be communicated and acted on to build trust with the participants.
What I mean by humility here is not so much the personal virtue of humility (avoiding personal egotism, arrogance, or pride) as it is a set of professional skills. If a person is personally arrogant, they may be personally disliked, and that can be an obstacle. But professionals can learn to listen, seek out information, share knowledge, be responsive, and acknowledge mistakes -- those are acquired skills that can be fostered in a project setting.
I think the combination of confidence and humility is especially important for IT professionals in all kinds of positions because the IT domain overlaps so much with other business domains. This is even more the case when my role is as an architect.
For example, many projects revolve around data. The creation and utilization of business data are business functions, not IT functions. But getting data to the point where it's complete, structured, integrated, and accessible enough to be utilized involves many IT contributions. And along the way, I'll need to recommend changes in non-IT process. This overlap requires IT professionals to have the confidence to lead without knowing everything (sometimes we call that "comfortable with ambiguity"), along with the humility to learn constantly. (Moreover, the overlap may require a reassessment of how the whole IT organization is organized and integrated -- a topic for another day.)
Confidence and humility have to be communicated, and acted on, in a balanced way to build trust between participants. Trust is crucial to any project for many reasons. For example: because it enables the free flow of critical information; because it allows each participant's contributions to be respected and fully utilized; and because it facilitates agreement on goals and measures of success.
If I go into a project communicating only confidence, that isn't enough. At one extreme, suppose I go into a first meeting communicating something like:
Confidence: "No problem, we can fix that for you by implementing solution X. I'll let you know when it's done."In that style of communication, it actually doesn't matter whether X is the right solution, because I haven't built enough trust to get agreement on whether X is the right solution, or even what the measures of success would be.
If I go into a project communicating only humility, that also isn't enough. Suppose that in a first meeting I mainly conveyed:
Humility: "I don't yet know enough to suggest a solution, and until I learn more I don't want to propose ideas in areas I don't know much about."In that style, I haven't established myself as an active participant in the project. The participants expect that I'll just offer my own, pre-existing expertise if called upon. That will hold back the project in those areas of overlap between IT and non-IT expertise.
Instead, I want to convey, and act on, a combination of confidence and humility:
Confidence: "From what you've told me, I believe I can create a process in which we come to a solution as a team."
Humility: "To do that, I'll be learning a lot from all of you, sharing what I know, and constantly responding to your feedback (and acknowledging my mistakes) as we work together."Of course, this isn't just a matter of a couple of sentences in a first meeting. This combination is a set of principles to act on. Whether I earn trust will depend on how I act on these ideas and what contributions I bring to the table.
Have you observed this balance in action, in yourself or in others? What are some other balancing acts that effective leaders negotiate?
Here's some further reading on the idea of leadership and humility: