Saturday, April 20, 2013

The $100k Door Stop

In my spare time, I enjoy decorating. My sons’ bedroom is decorated in a pirate’s theme and they love it. They are constantly running down the hall between the living room, their play room and their bedroom. At times, you just need to listen for the sound of little feet slamming on the floor or the sound of their bedroom door being flung open and make sure you’re out of the line of fire. I won’t tell you how many times I’ve had to jump out of the way to avoid being run over.

I was thinking the other day that it would be a good idea to get them a door stop for their bedroom door so there would be one less potential casualty in their mission to move as quickly from point A to point B with as few interruptions as possible. Well, I found one. I absolutely fell in love with this door stop. It’s a rope knot doorstop, sold by Ballard’s Design. For those interested, here is the URL:  http://www.ballarddesigns.com/rope-knot-doorstop/accessories/doorstops/10736?defattrib=&defattribvalue=&listIndex=0. The door stop’s price is $45. While that’s not an exorbitant amount of money, I think it’s a little pricey for a door stop, so I’m probably going to attempt a DYI project.

So, how does this in any way relate to technology? Let me tell you about a door stop that costs a tad bit more than $45.
A few years back, a peer, an Architect Manager walked into my office and delivered what I’m sure, he considered a landmine. “I just bought a server that your team will never be able to support.” Having been in the position for less than 6 months, I wasn’t sure exactly how to respond to the comment so merely said, “Great. Thanks.” He turned on his heel, seemingly disappointed at my lack of reaction. Internally, I was cursing life and this dysfunctional boob who was willing to sacrifice company stability for personal reasons.

In that particular instance, this Architect Manager purchased a system that no one in our company had ever supported and on top of that, the only requirement of any sort that was provided was that it be on an operating system that again, my engineers had never supported, Power Linux. That system became a very expensive door stop. It was delivered but no project plan had been developed for the system replacement. Once the business was engaged and a project plan created, it was found that the initial purchased needed an additional $100k or so of additional purchases to support the environment; storage, licenses, training, etc. The system sat for a year before any work was ever even started. 1/3 of the warranty period was eaten up waiting for teams to make plans and implement the solution. An additional six months went by before a timeline could be found to take a business outage. You see, this system was for a replacement of the support of the most crucial application in the company. It housed the largest database in the company. No small fete to replace. A three day outage would be necessary so Thanksgiving was the planned window. Teams across infrastructure, database, application support and the business were necessary for successful implementation.
The end of the story? A year later, the system was not performing properly, was impossible to update, the vendor did not provide reliable and experienced support and the business was again screaming about performance. A full system replacement was necessary in order to resolve the issues. The additional problem this time around? Our credibility was at risk.

This story is the perfect example of why IT purchases have to be scrutinized and considered from multiple views. At the time, no architectural standards existed for server environments. The only standards that existed were for desktops and those were sadly outdated with only a gig of RAM being the standard. You’re probably shaking your heads and wondering how it was possible to operate under such chaotic circumstances. The evolution to stability was not easy and was fraught with changes, both personnel and cultural. Otherwise, your IT purchases become extremely expensive doorstops and your IT department is taking away from your corporate stability and growth versus contributing.
·         First, you have to create, maintain and follow industry best practice supported architectural standards,
      o   By doing this, you insure decisions will withstand scrutiny
      o   You create an environment that is supportable and sustainable
            §  Purchasing systems that have the same core operating system or hardware is a key way    to reduce support cost
·         Next, a heck of a lot of planning needs to take place before hardware delivery is scheduled
      o   Who is going to provide the requirements?
      o   What is the system lifecycle going to be?
      o   How does this impact current business goals?
      o   What other projects are going on and how does this fit in with those?
      o   What is the priority?
      o   Is training necessary?
