Daniel McElligott from Version 1 discusses his role as a technical lead and the key skills required to prosper in the world of engineering.
Daniel McElligott is a technical lead working in platform engineering at Version 1. He has over 12 years of experience with software delivery, automation, CI/CD (continuous integration and continuous delivery/deployment) and release management.
Working as a senior consultant in Version 1, McElligott can be found leading teams and customers on their CI/CD maturity, defining their DevOps Strategy and roadmaps to achieve it.
When not working with customers, McElligott can be found speaking at tech conferences, including presenting at RedHat OpenShift summits in Dublin’s Convention Centre and The Helix.
‘Bringing the customer on the “journey” and looking back and seeing how far they have come and what value it adds to their business is highly satisfying’
– DANIEL MCELLIGOTT
If there is such a thing, can you describe a typical day in the job?
Most days start with a daily scrum, to check in with the team and establish any serious blockers that might impact our delivery schedule. The rest of the day can vary greatly depending on what stage of the project that we are in. I could be presenting in front of a CIO and board on the status of a large multi-vendor project or guiding a junior engineer on the basics of automation. But mostly it’s trying to strike the balance between scheduled meetings, unscheduled meetings, sprint deliverables and keeping the lights on.
My team is spread across Ireland, the EU and the UK, so remote working is the norm. I’m usually only in the office when there’s a requirement for in-person meetings or planning sessions with the client. WFH has its benefits but ultimately, we are all social creatures, so lately I find that I’m making more of an effort to get into the office regularly.
What types of engineering project do you work on?
I have been fortunate to work on some very exciting technologies with some brilliant people over the past few years. We have been supporting various types of application modernisation workloads, be it on the cloud, virtualisation or bare metal.
Lately, the most exciting technology I have been working with is Kubernetes and the tools that support it. Having a technology that finally enables efficient orchestration of immutable containers, with self-healing and auto-scaling features native to the platform is really exciting.
Kubernetes is transformative, not just for engineers like me that get to design CI/CD patterns which would have been overly complex and expensive on traditional platforms, but also for our customers too. A single approach for your organisation’s development and operational workloads across your estate as it evolves and grows is a huge advantage.
What engineering skills do you use on a daily basis?
As much raving as I did regarding Kubernetes in the previous question, as an engineer you have to be acutely aware that technology is a tool, not a solution. Or as a former colleague used to put it, “don’t automate for the sake of automating”.
Having empathy with your customer is a key engineering skill. Making their problem your problem. It’s essential to get a holistic view of their particular domain and requirements, identifying the value streams and the blockers.
Once a solution or optimised process has been defined, only then should you select the technology that’s best suited. I’ve seen too many engineers fall into the trap of “new and shiny” only to end up with more problems than they sought to resolve originally.
What are the hardest parts of engineering, and how do you navigate them?
As the tech lead on the platform engineering team, I’m accountable for services that support many different stakeholders, often with conflicting priorities.
Depending on their DevOps maturity and overall size of the customer, the platform is typically the central hub to several silos, thanks to the old adage of Conway’s Law. A change in culture doesn’t occur overnight, so bringing the customer on that journey, while not being a bottleneck to business as it evolves, is a challenge but it’s very rewarding when it’s done right.
Outside of the technical challenges, a core value that we have in Version 1 is ‘honesty and integrity’, it’s what I use to navigate difficult situations, telling customers what they need to hear – not what they want to hear. I live by this, and it has served me well so far!
What skills and tools are you using to communicate daily with your colleagues?
We use MS Teams primarily for day-to-day communication. Email still has its place, but IM tools, group channels and screen shares are becoming the norm.
Oddly enough, when in the office I find we end up using the same tools to communicate as we do when remote, especially if working on a problem. Maybe we should ban IM tools when talking with someone who’s in the office with you, but such tools have become too integrated into how we work now. This is the way.
How has this role changed as the engineering sector has grown and evolved?
Traditionally the developers wrote the code, and the sysadmin managed the operations. Deployments were less frequent and more complex.
Since the emergence of DevOps, both roles have merged with shared ownership in terms of building, deploying and running the code with frequent low-risk releases. I apologise for adding yet another definition of DevOps on the internet, but it’s gone mainstream now and with it, a whole bunch of subgenres exist: DevOps, CloudOps, DevSecOps, GitOps, InfraOps…
By and large, the role is the same, we are still hired to solve problems, but new patterns, technologies and ways of working have come to the fore. The customer exceptions have evolved also. DevOps is no longer a nice to have. A repeatable, reliable and secure way to release code is fundamental to most organisations now.
What do you enjoy most about working as an engineer?
Working with a team to solve a common goal, the natural camaraderie that develops over time, especially when working with people ‘in the trenches’. It sounds cliché, but bringing the customer on the ‘journey’ and looking back and seeing how far they have come and what value it adds to their business is highly satisfying.
What advice would you give to someone who wants to work in engineering?
Welcome to continuous learning. The learning never stops. This isn’t a nine-to-five where you just show up. You need to put in the time and personal commitment to upskill yourself continuously. We have a saying in work about staying a page ahead, and it couldn’t be more true. Certs are nice but nothing beats real world experience to real world problems. It’s a great career, but not an easy one!
10 things you need to know direct to your inbox every weekday. Sign up for the Daily Brief, Silicon Republic’s digest of essential sci-tech news.
