Is Work Supposed to be Fun?

Posted on 31 January 11 by Scot

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.

Posted in General | Tagged , , | 4 Comments

Another advocate for Openness, Transparency, and Accountable Management

Posted on 28 December 10 by Scot

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.

Posted in General | Tagged , , | Leave a comment

Working with academic vendors…

Posted on 5 December 10 by Scot

In my previous post, I made the outlandish statement that not all vendors are well-versed in the skills needed to properly handle large, fixed-price, contracts for one-off products.   Now, I want to discuss some ways to effectively work with such contractees.

Risk: Many vendors feel they are simply not prepared to assume the risk that’s involved in a fixed-price contract.  When you press them, of course, you find that risk assumption is not the real problem.  If you ask questions like, Could you do the project for $10 million?  Could you do the project for $100 million.  What if we offered you $1 billion? These questions are obviously silly, but they illustrate the point that there usually is a price point where the risk can be assumed.  So, what they usually mean by we can’t do a fixed price contract is that they don’t understand the risk well enough to be able to price it into their bid.  With this insight realized, there are a number of approaches you can take:

1) accept certain risks for the vendor
2) initiate some pilot studies to assess and/or eliminate key areas of risk
3) allow some flexibility in the bid price, with certain elements being priced only after enough effort has been made to understand and costs the risky bits
4) simply encourage them to price the uncertainty into their bid and submit a higher priced bid

Working Relationship: Most academic teams don’t really like the customer/vendor relationship model.  Many of them are in academia, and not industry, for exactly reasons like this.  They usually prefer a more interactive partnership where science objectives, technical requirements, and management decisions are made more jointly with less clear lines of authority from contractor to contractee.  The goals of the academic world include building and sharing new knowledge and closer interaction with the project partners helps fulfil these objectives.   The contractor, therefore, has to be willing and able to devote more resources to the project and have more interactions with the contractee than they might otherwise have, sometimes partnering in parts of the work and mangement efforts.  Lines of ultimate authority and responsibility can get a bit blurred in these situations, though, so it is important to make it clear who has the final say when necessary (although only when necessary) and what decisions and discussions have contractual implications vs. those that are simply exploratory debates and discussions.

Understanding the Contract: Many of our vendors (academic or not) do not seem to fully read or understand our contracts.  They often do not know exactly what they are expected to do, nor what their rights and responsibilities are with respect to the contract.  Sometimes this lack of understanding actually helps the contractor when, for example, a contractee does not realize that a change initiated by the contractor does not have to be accepted without additional compensation.  But even in these cases, ultimate harm is done to both the contractor and contractee if the  contract terms are not openly discussed and enforced by both parties.  No one who loses money in a contract due to changes by the customer will want to contract with them again, for example.  So, it is vital for the contractor to really explain the contract to the contractee and to constantly refer to it and abide by it when new situations arise.  This behavior gets everyone’s rights and responsibilities out in the open, eliminates a lot of arguments about what the correct course of action is, and build good relationships for this and future work together.

Contingency Management: I referred to this issue in my last post, but it’s of such vital importance to the success of a project that I want to bring it up again here.  First of all, it is important to realize there are three types of contingency: cost, schedule, and functional.  The temptation, typically, is to use them in that order, but that is exactly the wrong thing to do.   Towards the end stages of a project, often when the most problems occur as the pieces come together for full assembly and integration, there is very little functional contingency left. The only thing that will get you our of a jam at this point, is usually money.  The only time functional contingency has any availability is early on in the project, before the design has been set and components purchased.  Unfortunately, early on in the project, there should also be lots of cost and schedule contingency, so the temptation is to keep the product fully functional and start dipping into the cost and schedule buckets.  The problem then comes, of course, at the end stage, when the functional contingency has expired and the cost and schedule contingencies have already been spent.  You don’t want to hoard your cost and schedule contingencies past the end of the project, but you do want to make sure they are available in the latter stages of the project when you are most likely to need them.

The scientists and technologists involved in a project will not want to give up functions early in the project when, from their point of view, there is a pile of available time and money just waiting to be spent.  Worse still, they may want to start adding features as new ideas and products are discovered that will enhance the end product.  Ask any experienced project manager and they will tell you that succumbing to these two temptations is to go down a very precarious path towards successful project completion. So, one technique to employ is to leave hooks in the project for the cut or new functionality and set a date by which time it can be included if other risks have not been realized.  Doing so establishes the mindset that these three areas of cost, schedule, and function have to be continually balanced within each of their finite limits and may even inspire people to work harder in other aspects of the project so that their favorite functionality can be restored/added later.

