Cool is an Expensive Word for Engineers

Not long ago I made a video about Excel-based reporting. You can read it or just watch the video. The best part, the sexy “Only 3-steps required to update the dashboard”, starts at 5:00, and the updated report is shown at 06:15. ┬áThis is a data-rich, comprehensive report, I call it a Dashboard, and once the whole scope is understood, I feel no hesitation to call it cool!how-cool-is-that

Cool is an expensive word for Engineers. A thing must be quite special for an Engineer to call it cool. Automated Excel reporting is one of them. It was many years ago when I began to appreciate the power of Excel for Telecoms. The first time I used Microsoft Excel was on a Mac in 1989. My first computing experiences had been using UNIX Computers, and once I had even been forced to use a Compaq luggable running CP/M. But I had never before used a Mac. Continue reading “Cool is an Expensive Word for Engineers”

Write it down

Often it happens that an interesting or important detail crosses my desk for which there is no file or folder, or some other ready place to note the knowledge. These snippets come as emails, faxes, documents, meeting notes, conference calls or from my own notebook. It is far too easy to set aside or lose pieces of paper, and the volume of email is so huge even Google struggles to find things. The black hole of email, especially Microsoft Outlook email, is worthy of its very own blog. The flow of paper is a continual reminder how important it is to save the data somewhere and worry about the taxonomy later.

For each piece of equipment I manage I’ve created a separate text document or spreadsheet. In it I record the interesting and essential details for managing that equipment, ways to reduce event impacts, tips and tricks for getting reports and generally making the equipment do more of what I want it to do. I’ve heard this documentation called “paper brains.”

This unstructured input can become large and unwieldy. Eventually some of it may begin to lend itself to a classification scheme. If so, I like to structure it so it can be more easily accessed when it is needed. Either way, having it is better than not having because my memory is so horribly unreliable.

When an equipment outage occurs I try to document the problem and note the details of the repair. You’ll see many of those appearing on this site. This is how I communicate with my colleagues and add to the “corporate memory” for that equipment. Same when troubleshooting an individual subscriber complaint. If the front line customer care folks cannot resolve an issue and it gets escalatated to me, I document the results and share them among my peer group. The document goes into the the online repository for others to access. It is my hope that if I were to get hit by a bus someone else could take up my job behind me without impacting the business too much.