Albert Einstein once said “The definition of insanity is doing the same thing over and over again and expecting different results”.

May 3, 2013 8-48-28 PMWhen I first came to the PMI SFBAC board, we had a serious problem with continuity: The entire board was elected every year, and terms were limited to two, which meant there was little chance of any vision longer than a year being accomplished. In addition, the board was a working board, meaning each of the board members also wore an operational hat, which led to some odd silos within our volunteer organization.

Every year, we’d have an executive retreat and work on what the strategic goals of the organization should be. And the next year, a new board (often with little point of reference for the prior vision) would come in and do the same thing.

The board would try to apply PMBOK best practices to the organization, and implement things like PMO’s, only to have to end up starting afresh as we experienced another complete rebuild every couple of years.

I know we recognized continuity as a problem, and had a few things in place to help mitigate that problem, but the reality was, we had no real fix until we were introduced to Policy Governance® and combined that with another brilliant concept for our key roles: triplets.

Triplets was a concept that came out of some work we did trying to solve the problem of human capital in a volunteer organization. The issue was that we’d find a volunteer who was really good at something, and then for various reasons they’d be ready to move on. We’d scramble to find a replacement, often leaving the board member to do the work left behind for some time.

We also had this odd arrangement where the President was also the CEO and chair of the board, which meant the direction of the organization often changed completely when a new president was elected.

Because we’re a volunteer organization, accomplishments are a bit more difficult than they are in a commercial organization. Work is done on a part-time basis by people who have other more important things to do (like make sure the bills are paid). And since they work on something only occasionally, it often actually takes more person hours to accomplish (since setup tasks often have to be repeated, and simple tasks like turning on the computer are a larger percentage of time spent when you only have a couple of hours).

So the triplet idea was to assign three people to every job. This didn’t necessarily resolve the problem of losing key people, but it did at least ensure we had a candidate when one of our volunteers suddenly found  a new job and could no longer do what they’d been helping with.

Moving the operational work to the CEO, freed the board to focus on guiding the organization. It also separated the volunteers from any turnover in the board, since they no longer reported to a board member directly.

Athens KoliasAs of our last official board meeting, your PMI San Francisco Bay Area Chapter Board of Directors has a new Chief Governing Officer: Athens Kolias agreed to accept the appointment to lead your board and guide us in our journey toward leadership excellence.

When we adopted Policy Governance®, we learned that it was important to have a Chief Governance Officer to keep us on the track as we began the shift from working board to leading board, and that was the role to which I was appointed.

The CGO has two main roles: acting as the chair of the board which requires being assertive holding the rest of the board accountable to policy in order to speak with one voice, and secondly to interact with the board’s one employee (the CEO).


This video of an interview with John Carver will give you some idea of what we needed to consider in naming someone as CGO.

Please join me in congratulating the new board on a great choice for the new CGO, and congratulate Athens on showing the type of leadership that inspired her to be the clear choice.

In our first years with Policy Governance® we’ve managed to rewrite the bylaws, expand the size of the board, and create a more sustainable organization. With the help of our owners (the membership, the legal and moral owners of PMI SFBAC), we crafted our global ends statement (our guiding policy):

PMI-SFBAC members, people who live and work in Northern California, and virtual beneficiaries experience a continually improving standard of living, stability, a sense of community, self-esteem and self-actualization. These Ends will be achieved in a sustainable manner that represents value for the resources invested.

With this in mind, we’ve been able to focus on making the volunteer work more meaningful and useful in your professional life, and continue to build on sustainability. We’ve managed to increase what we are delivering, while driving down costs AND making our programs more accessible and valuable.

Thanks to the hard work of our CEO, Malika Malika, and her staff of volunteers, we have a growing volunteer operation and a sound financial statement, and solid reserves to carry us into the future.

In the coming years, we will continue the work of making sure the goals we are working toward are the right ones for the membership (you, our legal and moral owners), refine our policies, and continue to improve on what value that we can deliver together.

So here’s the board’s ask of you: take a moment to consider volunteering. We always have needs at all levels of the organization, the board is looking for people who want to learn more about servant leadership, and Malika has a variety of opportunities where you can help out and stretch your skills.





Enhanced by Zemanta
Serenity (Photo credit: Wikipedia)


A project manager has to be able to be in the moment and calmly react to any situation in order for a plan to succeed. Reacting to everything that might go wrong, or things that don’t help to achieve the goals of the project doesn’t get us to the product of the project (our “ends” or project goal).