Posted in General | Tagged | Leave a comment

Why are we surprised when vendors can’t keep projects on time and budget?

Posted on 22 November 10 by Scot

It has been occurring to me lately that there is a fundamental mismatch between how some astronomy projects  select and manage external vendors and their expectations of these external vendors’ performance.  In our case, we require competition and fixed price contracts.   Our typical instrument contract bidder, a university lab or department, is often not used to fixed price contracts.  To inappropriately stereotype, academia likes to be awarded grants and submit reports on the work accomplished after the fact.  That’s not what our contracts are. Universities are not used to, and therefore do not generally have the infrastructure for, fixed price, fixed schedule, competitive bid contracts.  They have not usually developed the considerable expertise needed to fully cost a new project and identify and manage  its  risks.  The end result is that they often deliver late and and over-budget, if at all.

An alternative to academia. we could pursue our contracts in the commercial world.  Except for  one, they don’t usually respond to our requests for proposals, and two, they generally cost more.  Their more properly calculated and risked cost is what generally prices them out of the competition and prompts them not to waste their time bidding.  Again, to inappropriately stereotype, the commercial world has learned how to cost and scope a project to ultimately complete a risky project to a fixed deadline and cost.   While their bids end up more expensive, the price more accurately reflects the risks involved in a fixed price bid for what is ultimately, after all,  a one-off product.  Those that know how to properly cost an uncertain project, whether in academia or outside, will inevitably come up with a higher price and a later delivery that those that do not.  So we are simply fooling ourselves if we expect a complete, on-time, on-budget delivery after selecting the low bid from an ill-prepared institution.

So, we have a couple choices. We can pay the higher price requested by those that really know how to cost a risky project or we can adjust our approach and our expectations and work with less-prepared institutions.  The latter, though, means acknowledging early on that the bid cost and schedule will not likely last the whole project.  If our selected vendors do not have the tools for full project management, we need to work more closely with them throughout the project, both training them and working as embedded project managers.  This effort will have real costs in terms of both resources and schedule.  By using our contingincies (see some of my thoughts on the use of contingency in the middle of this earlier post)  properly, for example,we can begin to generate a culture of cost and schedule containment from the early stages of the project.  At the beginning of a project, when the first hurdle is found, most people want to throw time and money at it since at that point, these reserves are well-stocked and it seems too early in the project to de-scope.  Yet, if schedule and cost are to be maintained, de-scoping early is often the most appropriate response.  One way to soften the blow is to leave hooks for the de-scoped capability to be added again later, if reserves allow. In some instances, however, that simply won’t be possible and a given capability will simply have to be eliminated in order for the project to stay on track.  Making these kinds of decisions early will help the project develop a plan-oriented culture.  If, on the other hand, there is more time and money than there is functional contingency, then we need to realize the initial optimistic delivery dates and costs  are not likely to actually correspond to the final delivery dates and costs.  We therefore need to set our expectations, and those of our community, accordingly, by adding in the schedule and cost contingencies necessary to assure the required functional specifications are met.  If time and schedule reserves are not very plentiful, then we must prepare our stakeholders for an ultimately de-scoped end-product.

If we really do need something on a fixed price and schedule, then we need to consider paying more to the people who know how to deliver in those circumstances.   It will look like it costs more to do so, but in the end, it may actually cost less and is certainly more likely to result in a useful delivered product than would a lesser contract awarded to a less realistic vendor.

(I realize there are commercial companies who don’t understand risk and universities that do, but my point here is to understand the vendor and adjust your stakeholders’ expectations and project management approach, accordingly. We may not always be able to choose with whom we work, but we can choose how we work with them.)

Scot has managed both projects with both commercial and university vendors. He’s seen similar mistakes made by each type (not reading the contract is a common one), but has also learned to adjust his style dependent on the vendor’s experience and approach.

Posted in General | Tagged , | Leave a comment

One year later …

Posted on 30 October 10 by Scot

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.

Posted in General | Tagged , , | Leave a comment

Healthy Conflcit

