Monday, March 20, 2017

On open government

An item at Opensource.com discusses the topic of "Open Government." This is timely for me, because where I work (local government) we have been building a new Open and Accessible Data Portal. Open data and open government is the new norm. Government is "of the people, by the people, for the people" (Lincoln, Gettysburg Address, 1863) and open data makes information about your government available to you, the taxpayer.

The Opensource.com article describes open government as "one with high levels of transparency and mechanisms for public scrutiny and oversight in place, with an emphasis on government accountability." Another way to describe open government is providing information in an open and accessible way, without filters.

The key goal for open government is transparency. Anyone should be able to view information about the government.

Open data laws require that public and government organizations provide information upon request, such as a US Freedom of Information Act (FOIA) request. There are a few exceptions, such as information related to security, but generally any information is accessible by making a FOIA request.

Open government takes this a step further. Why wait for the request before we make it available? Let's share the information proactively. If we can provide the raw data, governments should provide that.

And that's exactly what we are doing at my county. I'm proud to do this work.

Functional and Unit organizations

A colleague pointed me to a great article about Functional vs Unit Organizations. It's a long article, so it's difficult to summarize in a brief post.

Author Steven Sinofsky describes "going functional" at Microsoft, and says "No organization is purely functional or entirely unit-based, nevertheless in any given company of size (more than one product or more than about 100 engineers) there is almost certainly a dominant shape."

Sinofsky adds that while there's no obvious answer to "functional vs unit" for every organization, he does provide a few pros and cons. I'll attempt to summarize some of the core ideas here:
Pros
One product, one org. Sinofsky says "if you’re building one product then you just don’t really need “units”."

Better develops skills for each functional area. The "functional" org chart allows you to develop staff in the direction in which they are aligned. This is critical to an organization to grow its core strengths, especially as Sinofsky highlights that "the future of a technology company is never the current product, but the ability to lead technology change over many years and that only happens with depth of technology skills."

Easier to resource load balance. If you operate in a field that faces constant change, Sinofsky advises "A functional org is perfect for this because all the discipline resources are under one “roof.”"
Cons
Potentially diffuses accountability. When I worked in higher ed, we had a saying when referring to "academic IT" and "administrative IT": "One IT." It didn't matter what group you were in, but we were all in this together. But organizing your groups by function may spread out accountability.

Challenging to manage physically separate people. I've experienced this issue first-hand. It can be very difficult to manage people who are not sharing the same office space as you. Sinofsky agrees, and comments "a [geographically dispersed] functional org can be challenging because it pushes each of your functional leaders to become skilled in managing people from a distance."

People tend to feel less opportunity because there is “one” leader of a functional area. We all need to grow, and it's important for our star performers and future leaders to feel there is a place for them within the organization. Sinofsky agrees, and adds "there can be a feeling of limited opportunity “managing within a discipline” compared to “managing across disciplines”."
Sinofsky continues to compare and contrast Functional and Unit organizations. It's a long read, but worth your time if you are involved in defining your organizational structure.

Monday, March 13, 2017

Business and busy-ness

A friend and I do peer-coaching with each other, every few weeks. If you don't practice peer coaching, you should find someone you trust (and ideally outside your organization) and just talk for half an hour or an hour every month. Practice your coaching and mentoring with each other. Challenge each other. And help each other out. I find that these peer coaching sessions help provide clarify and allow me to refocus on my priorities.

This last session is a great example. In our last session, I related how things seem very busy right now, so my friend asked me what was going on. As I started to iterate the different things I was working on, I suddenly realized that I have over-stretched myself.

Here's a quick list of what I'm doing now:

  1. My day job (CIO)
  2. Founder and coordinator of the FreeDOS Project
    • Several projects associated with FreeDOS
  3. Director on the GNOME Foundation's Board of Directors
    • A few side projects for the Board
  4. Adjunct professor for an online class
  5. Writing articles for several different journals/magazines
  6. Writing a book about leadership
  7. Planning to write a book about usability in open source software
  8. Planning to write a book about management