Because a project manager’s biggest job is keeping everybody communicating, it’s easy to get distracted with all the chatter and worries of everybody on the team. You have to weigh the value of the cries of the Chicken Little‘s on your team in order to figure out whether the sky is actually falling or not, and if so, what to do about that fact.


For me this is a bit like the Serenity Prayer (written by American theologist Reinhold Niebuhr):


God, grant me the serenity to accept the things I cannot change,
The courage to change the things I can,
And wisdom to know the difference.


Continue reading

Screen Shot 2013-06-08 at 10.35.06 AMIf you read my previous post (WordPress Recovery), you know I’ve been writing some code to recover my old posts. It occurred to me I could take a small segment of what I’ve been doing with that code to demonstrate my approach to TDD.

Since I’m a hacker from way back, and also because I was in semi-panic mode about losing the content, I didn’t approach this task with testing in mind. Now that doesn’t always result in bad code: I’ve been doing this long enough that I can usually think through a fairly good model and code something that isn’t one long method full of inline code.

In this case however, once I had started coding, I realized again that this was an opportunity to practice coding the “right” way. I had already begun with a Maven project, and generated unit tests as I went through the process of starting to build the code, so I had at least some good functioning unit tests.

Continue reading

Well, I have the basics of my blog recovered now, so almost all of my posts going back several years are once again available.

In my last post titled Lesson Re-learned: Backups !, I admitted that I had committed the cardinal sin of making changes to my web site without doing a backup first (walking the tightrope without a net).

Luckily for me I had installed the WP Super Cache plugin, so all of my content actually still existed as static files, and being a bit of a hacker, I was able to throw together some code to effectively recover my posts.

Continue reading

Homer Simpson
Homer Simpson (Photo credit: Wikipedia)

I just shot my blog in the foot, or more accurately, I didn’t follow IT 101 and back things up before making a change.

I had moved my site to be completely WordPress based a while ago, and as a result I had a bit of a convoluted setup on my server.