·         Engage business analysts and stakeholders whose involvement is key to the success of the project AND to the understanding of the application functions. (You may wonder why I added this bullet item because this may seem a natural approach. Some architects assume they understand the business well enough to avoid getting the business involved in the planning and implementation components.)
·         Schedule hardware delivery once you have established how much time is necessary for testing, configuration and training for your team
  o  Protect your precious warranty period (every day the system is in production past the initial warranty is at a costlier warranty level)
·         Allow your teams time for hardware burn-in (Hint:  less than a year)
·         Document baseline performance expectations
·         Document the Support Plan
·         Use both Architects and Support team engineers to plan these steps

I don’t know any business that wants to or can afford a $100k door stop. Maybe that $45 isn’t so bad after all.

Sunday, March 24, 2013

If you can’t count it, it doesn’t count


Early in my career, I worked as a Statistical Analyst. I learned that you virtually live and die by your numbers. I learned that if you can present numbers to back up a discussion, you are a world ahead of those who can’t. So, once I moved into technology and I would hear someone present a case that a system was having problems, I would ask for the numbers or if I were the engineer in question, I would present numbers.
On the other hand, I was sometimes surprised that the numbers didn’t support what I was hearing from end users, which raised serious question marks in my mind about where problems really lay. At that point, deep analysis is necessary to reach the true root cause.

For IT:
While I am an advocate of producing metrics, it is key that IT departments not rely so heavily on the metrics that they forget to listen to the end users. From end users, you may get different messages:
·         The network is slow,
·         The system is slow,
·         My pc is slow,
·         Everything is slow

The reality is, the numbers will tell the true story. That is, IF there are numbers. Mature IT departments, with seasoned Service Management teams, metrics to demonstrate:
·         System availability
       o   Outages due to 3rd party providers,
   o   Outages due to extenuating circumstances,
   o   Outages due to excessive system use,
       o   Outages due to human error,
       o   Mean time to recovery,
       o   Mean time between outages,
·         Percentage of systems nearing obsolescence,
·         Percentage of systems nearing end of warranty state,
·         Percentage of systems requiring patching exceptions,

For a team that hasn’t quite matured to the point of providing full-blown metrics yet, system availability, obsolescence state, warranty state and patching state are a great place to start.

If you’re on the IT side of the house, meet with the business on a regular basis. By doing this, you become someone they are confident is going to listen to their issues.  If you are on the business side of the company and your IT department isn’t providing these metrics, ask why.

For ERM:
When creating or maturing an ERM (Enterprise Risk Management Program), the same can be said for metrics. You live or die by your numbers. KRI’s (key risk indicators) assist a company’s management and/or Board of Directors become more risk aware. The BoD should not be the last group (behind the press) to know about risk issues. Technology risk items need to include those items listed above but also align and support the business risk attitude. Unfortunately, meaningful KRI’s are impossible to manage unless there is a sufficient amount of measurable data.

Keep in mind that KRI’s are ever-changing depending upon a company’s strategy and goals. This may be uncomfortable for those who are of the mind to build a system and then leave it alone – “if it ain’t broke, don’t fixit it”. Key Risk Indicators/factors do NOT work that way.
·         Link KRI’s to a company’s strategy,
       o   This allows for the development and awareness around key risk factors,
       o   Map KRI’s to strategic initiatives,

This allows management to become more proactive in preventing risk issues from occurring by observing metrics,
       o   B e careful that indicators actually provide a clear picture of the risk. Just having a metric doesn’t mean the metric has value.

·         KRI’s create a unique experience to evaluate and communicate the company’s strategy
   o   After reviewing the key risk indicators, it’s possible a company may rethink strategy based upon the risk associated.

Another advantage to an ERM is that focus becomes proactive versus trying to figure out after the fact why a project or system failed. That’s key to the success of a growing company. Think of it as an early warning system that can give you the advantage you need to avoid risk.

If you are having difficulties figuring out where to start, give CGSolutions of Jax a call. We can help you work through the inertia and get to the guts of a reliable and informative process.

Sunday, March 17, 2013

