Good Crew Members

On a small ship a good crew member is easy to recognize.



They are those persons who do their jobs, and a bit more, looking after the ship, fixing what needs to be fixed right away. Small things such as putting away the used coffee mug you forgot on the cabin table. Going out in the night for a sail change without extra griping (and mind you, there is the "right" amount of griping and complaints to keep up morale).



They are those persons who show up for their watch just before without asking, perhaps with something hot for the ones coming off watch, and who leave for their off-watch only after the next one is solidly on deck.

They are those who are easy to get along with, and know when to keep up a happy banter with the others, and when to leave someone alone.

There is not much to say about physical, technical or other abilities as such - those can be learned, and will be learned if one takes a passage. But the basics of looking after the ship, after the crewmates, after everyone's well-being, that attitude is the essential foundation of a Good Crew Member.

Occasionally you'd wish we'd have more Good Crew Members in corporate life. People who would notice things that need fixing, and quietly just fix them. People that wouldn't complain when there is a little extra to be done. People that get along with everyone else.

That would be great. Sometimes you meet those people, and end up realizing that what works on a ship with a known destination and a voyage of limited duration does not work in a modern firm, excluding perhaps small companies.

So you have a good buddy is a Good Crew Member (GCM) in your company. She finds things to be improved or repaired and goes ahead and does it. There may be some that complain that it was wrongly done, the execution should have been different. Still, there are others that notice - this person gets things done. And so it starts, the GCM is asked to do more and more, and as long as she does that, the more she will be asked.

All the better, more responsibility, more visibility, proceeding up the ladder, thinks the Crew Member, and takes on more. And they pile it on - why not, this guy is getting things done.

Eventually and by default even the best of the best can handle everything, as unlike a ship - a closed community - a corporation is virtually boundless. Good Crew Members get to work more and more, and rarely are they given the necessary resources - surely they can pull that additional project off, too?

And so the structure which is looking for growth often ends up stressing the most valuable assets, Good Crew Members to a breaking point. What happens next is crucial.

In some cases the GCM is left alone, struggles for some time, perhaps suffers a person burn-out.

In some cases the GCM if promoted, moved to another position or otherwise disturbed so that the effective state is disturbed.

In some, very lucky cases, the GCM is driven to a point, but not beyond that, the GCM is not broken, but offered help, additional resources, whatever to make more happen.

And those lucky cases, those occasionally end out being success stories.
Great stories for all of the participants to tell tales about!

Working together does not work over e-mail

Over the past few months I've seen numerous examples of how things start happening once people get together to talking distance, face to face in the datacenter (engine room, this is a "nautically biased" blog).
The latest was the funniest. Someone wanted to move functionality (an instance) from amazon to a private cloud and someone else was helping. The e-mail dialogue was fascinating - first party in India, second in Europe:
India: "i'd like to move an aws instance to cloud xyz"
Europe: "Do x y and z"
I: "did not work,"
E: "check /dev/doohickey"
I: "I only see /dev/whatchmacallit"
[ repeat with variations]
Manager of I: "escalate"
-- at this point a call was agreed on and I and E were talking to each other.
Joint discovery " the aws instance is an old model and x y and z do not apply".
I'm picking on this anecdote (the tall, excitable bearded one - please note how carefully I'm removing all traces if identity) as it us so usual and actually pretty funny.
Two things:
- Face to face is best, phone and screen sharing is good, email chat is marginable and ticketed request response systems are effectively non-functional for troubleshooting.
- Remove managers and other non-essential parties from the discussion! Non professional advice is bad, and is worse if it is coming from a manager - bosses need to be listened to, obeyed abd respected if they are to function, and a boss interfering with troubleshooting is very counterproductive.
Is there a maritime equivalent! Yes, there is to the boss part (face to face is not much of an issue on  a ship).  Captains or officers who don't have the competence to let their crew to do the job seldom run happy, effective and safe ships.

State of the art multivendor outsourcing and innovation

This time I don't have a sailing anecdote or context to match the subject, and I believe there is a reason for that. Sailors would never be as silly as us IT folks, that is!

I'm writing about outsourcing and especially innovative approaches to that, which is splitting the service components into solution cards, obtaining the best price points per category by aggressive global sourcing policy, and resulting in nimble, multivendor outsources service and solution teams.

In other words, crews that no sane sailor could ever even imagine. And if you could imagine that - which some people do - you could not implement. Why not, you may say? Well, because unlike an (outsourced) IT organization and service components for that, a crew is literally on the same boat.
 If one has a problem, everyone has a problem. A good crew member is paying attention to problems on your boat - and her boat - and not on something else.
So this time all I can say is that good seamanship is out and all I can talk about is Information Technology. Oh how I wish I was sailing....

In Information Technology tasks are atomic. You ask this party to open your firewall, you ask the other party to assign the IPs to your servers, and you ask for a third party to install your application. And if you have other topics - EMC filer shares, LUNs to set up and iscsi shares to configure - you need to worry about those, too.

This surely is not a problem, if you are able to plan ahead without flaw.

If you happen to try and improve and innovate - what then?

Innovation, as everyone since Thomas Alva Edison knows, is 1% inspiration and 99% perspiration. In IT language -. your original configuration is WRONG.

You'll need to change the Firewall. And you'll want to redo you management IPs. Your application and your SAN and Storage will be, err, WRONG.

Now, every development step is a ticketing process, and if your client did the fashionable thing, these tickets will go to separate groups, and you will definitely not be able to just access the DC and do the job.
No, and that also makes sense, since DC is filled with systems that are under SLA, and ultimately the DC production network is quaranteed by SLA to stay up, and they can't let you touch that.

So the customer gets what the customer ordered. If the customer wanted rapid development and innovation - if the customer needed that! - Well, that is not happening.

This is something I've seen now repeatadly. I've found one cure, and that is elastic cloud computing, which eliminates several manual steps in the process above. If you have experienced good ways to evolve systems rapidly in production data centers - please let me know.

Oh, and if you wanted to change your data center and computing infrastructure to something nimbler - I'd like to hear about your approach there, too.