Having helped many friends and family members get into IT using the knowledge gained from many years working in IT. I created this website to help others get into IT.
19 IT career path advice tips for success in 2019? So, I've compiled a list of the 19 tips I think are essential for IT, including many types of roles and jobs that people interested in IT should be looking at.
The cloud is a big area in IT that's getting bigger and bigger. Amazon's AWS (Amazon Web Services), Microsoft Azure and Google Cloud are all big players in this area. Many organisations area adopting a cloud first strategy, that is anything they build, they are building for the cloud and not for traditional data centre. So there's plenty of building and migration work going on.
Many predict 'Cloud First' will be replaced by 'Cloud Only' where nearly everything will be moved from traditional data centres to the cloud, making many of the data centres redundant and creating an abundance of cloud jobs.
With new regulations coming in such as GDPR (General Data Protection Regulations) and the associated fines for not conforming with their requirements, along with the push to build and move into the Cloud, securing IT systems and services has become big business. The demand for security professionals has increased markedly especially in the area of Cyber Security.
Cyber Security is about protecting data by ensuring at a minimum are enforced and managed correctly:
Other areas contributing to Cyber Security include Risk management, Network Security, Incident Management, Monitoring to Training and Awareness
Putting in protections against attacks is Cyber Security, but how do you carry on if you're already under attack? This is where Cyber Resilience comes in and is a rapidly emerging area, especially as many organisations have experienced attacks and not been able to carry on operating during the attack or after having been attacked.
Cyber resilience is putting in measures to be able to deal with such scenarios, scenarios from Denial of Service attacks, viral/malware infections
Project Management Office is a function which ensures project management standards are consistent across a number of projects. By using agreed business processes, project principles, project practices and project templates, different projects can work the same way and more importantly report back status information which is easily usable as comparison to see how projects are comparing against each other.
Many PMO roles involve tracking the overall status of projects through data gathering (i.e. meeting regularly with project managers to get status updates) and providing reporting on project status to management. Project Portfolio Management (PPM) is another area where roles in PMO look at resource forecasting for various projects including how resources are financed by projects, again creating reports of these for management.
Agile is a project methodology predominantly taking over software development. Scrum is a subset of Agile providing a lighter framework for development and consists of three different type of roles:
(a) Product Owner
The Product owner is a person who represents the business and works with them to determine the product features. The product can be software, so a new payroll system would require the Product Owner to work with Human Resources (HR) to determine what the features are. The Product Owner will have a good understanding of what the 'product' is being developed, how it's going to be used and it's this vision that they will feed to the scrum team.
(b) Development Team
The Development team will not only consist of the software developers who will create the 'product' but also the testers, DevOps engineers and all other participants required to bring the 'product' into existence.
(c) Scrum Master
The Scrum Master has the power over the process to get the 'product' developed, so working almost like a coach to get the team to work to the vision and the values of the team and the Product Owner. Some people think of the Scrum Master as a Project Manager but whilst there maybe some shared qualities between the roles, the Scrum Master is distinctly different on many different levels.
I learnt Python, not fully or to an expert level but just the basics of the structure and the same with Terraform (not really a language like python, more a set of declarative statements). With python I learn how to import libraries, create functions, decision logic (if then else) and so on using my own project to read web data (from web pages) and analyse the data and then present the information I needed. Over the weeks, I tried more and more capabilities of Python and now I am fairly capable of using it including in administrating AWS Cloud services using AWS CLI and also creating AWS Lambda serverless functions.
What I didn't do was try to do and a to z approach of learning and doing a course, as most of the material learnt wouldn't be useful in the real world and would therefore be a waste of my time, which is limited with a full time job and family life to contend with.
Python is an easier of the languages to learn and it's widely used in the Cloud (e.g. AWS) and Machine Learning (Artificial Intelligence) and Data Science. It's not a skill that can guarantee you a job as a Python developer when you have little or no commercial experience of using it but it does give you an additional skill to add to your bow to increase your overall chances of getting a job in IT.
Ever thought about contracting instead of going permanent? Instead of getting a salary, contractors get paid a rate, be it an hourly or daily rate. For example DevOps contractors can a lot of money a day, I've seen £900 a day (that's £198,000 a year based on 11 months a year worked with 20 billable days a month minimum) whilst as permanent staff a salary of around £100,000 a year.
Contractors generally get paid more than permanent staff at the expense of not having the same benefits as their permanent counterparts like holiday pay, sick pay, employer pension contributions.
With less experience, sometimes it's easier to get hired as a contractor than go for a permanent job, simply because contractors are hired for the short term to fix problems and not for the long term where they would need to align themselves to the company culture, including company politics, appraisals, personal development plans and be able to
I got into contracting by mistake when the job market for permanent employees at the time wasn't great and I needed an income to survive, so took anything that came along with the belief it would only be temporary. Here I am many years later contracting, with no plans to ever go back to permanent employment ever again.
I've picked up more skills during my contracting time and progressed rapidly from IT support to IT engineering to IT architecture, learning from a myriad of companies in so many different industries including Government, Health, Pharmaceuticals, Banking, Utilities, Education, Insurance to Travel. Contracting has also allowed me to work in Europe and experience different cultures in places like the Netherlands, Germany, France, Switzerland and Ireland.
Contracting is a good way of working because so many people are scared of contracting. The uncertainty for them makes it difficult to leave their comfort zone of permanent work, just like I was once. This creates a lot of opportunities with limited competition and even better still contractors don't tend to appear on company financial figures as a 'head count' so when a company has to cut back on their 'head count' then they tend to get rid of permanent members of staff, consolidating the lost roles into less contractor roles.
DevOps is the new mantra in getting software built quickly and released by using automation, so from a single click to start building software can automatically go through a number of steps:
(i) Developer decides to push code (software they've developed on their computer) to the software code storage area, a central source code repository (repo for short);
(ii) Code checked for security issues using Static Application Security Testing (SAST);
(iii) Code is combined with code dependencies (e.g. Jave Run-time) and a container to form a build image;
(iii) Vulnerability checks done on build image for flaws;
(iv) Build image has Smoke, Unit and Integration tests performed on it;
(v) Run Dynamic Security Application Testing (DAST);
(vi) Push image to registry and tag image as ready for production.
There are controls around the how the initial step is done to stop unauthorised or malicious software code being deposited into the repo. The repo has the ability to determine when new code is added and can automatically call to start the next step.
Further steps can be initiated to actually move the build image into a 'live' production environment for us, as part of deployment process. The whole process is categorised as CI/CD, that's Continuous Integration (CI) and Continuous Deployment (CD). With the CI being roughly the steps (i)...(vi) listed above. The Continuous Deployment being the step to take the artefact, that is the output of CI, into a 'live' production environment. CI/CD is automated but can be manual or a mix of automated and manual but the full benefits of running an automated pipeline might not be realised.
The DevOps engineer will be responsible for managing the CI/CD environment with the software developers responsible for developing the code used for the software being released.
Watch out, there's a lot of automation in this area, so DevOps people may inadvertently put themselves out of a job!
Just for my 2 cents, DevOps is really just the about improving the release of software (including virtual infrastructure) by optimising the processes and removing bottlenecks. So it's more than just technology, its the people involved and if those people are a bottleneck in the way they work, then to improve things they must be challenged to work in a different note effective way. Phew, I feel better getting that off my chest :-)
DevSecOps or SecDevOps as some people call it, is about adding security into the build and release mechanisms such as a CI/CD pipeline (pipeline just means a serious of sequential tasks). Security tends to be automated to ensure it's uniform all the time, that is it's the same security tests applied every time software is built and released.
DevSecOps engineers are involved in setting up the code analysis tools that can do the Static Application Security Testing (SAST). These SAST tools like SonarQube analyse the code submitted by the software developers and code submitted by DevOps for infrastructure development (Infrastructure as Code - IaC such as Terraform, Ansible, AWS CloudFormation) and checking for any security issues or errors. Issues such as SQL Injection, hard coding passwords in code and so on. Dynamic Application Security Testing (DAST) will also be done where the completed application is tested using a serious of dynamic tests such as running through authentication checking steps, checking authorisation works, checking fuzz logic on functions in the application.
DevSecOps engineers will also ensure vulnerability management and patching is being done. So if there are servers in the infrastructure used for the development of software, the flaws in these need to checked and remediated. If container images are being used, then because these are immutable, they will need to be rebuild, that is new container components used and the container image rebuild using the CI/CD pipeline.
One of the places I worked at, I was chatting with one of my colleagues about how they got into working as a Business Analyst and I expected them to say they had gone to University, got an IT related and degree and then got an internship to do Business Analysis. They said they hadn't been to University and had changed careers into becoming a Business Analyst. They were really good as a Business Analyst as well as being very disciplined and well organised.
So what does a Business Analyst do? They work with the business, i.e. the different projects from different departments, e.g. a new payroll system required by Human Resources (HR) and they work what their need is, that is their requirements. More on what requirements are can be found in my free course free course.
They also work how the processes will work and create flow diagrams to show this, for example, the process of running the payroll payments they will probably add:
(i) the different people involved;
(ii) all the systems involved;
(iii) the interactions between the people and the systems.
This is a simplistic list but the picture below provides a more detailed view:
My opinions of certifications has changed somewhat in the past few years, before I believed to become certified without any real job experience was trying to cheat the system but now I think some certifications are essential to prove at least you have the aptitude for the job in question.
If you're already in IT, then certifications will produce a diminishing return, as the more you spend the less likely you are to benefit from the certification. Employers tend to look more for experience as a distinguiser between candidates and certifications are just seen as a minimum requirement. Some people will try to use IT certifications to try and enhance their chances of getting into IT when they haven't had the relevant IT experience, like the ones who do a CISSP but have absolutely no security experience. These people will struggle to come in at this higher level of certification, they'd be better getting an understanding of something like the Cyber Security Essentials published by the UK government and stating they've studied this on their CV.
When I was at school, I was always told by my teachers,
'You have to be a master in one trade instead of a Jack of all trades!'
How wrong they were, it's better to be a Jack of all trades, as having multiple skills can help move you into better career paths. By getting a basic grounding in a number of areas, it can become easier to sell your skills. Today IT requires more than just knowing one area but a broad range of skills. These skills don't have to be known at an expert level just a basic grounding. I have a grounding in Software Testing, Citrix Introductory knowledge, User Acceptance Testing, Quality Assurance and Quality Control and I use this as part of my pitch when I'm looking for work.
Once you have a grounding, you can then decide which of these skills you would like to delve deeper into and this may depend on skills which are in high demand.
Generalist careers include some elements of architecture like Solutions Architects, Enterprise Architects, who cover a wide stack of technologies but aren't necessarily experts in any of those technologies. I think, if you're already in IT and want to transition into Architecture then understanding a framework (way of doing things) like TOGAF or Scaled Agile Framework (SAFe) might be a good career move.
Try to avoid saturated IT career paths as this is vital for anyone who wants to succeed in IT, more so in today's IT market. It's important to put into context how the world of IT and computing has changed a lot over the past ten years from IT itself being a niche to being commonplace.
This has meant IT follows the simple rules of economics which all other sectors follow, where if there's too many people vying for opportunities in a particular IT area, then there will be too much competition to get a job.
Aim for exceptions such as Cloud, Cyber and DevOps related roles, as these are in high demand with acute skill shortages.
With the proliferation of crime solving series like NCIS and CSI-Miami, there's been a surge in people applying to study Forensic Science, only to find when they graduate there's very few jobs in Forensic Science and those few jobs are nowhere as glamorous as the ones on television. Likewise some areas in IT have very few jobs associated with, for example learning about MainFrame technology might sound interesting and promising but there's less and less jobs in this older technology.
What may be in demand today, may not be in demand after you've got the skills and this is why it's better to check the job market and try to expand your area of expertise.
It's important to know your competition in any IT sector, as with so many candidates applying for the various IT jobs advertised, only the experienced candidates stand much hope of being successful. An easy way to check is to see how long job remain on the job boards, if the jobs are filled quickly then there's a lot of competition, while if the job takes a while to fill then may be this could be an area of opportunity. Unfortunately this method isn't foolproof, as from experience I've learnt some recruiters including interviewers don't know what they're doing and can end up looking for the perfect fit which never exists.
When there's so many experienced candidates applying for jobs, the employers will always have a field day, as the opportunity to pick and choose only the best candidates at a good price (to the employer) is increased. Employers will look for those who have the most experience and not really care about taking on the inexperienced. But if it's the other way round when there's less competition, employers may take on those who are less experienced.
When there's too many people vying for a job opportunity, employers control the market. Not literally, as price fixing salaries would be deemed illegal and there are severe penalties for doing this. What they do instead is start out with a market figure and can try to reduce this when too many candidates with the right levels of experience apply. So it's important to understand IT salaries for saturated IT careers can also fall and are generally less than those careers in demand.
This is down to simple economics, particularly supply and demand, where employers know there are too many suitably qualified people on the market. As such employers know they can pay less and still get suitably qualified staff. It's a win, win, win situation for these employers but not for those who are looking for work. Sometimes employers will pay the going rate but only to an exceptional candidate. This is a serious win for the employer, as they get the best candidate available on the market, for much lower than expected.
One of the first jobs I was offered in IT was as a technician where I would visit the employers customers and solve any issues with the Electronic Point of Sale (EPOS) PC systems they'd bought. This job not only involved having to work long hours each day (driving for many hours on end) but having to work some weekends and public holidays.
The more hours worked each week, the lower the actual hourly rate would become, so if I worked 40 hours per week, the salary looked fine. Working any more hours diluted the hourly rate so much, that working in a fast food restaurant would pay more per actual hour worked.
I decided against taking this job, as the last thing I wanted to do was jump straight out of the frying pan and into the fire! I'm so glad I didn't take this job, as I probably would still be there. Working long hours and earning a pittance to what I'm earning now. Each opportunity needs to be carefully assessed, with the pros and cons, to make sure it is the right opportunity.
"Earn 30K working as a Network Support Engineer."
The word support in the title of the role, automatically puts me off such roles. These roles are not the most glamorous in IT and can involve working long and unsociable hours. Network support roles involve working with networking equipment such hubs, switches, routers, proxies and so on. The rise of the internet and client/server networks has dramatically increased the need for network professionals and those involved in the design, installation and configuration of networks do get paid well. However once the 'cool' stuff has been done, the people doing the day to day support, don't get the same level of rewards financially.
Another role with the dreaded 'Support' word in the title is the 'PC Support' role, again there's generally long hours associated with this type of role so the real earning per hour are diluted severely by the amount of unpaid overtime that needs to be done (unless you get this job as contract and have overtime pay included in the contract terms), there's little career progression and then there's the incredible amount of competition to get into this role, meaning you'll need so many skills and lots of experience just to compete.
Many dead end computer careers include the dreaded "being on call". Whereby should there be any problems when you're not a work, you get called. Then it's up to you to try to fix the problem, either by connecting remotely or by actually going back to the office. There's nothing more frustrating than being called in the early hours, dragging yourself out of bed and having to drive into work.
Some companies can be very sneaky about paying extra for being on call and actually include the on call allowance as part of the normal working conditions. Therefore they avoid having to pay any extra payments for being on call. Others will offer an extra payment to cover being on call payment which can be quite shockingly low. So the question is, is it really worth an extra couple of bucks a day to be at the beck and call of an employer 24/7?
It's like a prison sentence. You end up having to plan your life around being on call. You can't just fly off on holiday over a weekend. How can you be contacted when you're at 35,000 feet with your mobile phone switched off?
Any job that demands being on call is a dead end computer career! I strongly advise anyone against taking such a job. You end up losing control of your life.
You only really get quality training when you do a job for real instead of learning about it theoretically doesn't give you the skills or confidence to do the job for real. Learn by doing tasks is a good way, I watched YouTube videos and learnt how to set up AWS S3, CloudFront, ACM, IAM (users, groups and policies) etc. I've added these to my portfolio of skills.
Be wary of training companies, I have many articles on this website which warn you about the tricks some of these unscrupulous companies use to provide substandard training at high costs.