A Mother’s Choice/A Woman’s Choice


I’ve got about 8 IT blog topics documented to write on but this topic seems to be in the news a lot lately and near and dear to my heart. Please keep in mind that this blog is simply based upon my decisions and my hopes/dreams/my realizations of what works for me and my family.
The debate regarding what a woman’s role “should” be and “can” be has been around since I became a mother for the first time in 1982. At 21, I was a fulltime student and a fulltime Intake Specialist at a social agency servicing the blind. The decision to continue working was a financial one. When I had my second daughter in 1987, the decision to continue working was again financial, I was a single parent with two small children.  By that time, I had left the social agency for career growth and to be closer to home. I wanted to spend less time commuting and more time with my daughters.
I was fortunate in that I had a close-knit family and I was able to drop the girls off at my parents’ home before leaving for the office. They rode the school bus to and from my parents’ home. I felt like I had a checklist of items that I needed to have in order to insure my daughters’’ wellbeing.  They were with people who cared about their wellbeing, check. I was still available and engaged, check. My job as an Analyst afforded me the opportunity to work 40 – 45 hours a week and have weekends off. I was able to be a Brownie Troop leader, Sunday school teacher, an advocate for strong curriculum at school board meetings and an attentive mother.
Fast forward six years. I was in IT management for a national law firm (eventually they become international). I worked 50 – 55 hours per week. I was still active and engaged in the girls’ lives but I was also travelling for work at times. As my role increased, my father and I sat down and had a talk. He was proud of what I was accomplishing in my career and wanted to assure me that he and my mother would fill in where needed. My daughters were becoming used to running by the office and enjoyed opportunities such as Bring Your Daughter to Work Day. I made sure I was home at a reasonable time and turned on my pc when needed to work. The downside was the year I was on the road for over six months. I was gone during the week and home on weekends. Luckily by the time the project was over, the girls had only had two meltdowns. I dealt with the meltdowns by taking the girls onsite with me for a few sites. What I learned was that the three of us had an amazing connection and I needed to insure there were no more long projects.
The girls learned to send messages on my blackberry for me if I was in the middle of cooking or working with puppeteers at the Church building. They learned what made a good datacenter. They occasionally slept on the sofa in my office while I worked an issue. None of this impaired them as people.
Later when I worked for a large telecommunications company, one of my daughters napped during an all-nighter anti-virus configuration issue. The girls learned to be flexible. They learned that the hours at the office were what paid for the annual family vacation, cars and savings. I learned their thresholds for my time and attention. They survived a three month project when I worked 80-90 hours per week by a lot of phone calls and notes left on the bulletin board. The one rule I insisted on with my employer was that I would take every Sunday off. The girls and I made the most of our Sundays. They were older and better able to adjust; I was smarter about how I managed our time together and apart.
Fast forward to what seems like another lifetime. My daughters were off to college and a career. I had met my husband and a marriage a few years down the road I was the parent of twin sons. As Operations Infrastructure Director of a growing environment, I was focusing on stabilizing the environment. My husband, never having been a parent before, was relishing his new role. I was relishing having sons for the first time but was also basking in a more secure, stable and available work environment that my team had built. I was torn between priorities but knew I was making the right decisions for my family. My husband’s support was priceless. We were lucky enough to have a niece living with us who needed a part time job. We coordinated her hours so she could nanny and still be a full-time college student. They boys needs were met.
While there were times when I would have an all-night issue with hourly calls and then the next night have a baby that couldn’t sleep, they were not so frequent that they became a problem. More of a problem was the level of increasing stress at the office.  At some point, every professional has to weigh how much stress and its impact on their personal life is too much.
Fast forward a year and a half later. I’m the President of my own company. My sons are in Pre-Junior Kindergarten and excelling. My company is growing and becoming more demanding. I am basically living the dream I never knew I had. My husband and I work as a team with each of us doing what is necessary at any given time. We’ve pushed aside tradition roles and we work from our strengths. Do I feel guilt when I am away from my sons? No I don’t. They are with people who care about them and will help them become better people. They understand that work is necessary to buy “stuff”. We have more time together and its quality time. I don’t want them to sleep on my office sofa while I’m pulling an all-nighter, but it’s possible.
I’m not baking a lot of brownies or cookies these days but I still make a mean green eggs and ham upon request. We have art time as long as I don’t have a deadline but they understand what deadlines are, and how that means mommy has to focus or they have to stay in extended care.
My goal is to raise independent, self-starter citizens who have a strong work ethic and want to make the world a better place. I want them to understand self-control and self-discipline. Most importantly, I want them to know they are loved. I know I was successful with my daughters. I am confident my husband and I will do that for our sons. For my family, for myself, ultimately, the choices have worked.

