Tag: Management

  • 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.

  • Change Management – Another Instance of Management 101 Getting it Wrong

    Change Management is a idiom often heard these days where I work. I’m sure you know what it refers to – the process of implementing change in an organization and converting employee’s initial reactions of fear/anger/doubt to ones of discovery/understanding and ownership. The management steps used in this process involve opening up the avenues of communication to explain why the change is being made, providing training as needed, dealing with resistance, aligning employee and company needs, obtaining buy-in, implementing, and repeating – or some variations thereof.

    I never bought into this approach and have recently figured out why. First off, it starts the communication and gathering of input process too late – only after the decision has been made. In reality, employees should be part of the problem formulation and solution formation from the start and not only after the powers above have declared some particular change is needed. My second objection is more fundamental in that this approach espouses certain kinds of activities and communication approaches only during major change, when in reality the proper change management approach is simply a good every day management approach. Since the default is to do today whatever you did yesterday, nearly every decision made represents some kind of change. Why do we worry about communicating with employees, aligning needs and strategies, and getting buy-in only when we see some decision as part of a change management process and not otherwise? It just doesn’t make sense. Good communication and employee involvement make good management sense always – whether or not the company is going through a major change.

    It is not so much that the basic change management approach gets it wrong (and I’m sure some change management proponents adopt more sophisticated approaches which solve my implementation objections), it is more that it implies you need to worry about good management practices only during a big change and not otherwise. It is this implicit tolerance of bad management practices being the norm that I find the most troublesome and fundamentally bad for the organization. Good change management is simply good management. It doesn’t need to be separated into its own discipline.

    By all means, communicate with employees, get their opinions, align their needs with those of the company, and monitor the implementation of new projects, but do this early and do it al the time! Manage this way and you’ll never have to talk about the change cycle or change management again.



    Although not a particular fan of the “change management” dogma outlined above, Scot does believe in the Systems/Software Engineering approach to change control in projects. His life changed significantly for the better when he discovered CVS/SVN, for example, which he now uses extensively for his personal projects, both software and written.

  • Is Work Supposed to be Fun?

    Well, it’s almost the end of January and I do want to get something posted before the month’s out.  Let’s see if I make it in some time zone, at least.

    Our work recently had an employee satisfaction survey taken, the results of which  are a treasure trove of ammunition for someone like me who believes we can do better at the things we’re already good at and that there’s low hanging fruit in the areas where we aren’t doing so well. One of the questions we scored low on went something like:  My supervisor makes this a fun place to work.   While I don’t want to make a big issue out of this particular question, I did find it ironic that some of our leaders didn’t really understand the question.   To these people, work is work and fun is what you maybe get to do when you’re not working.  They didn’t seem to understand the point of the question and even said so publicly.  I guess that alone says something about why we scored so low here.

    So, what does this question mean? Is work supposed to be fun, or is it supposed to be just “work”?  First off, I don’t think the question is referring to how many parties or Friday nights at the pub, we have.  The question is asking if the time you spend at work is enjoyable (and does your supervisor help make it so). It is aiming at the question of whether you get up for work every day and dread coming in the office, or if you sort of look forward for a new day at the office, doing something you enjoy doing.

    My initial reaction to this question is, this is astronomy, it better be fun!  A (only) slightly deeper response is we spend so much of our lives at work that if it is not fun, we should be doing something else.  I’m sort of shocked that some of our managers don’t seem to get that.   Fun at work to me doesn’t mean a laugh a minute or always joking with my colleagues. No, it means, to me personally, being involved in a team, furthering a goal I believe in, and contributing my best talents to help us get there, while working with others contributing their’s. That kind of environment makes work seem less like “work” and more like “fun”.  I’m sure others have different visions of what would motivate them to want to come to work every day besides to collect a paycheck, although I bet the responses will be fairly similar to my own.

    Does my supervisor make this a fun place to work?Does my supervisor create an environment where I can use my talents to my greatest ability and contribute to a shared, desired goal?

    The idea that work is work and fun is what you do after hours is not only outdated, but is guaranteed to get you an unmotivated workforce looking for the next passing party barge with an opening.  Therefore, as managers, we have the responsibility to make sure our employees are getting something positive out of their work besides a paycheck.  Work is more than sharing the pain, distributing the load equally, and getting the job done.  To creating a growing, thriving, dynamic organization, we all need to create a place where people feel their talents are being used, their skills are being developed, and they are contributing to something worthwhile, bigger than themselves. At Gemini, we scored very highly in some of these areas, even some of the harder ones like sharing a common mission, working on something bigger than ourselves, yet feeling a part of it, but we missed out on the part about making all of it fun.  We’re thus missing out on the part that will eventually take us places we don’t even dream of right now – the part that that will let people’s imaginations loose to find ways to work within our current constraints to reach heights previously thought out of reach.

    We can’t forget about fun.



    Scot loves astronomy and acknowledges its many benefits, both direct and indirect, to society, but realizes that in the end, it is just astronomy. If it weren’t fun, he wonders why he would be doing it.

  • Another advocate for Openness, Transparency, and Accountable Management

    Somewhat recently, I finished reading Employees First, Customers Second by Vineet Nayar.  It was a very easy read since the techniques the author talks about using to restore his company to an industry leader agree a lot with what I already believe.  Nayar makes a strong case, based on real experimentation and use, for complete transparency, honest confrontations with the truth of what problems and potential problems lay ahead, freedom of information, and making management accountable to employees and not just the other way around.

    Early on in his tenure as CEO, Nayar realized his company had slowly gotten used to being at the top, satisfied with slow, steady improvement rather than large leaps of innovation.  Nayar writes: [My company] had lost its competitive edge because it had become tolerant of gradual change … and unless the company becomes obsessed with constant change for the better, gradual changes for the worse usually goes un-noticed. He also realized the solution to the company’s problems, even awareness of the problems themselves, laid within the employees, not necessarily with the managers at the top of the traditional hierarchical structure.

    In his introductory meetings with employees, Nayar realized there were three broad-types of employees: the transformers who understood and wanted to make things happen, although they were often hampered in doing so by the corporate structure, the fence-sitters who would usually not commit to taking action until there was a clear tide pushing behind them, and the nay-sayers who would pretty much be against anything new.   The key, therefore, to getting employees to take action, was to let the transformers loose. Once they were actively working, the fence-sitters would see that the tide had changed and join in. The nay-sayers, of course, would still be nay-sayers, but you deal with those people separately, anyhow and try to get them into better situations.

    How to get your employess off the fence? Give them a honest cause to believe in and, perhaps more importantly, engage those who are ready to act now, first.

    With these sort of tenets in mind, Nayar set out to create an environment where the employees, particularly, the transformers,  could catch, promote, and solve problems themselves. He turned management upside down and instead of making employees accountable to management, made management accountable to employees.   Managers were there to respond to the line workers needs, not the other way around.  Their shared job was to create an environment where people could easily innovate and solve their company’s problems. Of management, Nayar writes: People saw that some of the managers were little more than aggregators and brokers of information.  These mangers’ entire authority lay in their control of the information.  As soon as everyone had access to it, their power might come into question. And that was exactly what Nayar wanted.  He recast the value of his managers not by their zones of hierarchical control, but by their span of positive influence.  To help evaluate the latter, Nayar opened up the employee review process to allow any employee to comment on any manager in the company, within their functional or project unit or not.Other traditional performance review processes were changed as well. For example, instead of just rewarding support services by their time to close each submitted issue/request, Nayar’s company also added an incentive to be proactive by making the total number of requests and issues received a monitored metric as well.  Someone closing 1000 issues in 10 minutes each may actually be doing a worse job than someone who only closed 100 within an average of 4 hours.   It’s easy to solve long-recurring issues quickly. It’s much more useful to eliminate those common problems and leave time available to concentrate on the larger ones instead.

    Nayar created a culture of trust in his company by whole-heartedly adopting a strategy of transparency and openness. Of one purpose of transparency, Nayar tells a short story: “Why do you have such large windows?” I asked my friend [who had very large windows fronting a busy street where all could see in]…. “It keeps the house clean,” he said. Transparency promotes accountability by all – both management and line worker;  helps make problems, issues, and solutions, known to all; and not only keeps the house clean, but provides direct, verifiable evidence that it is so.  Powerful results for a simple philosophy that is actually easier to enact than the traditional one of hiding information behind a “need to know” umbrella.

    Nayar had public talks with staff members, did live video simulcasting of other important meetings, and always focused on the truth of where the company was at any given moment (for better or worse) as well as where it wanted to go.  He called one aspect of this approach Mirror, Mirror which he described as … a communication exercise that involved talking with employees throughout the organization about the truth as they see it and getting them to acknowledge the reality, the elephant in the room, that everyone essentially knows about but which has never been publicly acknowledged. This exercise sounds a lot like the looking underneath the rocks aspect of Good to Great. Not only do these exercises get the employees to see and acknowledge company issues, but it often gets them known to management for the first time!

    After getting the employee insights into the company’s problems and issues, Nayar engaged them in the solution process, as well.  He writes: Mahatma Gandhi, Nelson Mandela, and Martin Luther King Jr. … these great leaders did not formulate strategy by retreating with their top people to a private place and then emerging to make a pronouncement to the masses. No, they walked the roads of their countries, met their people, and talked with them ceaselessly, – just like the Level 5 leader of Good to Great.

    There’s a lot more to Nayar’s story than what I summarized here and I think it is also important to note that not everything Nayar tried went well.  Some solutions brought unintended consequences that either had to then be corrected, or a new solution put in place instead.  Other solutions, though, brought along unintended additional solutions, as well.  I think a key to Nayar’s success, as well as to that of the Level 5 leaders of Good to Great, is an inclusive, honest dialog, an erring towards too much available information rather than too little, and a willingness to try and experiment with new ideas.  No solution is going to solve everything, but if each one gets you further down the path to continual improvement, you’re doing very well indeed.



    Scot’s best teams, both to manage and work within, were hierarchically fairly flat. Equal access to information and abilities to propose and implement solutions makes it exciting to be part of a team and working on a problem. You can create an atmosphere where people moan in the hall ways about what is wrong with the company or you can create one where people buzz in the hall way about what each of them are doing to overcome the current problems.

  • One year later …

    Well, it’s been a year now since I started this blog.  I thought I should commemorate the occasion by writing something deep and reflective.  The problem is, I’m not very good at deep and reflective. So, you’re stuck with this post instead.

    A close friend of mine used to call me Mr. Spock, a nickname I was both proud of and resentful of.  I was pleased that my friend thought me logical, efficient, direct, and striving for optimization, all like Mr. Spock.  I was a bit bothered that he presumably also thought me lacking of emotions, the other defining characteristic of Mr. Spock.

    I realized, though, that like Mr. Spock, I grew up thinking that my feelings and emotions merely got in the way of getting things done.  (That my personal focus was/is on getting stuff done and not on feeling good, or making meaningful bonds with other people, etc., is another interesting note that will have to wait for some other post- maybe this blog’s second anniversary!) If something had to get done, it didn’t really matter what I thought of about it  – it still had to get done. What I came to realize, perhaps intuitively, and perhaps as a mechanism to keep the focus off me, was that the feelings and emotions of other people did matter to them getting things done. If I wanted to do things that involved more than just me, I had to take the feelings, emotions, desires, and needs of others into account.

    I started learning about what was important to others completely unaware of what I was doing. For one thing, focusing on other people kept them from focusing on me. I’ve always done things like ask my barber how she got started cutting hair, how she decided this is what she wanted to do, how she handles doing a hair cut the customer requests, but which she doesn’t like, …. I didn’t consciously teach myself to ask questions like these – it was just part of who I was.  People love to talk about themselves, and it helped me in that I didn’t have to.

    Happy First Birthday to astromanager.net!

    Later on I realized these sorts of questions, and the insights they offer, are exactly some of the keys I needed to have to be a better manager.  Strangely enough, not everyone is like me, so if I’m going to get the best out of people, I have to understand their needs and desires.  I have to be sensitive to their feelings and moods. I can’t treat them as chess pieces to be placed on the board in a winning position if they don’t want to be there.

    There wasn’t really a particular day or moment when I realized these things; as I said before, I found myself naturally doing some of them way before I ended up managing people and projects.  But I will say that as I gradually learned to pro-actively use this approach as a regular way of interacting with people, I became much more effective. (I also learned to build better relationships with people. Imagine that.)

    Simple concept, really- learn what people want and find ways to help and enable them to get it.

    Management, though, is full of simple concepts, yet we don’t always follow them. The tradition hierarchy of executive privilege, need to know information, top-down decision making, and etc., all violate these simple concepts.  Yet they have often been so instilled into our consciousness of what management is, that we can all too easily forget about the people side of management, and we end up blindly following these rather unnatural techniques of the past.

    So, part of my reason for writing this blog has turned out to be to remind myself of these obvious tenets of people and project management.   And like most things I do, if I can save others time by offering something I’ve done, then the return for my time spent has increased and I’ve made Mr. Spock proud by being even more efficient.



    While this blog is helping Scot be more like Mr. Spock in terms of optimization and efficiency, he’s still working on distancing himself from Mr. Spock’s dry, emotionless nature. His 8-month old daughter is certainly helping in this regards and although he hopes she grows up to know and love Mr. Spock, he hopes she doesn’t completely identify him with Daddy.

  • VWs in China and building relationships

    Combining my interests in German cars, international relations, and general management, I recently read the book, 1000 Days in Shanghai, by Martin Posth.  The book is about Volkswagen’s initial journey to become the first international automobile manufacturing partner in China.  I found several interesting themes in the book, particularly the patience and vision which the VW crew exhibited when things didn’t go as planned.  When factory workers appropriated factory supplies shipped in from Germany meant for the new joint venture factory and instead used them in their own Chinese car factory, for example, Posth philosophizes (and it was probably easier doing so years later in his book than it was at the time) that when the Chinese workers saw the potential success of their new company, these kinds of behaviors would stop.  Time after time, the Germans felt the Chinese violated the terms of their contract agreement while the Chinese felt the Germans weren’t living up to their word and doing what they could to improvise in a changing environment. Yet both side persevered and the VW/Audi story in China is a huge success.

    Then, in a recent airplane ride, I read a brief article in the in-flight magazine that was offering advice about doing business in China. The article echoed a theme I’ve also uncovered in working with the Japanese astronomy community:  the Japanese/Chinese business relation is built first on personal relationships (giri on / guanxi), then on the written agreement, whereas in the West/USA, the contract is the basis of the business relationships.  The people may change, but the contract remains. Our contracts are often very detailed and precisely worded.  Their contracts are broader and talk more about intentions and partnerships.  We use contracts to tell us what to do when conditions change. Our Eastern partners view changing conditions as natural reasons to renegotiate the contract.  Both approaches make sense, but both are fundamentally different and ripe for misunderstandings if these differences aren’t recognized up front.

    So, besides knowing a bit more to expect when partnering with some of our Eastern colleagues (something increasingly common these days), this situation reminds me of another simple, obvious, yet valuable point.  Any time you’re interacting with another person, whether from your own culture or one very different, it’s important to understand their environment; it’s important to state and understand each other’s expectations and assumptions.  Without this understanding, there would never be a Volkswagen in China. Without this understanding, it is much harder to reach true harmony and agreement in any of your human relations.



    When negotiating one international agreement, Scot remembers being frustrated while his negotiating partners complained they didn’t understand a certain passage of text. After failing at multiple attempts to figure out what wording was confusing and getting maybe just a little bit frustrated, Scot remembered that not everyone is as direct as Americans. What “we don’t understand” really meant was “we don’t like”. He could have spent all day going through the text word by word without addressing the real issue at all. With that bit understood, the problem was recognized and then fairly quickly dealt with and resolved. International negotiations are full of such fun opportunities to learn how others think.

  • Is project management enough?

    I was reviewing some notes from a colleague’s previous class on project management when I came across the following lines that caught my interest:

    A business or organization cannot survive on project management disciplines alone.

    Project management is defined as delivering to time, cost, and quality.

    Staff development is seen as an overhead if converted to a project cost, but [is] essential for an improving workforce.

    Employee development, morale, work/life balance, and even preventive maintenance/upgrades: these are all long-term needs that can easily be viewed as short-term distractions in a project-oriented culture.   It is clearly of little or no benefit to a project manager to use valuable schedule and resources on these kinds of activities.  So, this is where the functional (line) managers need to step to the plate. They are the ones that have the responsibility to provide a talented, skilled, stable, and motivated work pool to the project managers.  They have to be the ones to make sure their staff development needs are met.  They are also responsible for the basic functionality of the systems under their control. Thus, time for both staff development as well as system upgrades and maintenance must be reserved and held back from project allocation.

    I’m not saying that these project equivalents be considered sacred cows or anything. The resources spent in maintaining a well-adjusted, skilled staff need to be justified in terms of losses that would result from the expected turnover if these employee needs weren’t met. Similarly, system upgrade and maintenance task resources need to be justified against the potential lost time once they fail or need to be replaced.  But in any case, the responsibility for forming and advocating these projects must be with the employees and their functional, not their project, managers.

    Not a really complex or novel thought here, but just another indication of a need for intelligent and thoughtful management that clearly understands its roles and responsibilities.


    Scot’s graduate advisor, R. Ed Nather, has been known to say:

    If it goes without saying, better say it twice.

    As time goes on, Scot finds more and more wisdom in that statement and applies it often. Defining people’s project and functional roles is a great example of the value of explicitly stating what everyone often implicitly assumes without checking to make sure everyone else is operating under identical assumptions.

  • Who advocates for the Observatory?

    I’ve been reading a book on corporate boards, so expect a few posts on astronomy governance coming up, starting with this one. I really knew nothing about how boards out in the “real world” operate, so reading this book has been a great inspiration for reflection on boards I’ve seen in astronomy. There are plenty of things “wrong” with the Board I am currently associated with (according to the corporate model, at least), but one of the common complaints I’ve heard levied against it is not one of them: that its members are also its funders.

    On the surface, this complaint seems legitimate and I even bought into it for a while, since there appears to be a clear conflict of interest between someone trying to get more value for less money as a member of a funding agency while simultaneously advocating for the observatory to the funding agencies for the funds it needs to operate and expand.

    The flaw in this argument, however, is the passing of the advocacy buck to the Board instead of to the Observatory. Corporate boards are composed to represent the institutions’ stakeholders and certainly an observatory’s funding agencies qualify as stakeholders. Does this make it hard for the Board to argue for more funding from the funding agencies if the funding agencies are the Board? Yes, certainly. But venture capitalists and shareholders, analogs to our funding agencies, are regular members of corporate boards as well. It is not the board’s responsibility to argue for increased funding; it’s the responsibility of the Observatory to present a case compelling enough that its stakeholders are willing to invest more to get more return. This situation is exactly what works in the corporate world and it makes sense that it can work in the astronomy world, too. The observatory, however, has to be willing to act as its own advocate, making strong, supported cases, for the funds it requests. Our Board meets twice a year; who better to understand the ramifications of increased and decrease funding than the Observatory? Who better to argue to those with the purse strings what is best for the Observatory? The Observatory, or the Board?

    I think there are other issues with the the make-up of the board, but its having representatives from our funding agencies is not one of them. I’ll discuss some of the other issues in future posts.

    I should particularly note here that these are my opinions, not necessarily those of Gemini Observatory, for whom I work. See my standard disclaimer to the right.



    While on the subject of advocacy, Scot decided to link to the web splash of a recent result that he is co-author on: the analysis of the surface metal lines on a white dwarf star suggesting the remains of a rocky dwarf planet recently accreted onto the star’s surface. This scenario represents a possible interesting way to see the insides of extra-solar planets!