Posted on 24 October 10 by Scot

I recently picked up a copy of A Grand and Bold Thing by Ann Finkbeiner. It’s a book about the original Sloan Digital Sky Survey (SDSS). I actually haven’t read it yet, so I’ll probably say more about the book later, but I have had some fun flipping through the pages and reading/re-living various random passages and episodes. One thing I noticed by this quick perusal is that Finkbeiner seems to have chosen to focus her book on Jim Gunn (of course) and the Princeton / FermiLab tension that defined the project for a large part of its life. Upon reflecting on this choice, I realized there was no shortage of conflict within the SDSS and not limited to these two powerhouses. Yet, when I remember the years I spent with the SDSS, conflict is not one of the first things I think about.

No, instead I think about people’s drive and dedication to the project. I think about a group of people faced with a limited amount of time and money doing whatever it took to get their shared project done. I think about a talented group of people making each other better. And yes, I think of conflict, but a conflict born out of this shared mission, a drive to succeed, and ultimately, enough trust in each other that discordant views could be aired and the right answer would get chosen, regardless of its origin. I even remember instances where conflict was created as a mehanism to help spur progress.

So yes, there was conflict, Plenty of it.  Did people get bent out of shape, angry, annoyed? Did some people cross the line and make personal attacks? Did things sometimes get out of hand? Yes, yes, yes. And certainly some of this conflict could have, should have even, been avoided, but my point here is that for this project, conflict worked very well. The Sloan Digital Sky Survey was (and still is) an unmitigated success.

That conflict was so alive and flourishing I take as a sign of a healthy organization where trust and security were high enough to allow open conflict.

I certainly don’t generally condone creating conflict to try and improve productivity (although it can have its instances). What I do condone, though, is creating an atmosphere where conflict can and does naturally arise. Only when people are being honest with each other, have passion about what they are doing, and are generally united with a common ultimate goal in mind, does healthy conflict arise. Before you try creating conflict, try creating an atmosphere of trust and security. Seek out and listen to dissenting views. Fix the system, not the person, when mistakes are made. Establish a culture of openness and trust. Help people feel secure enough in their positions to know that mistakes are not personal failings and that false harmony is not the key to a productive workforce.  These things will create an atmosphere where honest conflict can arise, pushing, pushing, pushing at the boundaries of your project to do things better, faster, cheaper.  If you don’t have open conflict, you probably don’t have a very high performing organization.

Another thing I think about when I think about the SDSS is the difference between projects and institutions. Projects have a limited set or resources and time to complete a task. They therefore have to be focused and directed or else their project will fail. Institutions don’t have these same constraints.With a more or less guaranteed stream of funds, they merely have to do better this year than last year. Things can wait for an institution where they can’t in a project. What’s even more interesting here, though, is that there is nothing preventing institutions from acting like projects, despite their more steady funding. I think adopting many of a project’s methods and mentalities will help propel an institution to continued excellence and to not be content with simple steady improvement.

Scot remembers one of his first days with the SDSS. Standing around the breakfast table, he commented how exciting it was to be involved in the project at the such an early stage (official survey operations having not yet started). A visiting, real longterm Sloanie simply laughed and said that this was actually closer to the end of the project than it was the beginning. A very valuable perspective was thus quickly gained.

Posted in General | Tagged , , , , | Leave a comment

There’s more than one set of reasons for not communicating well…

Posted on 30 September 10 by Scot

There are some other topics I’ve been wanting to write about lately, but this one just keeps on giving…
I received an anonymous private reply to my previous post here on communications and the recent lunch meeting suggesting there are often other reasons people don’t communicate with each other besides not having an efficient infrastructure for distributing information. In these cases, we can develop the finest new tools to make sending and accessing information as easy as possible, get everyone trained on how to use them and communicate more effectively, etc., and nothing will change. We must first look in the mirror and ask ourselves why aren’t we communicating. Some possible non-communication responses to that question might be:

1) Information is power, a foundation for authority we don’t want to lose.

2) We are afraid of conflict and aim to slip things past people in hopes that no one who might disagree notices.

3) We are afraid someone will question our information and demand even more work from us, which we’d rather avoid.