Sunday, January 27, 2013

Low Hanging Fruit for securing your data

I recently met with a small business (SB) owner who was almost hyperventilating over the challenges of becoming PCI Compliant. To him, this was a hardship created by the government to make small business owners’ poorer, while putting more money into the pockets of big business. Initially, we simply talked about the Who and Why around PCI Compliance. Next, we broadened our discussion into his individual business needs and goals. We then translated these into a comprehensive plan for securing his environment in a manner that supported these. He came to understand that this did not have to be a six-figure plan to put some basic pieces into place with a quick turnaround and quick return on investment.

Who and Why of PCI Compliance:
For a SB owner, throwing the whole catalog of 12 steps to securing your environment is overkill. Unless a business processes over 20,000 credit card transactions a year, the requirements published by the PCI-DSS (standards group), are much more simplistic.
·         Don’t store ANY credit card data in your environment,
·         All transmissions should be on PCI-DSS approved devices,  (list available: http://www.cgsolutionsofjax.com/images/approved_pin_transaction_security_PED_Devices.pdf)
·         Fill out and submit Attestation paperwork annually.

Why being just PCI Compliant is not enough:
PCI standards are “minimal”. The interpretation of the requirements is even debatable depending upon the size and complexity of an environment. A seasoned “IT-savvy” Assessor will understand the difference between creating a program that basically just checks items off a list and a program that takes a meaningful and layered approach to security, while providing for PCI Compliance.

Reviewing Individual Business needs:
Whether a business is in a static position, growth mode, or facing the unfortunate position of losing market share, the SB owner needs to take a holistic approach to managing security and the potential liability surrounding a potential data breach.
·         What is the investment?
·         What is the Return on Investment (ROI)?
·         In the event of a breach, what is the business’s potential liability?
·         What is the cost of potential downtime?

Any investment, whether it is for technology, security, or other, should have an established timeline for an expectation on return. For small businesses, there are a number of investments that are necessary in order to insure data protection.

Low Hanging Fruit that will go a LONG way to helping secure your environment:

·         Antivirus/Malware

o   For antivirus, purchase multiple year licenses.

o   Have an individual join groups such as Secunia or the SANS group to receive notifications from antivirus and software vendors on outbreaks or potential vulnerabilities.

·         Desktop management support/warranty

o   Use built-in tools to restrict employee’s access to sensitive data, to questionable websites, to pop3 mail accounts.

o   Disable the ability to capture print screens for those employees who have access to sensitive customer or patient information.

o   Purchase desktops through a reputable partner who will provide desktop support in the event of a hardware failure.

·         Copier security

o   For leased copiers, insure the hard drive has been wiped, in a secure method, approved by the Department of Defense, prior to returning to vendor.

·         Printer security

o   Define who can print to what printers. Allow a limited number of employees to manage print jobs.

·         Paper security

o   Create a clean desk policy and either, purchase a shredder or, lease a shredding bin from a reputable vendor.

·         Social Engineering and Information Security training for employee

·         Mobile Device lock down (to include USB devices)

·         Business Continuity/Disaster Recovery solutions
The SB Owner I was speaking with had a small environment, but the general consensus by desktop support companies is that when a company has more than 10 desktops, the need for professional desktop support becomes pressing; the reason being that automation becomes key to reducing labor costs.

At CGSolutions, we have:
·         A library of sample policies and procedures that will get you started,

·         Templates that can be applied to your desktops to secure your corporate environment,

·         Business partners who have expertise in desktop support, including in regulated industries,

·         Partnerships with internet providers who focus on your current and future business needs, 

·         Partnerships with managed services teams.
Don’t let the fear of what you don’t know get in the way of being successful in your business. CGSolutions can help you bridge the gap between where you are and a secured environment. With over 28 years of experience in technology, we have the expertise to implement meaningful solutions versus those that simply check a box on an audit report. Give us a call, 904-654-7323.

Monday, January 7, 2013

Improve your FFIEC Exam Scores


The Office of the Comptroller of the Currency (OCC) takes a risk-based approach to bank operations. As a bank’s deposits go up, so does the risk associated with their operations. No one wants to get a bad score on their annual OCC exam and there are definite ways to avoid it. After all, the purpose of these exams is to protect consumers and consumers’ assets.

When I prepared for my first OTS (since then responsibilities rolled to OCC), I went to the FFIEC website to go over the IT booklet. I had actually worked on a remediation project prior to my managing an OTS audit so I was familiar with the power of the scores.  If you’re not familiar with the individual scoring process, the scale is 1-5 with 1 being the best and 5 being the worst.

The exam covers the following areas:
·         Capital Adequacy
·         Asset Quality
·         Management Competence
·         Earnings
·         Liquidity Risk
And Composite

I am not a banker nor am I an OCC employee. I am a technologist who has been responsible for the areas Operations, Business Continuity Planning, Management, Outsourcing Technology Services and Information Security (OTS wording) which fall under Management Competence and Composite. These are the areas I can provide expertise in.
To start, you should review your last report with a focus on:
·         Where do you need the biggest improvement?
·         What can YOU have an impact on?
·         Be aware of the bank’s asset balances and what that means to the OCC. If your bank is in growth mode, the last thing you want is for your areas of responsibility to be the causation of disapproval for expansion from the OCC.

The OCC relies on several Standards Setting organizations for their guidelines so if you are focused on Best Practices, the chances are good you’re on the right path. You may just need some formalization.

What were the documented Management Responses in the last report? Pay close attention to the management responses. Regulators do not like repeat items that have had no or insignificant progress made toward resolving open issues.

Next, download or designate someone to download the FFIEC IT handbook. The guidelines provide an excellent source for what policies and procedures you should have in place as well as where financial institutions should be focusing their security resources. A few things to keep in mind, regulators prefer to see formal plans with commitment dates and approvals from Executives to meet those dates. I really suggest you designate a specific person to oversee the remediation focus. This person should be aware of who is the assigned go-to person for each of the areas of responsibility documented in the handbook.

To further the progress,
·         Create a matrix that includes each line item, the potential cost, required effort and resources required. Also, include the potential risk of NOT remediating the item. The bank may choose to accept or transfer the risk associated with the line item versus attempting to remediate.
·         Get executive acceptance and sign-off.

To get ahead of a potentially poor Audit score, review your policies and procedures, Service Level Agreements, Operating Level Agreements. At a minimum, you need to have:
·         Employee acceptable use policy for technology systems and devices
·         Documented existence, adherence and review of technology policies and procedures

o   Change Control policy,

o   Incident response,

o   Privileged Account use,

o   Patch Management process,

o   Data access report reviews,

§  Focus on your key control points

§  Are there designated Information Owners who review data access?

o   Exception review procedure,

o   System Availability Reports

§  Problem Management Action statements and reviews

o   Software Architectural framework

o   Standard architectural review documentation

§  Are security and risk protocols a regular part of the architectural process? If not, this should be a high priority.

§  Have standards been implemented to reduce human error and silo’d decision-making? If so, this should be a high priority.
·         Technology Risk educational program for both business and IT employees.
·         Documented reviews of roles and responsibilities
·         Reports for new hires and terminations
·         Secured system access reviews
·         Have you had an outside firm perform a Penetration Test? There are multiple layers to pen testing but they really are the best way to ascertain if you have any open holes that need to be plugged.
·         There need to be documented and tested business continuity plans. There needs to be two types of plans. 1) Business Continuity, 2) Disaster Recovery. While the business is responsible for collaborating with IT through these tests, it has to be the IT team that drives these areas. While the business may know what to restore, the IT team knows the “how”.

