2017 wasn’t a great year for IT organizations. Most of the worst crises were self-created. Some were created by other people. In either case, here are six New Year’s resolutions that will help you avoid many of them.
1. Come up with fair and quantifiable ways to judge performance
There aren’t enough women in IT; there is rampant sexism. It is difficult to incentivize and retain skilled workers. Assuming you’re a growing or successful concern, these sorts of statements point to a deeper problem. What is your organization doing to incentivize and retain workers and how is it evaluating and rewarding performance?
Some things are obvious. If your executive meetings are at a strip club, and the boss makes comments about women employees, you have a whole different kind of problem. However, most bias is unconscious and difficult to confront on our own. Bias takes many forms; sexist, religious, racial, and cultural are among many.
By working in technology, you’re saying that you believe in quantifying and using data to make decisions. Why wouldn’t you want to take advantage of that internally?
2. Develop a systematic legacy install review process
In the 1990s, PwC and Andersen Consulting (now Accenture) went around telling everyone to adopt a project-based IT organization structure. Instead of an assembly line of roles with projects rolling through the organization, people were assigned to temporary structures around a specific project. This has advantages in getting projects out the door, and it allowed for outsourcing. But it rarely takes into account the effects of long-term maintenance. It also tends to just ignore any software that doesn’t have an active project around it.
Every software product that an organization manages, whether internal or external, should come up for periodic maintenance. To make the business case, a general assumption should be had that there is something horribly wrong with the software that will be an Equifax-level event. Therefore, each package or custom software should be reviewed and its risks cataloged. The list of CERT advisories should be checked and common development mistakes (SQL injection etc.) should be checked for. Automation should be added where it is missing (i.e. Jenkins).
By adding this review process as its own “project,” we can avoid many of these self-inflicted wounds.
3. Define clear local, cloud, and cloud migration server criteria
Unless financing and managing a large group of servers really is your business, your technology will eventually go to the cloud. There are, however, regulations and rules. These have to be understood. Not all software is cloud-ready; it needs to be repaired or replaced. You need a clear strategy and set of guidelines for on-premises servers, cloud platforms, and cloud migration to make this happen in a disciplined way that reduces risks and facilitates ROI.
4. Create a staff training/development program and include it in the budget
Most modern IT staff training seems to be a side effect of a vendor sales effort. The company buys a product it doesn’t know how to use, and the vendor salesperson sells training to go with it. If the vendor doesn’t sell such a training, ¯\_(ツ)_/¯.
However, your company wrote job descriptions, so you know what each person is supposed to be good at. There are training programs out there that help teach those things. Moreover, there are ways to train and mentor internally, so why not make this into a program?
You can’t justify the cost? What about turnover? Some companies don’t seem to mind turnover as people seek opportunity elsewhere. There is an dubious belief out in parts of Silicon Valley that freshers straight out of school come with new ideas and the magical ability to execute on them. They of course don’t know the difference between a new idea and a bad idea that has been tried before and blew up in everyone’s faces.
Errant beliefs aside, estimates are that replacing an employee costs 90 to 200 percent of their salary. You can prove some of this out yourself: Assume that the average tech worker makes $100,000. A recruiter costs 20 percent, so that’s $20,000. Most people take at least two months (optimistically) to get up to speed (that’s $16,000). There’s $36,000 lost easy. If you start doing all the math, you can find the training budget.
Maybe new employees are an agent of change, but loyal employees are the agents of actual execution.
5. Create a multicloud program and test your cloud applications on it
There are a lot of reasons that you’re going to have to manage a multicloud environment. Many of them center around the preferences and hard-headedness of technical people. However, you should use multicloud for other, more positive reasons as well.
One reason is because a completely dominant vendor will become abusive. You can look at the whole history of IT and see this is true, from IBM’s paternalism in the 1970s and 1980s to Oracle’s Trump-like mercantilism in the late 1990s to the present. However, most enterprises seeking to avoid abusive dominance are like Americans who believe in climate change: We all want to be part of the solution as long as it doesn’t require us to put any effort into it whatsoever.
Another reasons is because vendors that know that you can’t easily leave tend not to negotiate on price. Although not all of the cloud vendors will negotiate, some (like Microsoft) actually will. Getting the best deal means having a strategy that lets you walk away at any point.
Finally, stuff breaks. You may think having things in multiple zones is enough, but that’s a lot of faith in the not very transparent magic closet of elves that run Amazon Web Services. Meanwhile those zones mean something ,and that thing they mean is latency. While latency across cloud vendors may not be great, it may be better than failing everything over to the Midwest because a fiber cut or fire took out one cloud vendor’s East Coast datacenter.
6. If you’re already doing Slack, look into chatops
Despite devops, ops is still as much of a social and cooperative effort as software development is. We’ve seen Jira, GitHub, and other tools integrated with Slack—that’s the path to chatops tools. Like a lot of these sorts of technologies, the benefits are beyond the obvious lists of features and capabilities. Chatops is the sort of mashup that creates a subversive form of social change.
Let’s make 2018 a better year than 2017. Let’s look at putting into place practices that will avoid the follies of yesteryear. At the same time, let’s look to the future and start putting into place practices that make us better, focusing on how we work with both people and technology!