Connecting the dots: Let’s get ship done!

Today I’m joining Harness as a Principal Developer Advocate. Harness is a complete software delivery platform whose mission is to enable the 30M+ software developers in the world to deliver code to their users reliably, efficiently, securely and quickly. Joining Harness is a significant milestone in my professional career and I’m excited to tell you a bit more in this blog.

From Electrical Engineering to Tech

Back in 2011, I was a fresh face in Canada, ready with an Electrical Engineering degree, a bunch of research papers under my belt, and some work experience. Little did I know, though, that engineering is a regulated profession in Canada and comes with its fair share of red tape. For many international engineering grads like me, joining the workforce meant going back to school and redoing my entire engineering degree. This was a world away from the “tech” scene, where what you know matters more than any piece of paper.

As an older student trying to make ends meet, I had to juggle three part-time jobs. The only free time I could squeeze out of my crazy schedule was for exams and volunteering at the IEEE student club. Fast forward to 2014, and I stumbled upon an opportunity that felt like a golden ticket. A friend from the Ryerson IEEE student club posted about IBM’s search for Java-savvy interns. While Electrical Engineering programs didn’t offer as many programming courses as Computer Science, I excelled in my Java course.

The school internship was exclusively available for 3rd-year students. So, how did a second-year Electrical Engineering student like me even consider applying to IBM? I was driven by a hunger for success, and I knew I had to create my own path rather than following the conventional route. As the saying goes, “You miss 100% of the shots you don’t take,” and I was determined not to miss this opportunity. I got the job at IBM and this marked the beginning of an amazing eight-year adventure with IBM + Red Hat.

Quest to find my superpower(s)

In 2017, I was a competent developer, but I knew that coding wasn’t my superpower. I enjoyed the part which turned code into software. As I explored more, I started learning docker, Kubernetes, OpenShift, and various CI/CD tools. One key difference-maker was that I chose to learn in public. Over the next three years, I established myself as the go-to DevOps expert on the team. I had many senior IBMers send “thank you” notes for my talks and tutorials that helped them with customer projects. I found one of my superpowers.

IBM also had a Toastmasters club, and I eagerly joined to network with fellow IBMers and improve my public speaking skills. While most of my peers dreaded public speaking and writing documentation, I enjoyed doing both and these seemed to come naturally to me. I was about to realize my second superpower.

Around that time, an internal role as a developer advocate opened up at IBM. Reading the job description, I realized that I was doing all those things (and more) in my spare time. I was organizing meetups, writing content, delivering (internal) talks. I just didn’t know that the term “developer advocate” existed and I could get paid for doing the things I love.

“‘Passion’ may be an overused word, but I’ll use it here: the work I do as a developer advocate isn’t just a job; it’s my passion. Working in this role has propelled my career to new heights that wouldn’t have been possible had I remained in Electrical Engineering. In case you’re encountering the term for the first time, I’ve shared my perspective on what it means to be a developer advocate.

Connecting the dots

Steve Jobs once said, “You cannot connect the dots looking forward. You can only connect the dots looking backward.” I have a corollary to add here. The dots in your career align better when you have the power of connections. You might ask, “Does luck play a factor here?” Most certainly. We are all familiar with the saying, “The more I practice, the luckier I get.” While grit and hard work are paramount for success, a strong professional network can open numerous doors for you. What may appear as luck is, in reality, the power of connections.

Joining IEEE or Toastmasters clubs wasn’t a part of my job description, but I pursued them anyway in the hope of building new connections. Meaningful connections surpass the value of hard work alone. While you can improve your skills at work, a strong connection can unlock opportunities that hard work alone cannot provide. Over the past 12 years, I’ve actively cultivated meaningful professional relationships, ensuring that when I look back and try to connect the dots, they align more seamlessly.

Recognition > Stability > Title > Pay

This is my own formula to assess work happiness.

Pay is important to me because I have a mortgage and bills to pay. The grocery store doesn’t accept company values or the vision in exchange for bread. However, I believe that happiness comes from being content, not from chasing more money. Once a certain pay threshold is met, I find happiness in working for a company with the right title, stability, and recognition.

The statement ‘Titles don’t matter’ reflects a position of privilege. As an immigrant who once worked as a retail clerk at Staples for $10.25/hour, I care a lot about my title. My title signifies how a company values my worth and directly affects my career progression. A wrong title can limit my career possibilities and hinder my earning potential. That’s why I prioritize titles over pay.

Imagine receiving an offer to join a company with double the pay and a higher title. However, the company closes its doors in a few months, or there’s a sudden change in priorities, leading to the entire DevRel team being let go. What good is the pay increase or title in such a situation? I prefer career stability over a title and pay bump. Coming to work with the constant fear of the next sudden all-hands meeting, where you might be let go, is a terrible feeling, and it hampers one’s ability to perform at their best. This is why I value stability over title and pay.

