Friday, October 11, 2013

Leadership and humility

Leadership is a tricky topic. A few years ago, I attended a week-long leadership institute and was struck by the number of quite different definitions of leadership proposed during the week. One reason leadership is hard to define is that it's a balancing act. There's no single trait that makes an effective leader; an effective leader applies a balance of different traits, in different situations, and people lead from different positions.

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:

Wednesday, October 9, 2013

Make a graph k-regular

A 7-regular graph with 10 vertices: every vertex connects to 7 others.
To maintain my Python skills I picked up Allen B. Downey's Think Complexity, which is a great mix of Python exercises, algorithms, and complexity science. I especially like the way the book requires you to use the web to research math or computer science concepts to solve the exercises.

As I do the exercises I may outline some of the less obvious ones, if there isn't already a convenient reference on the web. Here's one.

The first chapter is on graphs, and exercise 2-3 asks you to take a graph with n vertices and no edges, and make it k-regular (regular to a given degree), if possible. In prior exercises, you've derived a Graph class from dict and added methods to interact with it. To make the whole thing more fun, Downey provides a library so you can easily draw graphs, as shown in the illustration above.

The "if possible" part is clear from Wikipedia: you can make a graph with n vertices k-regular if n>=k+1 and n*k is even. Also, if k is 0, no edges need to be added; a graph with n vertices and no edges is already 0-regular.

What distracted me for a while is that for most values of n, there are multiple solutions that are k-regular, as catalogued here. But eventually a thread on StackExchange gave me the hint that I should focus on a solution where the vertices are arranged in a circle and the resulting pattern of edges appears radially symmetrical (as in the illustration above).

More specifically, starting from a graph that meets the criteria above:
  • Place the vertices in a "circle". That is, a data structure that lets you start from any vertex and move in either direction to every other vertex, in a fixed order, until you return to the vertex you started from.
  • Starting with some vertex, for each vertex around the circle:
    • If k is even, add edges to the next k/2 vertices in both directions on the circle.
    • If k is odd, add edges to the next (k-1)/2 vertices in both directions around the circle, and then create an edge to the vertex that is "opposite" on the circle.
Note that in our Graph class, adding an edge between two vertices that are already connected doesn't create another edge (otherwise we'd no longer have a simple graph).

To make the "circle" in Python, I put the vertices in a list, which has indices 0 to n-1, and looped over the list of vertices. Where needed I added code to "wrap" the list. For example, if you are at vertex n-1 and are adding an edge to vertex n+1, subtract n to get to index 1 instead.

To get to the "opposite" vertex in the circle, add n/2 to the current index (which may require wrapping). This works because if k is odd, n must be even for a regular graph to be possible in the first place.

I won't post code, because that would be cheating, but this should be enough to solve it. To test it, it helps to create a method Graph.is_regular(). Then you can loop over combinations of n and k, make a regular graph for each combination, and test it, alerting you to any that failed.

Saturday, September 21, 2013

Travels in 2013

I had planned to travel for several months in 2013 to gather material for photography projects, and it has been a very rewarding experience. Since March I've stayed in 27 places in 10 countries, from India to Turkey to Scandinavia. Now I've got a mountain of photos to go through (about 17,000), but here are some first results to show for it:
Lots more work to do, but I'm very pleased with what I've processed so far!

Monday, March 11, 2013

SOA research article published

For the past few months, I've been working with Leo Fernig on a research article for the EDUCAUSE Center for Analysis and Research (ECAR). Our article is about the state of SOA in higher education -- where do universities stand, and what successes and challenges have they encountered? It's based on a survey conducted by the ITANA SOA working group in 2012.

It was a pleasure co-authoring with Leo and I'm excited to see the article published!

Tuesday, November 6, 2012

ITANA F2F Enterprise Architecture Workshop

Our all-day Enterprise Architecture workshop in Denver is done, and I thought it went very well. We had a great group of attendees and two wonderful guest speakers, Laura Patterson from the University of Michigan and Shel Waggener from Internet2. Several months of work by the planning committee definitely paid off, and it was great to have the opportunity to work with Chris, Leo, Paul, and Jim on this event!
Do I have photos from Denver? Of course I do.