If you can create a Risk Management framework or program in your bank, you can turn your 3’s into 2’s and perhaps even a 1. The unspoken benefit of a Risk Management program is an awareness of potential risks that sit in the back of an employee’s mind and hopefully will deter security risks.

Friday, December 14, 2012

Lessening the impact of a DDOS Impact


Bank robbery used to be simplistic. People, in masks, walk in with guns, real or pretend, and take whatever money was in the local vault. Unfortunately, the first warning anyone got that there was about to be a robbery was when the robbers burst into the bank in ski or comic masks. Today’s “robbers” don’t have to walk in the doors to be effective. They can sit comfortably in their living rooms with their feet propped up and commit crimes that undermine consumer confidence and a financial institution’s reputation in moments.
From a technologist’s standpoint, the technology behind the DDOS (Distributed Denial of Service) attack is brute force in nature. The attack’s target is internet facing servers that accept a certain number of connections and can then be overwhelmed by too many connections; basic and easy to perform.

There are steps you can proactively take to lessen the potential attack. These require:  

Planning

  • Banks with established incident response teams have a greater opportunity to control the impact of a denial of service attack.
  • Teams should rehearse an attack and the planned response
  • Teams should have assigned roles and responsibilities with multiple methods of contact
  • If a bank is a consistent target, perhaps cyber insurance should be considered.