Basically, I think my problem is I said "yes" to too many things. Someone asked me to take on a new responsibility, and I agreed to it before I really thought about how much free time I had available, and how much of that time I could realistically commit.

Take this as your reminder to stop and reflect on what extra things you've taken on. Have you tried to tackle too much? What can you do about it?

In my case, I'm planning to step down from the non-profit board when my tenure is up, in May. I'm also going to avoid teaching again, at least for a few years. And my book will have to wait until I have a little more free time to commit to it, while the future books will be put on "hold" until the first book is done.

Monday, March 6, 2017

On becoming a multi-dimensional leader

I recently discovered this great article from last year about "How to gain merit, regardless of your job function." The article begins by describing the ideal workplace, one organized as a kind of meritocracy: "In a meritocracy, leaders progress because of their demonstrated leadership abilities (not their formal titles). But how exactly do you gain merit in an organization using practices that aren't specifically related to your job function? "

The article then lists several key attributes for successful leadership in such a meritocracy. I thought this was good advice for any leader, and I wanted to highlight the attributes here:

  1. Listen to people
  2. Put yourself out there
  3. Maintain your moxie
  4. Cultivate diversity
  5. Own your mistakes
  6. Be mindful

I've discussed several of these leadership traits elsewhere in Coaching Buttons, but it's good to highlight them again here.

Monday, February 27, 2017

Finding the gems in your team

I'm away at a conference this week, so I wanted to share this brief link to a podcast interview from last year, at the CIO Talk Network.

The topic of the interview was "Discovering and Polishing the Real Gems In Your Team" and featured two leaders sharing advice about how to find and develop the next stars within your organization.

"A leader’s team may consist of different types of workers. For some of these workers, it’s just a means to an end, but there are others who believe that the work they do, matters. These workers demonstrate complete integrity and dedication towards their jobs and have a deep understanding of their organization’s goals. So how should a leader go about discovering and developing them?"

The interview features Helen Norris, Chief Information Officer, Chapman University and Tom Kolditz, Founding Executive Director, The Doerr Institute for New Leaders at Rice University.

I'm friend with Helen, and we peer-coach each other, so it was great to hear her advice in this interview.

Monday, February 20, 2017

The open leader

OpenSource.com recently posted a great about "open leaders" and "Why we need open leaders more than ever." In brief, the article discusses how leadership changed in the Twentieth Century with globalism and teams that were geographically displaced. And this new mode of working led to a new kind of leader: the "open leader."

The article makes clear that leadership can happen at all levels of the organization. And I agree! To be most effective, you need to develop your emerging leaders so people can "lead from the balcony" or wherever they are, to provide vision and drive strategic direction. From the article:
As organizations continue becoming more open, even individuals without "leadership" titles feel empowered to drive change. These organizations remove the chains of hierarchy and untether workers to do their jobs in the ways they best see fit. History has exposed 20th century leaders' tendencies to strangle agility through unilateral decision-making and unidirectional information flows. But the new century's leader best defines an organization by the number of individuals it empowers to get something done. There's power in numbers—and, frankly, one leader cannot be in all places at all times, making all the decisions.
The article provides a list of five attributes for the new "open leader":

1. Control
"Where the leaders of old are focused on command-and-control positional power, an open leader cedes organizational control to others via new forms of organizational governance, new technologies, and other means of reducing friction, thereby enabling collective action in a more efficient manner."
2. Communication
"The open leader seeks to engage an organization by sharing information and context (as well as authority) with members of a team."
3. Trust
"Open leaders embrace uncertainty and trust their followers to do the right thing at the right time."
4. Autonomy
"Where the powerful command-and-control 20th century leader is focused on some position of power, an open leader is more interested in the actual role an individual plays within the organization."
5. Empowerment
"Open leaders are focused on granting authority to members of an organization."
How do you compare to the new "open leader"?