When I first set up my WordPress blog it was as a sub-domain of, and was housed at (also aliased to The site just static pages that hadn’t changed for years.

So when I finally got my blog set up to host the few static pages I had, I just changed the directory on my server to have a symbolic link to the directory where had it’s content:

  1. Removed the directory httpdocs from /var/www/vhosts/
  2. Added a link in that folder to /var/www/vhosts/

This actually worked really well, since the content was only in one place, and all I had to do was change the host name in WordPress. Continue reading

When I was in third grade, we lived in Fairbanks Alaska, and I wanted to be a grown up. Because Alaska is frontier wilderness, a lot of the activities I remember were around doing things in the outdoors with the family.

I wanted to be grown up, so I got a paper route (at eight years old I was the youngest one they’d ever had). I remember that I had to borrow my Dad’s typewriter to write the circulation department telling them why I wanted to be a paper boy.

I also remember my parents making me take my little brother with me so I wouldn’t get into trouble and getting into trouble anyway (but that’s a whole bunch of different stories).

Continue reading

I decided I’d walk through creating a new app to replace one I’ve used for years on my iPhone that no longer appears to be maintained. The app in question is called GasBag which as near as I can tell stopped being updated in 2009 (see:


I could just write a quick and dirty web app to store my mileage, but I figured I’d approach this as an exercise in building an iOS application with a design first approach.


At a high level, what I want is an app that easily captures my mileage, and allows me to save that information somewhere that won’t get destroyed. There are a number of features that GasBag had that I liked (for instance being able to send an email with my mileage information), and a number that it doesn’t have that would be nice (like allowing me to use it for multiple cars, or to do some data capture from a gas station receipt).


Continue reading

I grew up in a fairly large family: three boys, a girl and Mom and Dad. We had a gazillion aunts, uncles, cousins, grandparents , relatives and friends.

Because of this, there were a LOT of communication channels, and as a natural part of her position in the family, that meant that Mom was a hub to a LOT of that communication.

So as we all grew up, and moved on with our lives, I began to see something interesting happen: because we all spoke less frequently, there would be times when we would hear about things in a very delayed fashion.

“Oh that was probably around the time that Aunt Jo died”

“Aunt Jo died?”

“Oh, I thought I told you, that was last year”

It took me a while to figure out what was going on, and see this sort of thing happen in my own life. As near as I can tell there are a few of reasons why we as humans have trouble with complex communication channels like the one I see in my family.

Reason 1 – Once we plan to communicate, we forget to do it.

Especially when we are busy, and have limited interaction with people, it is easy to plan to give a message to somebody and then get distracted with other things. In the case of the family dynamic, as we were no longer all in the same household, fewer opportunities to actually say the things that are planned to be said wer available, meaning there were more opportunities for distraction between plan and action.

Reason 2 – Once we verbalize to some people, it’s hard to remember who we talked to.

A huge survival trait we all share as humans is generalization, and our subconscious tends to exhibit this with the people we are closest with. If you’ve ever heard a parent run through all the children’s names before hitting the right one, you know what I’m talking about.

And because the subconscious doesn’t really differentiate much between planning to do something and actually doing it, the plan we made to talk to four other people, really does seem complete once we’ve talked to some portion of them, because we thought about talking to them all.

Reason 4 – Priorities change.

When we plan to communicate, we know it’s important but with limited opportunity for that communication, other things come up that mean we don’t get around to it, and it no longer seems as important. In the fictitious “Aunt Jo” example, time has passed, mourning is done, and there’s not usually a reason to remember that we never had that conversation we meant to.

Reason 5 – We remember good things better than bad.

I’m a firm believer that it’s important to give feedback immediately, especially when it’s about something bad that happened. I also believe that over time, we remember the good moments in our lives better than those that aren’t as positive. That’s why when you think about the music that was on the radio when you were in high school, all sorts of wonderful tunes pop into your head, but when they actually play the top 40 from that same year, you hear some things that make you smile and wonder why they were popular.

This is probably another survival trait: I know for me, I can remember what to avoid, but the memories for what a burn feels like, or how much it hurts to skin my knee, is not nearly as vivid as what it feels like to hug my wife, or have that wonderful feeling of contentment after a holiday meal.

So if communication about something bad gets delayed long enough, it’s human nature not to bother with it. Not only do we  want to avoid dredging up things that aren’t fun, but the value of doing so has diminished, and so we just choose to forget (and maybe can’t remember).

So my solution for the Mom Communication Event ?

It’s really the same goal with every bit of communication, test that the message you sent was the one received. I used to wonder why people used to say “Did I tell you about …”, but now I know why, they were just being human, AND being good communicators, just like my Mom.


I was reminded a couple of days ago of the danger of using tools that help you to get things up and running quickly, by a question that I was asked in an interview. The question was pretty simple, but not something I’d thought about for a while, which was: “What are the verbs used in RESTful services?”.


Now intuitively I know that answer, but hadn’t really thought about it for a while, so I basically answered incorrectly (mostly because I suck at inteviews), only remembering that you do GET and POST in HTTP, so responding that GET is to query and POST is for inserts/updates.

Of course I know the reality (and one of the advantages) of RESTful services is that they behave by contract, so they can use the full complement of the HTTP verbs, and the convention is to use each one for a specific purpose:

  • GET – used to get or retrieve a resource (always returns the same resource for the same query).
  • POST – used to create a new resource (returns the location for the newly created resource).
  • PUT – used to replace a resource (typically an update).
  • DELETE – used to remove a resource
  • OPTIONS – sometimes used to describe information about what verbs a service can use for a specific URI (not normally implemented however).

But the last few times I’ve done RESTful services, I’ve simply let an IDE generate them for me, so I haven’t even thought about those last statements. In the IDE, all I had to do was say I wanted to add REST (using Jersey) to my session beans, and voila, I have a full fledged RESTful service.

And of course on the consuming side, all I have to do is call the right method, and under the covers the Jersey client stuff does the right thing about which verb to use. So I’m not actually thinking about what’s under the covers, and because of that wouldn’t be quick on my feet about how the service is constructed under the covers.

There are of course pros and cons to approaching code in this way. In the early days of writing code, we all had to know what the machine language underneath looked like. Modern languages hid that complexity from us, and reading assembly language became a lost art practiced by rocket scientists and performance gurus.

By hiding the complexity we have been able to develop insanely complex applications that would not have been possible without those building blocks. Freeing ourselves with increasingly general patterns in code, we are able to focus on solving the problem at hand, and stand on the shoulders of those that go before us in doing so.

I don’t expect to need to write a RESTful service from scratch any time soon, but it is a good reminder that when you rely on tools to build your code, you are risking living with a lack of understanding of the underlying mechanism, which could make it difficult to know about the pros and cons of a solution.


Enhanced by Zemanta