There’s nothing I like more than talking tech with anyone who will listen, well except maybe actually doing the tech. But talking is pretty keen too. It’s a lot of fun to discuss the new technologies that are emerging, or listen to other’s experiences and issues. Talking tech is something that I think all technology professionals like to do, especially consultants. In the past, having an engrossing technical discussion could also lead to new business opportunities, as the technical leaders in the client’s organization were often the decision makers. While that is still true, the decision makers are increasingly from non-technical areas of the company. It could be someone in marketing who wants to adopt a new web platform for the next major marketing campaign. Or it could be the head of Finance, who is tired of waiting for the IT department to update their aging accounting software. These people have budget to spend, an interest in technology, and no one to talk to. That’s why as IT professionals, we need to bridge the gap.
Have you ever heard an accounting person arguing with an IT person over a technical issue? It’s like the two of them are not even speaking the same language. In fact, even if they’re both using the English language, their words are meaningless to each other. The accounting person is talking about return on investment (ROI), general accounting principles (GAP), and finance controls. The IT person is talking about security patches, IP addressing issues, and firewall rules. It’s no wonder that these two parties walk away feeling misunderstood and frustrated. If someone were able to mediate the exchange and translate the jargon both ways, each party might feel that they have a common goal, and what the challenges are for each party to achieve those goals. Instead too often a request to IT feels like a battle, almost as if the IT department is actively trying to stymie the efforts of the business to improve their process and procedures. Suggestions are shot down, applications take months or years to roll out, and when they do finally launch the applications don’t even meet the business needs of the end users. The end result? Shadow IT and the diminished role of internal IT within the company.
Non-technical folks speak in business terminology, and when they express a business need or requirement they expect that an IT team, internal or external, can interpret those requirements into a technical construct that meets the business need. Designing a solution is often as much about business requirements and goals as it is about technical architecture. After all, you can build an elegant technology solution, but if it doesn’t actually meet the needs of the business then it is effectively useless. Worse yet, it is a waste of resources which never sits well with business people. That’s why whenever I am working on a new solution, I want to make sure I am talking to the project sponsor and the business stakeholders. They know what they need from a solution, at least from a business perspective. Only after gathering the business drivers and requirements do I try to assemble a technical solution. Too often we approach from the opposite end where we let the technology we want to implement steer the conversation. There have been several planning meetings that have a pre-game meeting with just the IT folks and the conversation goes something like, “Alright, we need some additional capacity in our vSphere infrastructure, so let’s oversize the application and try to get some additional capacity and storage out of this project.” The assumption has already been made that the application will run in-house, virtualized, on some array-based storage. Those are some broad assumptions, and possibly totally wrong. We need to go into the planning meeting with an open mind, and walk away with a list of business requirements in a prioritized list. Once the requirements are known, then a solution can be pitched and validated by the business.
Rather than a roadblock or a ferry - stretching the metaphor a bit here I know, we can be the bridge between business and IT. How do we do it? By learning some business fundamentals to be able to speak to non-technical and technical folks alike. I’m not saying you need to go out and get your MBA, but being able to understand concepts like business strategy, core competencies, ROI, and total-cost-of-ownership are key to engaging with the business people in the room. Being able to explain how an all-flash array enables a client to grow their business and improve their bottom line makes an ally out the business team, and helps present IT as a driving force for growth and not just a cost center. So while I would encourage you to go out and sharpen your technical skills, at the same time it couldn’t hurt to read a book on business fundamentals. There are also some great websites that track business trends along with changes in technology. Try occasionally looking at CRN, CIO.com, and BusinessWeek to keep abreast of the business side of the house, and next time you hear someone talking about CapEx and OpEx those won’t just be a marketing line from Office 365.
What's New in the AzureRM Provider Version 4?
August 27, 2024
Debugging the AzureRM Provider with VSCode
August 20, 2024
State Encryption with OpenTofu
August 1, 2024
July 24, 2024