Communication

  • Banks need to decide who will be the liaison with the FBI Cyber Unit, Homeland Security and any other security agencies that manage cyber incidents.
  • A phone tree should be created with security, legal, compliance, marketing or Public Relations and technology individuals who have actionable roles.
  • A plan for communicating with customers in some other method than through the public call center numbers should be established.

Active monitoring

  • Internet providers have tools that monitor traffic 24/7. Servers have tools that report the number of connections, whether it’s successful connections, waiting connections or failed connections. Metrics should be easily available that reflect normal traffic for the time of the month and day. There may be occasional outliers but for the most part, traffic is somewhat predictable. A rise in connections could be an attack beginning. When IT staffs see this type of increase in traffic, it should be investigated and preventative measures taken to avoid an attack completing shutting down the bank’s websites. 
  • If a bank does not have the type of active monitoring discussed then they should consider using a 3rd party to either a) host their web servers or b) implement monitoring for the bank.
  • Monitoring the web server interfaces will again offer insight into predictable traffic patterns. Outliers should be considered potential signs of an attack.

Training

  • Providing employees with training on how to detect an attack will go a long way toward lessening the potential impact.
  • Providing customers with training on ways to recognize potential malware that could launch an attack will also help.
  • Create two-factor authentication requirements and train customers on the need to have separate passwords for their banking environments and other browsing needs.

Successful patching program

  • Although a bank can’t do a lot to avoid zero-day exploits that have yet to be realized by the security company, a number of institutions are lax in their patching processes. Windows servers are no longer the lone targets. Teams can underestimate the hypervisor environment’s potential payload and with many institutions using virtual environments to lessen the physical server overhead, this is a potential gold mine for Trojans and malware.

If a bank is a target of a DDOS attack, the chances are there will be some impact. Following the steps above are designed to lessen the potential impact.

Friday, December 7, 2012

