Simple Information Technology Principles

Guidelines For Technical Leaders:  A Network Engineer's Perspective

PDF Version
By Brian Jemes
networkmade.com

Introduction

These principles provide simple and effective guidelines for technical leaders.  They form a stable decision-making framework for navigating the ever-changing landscape of enterprise information technology.  They are especially helpful in times of radical change in organization structure, management philosophy, or technology development.

Technical leadership is a balancing act.  Optimizing in one area usually sub-optimizes another. Therefore, many of these principles are in opposition to each other.  It is appropriate for technical leaders to find these principles leading them to make different decisions depending on differing circumstances, goals, and culture.

When presenting plans and recommendations to business decision makers, it is important to demonstrate direct applicability to immediate business needs, rather than citing these principles.

Information Technology General Principles

  1. Simple is beautiful. (from Jeff Case)
  2. Optimize for customer experience.
  3. Shared infrastructure reduces cost.
  4. Flexibility is required to meet diverse customer requirements.
  5. Flexibility increases complexity and risk.
  6. Risk management increases complexity and reduces flexibility.
  7. Complexity undermines service stability.
  8. Encourage exception requests.  No architecture meets all customer requirements.  
  9. Every infrastructure has an architecture, even if undocumented. (from Kelly McDonald)
  10. Embrace change.  Customer requirements are a moving target, and there is always new technology to be evaluated and integrated.  
  11. Architecture change increases complexity, until fully implemented.

Information Technology Service Principles

  1. Standard Solution Principle: Using standard solutions reduces implementation time and simplifies engineering and operations. Architectures should provide for a minimum (usually small) set of standard solutions that will satisfy most customer requirements.
  2. Standard Exception Principle: When the standard solutions are not sufficient to meet a customer's requirements, it may be necessary to grant an exception.  Minimize future exception requests by implementing each exception in a broad manner that will meet many similar needs.  In this way, exception requests lead to new standard solutions.
  3. Excessive Exceptions Principle: Exception requests should rarely need to be granted. If the exceptions become the rule, create a new architecture that has standard solutions appropriate to most customer requirements.
  4. Customer Behavior Modification Principle: Billing drives behavior. Choose cost recovery methods that reinforce desired customer behaviors.  Discourage duplication of effort by encouraging visibility of total cost of ownership.  Partner with the purchasing, contracts, budget, and human resource groups to encourage accuracy and completeness in tracking information technology spending.
  5. Cost Recovery Principle: Cost recovery should be simple to explain and reflect the actual cost drivers for the service. When cost recovery significantly diverges from cost drivers, “shadow” information technology and duplication of effort will increase.
  6. Self-Service Principle: Eliminate routine engineering tasks with 1) inherent properties of the infrastructure or 2) automation that allows customers to execute well-defined tasks.  Self-service capabilities should be limited to well-defined tasks with an audit trail to facilitate operational stability and infrastructure security.
  7. Continuous Improvement Principle: Minimize service disruption by consistently following up after unplanned outages to 1) understand the root cause(s), 2) re-evaluate processes, tools, and implementation, and 3) make appropriate changes.
  8. Incident Accountability Principle: After an incident, foster accountability and minimize risk of repeating a mistake by assigning continuous improvement and customer follow-up tasks to the responsible engineer(s).
  9. Transparency Principle: (from Dave Lien) Promote partner and customer trust by 1) sharing details about service issues and implementation mistakes and 2) following through with continuous improvement changes to address them.
  10. Keep Partners Close Principle: (from Team of Teams) Stay in close communication with partners, regardless of organizational hierarchy.  This will provide many opportunities to build trust, diffuse grievances, and maintain a common understanding of priorities and issues.  Focus on the teams that send/receive the most service requests to/from each other.
  11. Operational Stability Principle:  Thorough internal team review of infrastructure changes will ensure that changes are well planned and justified.  Prioritize resolution of customer-impacting operational issues over planned infrastructure changes.
  12. Change Freeze Principle:  Minimize outages during critical times in the organization calendar by enforcing an information technology “change freeze” period.   A “change freeze” is not absolute, but rather the use of a more rigorous change review process to ensure only properly justified “high risk” changes are made during this time.  Routine operational changes should not be affected by “change freeze” periods.
  13. Service Relevance Principle: Keep services relevant by routinely improving customer experience, efficiency, and capability.
  14. Common Cause Principle: (from Steven Lovaas) Expand the scope of an initiative when launching a major change.  Identify and include the complementary goals of key partners.  While this will add complexity and expend more resources, it will multiply sponsorship and accelerate implementation.
  15. Service Stability Principle: Promote service stability while enhancing services and upgrading technology by 1) conducting lab and field testing before a phased deployment,  2) funding a test/spare pool of equipment, and 3) supporting flexible work hours.  The best time to conduct field tests and production deployments is typically outside normal business hours.
  16. Proportional Change Review Principle: The change management review process should be proportional to the scope of impact and degree of operational familiarity.  As scope of impact increases, so should the resources spent on change review.  As operationally familiarity increases, resources spent on change review should decrease.
  17. Architect for Change Principle:  Adopt architectures that are independent of specific technologies and organizational structure, so it won’t be necessary to re-design the architecture when technologies and organizations change.
  18. Distributed Access Control Principle: Push access control enforcement as close to the resource as possible. This will simplify management, analysis, audits and troubleshooting. Centralized policy management tools are highly desirable and not incompatible with distributed access control enforcement.
  19. End-to-End Service Metrics Principle: Establish ongoing, end-to-end performance monitoring tools.  This will facilitate: 1) proactive detection of service disruption, and 2) objective service metrics for customer experience and service providers.
  20. Architecture Debt Principle:  Old architectures never die, they just become unfunded necessities.  Be reluctant to adopt a new architecture and always embrace the opportunity to eliminate an old architecture.  It is complex, expensive, and constraining to manage multiple, overlapping generations of architectures.

