In my experience building and training cross-functional teams, I’ve identified three key principles that apply to both engineering and IT. These principles should be taught to all new hires and embraced by IT managers everywhere.
Infrastructure Principle 1: Build for Simplicity
The old adage “Keep it super simple” (KISS) sounds corny but worth following – no matter how complex your computer system.
Do you prefer a smart algorithm that improves performance by 2% or code that’s easy to read at 2 a.m. when you’re at home trying to figure out why your site is down? The choice should be clear: understandable code – especially in less than ideal circumstances – is code that will help you out of a bind and be easier to maintain, train new hires, and develop.
[ Related read: 10 ways DevOps can help reduce technical debt ]
Part of the simplicity also means meeting your employees where they are. Businesses need change as they scale, but in times of rapid growth, they also need to expand their IT team at a similar pace and create systems that reduce friction as much as possible. An example of these types of systems is the automation of your computer ticketing system.
At Coda, there is an integration between a Coda document and Slack to automate IT requests. An employee can request help in a designated Slack channel, and someone from the IT team responds with a ticket emoji. This emoji triggers the creation of a new ticket in a sorting and tracking document and assigns an owner to the ticket based on the type of request.
This way, employees can request help with the tools they already use for work without having to fill out a form or log into separate software. On the IT side, you can automate tasks that would otherwise be manual.
Remember that it is essential to continue to adapt these systems as your business grows and ticketing volume increases.
Framework Principle 2: Prepare for Failure
It’s a fact of life that all software fails, and history proves that if you don’t plan, you plan to fail. When you design and test your systems to integrate with the backup plan if needed, many issues can be easily avoided or mitigated.
A classic example of software engineering is the system by which on-call engineers access production databases. A well-designed system provides key auditing and compliance mechanisms as well as access, but if it fails, you need a secondary system that is equally compliant with your security policies. Above all, because this secondary access system is not used often, it requires solid documentation and should be tested periodically, ideally once a quarter.
[ Also read 4 ways CIOs can create resilient organizations. ]
Computer systems, even if only inward-facing, should be designed in the same way. Approval and escalation processes should always have a backup, playbooks should be written, and no one should hold the keys needed to make changes. If the primary contact is unavailable for any reason, you should still be able to work as usual.
IT should always incorporate best practices into documentation and backup plans.
Planning for “human” transitions is just as essential. IT should always incorporate best practices into documentation and backup plans. It can be as simple as having an engineer on call when the IT guy is on vacation. As your business evolves and your services expand, these best practices must also evolve. So when a critical team member leaves the company, solid documentation and a succession plan are already in place.
Infrastructure Principle 3: Design infrastructure as meticulously as you write code
Overall, you should design your internal systems as meticulously as you write code. You would never launch an app without careful planning, seeing every corner and fixing P0 bugs. The same should apply to computing.
Treat infrastructure as valuable as software. No seasoned engineer would find it acceptable to log into a production machine and change code on the fly outside of an emergency – why should your IT setup be any different?
All changes should have an audit trail so you can look back and understand who made the change and why it was made. If your current systems don’t allow this, consider what additional tools can help transform your code into infrastructure.
Be deliberate about the design of your computer system. If done right, it will save time and money in the long run. And your end users (employees) will have a better experience, with tickets resolved faster and fewer incidents breaking when changes are made.
IT managers can embrace principles such as build for simplicity, prepare for failure, and design meticulously, and in doing so, IT systems will reap the benefits. Employees are happier, teams can do their jobs more efficiently, and when things go wrong, there’s always a plan.
[ Discover how priorities are changing. Get the Harvard Business Review Analytic Services report: Maintaining momentum on digital transformation. ]