This post is a continuation of my previous post. I thought I’d elaborate on the foundation I have built thus far…
If you are like most engineers, you probably get a kick out of working with technology; taking things apart, seeing how they work and (hopefully) putting them back together again, in one piece.
Okay, the last bit was unnecessary…most of us engineers have never taken things apart as kids, or even if we have, we’ve always put things back together again, as good as new (I jest).
What I’m trying to articulate here is that it takes a very special type of person to be an engineer. You probably aren’t going to be an engineer if you aren’t cut out for it (the training years are laborious enough to dissuade anyone but the most highly motivated individuals).
In other words, it is in our nature to try and find out how things work. Why they do certain things and what the purpose of these “things” are. The world of the Systems Engineer (IT) is a little more daunting than that of the regular engineer (say electrical or mechanical). That is because we have to deal with both hardware and software and try and integrate a multitude of such systems, towards a certain goal.
The purpose of this post is to try and focus on that goal. As good Systems Engineers, we need to understand why we are doing what we are doing. And as a corollary thereof, we also need to understand what the implications of what we are doing are (how do we impact the bottom line).
In many organizations, where the business is not primarily IT, and the culture has not evolved yet to acknowledge IT as a partner (i.e. consider IT to be a cost center as opposed to a revenue generator), this can be hard to articulate. But there are steps that can be taken towards that end. Which is perhaps a topic for another post.
But to the task at hand — let’s look at “Why are we doing what we are doing”:
To be really able to understand the objective of anything, we need to understand the reasons behind it. Some could be super obvious, like why you are putting together an ERP system for your organization (or a Supply Chain Management component, for instance). The ERP system is the “life blood” of your business.
In some other cases, it might be harder to understand. For instance, you are putting together infrastructure for a data warehouse, it would be a very good idea you understand what kind of analytics the business wants to run on this system. In fact, a lot of very useful information will emerge once you start asking questions to understand the role of the system.
- What kind of data are they analyzing
- How many times do they want to run their calculations
- Do they want to run queries against the system at regular intervals
- or do they want to be able to run queries against the system at any time, giving their users access to a front-end reporting tool
- What are the systems that feed data to this system
- What are the systems that the data from this system get fed to (if any)
- What type of model do they want to employ – data marts feeding the warehouse or warehouse feeding the data marts (i’m probably watering it down a lot – here is a good reference .)
- What is the frequency of data load (is it batch or realtime)?
All these questions and host of others will start and it’s a good idea to not assume anything. When in doubt, ask questions. To repeat that old cliché – “There is no such thing as a dumb question”. Sometimes we are not responsible for designing these systems – it still is a good idea to ask those questions and learn.
Mature IT organizations will have high level design documents that cover the business processes supported by various components of IT and at a high level, how data flows between these components. If you don’t have access to this information, ask someone that does. If there is an Enterprise Architecture group in your organization, reach out to them (or do what I do, ask my manager to help me get that information).
If you haven’t tried to understand the “Big picture” before, you will be surprised as to how much a bunch of visio diagrams or power point presentations can tell you (I love pretty pictures – so go suck an egg, those who consider it below their dignity to suffer through powerpoint “death sessions”). Diagrams can tell us a lot more far more efficiently (a picture is worth a thousand words, as that old saying goes) than hundreds of paragraphs of text can.
Having presented that, I would like to bring focus back to strategic thinking now. According to me, it is both an art form as well as a type of particular ideology to adopt. That said, let me present some thoughts about things I consider absolutely paramount towards developing Strategic thinking:
- Learn the Big Picture
- Learn to separate things that are purely tactical from things that can be strategic (or can be addressed strategically)
- Identify engineers (whether in your group or peer groups) who can help you learn and improve your repertoire — develop a rapport with them. I’ve always found it helpful to identify who the “go-to” people were in any organization I’ve worked in. They can help in filling knowledge gaps and as partners to brain-storm with as the need arises.
- Always have the long term in mind (this calls for awareness of how technology is evolving – reading lots of material online helps, so does attending conferences and seminars) – may be, a starting point would be to map the medium term to the depreciation cycle of your organization. A long term could then be 2 depreciation cycles.
- Stay flexible and adaptive – don’t get locked into a particular technology or decision. Keep and open mind. Technology evolves rapidly (far more rapidly than a 3 or 5-year depreciation cycle, for instance). So, while we can’t expect to be at the cutting edge of technological development at all times, it is good to keep an eye on where the world is going to be, when we finally pull around that corner.
- Don’t ever accept a narrative that limits your domain (in other words – don’t let anyone else dictate what you can or cannot think of, wrt technology). Nothing is sacrosanct
- Get into the habit of collecting data
- Develop a set of tools that you can use to access data and analyze rapidly (a tool like splunk is very powerful and multi-faceted. Learn how to use it and simplify your life). Learning how to use SQL with a database (mysql maybe), how to use pivot tables in MS Excel perhaps. They are all valuable tools for data analysis.
NOTE: The list doesn’t necessarily need to be considered in the order presented above.