Ode to Doug Woods


 
 Over the years, I’ve had some interesting work experiences. You can’t work for thirty years without having some great experiences and some – not so great. OR, you could do as I have done – and wonder – is it the situation or is it me? My preference is to think – it’s the situation. I say that rather tongue-in-cheek as people that know me, would understand.

I met Doug Woods after I moved to Jacksonville. I was working as a consultant on an Active Directory project that resulted from a less than glorious audit finding. Doug’s career had traversed the development focus in the banking/mortgage industry. As a consultant, I was only exposed to him in progress meetings.

My first observations were that Doug was quiet spoken and exuded authority. I later found that he was a seasoned professional who asked intelligent questions and quickly got to the point without a lot of rhetoric. Little did I know at the time, there were a lot of changes going on in the department. At the end of the Active Directory project, I would go from being a consultant to being the Director of Operations Infrastructure. That’s when I learned about the man, Doug Woods.

Doug was a cowboy at heart. I don’t just mean someone who rode a horse and wore a cowboy hat and boots. Doug did do those things but he reminded me of the cowboy heroes that could be counted on to always try to do the right thing. Doug grew up in Oklahoma so I am guessing hard work was in his backbone; it definitely seemed to be. I’m not going to try to make Doug out to be an all-seeing, all-knowing super-hero. He was not a saint and he had his faults. If I tried to state otherwise, he would smack me on the back of the head, much like Gibbs in NCIS. I’m sure he could do it, all the way from heaven.

What Doug did do was allow people to work within their strengths. He allowed for the fact that no one person can know everything and not make mistakes. He had a phrase and a tone that I remember to this day, “That’s not good”. While he said that in an even tone, you could feel the disappointment wash over you. It’s not that Doug ever withheld direction from you. He expected you to put forth your best effort and if he suspected you had done less than that, you knew – he knew. I’ll never forget getting a call from him on my way to the office one morning and an invitation to meet him at Starbucks. I’m certain Starbucks lost money when Doug passed away. I didn’t know at the time that a morning invitation to meet at Starbucks was his way of having a conversation that didn’t place you in the formality of being in the CIO’s office. I appreciated his grace and thoughtfulness. I had many Starbucks meetings with Doug over the years we worked together. Some were to discuss problems in the department, some to talk about strategy and focus. Those meetings were when personal details came to light and I learned to appreciate the man Doug Woods was.

At some point in his life, Doug had the wisdom to learn patience. I suspect patience was not in his initial makeup. I know it certainly was not in mine. I had and still have an impatience for people not putting forth their best effort. Doug helped me temper that impatience though and become more understanding. Doug and I shared an empathy for people.  We shared a belief that people should be truthful in their dealings and a handshake or an agreement was golden. I’ll admit Doug and I both experienced disappointments when dealings didn’t turn out that way.  Doug had been in the business world long enough to believe you hold people, whether they be employees, peers or vendors to certain standards. He wasn’t blind to people’s shortcomings but was tolerant and gave people the opportunity to make amends. He treated vendors like partners but knew how to get the best possible deal. He was always willing to be a reference for vendors and gave a lot of them opportunities to grow because of his support.

Doug was a gentleman who had a respect for women that I appreciated. Women in technology are a minority and having worked in technology for over twenty-five years, I had been met with prejudice and discrimination on many occasions. Doug asked my opinion and for my expertise in infrastructure many times and appreciated my willingness to tell him when something was outside of my area of expertise.

An open-minded manager, Doug encouraged open conflict in an effort not to stymie the creative process, but also knew when to put the brakes on to keep the discussions from becoming personal. At times, he would cut through the postulating and territorial behavior to find common ground. His expectation was that everyone would work together to find the best possible solution for the business. If anything was his undoing, it was his underestimating the ferocity of people stuck in their ways.

It’s been three years since Doug Woods passed away from cancer. He fought his cancer with a quiet strength that spoke of the way he lived. He is sorely missed.