The question I get most often about my career is “how do you have a position in technology management without a background in technology?”. It’s been my experience that most business management people are in my shoes, they have some sort of a business/accounting/finance background and not a development/engineering background. So how do you add value without having a degree? I’d argue that a degree is a good indicator of knowledge when you are 22. When you are 30, you can be expected to gain knowledge through other avenues. That accumulated knowledge is even more valuable to an organization.
Of course none of this applies is you just want to be a numbers monkey. If that’s the case, this site probably isn’t for you. Let’s get into a high level roadmap for those that want to actually help shape the org.
The basics:
The very low end of your expected knowledge basic starts with simple concepts. Do you know the names of all the major applications? I say “major” here are some companies have thousands of apps. Some are so small you don’t even hear about them until you’ve worked there for a few years (and something has gone wrong with them). Do you know the basic architecture of the technology stack? You should be know the flow between applications. Do you know what all the acronyms mean? Every firm has their own acronym language. You should know this. People love to give apps “clever” names. You should be in on the joke. You should learn the basics within the first 60 days on the job. If it takes you longer than that, you aren’t trying hard enough.
The next level:
You are now able to sit in a meeting and not ask the dumbest questions in the room. So what’s next? What language are your applications programmed in? Yes, you may not know how to write a single line of code but you need to know if it’s a Java or C++ application. This will help you understand the staffing requirements and why certain applications are more expensive than others if you try to change them. What type of hardware does the application run on? You should know if it’s Linux/Windows (god forbid Solaris). This help you understand the front to back requirements to run the app. What are your developer tools? These days, the tools that help your developers be productive are some of the most important investments you can make. What do your programmers use? Why do they like/need them? Are there better (or cheaper) alternatives in the market? The good news on this one is that likely your developers will bring these to your attention. Have you built those relationships? What’s the company’s DR strategy? This can drive costs and hardware choices. The next level is not an exhaustive list but should happen within the first year.
Beyond:
The final stage is too large to be written here. You’ll spend your entire career building this knowledge base. Do you know trends in the market? You’ll need to keep up with peers and what your competitors are doing. This should be an active part of your career. Are you benchmarking not only costs but other value metrics? This can be as simple as Gartner or as involved as a bespoke study. You should use this data to help make recommendations. Not change for the sake of change, but change to drive business outcomes. What’s your strategy around the use of new/unproven technologies? Clearly you have to know and understand the incumbent technology to be involved in these conversations. You’ll have to understand the risk appetite of the company and your ability to absorb change. The list goes on forever.
The quicker you develop these skill sets and add it to the knowledge about your business, the more successful you will be. So what’s holding you back? Afraid to ask “dumb” questions? Don’t be. I’ve found that people love talking about their jobs. Take a few people out to lunch or just swing by their desk and ask away. They are paid for the knowledge as well as their production. Tap into that on a regular basis. Don’t let your insecurity hold you back.