I’m sure there are countless others, but I’m also convinced that a careful analysis behind these reasons for purposefully not communicating will reveal that they are, in fact, flawed. In this day and age, authority vested in the ownership of privileged information is doomed to fail. People lose authority and respect when hidden information is inevitably later revealed. If people disagree with your information/decision, better to get that disagreement out at the start than when you’re trying to get people involved to implement a plan. If a single person constantly creates discord in response to new information, then you have a management issue of that person, not a reason to stop communicating. Yes, you may get asked more questions and have to do more work, but if the result is better information, or a better decision, isn’t that work worthwhile? Furthermore, if you open your information to others, you will just as likely get support back from people with offers to help who would not have known to do so otherwise.

So, in addition to doing the experiments, and seeing what communication schemes might work better for us, I propose we need to first look seriously inward and see if there are other reasons we choose not to communicate. For if we don’t heed the latter, all the new tools and good intentions in the world will not fix the problem.

Posted in General | Tagged | Leave a comment

To fix a problem, first look in the mirror, define it, and own it

Posted on 21 September 10 by Scot

There is an interesting discussion starting from a post I made on an internal work blog.  So, I thought I’d repost a slightly edited version of it here.

I attended a rather disheartening informal lunchtime meeting recently at work. One of the issues that came up involved a recent communication lapse where one group of stakeholders was not informed about a decision made by another. This kind of thing happens all the time, but it is of course instructive to evaluate what happened after the fact and see what changes can be made to help prevent future repeats.

It took me a little while to realize, but what I found so disheartening from the meeting was an apparent lack of desire to really work together to learn to communicate better. What I saw were people establishing how they were victims of someone else’s poor communications and people looking for the solution that would get the other guys to behave. In that kind of environment, it is impossible to explore solutions. That didn’t prevent many people from proposing solutions, but fault was found with all of them and the meeting ended, I thought, with general bad feelings about the apparent inaction to correcting our problems. No proposed solution solved all the identified problems, so why try any of them?

I will grant that there is no single solution to improving communications. There are tools that can be used, procedures that can be changed, attitudes and actions that can be rewarded and condoned, but no single one of these is a cure-all (yes, even archived mailing lists). Some of them will even fail, or make things worse. But what bothered me the most at this meeting was that there was no desire or commitment to try these things at all. True – each attempt might not work and nothing we can do on its own will solve all our problems, but if we try something new and learn a bit about what works and  what does not, about how we communicate and expect to be communicated with, then we gain and we are more likely to eventually arrive at a package of solutions which does work. If we are too busy blaming each other, we will never be open to exploring what each of us can do to create an environment where communications and information flow freely and easily.

This image represents the result of a lot of dedicated, cross-disciplinary work in a cooperation between HIA, Gemini, and ARC. It may not look like much, but it's one of the first full three-CCD images of our new CCDs from our new controller for GMOS-N. The one dark column is a known, separate problem we are also resolving. We expect to have these CCDs available for our community to use some time in 2011.

If we had a detector controller where data were not flowing well from one channel to the other, we’d be actively debugging, swapping boards, adding ground connections, hooking up the oscilloscope to see what’s really being transmitted, etc.  Why do we apply this experimental approach to our technical problems, but not our cutural ones?  Why do we  involve people from different disciplines to debug a detector controller, but not our communications?  Learning to take shared responsibility for our communications and our communication needs is a big project, but we have ways to handle big projects.  Why aren’t we applying these ways and methods to one of the most important underlying issues affecting everyone here?

(Standard disclaimer: we are making progress and our problems are a lot better ones than at many other places; it’s just that we still have a ways to go….)

Here’s an addendum I made in addressing one posted comment on the internal site:

…there are plenty of unpleasant problems that are being addressed here, but not this one. Perhaps because it is larger than the others, perhaps because it involves people and not technology, perhaps because the solutions are unknown and success not assured. It’s almost as if (which in my experience usually means it is) we are trying to outsource the solution to these problems through training, consultants, working groups, before really taking the internal look in the mirror at honestly confronting what we are doing right and wrong and owning the problem ourselves. Only after we all make an honest self-appraisal, I suspect, can we gain much benefit from these outsourced solutions. This is not something “they” need to do, but something we all need to do.

Scot realizes that no matter how good things are, there is always a biggest problem. Keeping the absolute, as well as the relative size of a problem in mind is important to maintaining perspective.

Posted in General | Tagged , | Leave a comment