Monday, February 13, 2017

How to write an email

Some people claim there's an art to writing an effective email. In my professional career, I follow these general rules for writing emails:
  1. Write email
  2. Delete most of it
  3. Click Send
I find brevity is often best. If I write too much, I may lose my audience. But there's a tipping point: you need to provide a certain amount of context. If you don't "set the stage" or don't provide enough background, your recipient may not understand your message. How little is "too little" in an email?

Let me draw on a few real-life examples. Outside of my regular job, I sometimes teach an online computer science class ("CSCI 4609") at a university. As an online class, we have a flexible class size, although we try to set the "reserve" limit at ten seats. After the first ten students sign up, you need a permission number. But I'll usually give a permission number to whoever asks for one. Usually.

The exception is for students who don't meet the pre-requisite. We require that students take another computer science course ("CSCI 2101") before taking mine. This provides a grounding for the material in "CSCI 4609." Such pre-requisites are not unusual at the university level. If you don't have the pre-requisite, you need to get a permission number from the instructor (me) so you can register for the class.

Let me use a few examples from this class to show how providing a bit of context can make your request more clear:
Too little information
You can imagine my confusion when I received an email like this one from a student who wanted to take my class: (not the actual email, but representative)
Hi. Please give me a permission number so I can register for your class.
Why did this student need a permission number? There were already ten students in the class, so the system might have prompted the student that the class was "at reserve" at the student needed permission to add the class. Or the student might not meet the pre-requisites. I need to know more before I can give a permission number.

In the first example, it's no problem to add the student; I don't mind more students in the class. But if the student didn't meet the pre-requisites, then I need to check that the student won't be in over their head. I want them to succeed in the class, but if they take the class before they understand certain basic concepts, they will find the class very challenging.

I responded to this student to learn more about their situation. Each email was equally brief, requiring us to exchange several more emails before I determined if the student should be added to the class.
Too much information
While it's challenging to respond to too-brief messages, it can be equally difficult to make sense of the small novels that some people send me. Here's another example from a student who wanted to take my class: (not the actual email, but representative)
Hello Professor Hall. I was looking through the catalog to find another class I wanted to take this semester and I saw your class, CSCI 4609. This is a really interesting topic and I'd like to take it. I talked to a few of my friends about it and they think this is something that will really help me after graduation, so now I really want to take your class. I was in the student center last night going through my course registration for Spring semester and I tried to add your class. The registration system is a little difficult to use, so I'm not sure what the message is trying to tell me. When I add your class I get a little red box that pops up and tells me I needed to contact you and get a permission number. But I'm a senior and this will be my last semester before I graduate. I have taken all my other CSCI classes already, and this semester I only have my capstone plus some classes for my minor. I have taken the interface class, last year with Dr. Smith, so I meet the requirements. When you have a moment, I need to get a permission number so I can finish registration in the class. I know we're out of queued registration but your prompt attention would help me to get the class for next semester. I would really appreciate it. Thanks so much!
Okay, wow. That's a lot of information. And the actual email I received was much longer than the sample I wrote for you.

This email is unclear and unintentionally buries the request in an avalanche of extraneous information. I don't need to know where you were when you tried to register for the class. I don't need most of the information here.

Reading long emails like this one seem like more work than reading other emails, because I need to parse the email to figure out what's really going on. Please keep them short for the sake of the person who will read it. Breaking up the email into paragraphs will also make the information more clear.
Just the right information
Let me edit the above email into a message that has just the right amount of information:
Hello Professor Hall,

I would like to take your class, CSCI 4609. I am a senior and have the pre-requisites, but the system says I need a permission number to take the class.

Can you send me a permission number?
That's much easier to read! Notice that the email provides a brief context to "set the stage" before making a simple request? The use of short paragraphs helps the reader to parse the email for the important points: The student has met the requirements, but needs a permission number from me. That's a clear request, and one that doesn't require any follow-up from me.