Justin's TechBlog

A Software engineer with a tangent on DevOps/SRE and all things cloud - from the dark world of WinTel. Loves to play around with CI/CD tools, and all things cloud scale, and spends much of his time gaming. If you're a Ops/Infra/WinTel guy looking to transform into something more relevant, this is your blog!

2017 year end post, and time to #HitRefresh

Yet another non-tech post! Been a while since my last rambling here - and that says something I guess. Last I posted was a few days before I started my new role at a healthcare SaaS company as the “Devops Lead” or “Site Reliability Engineering Lead”. I’ll catch you guys up, plus, reminisce on the last couple of years, and lastly let you in on some announcements.

The last six months (technically, five months and 22 days)

The last six months, as much as I hate using cliches, was a roller coaster ride. Joining a product organisation in the healthcare space was an exciting move for me at that time. I’ve never been in a product organisation, or outside consulting, for that matter. It was an organisation with huge potential, i thought, despite being in the healthcare space which is considered one of the slowest industries out there. The last few months have been excruciating though. It’s unfortunate that when I think of updating my CV (or LinkedIn), I can’t think of much to update it with. Despite being in a senior role (with no one to directly manage, but with “dotted line reports”), I totally felt disempowered and hopeless in enacting and affecting meaningful change. I’ve managed to create a huge and long backlog, but with no one to call my own in a team/squad, I could only chip away so much.

This just reinforces my belief that any lasting and meaningful change in the line of DevOps has to begin in the culture/people. Not in tooling, not in architecture, not in process. Also, having unaligned and harmful goals across the organisation will stifle initiative to change (I’m reminded of Dr Eliyahu Goldratt’s The Goal). My failure though, was early on during my interview process, where I assumed that the organisation understood that they had to go through painful change in order to at least have a seat on the tech table, much less lead the market.

They did not. Convincing any organisation to change, will ultimately be a futile task if individuals’ bonuses, KPIs, and salaries depend on that change not happening.

On “Hitting Refresh” and the last four years

Since that fateful job interview with Amazon Web Services that went awry four years ago (promise, ill blog about this separately), I’ve made a conscious decision to reinvent myself, make myself more relevant to the changing tech landscape. Prior to that, I have been with a huge global IT consulting firm with absolutely no idea on what’s happening in tech, which made me into a very outdated professional as one can be in this industry. Shortly after leaving that consulting firm, i’ve kick started my journey back to becoming what I am now, a software engineer, with specialization on DevOps/Site Reliability Engineering, and all things cloud. I’m very proud of what I’ve accomplished, and believe that i’ve truly #hitrefresh on my career. Which leads me to the next thing…

What’s next?

As of yesterday, I’ve tendered my resignation from said healthcare SaaS company, and am finally joining my dream organisation since I started working, NASDAQ: MSFT, or Microsoft Corporation. And I’m happy that I didn’t have to ditch an ounce of my technical self to get there. I’m taking up a Field Engineering role in their Modern Applications Domain - as a DevOps specialist slash Software Engineer. Which tells me that they want their teaching their customers to start using the cloud the right way.

I’m optimistic, but cautious, as I’ve been in consulting organisations before, which do not foster customer obsession (like my ye old IT global consulting company from a previous life). Which normally translates to KPIs around billable hours - not exactly the best KPI to encourage customer obsession and innovation. Some consulting organisations though, have realised this - AWS’ consulting/architecture arm, , and is solely goaled towards getting their customers to build stuff on their cloud the right way, and the cheapest way as well. I’ve heard rumors that anyone in AWS’ architecture/consulting team is goaled towards lowering their customers’ spend on AWS. Not sure how much of that is substantiated…

Scroll to top tarzipsource code