Surprising Role Differences Between Frontend Engineer and Developer Advocate
Change is a scary thing. Even with an abundance of preparation, you may be worried if you’ve made the right choice. It’s only with time, and the events in your rear-view mirror that you have the space to reflect on whether it was the right decision. From graduating from school college or university; to moving town or home; to welcoming a new addition to the family; to transitioning jobs and companies; the anticipation and nerves in the pit of your stomach can leave you worried if the leap you’re about to make is worth it.
Three months ago, ahead of my first day as a Developer Advocate, I had the same pre-first day butterflies in my stomach that I do with every change. My husband will attest that I am that person who tends to like having a plan or having considered every angle before diving in. I had weighed up my reasons for leaving carefully. I had done my homework on the expectations of this role, and the typical responsibilities of advocacy roles thanks to some great conversations and resources from wonderful advocates like Trisha Gee, Helen Scott and many others. I had researched the company I was due to join and was happy I was joining a strong, friendly and supportive team who would support me along the way. I felt very much prepared and happy with my decision.
But then the sly imposter’s voice starts whispering in my ear. Have you missed something? Have you made a mistake? Should you really leave a comfortable spot in the investment bank you’ve been in for 10.6 years for advocacy?
Although my experiences of my first conference slot as an advocate gave me an indication, passing my probation and becoming an Elastic Certified Engineer have shown me I enjoy advocacy and am performing well. It also exposed me to many additional differences that I was not expecting despite my meticulous research. Here I share five surprises I’ve encountered in my first 3 months as an advocate, for anyone curious about jumping into advocacy, or even those interested in movement from regulated industries such as banking to tech.
Eeep, Where are the Bumpers!
This insight is very much specific to my experiences of moving out of a heavily regulated industry. Prior to this role, I spent just over 10 1/2 years working in investment banking. I had worked for the same company since graduating from university. Despite having progressed through the ranks, and undertaken a mixture of tech contribution and leadership roles, I still felt like I was in my first ever grown-up job in some regards.
Finance generally is a regulated industry. It might not be apparent when you start, or for this in other industries, but regulation has an impact on the processes and techniques you adopt when building software. Banking, in particular large incumbent investment banks, can adopt processes that, while often necessary, can make getting things done challenging. It’s natural for developers wanting to ship software to find jumping through these hoops frustrating. Often it’s not apparent what the justification for the procedure actually is. Or these processes can feel like archaic and overly-bureaucratic procedures that are maintained in lieu of adopting modern, automated techniques that could produce similar or enhanced controls and faster delivery rates and less aggravation. Sadly towards the end of my tenure, I felt this frustration as some procedures no longer made sense to me, and indeed some colleagues, and seemed to be more driven by other individuals’ aversion to change than as legitimate protection. Yet for the ones that did make sense, they gave you confidence that there were guard rails in place to stop you from doing something you really shouldn’t.
Jumping into a tech company that is currently scaling is a large step away. I imagine moving to a small start-up would have been an even larger change. Often many of the processes you took for granted are there are not, or are regularly evolving. This change can feel odd. Much like the first time you go ten-pin bowling with the bumpers (aka those metal barriers that stop you from rolling the ball in the gutters) down as a child. The first few times you’ve visited the alley as a child you might have had the bumpers up, or perhaps the metal contraption, or ramp, to help younger children roll the ball, to help you get a strike. Suddenly not having those aids available can be initially scary and intimidating. You may be fearful to make mistakes or throw a few gutter balls. Thankfully my experience has shown with a supportive team who has welcomed me and answered my myriad questions, after a few throws you’ll adjust and start hitting pins down again.
Beware Freedom Paralysis
An extension of this lack of bumpers is an abundance of freedom, which you can fear you’ll fail to capitalise on effectively. Most software engineering teams operate today with a rough plan of where they are going. They will have either regular releases or working cadences where they deliver features. Note I purposefully avoided the use of Sprints there people, as Kanban and other frameworks and techniques work for software too! Ideally, teams will adopt a continuous delivery model with knowing what product direction is and developers will feel confident picking up the next feature for development. Your deadlines feel a lot more concrete.
Starting out as an advocate requires more exploration, and has a less concrete path. Some of your activities may tie into conference engagements and booth duty for scheduled conference sponsorships with set dates. But much of your learning and initial content generation doesn’t have a set deadline. Furthermore, this deadline isn’t really set by a single individual such as a Product Owner, Product Manager or other tech management. I have a lot more admiration for advocates as I’ve realised you have to be strongly self-driven to generate authentic content that fits the products you advocate for, and then share it in various forms. This can also be even more challenging as many of the advocates I know and work with work remotely or while travelling.
I’ve had the issue of having so many ideas that I’m not sure where to start
It’s up to you to find your own way and formulate a plan of what areas you want to focus on. Over time I’ve found that so many ideas for content and projects have appeared in my head that I have to note them down somewhere and form a rough plan of what I’m going to focus on for the next few months. Those who know me as the reformed Scrum Master and Agile geek will be happy to know I have a simple private Kanban board to throw these ideas on and evolve them over time.
It’s important to also find your niche. You might think your job is simply to showcase the products built by the company you work for. To present engaging content that is interesting to the community, you need to present an authentic voice. Furthermore, it can’t be a simple product pitch that you throw down developers’ throats. I was surprised that I could maintain my passion for frontend development, and use that to frame the topics I share with the world with a sprinkling of the products for which I advocate.
Actions Speak Louder Than Titles
There are many different titles that people will give themselves within advocate circles. You might have come across individuals calling themselves Developer Advocates, as I do. Others refer to themselves as Developer Evangelists or even Developer Relations. Figuring out the difference between these titles can be confusing, as they largely mean the same thing. However, this community realises that the title is less important than producing content and engaging with a strong community of enthusiastic developers.
A wise and experienced advocate once told me I was already an advocate in practice since I was speaking at conferences and sharing blogs with the world. Yet when I decided to add Developer Advocate at Heart to my LinkedIn profile to attract more advocate roles, it felt forced and fraudulent. Part in a way because a lot of the content I had written had more of an agility or engineering manager vibe. However, the main reason for this was the simple fact that the procedures of my prior organisation when reviewing my content left it feeling like unappreciated efforts that aren’t part of my responsibilities as a front-end engineer. Although some were very supportive and gave me strong mentorship, sadly after a while their support was overshadowed by negative views and experiences.
Now that I’ve moved onto this role I see what this advocate meant. Much of the skills I have built in speaking, blogging and coding are those that I use now as a Developer Advocate. Even in the first 3 months! Those same skills will be the ones I will continue to build now that I have the title.
Spare Time Is Now My Job
As an extension to the prior point on actions, I have a stronger appreciation for how amazing it was for me to undertake advocacy in my spare time when it wasn’t technically my job. Prior to becoming an advocate, I spent an inordinate amount of personal time working on my blog or building a talk. In my last role in the bank, I was strongly encouraged to use company time for building out talks. However, working in an organisation where software and technology are a cost rather than a direct sellable asset can mean justifying working on a conference talk over coding up feature X or attending feature Y is difficult as it can be challenging to justify to users who needed that feature last week.
By the end of my software engineering tenure, I found that I enjoyed the time I spent tinkering with code examples or writing talks and blogs far more than building the software and following the required procedures to get my changes live. I once had a boss who emphatically proclaimed when I started working for them that they worked to live rather than living to work. When I heard this as a young software developer living with roommates in London without any dependents or cares I found this strange. We were working 40 plus hours per week, with emphasis on the plus for me. For this reason, the idea of spending the majority of my week not enjoying what I do seemed alien.
Now as a mum and driven technologist I do get the idea that other priorities drove this individual. Our priorities and passions morph and evolve as we progress in our careers. If your side hustle is more interesting than your day job, and it’s viable to make a career out of it, it might be time for a change. I’m still in awe that I get to do the conference attendance and talks that I considered a fun side gig as my job. Pinch me!
Still a Developer at Heart
One factor that can make those reluctant to change from software development to advocacy is the amount of code. The coder stereotype is that we sit coding frantically all day and hate writing documentation with a passion. With a move to advocacy, there can be a natural concern that you will rarely get to code or tinker with new technologies, languages and frameworks. Instead, you’ll spend all your time building presentation decks and writing thought-leader-style blog posts.
I’ve been happy at the amount of code that I’ve been able to write. Part of advocacy is I need to understand how to use the products the company makes available to developers, and by extension, help share this knowledge. I’ve found in comparison to some leadership roles I’ve undertaken such as Tech Lead and Scrum Master that I have written more code in this role.
There is a reason that I include developer in my title. Development is still a strong part of my identity. I am still a developer at heart, who advocates for some pretty cool software. Long may that continue!
Thanks for reading! Do reach out if you’re interested in finding out more about my experiences, or have any questions.
Carly Richmond 