Tuesday, January 10, 2012

email jail

I have read, with interest, about quite a few companies that have now banned email.  While I don't think this is something that would work well for all companies, for some, it just may.

Many people have adopted email as their de facto standard of business communication, and it does have a lot of features that would allow you to believe it is good for that purpose.

It does the following quite well these days:

  • Allows you and others to see, use, and share a common calendar
  • Allows you to sort messages into categories, even automatically
  • Allows anyone anywhere to send a message that will wait reliably until you view it, eons even.
  • Allows communication to multiple people at one to time
  • Can cover vast distances in seconds
  • Can be archived and retrieved for as long as it makes sense to store
Unfortunately, every item up there seems to have a corollary.

  • People assume that if your calendar is open that you must not be busy with anything.  Worst case, managing the calendar and attending meetings because you had an open time slot takes the place of working on many of the things you had meetings to talk about accomplishing in the first place.
  • Allows you to sort things directly to trash.  Okay, maybe that belongs in the top list...
  • If you did not, for whatever reason, read the email message in the first few days of its life, its value seems to diminish rapidly.  Storing messages for a long time really only has value to the legal department.
  • Allows everyone to realize you cannot compose a good sentence all at the same time.  Right along with this, allows everyone to realize you always click reply all, and allows everyone to receive the same junk mail you only meant to send to one person.
  • Can cover vast distances in seconds.  Need I say more on this?
  • Storing messages for a long time really only has value to the legal department and government agencies that do not exist.
It is just a gripe if you don't also propose a solution.  Instead of banning email, try to use it better for what it can provide you, and do not let it and the infernal calendar consume your day.

  • If the only way to accomplish things other than meetings is to block time in your week, then block time in your week.  People expect you to take action from email, but they also want you to take action from the times they actually get to talk to you.  Alternately, consider denying some invites, or ask for them for a different timeslot if the topic is important.  Remember that one of your workmates thinks it was important enough to invite you to.  Use the automatic reply to your advantage.  "I am away from email today, and will get to your message in due course."  Set it to only send to a person one time of course.  Only say you will get to it if you plan to get to it.
  • If you find yourself sorting things directly into trash, take the proactive measure to trace down the source and solve the problem that is generating the email.  If it is an automatic process, fix it.  If it is not important enough to fix, then why is it emailing you, or anyone else for that matter?
  • Old mail is probably the hardest thing to manage.  I think an entire book could be written on this, but then you may email the book to your friends, and it might sit in their boxes for too long.
  • This one is simple.  If you cannot compose a sentence, get help.  If you are scared to ask for help, you have already lost.  Nothing will let your workmates know that you are too rushed to pay attention to what is going on around you than a reply all to the email from HR asking people to not use the reply all function unless it is absolutely necessary.  Don't use run-on sentences either.
Anyone out there wish their company was one of those that decided to ban email?


Wednesday, October 19, 2011

misused - part 2

the database administrator

This would be an easy part 2.  I could simply copy and paste all of part 1 as it certainly all applies.  I want to take it just a bit further though, because this one still  baffles me in a lot of respects, in a lot of places.

Through my professional career, I have had the opportunity and privileged to not only meet and work with a good number of DBAs, but also to manage different people in this role over a period of 12 years.  I have come to understand their passion for data, for the query that can turn raw data into useful data, and their ability to manage the care and feeding of data, from the bits laying around on the hardware, through the schema, massaged by the application, and finally displayed to the consumer by which point the data should now be information.

The befuddlement for me is how much a typical organization ignores their data, and therefore the people that take care of it.

After people, this is the next most important part of your organization.

The above is true even if you do not own a computer.  At the lowest level, accounting is data driven, and even if you claim to not be in business for money, you still have to report taxes and keep track of your funding to keep rolling.  Most businesses these days run on data, and it is used in multiple aspects of a successful organization.

If you sit back and realize this, then ask yourself a few questions.  Start with "is my data in good shape?" and lead on to "how do I know it is in good shape?" and "what have I done to ensure its integrity?"

Would it surprise anyone to know there is no such thing as a perfect database?  A database where all the information is accurate, all the indexes are used correctly, and all the integrity is correct? 

It does not exist.

Here is only some of why:

People enter data into databases.

People write code that interfaces to databases.

DB engines at time have bugs and issues, and are evolving.

Integrity checks are an evolving animal.

Schemas are created by people, or sometimes worse, by programs written by people that understand data structures very well, but not your data structure.

Mirroring, replication, clustering, sharding, etc are all evolving practices.

...and the list goes on.

All the above items play together in their own harmony to ensure the perfect database does not exist. 

Do not despair, all is not lost.

You have available to you a very special person or even team of people.  These people live, eat, and sleep data, data structures, database schemas, relations, indexes, engines, and all those things most have only heard in passing.

Much like the systems administrator in part 1, did you invite them to the party, or did you look at them as only a custodian of something tossed at them after the fact with the expectation they keep it running and healthy?

If you fall into the latter category, Why?  It does not have to be that way.  It should not be that way.  IT works better when it is NOT that way.

Bring them into the team up front.  Enlighten them of the problem the team is trying to solve, and be ready to be surprised when they come up with a solution to the problem you have never thought of, or an idea for the team to consider that may change the path of the project and eliminate an obstacle everyone else thought would be the most difficult aspect.  Be prepared to see them as a team member, not a data slinging automaton.

Be an agile leader that allows this to happen.  Remove the roadblocks and the mindset.  You will not regret it.

Be the database administrator that provides input to an entire project team.
 

Monday, October 17, 2011

Misused - Part 1

the systems administrator

All too often in my career, the systems administrator has been the role of the misused. After 20 years of being one, managing many, understanding how they breathe, what they thrive on, and what they are capable of, I can tell you this. The company matters not. The size of the organization matters less. The leadership, ah, there is what matters. A good systems administrator will be a silent type. You never have to hear from them  because they are always behind you, trying to making whatever it is you dreamed up to work. Tirelessly working out its issues, they are; sacrificing time after many have become pillow-fodder.

Why?

They believe this is what their job is, what their roll is in the big picture, and they have been trained and engrained to believe it since about 20 seconds after the computer was invented.

It does not need to be this way.

What if...

...they were an equal member of a kick butt team, able to provide input, be listened to and listen in alike.

...they assist in designing the road that carries everyone forward, pointing out where the path can be straighter and faster.

...instead of being handed something to make work, they have a hand in making it, so it works. Making it so it can be supported. Making it accomplish.

...allow them to do, to make, to attempt, to fail, to learn as a team, on the project, at the start.

You can. It works. I have seen it. I have done it.

If you have a systems administrator, you have, first and foremost, a person. Get to know them. Understand their strengths and what drives them, then tell them where you want to go, not how to get there. Work with them on solving the mutual problem and be amazed at what they know, and what they can accomplish as an equal team member from the start. Consider the following:

Do not ask for "a server". Ask for assistance solving a problem that requires resources and their expertise, then do the same for the network it rides upon. Work together on the design as engineers of network, server, code, delivery, monitoring and those things that are important to the operation of the problem solving solution.

Do not throw it over the fence. It does not matter what "it" is. No ownership will ensue. No digging in will commence. No availability will survive. Nobody will stay around.

Be an agile leader that makes this happen. You will not regret it.

Be the systems administrator that provides input to an entire project team.