Mithun was my second-line manager at Red Hat. Both my then-manager, Jay Dobies, and Mithun made me feel celebrated at work. There’s a saying that goes, ‘Work where you’re celebrated, not tolerated.’ You may have heard of test-driven development, but recognition-driven development is the best kind. Recognition > Stability > Title > Pay because being recognized by management gives me the confidence and mental boost to engage in more meaningful work. The opposite is also true. An important note is by “recognition”, I’m referring to public praise and appreciation, not necessarily to promotions or pay raises.

Why Harness

I set a very high bar when assessing my next employer. While most candidates focus on preparing for interviews, they often forget that interviews are a two-way street. I interviewed Harness, as a company, the same way they interviewed me. I may be biased, but I can confidently say that Harness passed my assessment with flying colors. Here are the seven steps in my interview process for evaluating Harness:

1. The offer:

This is the most basic test. Do they satisfy my minimum required title/pay/PTO requirement? I received a strong offer from Harness so this part was a ✅.

2. Product-Candidate-Fit:

If you were to ask my former colleagues what I’m known for, you’d likely hear keywords like DevOps, CI/CD, GitOps, Tekton, Argo CD, and Kubernetes. I can create content at both 101 and 201 levels for most technologies, but DevOps and CI/CD are my forte. I can delve deep into these topics, so when I was considering my next employer, I sought a company whose main focus was on technologies I excel at.

3. Excitement Factor:

Developer advocacy is a unique role that requires genuine belief in the product to effectively evangelize it. That’s why I tried and tested the Harness platform to see if it genuinely excited me. From robust documentation to user-friendliness and enterprise readiness, I could envision myself helping developers tackle software delivery challenges using the Harness platform. If you haven’t tried Harness yet, I encourage you to sign up for free and see for yourself.

4. The interview process:

An interview process can provide significant insights into a company. I actively maintain professional connections with recruiters. When I started looking for the next adventure, I reached out to my recruiter friend at Harness. Thanks to the connection and trust we had established in the past, the interview process felt less formal and more authentic. It involved a transparent and efficient assessment of my skills and experience (no leetcode interview 😉). Following the interview process, Harness didn’t present a lowball offer, and I didn’t play negotiation games. The process moved swiftly, and within four weeks, both parties had reached a signed agreement.

5. The brand assessment of the company:

When I put on a company t-shirt and speak in public, my personal brand is attached to the company brand. During the interview process, I conducted some research on Harness. From crunchbase to LinkedIn to Harness in press, I found out that Harness is on a solid growth trajectory and has a strong brand presence.

6. The founder(s):

I’ve long been an admirer of Jyoti Bansal. Jyoti has a tremendous track record of leading high-growth technology companies. Beyond his business acumen, he is very technical (more than 25 US patents). Highly technical founders have always been a key factor in my decision to join a tech startup. Since we’re discussing the interview, here’s one of Jyoti’s posts that I found inspiring:

To answer this question, I was most proud of the work I did with Terraform at Aiven. I heard from multiple customers that Aiven Terraform Provider and the related docs were one of the main reasons they chose Aiven. I authored Aiven Terraform Cookbook - a bunch of commonly used Terraform manifests to deploy data services. This cookbook was heavily used by Aiven’s solution architects.

7. The direct leadership and understanding of DevRel:

Recently, I wrote about the identity crisis in DevRel. From influencer marketing to sales and everything in between, many companies have misunderstood the role of DevRel. I wanted to ensure that my definition of impactful DevRel work aligned with that of Harness’s leadership. To my pleasant surprise, my direct leadership at Harness not only shared the same understanding of DevRel and its impact as I did but had also read my blogs on developer relations before the interview.

Let’s Get Ship Done

There’s a massive market opportunity for solving enterprise software delivery challenges. Traditional CI/CD within a single network for a monolithic app is rarely the solution. Today’s enterprise customers are building within air-gapped environments, automating secret management, and seeking an intelligent delivery pipeline capable of troubleshooting build and deployment failures, identifying and helping resolve security vulnerabilities in real-time, all with a privacy-first approach.

During last week’s {Unscripted} 2023 conference, Harness announced the official release of four new product modules on the platform: Harness Code Repository, Harness Internal Developer Portal, Harness Infrastructure as Code Management, and Harness Software Supply Chain Assurance. With these advancements, it’s an exhilarating time to be part of Harness as we push the boundaries of software delivery and elevate the developer experience. I’m beyond excited to return to my DevOps and CI/CD roots and join Harness to GET SHIP DONE!