Month: May 2011

  • Balancing Two Boards

    Gemini has two Boards – the Gemini Board from the international partnership agreement and the AURA Board. It’s actually a bit (well, OK a lot) more complicated than this. The National Science Foundation (NSF) is Gemini’s Executive Agency. They collect and distribute the funds for Gemini from the Gemini partnership. They also provide the funds for the US part of Gemini. AURA is our Managing Organization and is basically responsible for the management of Gemini. They have their own board and a specific oversight committee for Gemini, the AOC-G. The Gemini Board is basically our governing body, being the representatives of the partner countries to Gemini’s operating board. If each of these agencies, boards, and committees wants a review twice a year, Gemini would (and quite nearly does) end up with a major review a month. This would be bad enough, but as you can imagine, with so many organizations, boards and oversight committees, it can get a little confusing figuring out who is responsible for what and to whom. The lines of control and authority are blurred and complicated. The Gemini Board sets Gemini’s direction, yet Gemini’s Director takes home a salary provided through AURA. The reviews from the different groups in the observatory’s governance structure often end up commenting on the same aspects of the observatory while leaving other aspects untouched. In some areas, everyone wants their piece of the action, to have their say, while other aspects escape without much scrutiny at all. Overall, it’s a recipe for confusion and disorder.

    The Gemini Partnership Agreement specifies the general roles of the Gemini Board, the Executive Agency, and the Management Organization. but of course not those of each of their boards and oversight/review committees. So, even if everyone read and understood the Partnership Agreement, there would still likely be confusion. The Partnership Agreement and Management Organization’s contract will be up for renewal soon (~2015) so we have an opportunity in a few years to simplify this whole structure and come up with an organization that has clearer and cleaner lines of authority and responsibility. In the meantime, though, we still have to make things work a little better than they do now. The unclear lines of communication and authority are hindering us from becoming a true high performance organization with a single team able to focus on a common mission.

    Balancing Gemini's Boards takes some care and thought, but should not be too difficult if can agree on a clear division of roles and responsibilities.

    In their book, Corporate Boards: New Strategies for Adding Value at the Top, authors Conger, Lawler, and Finegold define the primary roles of the corporate board as follows:

    1) giving strategic direction and advice
    2) overseeing strategy implementation and performance
    3) developing and evaluating the CEO
    4) developing human capital
    5) monitoring the legal and ethical performance of the corporation
    6) preventing and managing crises
    7) procuring resources

    With only a little study, these 7 roles divide up fairly nicely to those potentially of the Gemini Board and those of the Managing Organization. The Gemini Board represents the partnership’s interest in Gemini. AURA and its boards/committees represent Gemini’s management and staff. A natural division, therefore of these roles would assign #s 1, 2, 6, and 7 to the Board and #s 3,4, and 5 to AURA. This division of roles lets the Gemini Board concentrate on strategy and resource procurement (partners, development funding, etc.) while AURA concentrates on human resources and legal operational issues. Allowing AURA the time and focus to concentrate on developing, evaluating and supporting Gemini’s human resources would be a nice benefit to this approach and would help Gemini develop and keep its best home-grown talent for future roles within the Observatory.

    This division of roles also allows the opportunity for the Gemini Board to review AURA’s performance and, if we’re really being open to new ideas, to have the AURA Board, or even better, an NSF (our Executive Agency) review committee, evaluate the Gemini Board’s effectiveness. Each Board reviews Gemini in the areas of its domain, and each Board (and/or the NSF) reviews the other Board to keep everyone honest and help ensure everyone is working as optimally as possible, together, to push the Observatory forward. This sort of separation of powers is very consistent with the responsibilities of the Gemini Board, Executive Agency, and Managing Organization detailed in the partnership agreement. The Board is given the fiscal and strategic responsibilities for the Observatory as well as oversight/review of the Managing Organization. The Managing Organization is given the responsibility to develop management plans, employ key Gemini staff, and carry out Board decisions. They are thus also the likely choice for the roles of top personnel development and review within the Observatory. The roles I’ve defined could easily be agreed upon now with only a slight extrapolation necessary from the partnership agreement, and formalized, after some time to see how it works, in the next partnership agreement.


    These are interesting times for Gemini, perhaps even more so than on average. Scot hopes discussions like this one happen often and broadly while we discuss and form the structure and organization of Gemini into the next decade.

  • Agile development and change implementation

    While I’m on the topic of change management and how it isn’t very different than plain old good management, I feel like I need to address one additional aspect that people often get wrong. Initiating a big change is hard and it’s nearly impossible to get everything right. This difficulty can cause an organization to stall in the middle of its change process, or worse still, never get its changes off the ground at all. People can worry so much about trying to get everything right at the start, that they never actually start! These people are missing a key insight, though. They are almost guaranteed to not get a big change completely right, at least not at the start. So instead of spending so much time planning perfection that you never actually get started, plan instead to make some adjustments and corrections as you go. I look at this sort of like the agile development process for software.

    Instead of the traditional software design approach of getting all the customer specifications, defining all the other interfaces and requirements, producing the proper flowcharts, and pseudo-code, all before writing any actual lines of source, the agile approach relies on rapid development cycles with frequent releases between customer and vendor. These frequent releases and testing cycles allow bugs and requirement misconceptions to get caught early and fixed before they are too buried in the code to be easily changed. Fundamental tenets of agile development (thank you wikipedia) include valuing:

    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan

    While the items on the right are important, agile development places more value on those on the left. Agile development processes are now expanding beyond software to other areas of engineering and development as well. Rapid releases, real time customer interaction and results assessment, and teamwork development are all agile tenets which translate easily to other endeavors including change and general management.

    Agile Development cycle
    A simplified description of the Agile development process.

    Planning is important, as are defining initial requirements and defining your end point in terms what outcome defines success. But planning, even 100% perfect planning, doesn’t guarantee success. In some cases there are too many variables, too many complex systems, that it is impossible to plan everything with 100% accuracy before starting. In these cases, I say borrow something from the agile programming model. Define your needs, define your end point and make a first release. Test, evaluate, repeat, until success. Don’t let lack of predictability or perfection prevent you from making a needed change. If you can’t solve everything at once, that’s OK; solve what you can and evolve from there.