Information Technology Team Principles

  1. Expert Operations Principle: Minimize information technology staff by investing in tools and people.  Build a small, expert team. Invest in training and tools for experts.
  2. Engineering Productivity Principle: Engineers need stability to be productive. Minimize impact of organizational change on engineers by setting achievable goals and protecting their time so they can complete deliverables.  Only re-assign or cancel projects as a last resort.  
  3. Flexible Work Hours Principle:  Embrace flexible work hours.  Frequently, engineers are expected to work outside business hours (see Service Stability Principle).  This flexibility should be reciprocated.  Support flexible work schedules, as long as 1) sufficient staffing is maintained for operations and support, and 2) changes to work schedules are planned in advance.
  4. All For One Principle: (from Kathy Crowley) When there is an engineer working in the field with a customer, the team should drop everything to make that engineer successful if they need assistance.
  5. Knowledge Sharing Principle: Promote personal and organizational growth by fostering a culture of sharing. Organizations and engineers who share knowledge encourage efficiency and minimize duplication of effort.
  6. Be Your Own Toughest Critics Principle: (from Ramesh Gupta) Before taking a proposal to other teams, do a detailed internal team review.  Be critical and direct, but respectful, with feedback.  Make sure the proposal has been thoroughly vetted and refined before taking it to other teams.  By improving a proposal internally, a team will gain a reputation for proposing well-crafted proposals that proactively anticipate and address issues and concerns.
  7. Professional Detachment Principle:  Take pride in your work.  Be passionate and productive in pursuing an idea, project, or strategy, but don’t take it too seriously.  Avoid the temptation to treat any delay, rejection, or criticism as a personal attack. Always maintain a professional detachment between yourself and your work.
  8. Persistence Principle: Don't give up on important proposals, or concerns, until the directly responsible manager understands it.  Make sure to communicate clearly and by multiple means.
  9. Know When To Stop Principle: (from Dell Fischer) Quit pushing a proposal, or concern, if two levels of management disagree.  Respect the decision.  Don’t become a nuisance. Focus on other things.
  10. Pick Your Battles Principle:  Be a force for positive change by: 1) enthusiastically supporting change moving in the “right direction”, 2) energetically opposing change moving in the “wrong direction”, and 3) creatively minimizing compliance effort with change moving in a “neutral direction”.   It is equally important to minimize debate about alternatives when change is moving in the “right direction.”  Support any path forward as long as it is moving in the “right direction”.
  11. Force Multiplier Principle: Delegate responsibility for important deliverables to an engineer.  This will foster trust and ownership and improve productivity.
  12. Ownership Principle: One throat to choke. Delegating project responsibility to a single technical leader will promote accountability and engagement.
  13. Leadership Development and Retention Principle: Grow leaders from within. Reward top performing engineers with more responsibility and scope in project assignments.  This may increase project risk, but it enhances staff retention by keeping future leaders challenged and engaged.

Information Technology Pendulum Principle

There are decisions for which there is no unchanging guiding principle.  Over time, most enterprise decision making will trend toward one of these extremes until a course correction is deemed necessary.  Then decision making changes to trend in the opposite direction.

About The Author

Brian Jemes began his career in enterprise IT at Hewlett-Packard (HP).  In the 90s, he helped grow the HP Intranet from a research and engineering network into the company’s mission critical enterprise network.  Around the turn of the century, he was the network architecture lead during the massive reorganizations and infrastructure changes that resulted from the HP splits and mergers.  In 2006, Brian transitioned to leading a small network team at the University of Idaho through the "Wi-Fi explosion" in the late oughts and Software as a Service and cloud computing migrations in the teens.

Acknowledgements

This work began in 2016, after Kelly McDonald challenged a group of technical leaders at a Westnet Education and Research Consortium (WERC) meeting to write down and share some of their information technology guiding principles.  Brian had been looking for a way to share what he had learned in his information technology career.  Kelly's challenge helped Brian find a structure that is well-suited to his communication style.

Brian would like to express his deep gratitude for all of the colleagues he has worked with in his career.  He discovered these principles working with them in many challenging and stressful circumstances.  There are too many people to name here, but most of them can be found in his Linkedin connections list.

Revision History

December 2019                        Simple Information Technology Principles                        Version 1.6