In my experience building and training cross-functional teams, I’ve identified three main principles that apply to both engineering and IT. These principles should be taught to all new hires and adopted by IT leaders everywhere.
Infrastructure principle 1: Build for simplicity
The old adage “Keep it super simple” (KISS) sounds trite but is worth following – no matter how complex your IT system may be.
Would you rather have a clever algorithm that nets a two percent performance improvement or code that is easy to read at 2 am when you’re at home trying to figure out why your site is down? The choice should be clear: Code that’s understandable – especially under less than ideal circumstances – is code that will help you out of a bind and will be easier to maintain, train new hires on, and build upon.
[ Related read: 10 ways DevOps can help reduce technical debt ]
Part of simplicity also means meeting your employees where they are. Companies need change as they scale, but in periods of rapid growth, they must also expand their IT team at a similar pace and create systems that reduce friction as much as possible. An example of these sorts of systems is automating your IT ticketing system.
At Coda, there’s an integration between a Coda doc and Slack to automate IT requests. An employee can ask for help in a designated Slack channel, and someone from the IT team replies with a ticket emoji. That emoji triggers the creation of a new ticket in a triaging and tracking doc and assigns an owner to the ticket based on the type of request.
In this way, employees can ask for help with the tools they’re already using for work without having to complete a form or log into separate software. On the IT side, you’re able to automate tasks that would otherwise be manual.
Remember, it’s critical to continue adapting these systems as your company grows and ticketing volume increases.
Infrastructure principle 2: Prepare for failure
It’s a fact of life that all software fails, and history proves that if you fail to plan, you plan to fail. When you design and test your systems to cascade into the backup plan if needed, many problems can be easily avoided or mitigated.
A classic software engineering example is the system by which on-call engineers access production databases. A well-designed system provides key auditing and compliance mechanisms along with access, but if it goes down, you need a secondary system that is just as compliant with your security policies. Importantly, because that secondary access system isn’t used often, it requires robust documentation and needs to be periodically tested, ideally once a quarter.
[ Also read 4 ways CIOs can create resilient organizations. ]
IT systems, while only internal-facing, should be designed the same way. Approval and escalation processes should always have a backup, playbooks should be written down, and no one person should hold the necessary keys to make changes. If the primary point person is unavailable for any reason, you should still be able to perform business as usual.
Planning for “people” transitions is just as critical. The IT department should always incorporate best practices with documentation and backup plans. This can be as simple as having an on-call engineer when the IT person is on vacation. As your company scales and departments expand, these best practices should also scale. That way, when a critical team member leaves the company, there’s already robust documentation and a succession plan in place.
Infrastructure principle 3: Design infrastructure as meticulously as you write code
Across the board, you should design your internal systems as meticulously as you write code. You would never launch an app without careful planning, seeing around all corners, and addressing P0 bugs. The same should apply to IT.
Treat infrastructure as something as precious 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 configuration be any different?
All changes should have an audit trail so that you can look back and understand who made the change and why it was made. If your current systems don’t enable that, determine which additional tools can help you turn your code into infrastructure.
Be deliberate about your IT system design. If done well, it will save time and money in the long run. And your end users – employees – will have a better experience, with tickets resolved more quickly and fewer things breaking when changes are made.
IT leaders can adopt principles like building for simplicity, preparing to fail, and designing meticulously and by doing so, IT systems stand to reap the benefits. Employees are happier, teams can do their job 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. ]
