Charge Me Up

Respecting the Social Battery in DevRel

Over the past year, I’ve gained a great insight into the developer and community focus of developer relations. As an advocate and engineer, I’ve enjoyed connecting with and learning from so many wonderful and intelligent people.

As an extrovert with introverted tendencies, I’ve often found some of these events to be as draining as they are engaging. And at my first Engineering All Hands this year I found I’m not the only one. We had a great conversation on tiredness, with one colleague referring to their depleted social battery. I had never heard of this term, but it resonated strongly with how I was also feeling by the end of the week.

Ever feel like you’re running on empty?

In this piece, I discuss the factors that impact our social battery generally, as well as those specific to DevRel and tech. I’ll also share tips on managing your own social battery, learned from my wonderful colleagues, and resources you can use to manage your own social battery and well-being.

Like a Battery

The social battery is the allowance of energy a given person has for socialising before it starts to harm their well-being. Introversion and extroversion is a scale, which we can move up and down throughout our lives. Having been a prominent extrovert for a large portion of my life, and therefore being energised by social interactions, I’ve had points of introversion as well. Everyone has a different capacity for social engagement, or battery size, and this battery size and capacity ebbs and flows.

The metaphor of a battery representing social energy charge always reminds me of the Duracell Bunny. As a child, I would regularly see TV adverts of bunnies powered by competitor batteries quickly becoming tired, whereas Duracell would keep going for longer.

We can’t all just keep going like the Duracell Bunny!

But it’s not just tiredness that is a sign of a depleting social battery. There are other signs, including:

Mental exhaustion or difficulty processing new information.
Periods of quiet or inactivity in group conversations.
Irritation caused by not only others but loud noises, music or lighting.
Difficulty responding to emotions or verbal cues from others.
Physical symptoms such as headaches or back pain.
Insomnia or difficulty falling asleep due to overstimulation.

Any of these side effects can also have an impact on productivity. As can the working environment, which I’ve written about before based on my experiences of working in a busy and overcrowded office. We need to be mindful of the causes, and on the lookout for the symptoms in ourselves and each other.

Human Battery

Tech does have some industry-specific challenges in supporting the social battery of those working within it. We’re not talking about the developer stereotype of an introverted developer hiding in the corner of the office in front of their laptop coding away in a set of enormous noise-cancelling headphones. The explosion of increased collaboration driven through the adoption of agile, or sadly fr-agile, ways of working and techniques such as pair programming means that everyone working in tech is working in social ways with less time for isolated work. I must emphasize that these techniques are wonderful and essential for building better software that solves real-world problems. But if they are not used in a balanced way they can drain people anywhere on the introvert-extrovert scale.

DevRel and community can introduce challenges in maintaining a fully-charged social battery

It may seem like DevRel is an extrovert-only club, but I’ve found having a mixture of individuals on the energy scale helps accommodate developers across the community. In the DevRel world there are several unique considerations:

Advocates, program managers and company representatives moving between extremes of solitary work building content and highly social settings such as meetup talks and conference booth duty.
Interacting with a mixture of introverts and extroverts within the community.
The increasingly remote nature of our work as we complete tasks working at home, or on public transport as we travel to events. Working for a company such as Elastic that is distributed by design means many individuals will visit offices occasionally, myself included.
Traveling long distances for a conference or event can mean working while managing jet lag, which can be a draining experience.

What’s more important is that we acknowledge industry and environment-specific factors, and give space and empathy to help each other prevent or manage a drained social battery. This includes colleagues, counterparts and the developers and users with which we engage.

Low Battery

Irrespective of where you feel you sit on the introvert/ extrovert scale, it’s important to build a personal toolkit to prevent or manage depleted social energy levels. Here are some tips that have worked for me, as well as some I’ve learned from others:

Be sure to take the idle time that you need to do things you enjoy when you need. Perhaps it’s listening to music or a podcast, as it is for me. Or maybe you are more of a knitting person. Brief regular breaks help you maintain charge.
Balance short and long spells to maintain energy. This has been the biggest challenge for me while juggling work and parenthood, even with a supportive co-parent on my side. Taking longer spells for restorative activities, which for me are things like reading a book in the bath or taking a walk outside with my camera, is necessary to maintain energy.
Use conference schedules or your personal meeting calendar to plan potential points for personal time. It can be useful to take a planned break on particularly busy days to recharge your energy before it is completely exhausted. Even if it’s 10 minutes to grab a cup of tea as I do before giving a conference talk.
Identify the social events you can step away from to avoid order-stretching yourself. Sometimes at work gatherings or tech conferences, you may feel you have to attend every social. But the reality is social engagements will be optional.
Take time to relax at home with family or on your own after a long trip. Chilling by yourself in your hotel on a work trip can help with a temporary restoration, but home is where the heart is after all!
Support others when they step away, and respect their decision to take time for themselves. If you are a natural extravert this may be challenging as it’s at odds with how you get your energy. But it’s the best way to garner mutual respect when you need your own break.
Be friendly and open to those who approach the stand. If someone has low energy they may want to just have a look at the swag or any product information, rather than have an in-depth conversation. Don’t force the issue.
Seek out nature or fresh air. Be it a hike or even a step outside, both a great ways to get energy back. Especially if you’ve been sitting inside an office or conference venue all day.
Use the Pac-Man Rule to allow people to join conversations if they wish. This is particularly inviting for those who don’t know many people at an event.
Withdraw from events if it’s getting too much. Self-care comes first!

All Together Now

I still consider myself an extroverted introvert. It has taken me quite a while to be comfortable saying no to social events and taking my recharge time. Especially as a parent caring for an excitable and enthusiastic little boy who can definitely deplete your energy quickly! It’s important to take the time to find your social limits and the activities that help you recharge those batteries!

In researching this piece I found these resources helpful:

Do check them out. Best of luck maintaining your DevRel social battery!

Thanks for reading! Do share if you have additional tips to share on managing your social battery charge.

Take a Picture

Programmatic Screenshot Capture Using Playwright and Node.js

As engineers, we are always looking for shiny new greenfield projects or rewriting ageing legacy applications. We rarely get the opportunity to rebuild an application from the days we learned to code and see how far we have come as a developer. I’m lucky enough to be in that same situation.

Moving back into the search domain through my role as a Developer Advocate at Elastic has inspired me to revisit the Fu-Finder game that I built for my master’s thesis. One of the first tasks required to build this game is revisiting the URL dataset of the old game, and capturing screenshots to show in the game. A large number of the URLs have changed or no longer exist. But for those that do I need updated screenshots for players to search for.

Previously I used WebKit and Python when building the original game. The majority of e2e test and automation frameworks have screenshot capabilities, including Cypress and Selenium. But since I’ve been playing with Playwright and @elastic/synthetics, I’ll show how Playwright and JavaScript can be used to capture these screenshots.

Pictures of You

The final version of the script get-screenshot-images.js is available on repo carlyrichmond/elastic-fu-finder. The process for generating the screenshots involved 3 key steps:

Extract the URLs I want to capture. Following an experiment using the Elastic WebCrawler, I have a set of URLs present in the index search-elastic-fu-finder-pages that I can pull out using a search call to return all results.
Set up the Playwright browser configuration.
Capture a screenshot for each URL and save.

There are many great resources out there that show how to capture screenshots using any of the myriad of automation frameworks. I came across this amazing article by Chris Roebuck that covers 7 different approaches. I used the Playwright example as a basis, ending up with code that looked a little bit like this:

const { chromium } = require('playwright');
const imageFolder = 'images/screenshots';

// Elasticsearch URL extraction executed before getScreenshotsFromHits

// param: hits, results consisting of document id (_id) 
// and document source (_source) containing url
  async function getScreenshotsFromHits(hits) {
    let browser = await chromium.launch();
    let page = await browser.newPage();
    await page.viewportSize({ width: 3840, height: 1080 });

    for (const hit of hits ) {
      const id = hit._id;
      const url = hit._source.url;

      console.log(`Obtaining screenshot for ${url}`);
      
      try {
        await page.goto(url);
        await page.screenshot({ path: `${imageFolder}/${id}.png`}); 
      }
      catch(e) {
        console.log(`Timeout received for ${url}`);
        continue;
      }
    }

    await browser.close();
  }

Playwright gives us access to various different browsers. However, I found a rather troubling issue when using Chromium against a subset of my websites.

Don’t Stand So Close to Me

Some websites blocked my script, which resulted in Playwright capturing a screenshot for a 403 error in the browser, exactly like the one below.

This was a new issue that I didn’t encounter previously when using WebKit way back in the day. It’s not surprising given the expansion of the web over the past decade that websites are protecting themselves from automated agents. Especially if they expose a public API where the data can be extracted in a controlled way.

A bit of Googling led me to good old Stack Overflow, and this thread on Python access with Chromium. This old yet detailed post mentions detection of the User Agent to block traffic, which makes sense.

Local Boy in the Photograph

I could have simply excluded the impacted URLs from my dataset. I also considered using the new Headless Chromium option based on this other Stack Overflow post to address the limitation.

In the end, I decided to use an alternative browser. I also played around with the fullPage option, which was a tad too large, and the clip settings to get the content that I wanted from my pages:

const { firefox } = require('playwright');
const imageFolder = 'images/screenshots';

// Elasticsearch URL extraction executed before getScreenshotsFromHits

// param: hits, results consisting of document id (_id) 
// and document source (_source) containing url
  async function getScreenshotsFromHits(hits) {
    let browser = await firefox.launch();
    let page = await browser.newPage();
    await page.viewportSize({ width: 3840, height: 1080 });

    for (const hit of hits ) {
      const id = hit._id;
      const url = hit._source.url;

      console.log(`Obtaining screenshot for ${url}`);
      
      try {
        await page.goto(url);
        await page.screenshot({ path: `${imageFolder}/${id}.png`, fullPage: true, 
clip: { x: 0, y: 0, width: 3840, height: 1080 }}); 
      }
      catch(e) {
        console.log(`Timeout received for ${url}`);
        continue;
      }
    }

    await browser.close();
  }

With this trusty code, we’re now able to extract screenshots successfully. Woohoo!

Conclusions

I’m excited to say the Fu-Finder sequel is in progress thanks to Playwright helping me extract screenshots from a set of pages. I have limited execution of this script to a one off extraction to respect these sites. The last thing I want to do is initiate a denial of service against them!

When crawling to extract the content, such as with a crawler, I would respect the restrictions put in place by a site’s robots.txt as I did with my original list of URLs. The majority of Open Source and Commercial Crawlers will respect this file, and so should you!

Happy screenshot capture!

(Not So) Basic Instinct

Nurturing Problem Solving Instincts in the Tech Industry

Nature versus nurture is an ongoing debate as to whether human behaviours are driven by inbuilt natural factors already there, or are formed through environmental factors such as parenting and life experience. When considering the skills required for building software, or indeed anything else we do in life, you always wonder if it’s always been there or built via experience.

Other life events and experiences make us better technologists, including parenthood, caring, traveling, and being just a friendly human. I always remember chatting about my upcoming parental responsibilities with a friend. You’re never sure if you’ll be a good parent or not, and feel the weight of responsibility in looking for a tiny helpless human. My friend reassured me that the hidden kernel subroutine will kick in when you’re ready, which I found amusing and reassuring. Thinking about that story now and how my now 3 year old has turned out (shock!) leads me to realise that some instincts were there, but a lot of the instincts formed through practical experiences such as trying to get them the baba to sleep at 3am, or learning tricks from my husband how to get a slippery toddler out the bath (true story).

Becoming a good software engineer, and Mum, is hard and requires you to build your own instincts

Over my 11 year career in tech, I’ve noticed with each move I become more comfortable with uncertainty, and find my feet more quickly than with the last move. It is my opinion that through my school, university and software engineer career I have built instincts through trying, failing, adapting and learning from others. Here I reflect on the main types of instincts I’ve nurtured through my technical career, and share tips on how you can build these instincts too.

Helps Me Help You

You may not know this, but my first role straight off my 15 week training program within the bank was a rather mixed role. I was a developer reading rather than writing Perl and coding in Python, SQL and AxiomSL (aka a data management platform with an in-built ETL used for financial domains such as regulatory reporting, capital reporting and liquidity management calculations which now looks to be part of the company Adenza…). However, I also supported the calculation and submission efforts by users in production. Normally, as I came to find later, these roles are not normally combined.

This dual responsibility definitely made me better at multitasking, or at least I think it did. I know from psychology But it also introduced me early to the need to prioritise my work. This was a slightly different experience to my peers who didn’t have the same support commitments when starting out. If it got to them as an urgent escalation, it was a drop-everything situation. Yet for me it was more nuanced. Submission issues were a red alert situation, absolutely! However, some user production questions were a mere DEFCON 5 situation, or for those who haven’t learned the lingo from Mr R’s love of Star Trek, not a big deal at all.

My first role helped me learn the importance of triage and that the nosiest issues is not always the most important

The context was important in determining the priority. This taught me early the importance of asking questions. Just like an hospital emergency room scenario Darria Long discusses in her TED talk, the loudest patient is not always the highest priortity. Issue triage typically involved me asking questions to categorise an incident such as:

What environment is this issue in? Production may be critical depending on impact, but QA may not be depending on whether they are using it for upstream application verification compared to testing adjustments before applying them in production.
How do you expect this logic or feature to work? Differing expectation versus reality is still something I see even today as a Developer Advocate.
Do you have any screenshots or error messages? This question still proved useful later when I transitioned into web frontend development.
What is the impact of this issue? Knowing if this impacts an external submission today versus internal reporting was a key indicator of priority for me at that time.

When it came to requirements prioritisation this was my first insight into the subjective nature of importance. Sadly I got stung a couple of times when focusing on building something when they wanted me to focus on another requirement resulted in some uncomfortable questions. When you first start as an engineer, you want to please users and establish a reputation for delivery.

Every issue is important to someone. Therefore, depending on who you speak to it’s easy to be led astray and focus on building the thing to solve the problem, especially if it’s easy and you’ve built confidence in the technology you need to use. It highlights the importance of building in small increments as advocated by agile principles and agreeing on a common strategy as a team, rather than working in waterfall as independent units, and not discussing priority enough.

An Honest Mistake

Instincts on the root cause of errors is another skill that requires nurturing to master. When I moved to be a frontend web developer, I learned the importance of reading and interpreting error messages and logs. I indeed had to read logs and interpret error messages when things went wrong. However, what made this different is that this was my first tech stack move. At this time I was learning Angular, Typescript and many other different technologies.

Anyone who’s done any web development in the last 10+ years will be aware of the framework and tooling explosion in that space. It can be intimidating to pick them up as they often have their own opinionated patterns you need to follow. Angular in particular enforces very strong structure and style if you check out the style guide. In addition to learning new terms and patterns, you also need to develop instincts for reading and processing stack traces emitted when things go wrong. While advancements in recent releases have improved the developer experience, such as the improved developer experience for the banana in the box error introduced in Angular 14 in 2021, the reality is that diagnosing error messages is an art that we hone instincts for with each feature we build, and through researching and understanding the intricacies of how they work under the hood.

If only all error traces we counter in web development were as straightforward as 404!

We also get better and researching issues and building search-fu to understand the relevancy of information we find. When you start as an engineer, you may be more likely to reach out to a mentor to help with confusing error messages first. However, later as you get better at using Google, or your favourite alternative search engine, you get better at finding not the exact error message, but find related messages triggered from other libraries and from there and generate ideas on how to solve the problem at hand. These skills have proven not only useful in my role as a developer. As an advocate who looks to build content and show via prototypes the features of particular technologies, diagnosing and fixing error messages, possibly in unfamiliar ecosystems, has helped me learn Elasticsearch and the technologies I advocate for quickly, and continue to keep up to date with them.

Human After All

A common career path within technology, but not the only path, to engineering management also requires learning. While often this progression is suggested as the default path, it is a role I believe requires building specialised skills that also need to be grown. Just as I did as an engineer, as a manager I engaged in research, training and reading to build the skills required of a good manager and technical leader. Let’s not confuse leadership and management. They are not the same thing.

Stepping into management can initially be a fearful construct. Breaking people seems far easier and scarier than breaking software. For me, I found the need to build my empathy, delegation and teaching skills to be a better people manager. There is also the need to get up to speed with company policies, such as sickness, performance and parental policies, and resources for career growth and mental health. As a manager, you need to support people through life-changing events and ensure they can bring their best and authentic selves to work in good times and bad. My first time supporting a direct through personal challenges was hard, and I feared making it worse.

Managing humans means listening, supporting and treating your directs like humans first, not resources!

The best advice I ever received was to treat people like a human first. Since then I’ve learned practical skills such as active listening that support that human first notion. Use your humanity as your driving instinct, and you should be able to support people.

I Gotta Feeling

With any job move, it can be difficult to generate instincts on your remit. When changing careers, or moving into a new domain it can be difficult to figure out if something is of benefit to the community you serve. I’ve found that moving into DevRel that events have varying target audiences, from developers through to executive levels. It is not always clear-cut who they are aimed at, which events are relevant to which communities and which content would be of interest to those communities.

Events have different audiences, and building the spidey sense for which ones appeal to developers is hard. Recommending content and events for audiences that are not the intended target can leave communities uncomfortable. I’ve experienced representing my company at events and being given the sales pitch when the reality is I don’t have the authority to commit to purchases. I’m sure current and former Vice Presidents working as software engineers within financial institutions will all know exactly what I’m talking about. For those unfamiliar, VP is not board-level but the first rung on the promotion ladder. I use that experience and empathy, along with guidance from more experienced colleagues, as the basis of the Litmus test I use to classify developer and non-developer events.

Much like Litmus paper can identify alkaline and acidic compounds, as advocates we need to form instincts in roles to identify if content is relevant and useful to the community we support and nurture

When speaking and writing content, I also need to ensure the topic is something I can speak on as an authentic authority. Much of my experience as a frontend engineer means I use technologies and solve problems primarily with a frontend rose-coloured lens. I can also dabble in domains related to my experience such as Java and Observability given my limited application support experience.

I personally will struggle to give concrete recommendations on operational and security topics given my lack of experience and expertise. I try to ensure I give my genuine opinions and experiences of using tools, or how I would use them to solve problems I have previously encountered. I also need to be aware to also share my experiences and guidance on topics such as diversity and technical leadership as well as products of the tech company I represent. I am passionate about being a well-rounded and empathetic software engineer and building others by sharing my experiences and learnings through 11 years of building software.

Mother Stands for Comfort

Looking back at these experiences, I see merely a subset of the different hats I’ve worn working in the software industry for 11 years. Like my journey through motherhood, all the instincts I have gained through successes, experimentation, failure and reflection. Even now I’m still learning and honing new instincts as I build software and write content. Each new insight helps me to form a gut feeling about what is right or not for me in a given situation.

Just like in nature, our instincts for building software and performing our roles evolve through learning and experimentation

You may not think you have instincts, especially if you’re worried about being found out as the impostor in your team. Trust me, they are in there! They may not have always been in there since your inception like that mythical motherhood kernel subroutine I searched in myself for at the start of this story. But trust that you can build your own instincts, and use the guidance and help from others to nurture them further. Trust your gut as it evolves over time. And if it doesn’t work out, learn and try again!

Thanks for reading! Do reach out if you think of other instincts and lessons you have learned that I too could learn from.

Jump In

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.

We all have that imposter whispering in our ears questioning our decisions. I just imagine mine looks more like the Shame Wizard from Big Mouth!

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.

Moving from a large to small company is a bit like the first time you go bowling as a kid and don’t have the bumpers or ramp

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.

Irrespective of whether you’re a developer speaking or an advocate, you are still part of a community and able to share ideas

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.

One great advantage of becoming an advocate is that speaking, blogging and coding is my job, leaving my spare time for me to spend with my family

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 glad to have had the opportunity to write more code compared to some other roles I’ve held in my time

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.

Should I Stay or Should I Go? (Na na na na na na na na)

Reflections on Engineer Role Moves Within and Across Organisations

So someone has resigned. Read all about it! Suddenly the rumour mill is working overtime as the news of an individual’s impending departure starts to spread through the grapevine like pests hungrily searching for nourishment from this morsel of gossip. Many of us will have conflicting views on this depending on whether we are the recipient of news or the resignee.

Saying goodbye to a company can be hard, but also opens exciting opportunities and fortunes

I wouldn’t call myself an expert on developers resigning, but I do have a few thoughts on the resignation versus mobility debate. In my 10.6-year tenure, I’ve resigned twice, retracted a resignation once, moved teams twice, been promoted once, and moved roles several more times within teams. I’ve also seen the other side of the coin, being the manager or lead trying to grapple with the resignation fallout. Throughout my career, I’ve always had a gut feeling that it’s time to move on to something else to scratch the unfulfilled itch in my current role. Sadly I’ve not always acted on it as quickly as I should. But even that inactivity has helped me learn and grow.

This rich career tapestry has molded my opinions on whether a hop to another company is always the right call for your career. As I started my latest exciting chapter recently, I share my thoughts on resignations. In this piece, I’ll cover the reasons people, and more specifically engineers, quit; when a move might be a better option for you; and tips for managers on how to handle resignations with grace based on my own experiences on both sides of the table.

News of the World

Through my own recent experience, I’m come to think of each resignation as a tabloid newspaper. I can sense some eye-rolls will appear as I write this, but hear me out!

Resignations are structured similarly to a tabloid newspaper article

There are three primary elements of any tabloid newspaper article, at least in the UK where I reside.

There is a single bold headline that is the deal-breaker for staying within the role. Now it may not be a catchy pun like those used by many tabloid front pages here in the UK. But it’s normally the 10 words or less tipping point that has led this person to decide it’s time to move.
Those catchy simple headlines are normally prefixed with a more detailed subheading to give a little more information. Here I like to think in resignation terms there may be some smaller niggling things that are not the top reason but have contributed to your rockstar employee wanting to do something different.
Finally, there is the story itself. The opinion piece that any resignee has on how this bigger picture and smaller elements have manifested into a situation.

The headline and subtle subplot are all relevant to a resignation. As a manager on the receiving side of resignation, if you’re looking for things to fix in your organisation to eliminate further, you should scruitinise not only the sensational headline but the subtle detail in the subplot. It’s also important to look at common themes across multiple resignations across teams and institutions. Through the great resignation of 2021 and early 2022 personal factors can mean there may not be common themes, but certainly, from speaking to friends and colleagues it’s more common that bugbears that have subtly gnawed at us over time have eventually built up, and the personal circumstances become the final push to send you on your way.

She Moves In Her Own Way

Managers and leaders always want to have a simple, one size fits all reason for why people leave. Having been on both sides of the table a few times in my career, I know that is not the case. Thinking back to our tabloid analogy, it would be a pretty boring read if every article had the same headline!

The most common reason people cite as the silver bullet of resignations is that "good people leave bad managers". At one time I strongly believed this to be the case. I’m sad to admit that at one point it was the source of my sudden pandemic burnout-induced rage quit that forced me to search for a new role. But each story normally has a more nuanced subplot. I’m more inclined to believe that good people leave bad cultures, opportunities, or processes, that can spread within teams, departments, or entire organisations through one or many individuals.

We’ve all had good and bad managers, although I hope none of you have worked for these super villains

I’ve always agreed with Rands’s principle that at some point a person’s shields go down, and they become open to new opportunities. His piece gives a wonderful set of questions that flow through people’s minds when the potential of a change emerges. I won’t cover this point as he does an amazing job doing so. But for engineers, architectures, and managers with an engineering heart, there are a few recent themes I’ve observed that contribute to a person putting their shields down:

Do I get to work with the technologies and frameworks that I’m interested in? Particularly in heavily regulated sectors where adoption of bleeding-edge tech is considered with an immensely strong aversion for risk concerns, developers may become tired of working on old tech and concerned that they may become stuck and unable to progress in the industry.
Am I getting enough time to focus on the contributions that I’m passionate about? This can be outside open source contributions or community contributions as well as within the business that you work for.
Do I feel productive? Are there organisational procedures that I need to follow that I feel impede my ability to get stuff done? Am I struggling with excessively bureaucratic processes? These may also be driven by company culture or political reasons too.
Do I see a clear career path that fits with where I want to go? For engineers that want to stay technical and are not interested in management or people development, companies must provide tracks for technical progression as well as progression into engineering management and other tracks such as design, testing, and agility.
Do I as a developer feel respected by the establishment. In non-tech companies such as banks, health, and ecommerce where the main commodity or service is not software, you still want to feel like part of the team and not an afterthought.
Do the firm values and mission still resonate with me? Have I outgrown these values? Or am I feeling that I am connected to these values, but others are not practicing them in a way that I’m comfortable with?
Are the testing and technical debt practices treated with the same respect as the development of new user-focused features? Are you able to follow industry best practices in these areas? Speaking to some developers over the years, deprioritisation of these themes produces products that become more difficult to add to and maintain over time, leaving them feeling a lack of pride in the products they build.
Do they have the flexibility they want to need when it comes to hybrid or remote working? Sure, some people prefer the office, but the adoption of the office-focused ethos that many companies are adopting at the moment doesn’t work for everyone. Some people want to spend portions of their time working while traveling or visiting family. Some like me find the benefits of home or hybrid working make family life more balanced. If you want to maintain a diverse and talented workforce mandating office attendance in a post-COVID era may put you at a disadvantage for recruiting them compared to more flexible firms.
Yes, salary and perks are also a factor too. Let’s be honest here! Of course, this list is not exhaustive. I’m sure you’re thinking of many other factors based on your career path to date. But any one of these can open up the technical mind to considering a change.

Time to Move On(?)

When considering a move it’s often the case that we immediately jump to moving to another institution. However, evaluating the potential for an intra-company option might be a good option depending on the reasons you have for leaving. I remember seeing Carla Harris speak a few years ago walking through some of her pearls of wisdom. The one pearl that I still remember vividly was when she discussed the seat versus the house. The seat in this case refers to the role and high-level duties that you perform each day. The house is the institution in which you are working. She implores us to consider in times of career struggle if it is the seat or the house that is the cause of our discontent.

When considering a move it might be the role, or seat, in the house that’s not quite right

This advice has steered me well for a few years. I stayed in the same firm for 10.6 years and moved seats several times. It was only when I eventually realised that I wanted to take a different direction that wasn’t compatible with the house, that I ended up resigning. To continue the analogy, I could have stayed and worked to remodel the house, aka change the problems. But another lesson I’ve learned from The Liberators Network is that sometimes it’s worth thinking about if you think the fight to change in some situations is worth your time. Beliefs or opinions that are strongly embedded in organisations can be very difficult to change, even if people agree that they should not be there. In the end, if you will exert significant effort and time to rectify the problem that you don’t think is worthy of your time or impacts your personal timelines, it might be best to find another house that can be a home to these ideals and values.

A (Person) Worth Fighting For?

I’ve seen many engineering managers disagree on whether it’s worth trying to negotiate to keep someone. This applies to moves out of the organisation, as well as internal mobility moves to other teams. I think there are good and bad ways to approach it. Sadly I’ve handled it badly and well for different individuals over the years (apologies to those in the former camp). But in my experiences on both sides of the table, and experiences with amazing and not-so-amazing managers handling my cases, I’m starting to build a blueprint of how the best resignations are handled. Here’s how I think it should go.

You should always start by saying congratulations. Acknowledge their good news. This is the true distinction between good and bad managers. A bad manager takes it personally. Most managers immediately go into problem-solving mode, ask a myriad of questions and propose tons of solutions to try to fix the problem. A good manager acknowledges this is good news for the resignee and expresses happiness for them.

Don’t forget to say congratulations!

Next, ask them questions about the new role, and really listen to the answers. Find out what is exciting about this new adventure. How does this engagement fit in with their wider career goals? This moment is about the person resigning. It’s easy to jump ahead and think about the hurt you may feel that someone is leaving your team, or how this person leaving impacts how others see you as a manager. You need to be humble and leave your ego at the door. It’s not about you!

Discuss why these elements are not present in their current role. Especially if you have been working with this person to identify ways to expose them to these opportunities already. It may be a question of timing or personal circumstances that mean the timing to jump is now.

As uncomfortable as it may be, you should discuss compensation and perks offered in their new role. Amid the great resignation, offers are high. Particularly for long-tenured individuals who have not hopped around a lot, there may be a significant jump. Does this help them with personal aspirations? Can you counter? If you are thinking about discussing a counteroffer with management you should also consider carefully if you should as well.

Know when you need to lay your gloves down, as not everyone wants to be fought for

Ask them if they want to be kept or fought for. This is important as we normally miss this and immediately escalate to keep people, particularly rockstars that you may want to retain. If someone truly has their heart set on leaving, you should respect this decision and support them in their transition. Throwing directors and senior folks at them to convince them to stay can sour the company’s relationship with that individual and make them feel uncomfortable. Not everyone wants to be fought for.

It’s Your Move

The Great Resignation has meant it has been an employee rather than employer market. In these times companies need the realise that retention of good people should be of equal, if not greater importance than attraction. Larry Fink’s CEO letter hammered home for me that managers, not just CEOs, should be mindful of the various issues facing their people and be thoughtful in how they engage with individuals.

In addition to upending our relationship with where we physically work, the pandemic also shone a light on issues like racial equity, childcare, and mental health – and revealed the gap between generational expectations at work. These themes are now center stage for CEOs, who must be thoughtful about how they use their voice and connect on social issues important to their employees. Those who show humility and stay grounded in their purpose are more likely to build the kind of bond that endures the span of someone’s career.

Larry Fink’s 2022 Letter to CEOs

Considering this sentiment, even after the resignation, it’s worth keeping in touch after they leave, and leaving the door open for strong people that you enjoyed working with. Leaving for a new company is always a step into the unknown. Although it might be rare, people may want to come back. I don’t have any experience of this, so I suggest reading Helen Scott’s amazing piece on her experience going back to JetBrains which covers this situation well. I agree with her that probation periods are an opportunity not only for employers to evaluate if you are a good fit for the organisation, but also if this institution is a good fit for you and your aspirations.

Just as the sign says, I don’t know where I’m going from here, but I promise it won’t be boring

Moving companies can be scary. I was at the same establishment for 10.6 years, and it was my first grown-up job after university as well. So of course I’ve been feeling a mixture of excitement and terror. I’m loving the change and challenge a couple of months in. I’ve also been fortunate to connect with old colleagues and community friends at Devoxx UK 2022 as well, which was amazing too. If you’re currently thinking about staying or going it can be an agonising decision. You may be worried about the timing, what will happen if it doesn’t work out, scary thoughts about being found out as the imposter, or even if the perks will leave you and your family at a disadvantage. The best advice I’ve received is not to overthink it. I’m now embracing that sentiment and enjoying the ride!

Thanks for reading! Do get in touch if you would like to chat about my moving experiences, or discuss your own. For those who now have The Clash stuck in their head, apologies and enjoy!

Speak Your Mind

The Differences Between Conference Attendance Experience as an Advocate versus Speaker and Attendee

It’s tech conference season! I’m starting to find that there are two busy periods in the year for tech conferences: April-May and October-November. It’s kept me busy as a new developer advocate starting in April 2022.

It’s more of a learn-by-doing approach, just like learning to swim by being dropped into the middle of Loch Ness. However, I wouldn’t have it any other way as I’ve always been more of a learn-by-doing person. My first ever manager referred to this style as “filling your boots”, which means diving in and taking as much as you want. You just need to balance this with not taking too much. Otherwise, you’ll end up in a similar situation to my husband in his youth where his boots filled with mud at a festival and he struggled to escape the field of sludge (sorry honey)!

I have been fortunate enough to speak at several conferences, including Devoxx UK in 2021 and 2022. My first experience was as an engineer with a passion for speaking and the second was as a developer advocate. I’ve enjoyed both of these experiences. I’ve also experienced vendor booth duty at DevOpsDays Birmingham, which was an enjoyable education. Up until now the closest experience I had was attending university recruitment events on behalf of my prior company.

Speaker on stage as seen by the audience

In addition to adjusting from online to in-person tech conferences, I’ve also been adjusting from attendee to speaker and advocate

I can’t help but see some key differences in my conference experience between my different roles. In this piece, I share my comparative experience as an attendee, speaker, and advocate, as well as tips on how to maximise your experience irrespective of your title.

(Not) Guilty

One key difference when attending is an advocate is that you see attending the conference and speaking to people as part of your job. As a general attendee, even though you are representing the company, it can feel like it’s perceived as a bit of a jaunt because it’s not a common activity for you to engage in. Even if you’re a regular meetup attendee, you are going to sessions in your own time at lunchtime and evenings rather than during traditional work hours. So going to a conference during the day when you have a mountain of work to do can leave you feeling a little guilty.

This could partly be dependent on the various factors that have led to your attendance, such as:

Whether you paid for your ticket out of your pocket or if it was expensed via your company.
If the ticket forms part of a dedicated personal training budget or a centralised departmental pot. I’ve seen where this is held centrally that you are less likely to partake in training outside of internal company offerings.
The number and levels of approvals required for conference attendance and speaking. While many start-ups and scale-ups have lighter procedures such as manager approval, larger institutions may have more defined or multi-level approval processes.
Any expectations regarding knowledge sharing of what you find out. Some organisations or departments encourage you to share what you find out via internal blogs or knowledge-sharing sessions. One former colleague I bumped into at Devoxx UK was in this situation where they were taking notes so they could share their learnings when they returned to the office to justify the ticket cost.

I’ve always felt the need to maximise the attendance experience as a junior engineer when I’ve committed to sharing my experience internally when I come back to work. It’s understandable to think of this as actual work since it’s a quantifiable contribution. Often as engineers, we dismiss non-contributory efforts such as catch-ups, 1:1s, or admin because it’s not writing code. then when we transition to management, leadership, or even DevRel roles we realise that these contributions are not only valid but what we spend most of our time on. It’s important to drop the guilt, as learning new technologies and hearing about other experiences makes you better at what you do, irrespective of whether that’s engineering, management, or even advocacy. So enjoy!

Bounce Back

As you progress on your speaker journey, you’ll find you become more resilient to handling issues that appear in your talk. Possible issues are false starts, mispronunciations, and technical glitches. I remember vividly how my first-ever issue knocked me off my flow entirely. It was an online evening meetup where I drank all of my tea before my slot, and then ended up trying to curb a coughing fit live on camera with no water or beverage in sight.

As you gain speaking experience, bad things don’t stop happening. You just learn the resilience to take these issues on the chin and keep going

At that moment I wanted to earth to swallow me up. However since that eventful meetup, and through the advice of other speakers, I’ve learned that the secret to conference speaking is not that your session is full of mistakes. It’s that you keep going irrespective of the mistakes that you make. This realisation has helped me adopt a change in mindset. Despite being a pessimistic character, I no longer finish a talk feeling it was a disaster if one little thing went wrong.

I remember seeing the wonderful Gary Fleming at Lean Agile Exchange 2020. I’ve never seen someone so calm under pressure. He started his talk late because of unexpected Zoom issues at the conference. His clicker wasn’t working so he casually through it over his shoulder. Yet he gave one of my favourite talks at that conference. I remember thinking I would never be able to have that confidence to cope with the unexpected. Yet I feel I’m starting to get there.

I got through the glitches, whoop!

This year at Devoxx I had a couple of glitches. My HDMI adaptors didn’t play ball, so I borrowed one from the tech gurus. My shiny new clicker with spotlight capability, which I tested at home for 2 weeks prior, kept freezing. So I abandoned it and went between the large screen and my laptop instead. I had a couple of stutters here and there. Not everything was as I practised. Yet I managed to get a couple of audience laughs, and many compliments afterwards too, including from the amazing James Gough who has been a fantastic mentor to me throughout my career. I’m not completely calm under pressure yet, but I’m getting better at hiding it over time.

Connect

Your first time attending a conference on your own can be a pretty scary one, regardless of your role or whether you are speaking or not. You probably won’t know many people at the event. It can be a bit intimidating to try and strike up conversations with people. Especially if you are an introverted character, or are from a diverse demographic. When you feel like you stick out like a sore thumb, you may be reluctant to speak to large groups of people that you don’t know.

As I attend more conferences I’m feeling more confident about connecting with people. Between DevOpsDays Birmingham and Devoxx UK this month I’ve met with many wonderful people, and had so many interesting and insightful conversations. Not all of them are about tech either. I’ve had wonderful conversations with other speakers where we have all shared our tips. Including the aforementioned notion that no speaker is perfect, and it’s that they keep going.

Conferences are great places to connect. It can be hard at first, but you will be welcomed with open arms

It’s not necessarily that I’ve become this super confident person that can walk up to any stranger and chat away. That is still a work in progress. What has changed is that I’m starting to see familiar faces appear at conferences and meetups. These individuals are also kindly introducing me to others so I can expand my network further. Conference communities are always a friendly bunch when you get to know them.

If I’m attempting to speak to people I don’t know without an introduction, I’m learning to ask more about what others do to strike up a conversation as well. Chatting with a friend this week I agree that people love to talk about themselves, so asking questions is a good way in.

Born to Be Wild

What you do in your day job may affect what talks you select to see at the conference. Thinking back to that justification of the ticket price mentioned previously, we may naturally want to pick topics relating to the tech we use every day to ensure we have the practical knowledge to take back to our organisations. Yet we can still learn a lot from attending sessions outside of our comfort zone. Particularly when it comes to identifying emerging tech trends, different opinions, or alternative patterns.

I saw so many wonderful talks at Devoxx UK this year by some fantastic speakers, and not all are strictly related to my elected speciality of frontend development. Some of my favourites were:

The opening keynotes I caught gave some wonderful thoughts. Holly Cummins covered the emergence and future of the Java ecosystem with great humour. Asim Hussein clearly explained carbon neutrality and offset definitions in a way that means I finally feel like I understand these definitions.
Grace Jansen covered stateful and stateless microservices in a great session that helped me reflect on my prior microservice experiences as an engineer and realise that it’s not as clear cut as having all your services be stateless.
I got to see my new colleague David Pilato in action with his FS Crawler and Elastic talk. Given I’m new to the Elastic stack it was great to see a starting example of how to show off the product to developers using a meaningful use case.
Taking a glimpse into the secret life of Maven Central with Joel Orlina was great. Although I’ve only used Maven repositories with Gradle in the Java ecosystem I loved the level of transparency he shared in this talk on their scaling challenges, and how they worked with publishers to address these issues.
As a JavaScript and Typescript engineer, I was excited to see Alvaro Berruga talk about what’s coming next in JS. I learned more about the proposal process, which was really interesting. Now I know where to find the language proposals too!
Going out of the traditional Web stack with Quarkus Renegade with Sébastien Blanc and Stephane Epardaud was an interesting education. I’ll be looking to learn more about Quarkus in the future, hopefully at a London Java Community meetup!
I have some experience of Kafka from an enterprise system architecture angle, so it was great to see Danica Fine show a home project using Kafka and senors to give her alerts when her houseplants needed watering. I appreciate the practicality of this approach given my poor track record of keeping plants alive!
Martijn Verburg’s session on running Java containers on cloud infrastructure was very insightful, and I appreciated the practical tips on Garbage Collector selection. My prior experience is that GC selection is never considered, and teams always go with the default assigned by the JVM.
Seeing nature and software battling it out against each other in the security domain was an enjoyable experience. Well done to Grace Jansen for covering both sides of the battle solo!
Learning more from Guy Royse about Redis and RediSearch on an interactive adventure to find Bigfoot was a great experience. This was a wonderful example of using humour and a practical use case to showcase search capabilities. I’m hoping to give Elasticsearch justice in my new role with some of the tips I picked up in this session.
Seeing some of the ML approach adopted by Jonas Mayer, Martin Förtsch, and Thomas Endres to respond to and address sh*tposting online was very amusing and insightful. It refreshed me on some ML challenges such as stopwords and training considerations that I hadn’t been exposed to since my university AI course.
Seeing Andrew Harmel Law talk about practical tips for capturing the four key metrics from Accelerate was definitely of interest to me as an agilist and frontend engineer encouraging the adoption of data visualisations rather than the usual data grids, as per my own talk slot!
Hearing Kevlin Henney’s closing keynote on our attitudes to change in the software we build made me smile. It was great to see that I’m not the only person who has read Your Code is a Crime Scene by Adam Tornhill too!

Of course, I should also call out the social elements like Java Jep’dy, the speaker dinner, and Devrocks drinks on Wednesday and Thursday evenings too. These were great opportunities to have fun and connect with people.

It’s not so often you see a Java game show with big prizes!

I also have a few others I’m awaiting viewing when the playlist goes live:

Sadly I missed the start of Julien Dubois’s session on accessibility. As a frontend engineer, I’m wanting to educate myself more on how I can make the things I build accessible to all, so I will definitely be watching this back.
Everyone raved about Julien’s session on REST, to the extent that the room filled out. So I’m checking that out when I can!
The same goes for the React Micro frontend talk by Rotem Zifroni. I didn’t make it after my talk slot before the doors closed so I’ll be watching that closely to see how closely it mirrors my early experiences of Angular Micro frontends and the potential approaches that can be taken.
I really enjoyed the mental health-focused keynote at Devoxx 2021, so will definitely be checking out Frédéric Harper’s session emploring us to not .gitignore mental health.
I’m interested to hear Jonathan Rigby’s experiences of metrics mania in his talk when I can. It’s my experience that teams gravitate towards extremes of over-metrification, or not having any metrics at all. So I’m interested to find out if a happy medium is possible.
TDD and other drugs was full, and I heard wonderful things. So I will be watching Vanessa Formicola’s session when it comes online.
I want to hear Anders Norås’s talk on the Marvels of Teenage Engineering. Speaking to him at the conference it sounded like he had many inspiring stories about prominent technologists learning as teenagers, which I find inspiring.

Stop & Listen

Overall I’ve found the experience of attending conferences as an advocate to be an exhilarating and enjoyable one. I’ve met many people from various companies, made connections that will hopefully lead to future meetup opportunities, and also connected with prior colleagues as well.

As technologists, we should seek out more learning opportunities at meetups and conferences to grow

Irrespective of whether you are a speaker or not, conferences are a great opportunity to grow as technologists, expand your knowledge of frameworks, languages, and tools and connect with others that can educate you and challenge your thinking. These are benefits you can take back to your day jobs, not just by sharing on a blog or a knowledge share session, but also in the development of the software you build. Don’t feel guilty about taking the time to grow!

Thanks for reading! Do get in touch with your own tech conference attendance experience, especially if they differ from mine.

Get Off the Phone

A Year of Having No Work Access on My Personal Phone

For many, the end of 2021 and start of 2022 has been a time of reflection and comparing for many of us. It doesn’t help that this year social media sends us flashback reminders of prior years. Through the pandemic some of these has prompted feelings of hope for us, such as photos of holidays and family events. Nevertheless, reminders of 2020 events have shown times of great strife and regret that we would probably care to forget.

I also have similar experiences when flipping through prior blogs. They can help generate new thoughts and insights for me, which I always appreciate with a wry smile. A recent unpublished blog has got me thinking about back to January 2021, when I made the decision to remove all work applications from my phone. It was an easy decision to make at a time where I was burned out and our family were struggling with isolation after spending our first Christmas and Hogmanay, or New Years for those non-Scots reading, locked down in London away from friends in family in Scotland. I remember coming back from a two-week vacation with an uncomfortable static buzzing continually prickling through my brain, and black raccoon-like bags weighing down my eyes.

Phone are not just for chatting anymore!

It is now one year later. As I come back from a truly relaxing break with my family, embracing the joy and giggles of a happy toddler eagerly playing with his grandparents and cousins, I am glad I didn’t finish and hit send on that piece. Time and distance have helped me consider the decision in a more pragmatic way, and truly see the benefits this has given me for my work and home life separation. I did make other changes. Moving role, adding night off Thursdays to write or lounge in the bath, and ensuring I prioritise work items that I enjoy over the slog of the next item on the to do list were great aids to my mental health and wellbeing. But the most impactful one was definitely wiping all work apps, including email, from my phone.

In the midst of my return to work, I also had a conversation with a mentee who was considering installing works apps, including email on their phone. Over the years I’ve had many of these conversations with recent graduates, and each time they make me think about how keen we are to plug into the matrix of work before considering the consequences. Here I share the drivers that caused me to refute Bring Your Own Device, or BYOD, as a productivity driver, and share tips and tricks to help you decide whether unplugging from the work Matrix will work for you.

Why Do Fools Fall in Love?

The tale of how I came to be plugged in is probably an experience shared by many engineers in their initial rise through the ranks. I received my first dedicated work handset a few months after starting after a late night in the office monitoring report submissions. At this time, it made sense as it allowed me to monitor from home without needing to login from the office, or even connect remotely from home.

When the company adopted BYOD a few years later, it seemed like a natural thing to immediately adopt since I was used to having some connection to work. Despite discussion with a good friend about their decision to not adopt BYOD on returning their device, I decided to keep my access. At this point I had formed the bad habit of checking emails on my commute and at home in the evening, much like many others as discussed in this piece from 2015. I told myself it helped me see what I would face the next day and form a plan of what I needed to tackle when I made it to the office.

In hindsight keeping an eye on work emails through maternity leave was probably not very healthy!

I even continued this pattern while on parental leave. I told myself at the time that it was a useful means of keeping connected to the project to which I would be returning. I listed it as a valid learning mechanism for keeping up to date. It also formed my opinions about email as a bad medium for software alerts, which I reflected on at the time, as I found test environment alerts flooded my inbox making it difficult to find useful content. In hindsight, I now consider it more to be a symptom of FOMO and fear of being forgotten by my team. Especially since I was moved project on return to work, the time does feel wasted.

When the pandemic hit, I added our chat app to my phone to ensure I was contactable at times where I was looking after my son. I’m sure any parents reading will remember the challenge of that time. I found this constant connection contributed to a rather nasty burnout in December 2020. I have vivid memories of one lunch time where my phone was buzzing off the table with messages from my team to try and action an urgent approval while I tried to feed a weaning baby. I also found that many of us as we adapted our work hours around personal circumstances defaulted to using chat apps for everything, leading to notifications late at night for non-urgent queries.

Maintaining a work connection on my phone meant I was always on when working from home

It was clear to me I was no longer reaping that perceived benefit of preparing for the next day. Instead, it made it difficult to sleep as I thought of the next problem I would deal with in the morning. I had been giving advice to colleagues, graduates, mentees and team members at that time to think about if they should have this connection to work. Yet I never took my own advice through that time. It was this realisation that led me to pull the plug and uninstall all work apps from my phone.

Who’s Zoomin’ Who?

My story may resonate with you at this point. It may not quite have you convinced. If you fall into the latter camp, you may now be rhyming off the reasons you need to maintain your work connection after you log off. I’ve been there! I found that noting down when and what I did on my phone in a couple of days and compared them to my motivations for having the access, was helpful. I ended up with something a little like this:

*It’s worth noting down your expectations versus your mobile work activity to assess if they align*

I regularly told myself that I needed to be connected to help plan my working day on my commute, but also to ensure I could support my clients and cover support emergencies as they arose. I now see from the above listing that it had evolved to searching for issues that it became a problem. Or as an attempt to multi-task when I really should have been focusing on picking up the food Mini R was enjoying throwing around the floor. Part of the problem in that latter scenario is since you don’t really have context of the message, you don’t know if it’s ignorable or not. Meanwhile, now that I am only contactable via a phone call, I’ll only be contacted for true DEFCON 1 instances, leaving me time to focus on lunchtime.

The other opinion you may have, which many new developers and myself at one time have, is that you don’t have anything else to monopolize your time. Therefore, occasionally checking work while chilling with Netflix isn’t the biggest of deals, and not a major inconvenience on my time. While I do agree that I no longer fit in this position, and now that I have a family my time is more important, I do have some regret of the things I could have used that time for instead of working.

Among other things, I wish I had taken more bubble baths instead of being on my phone

Perhaps I could have written more. Or took part in more spare time coding. Or taken many more relaxing baths, which I now wish I had the time to do. Or had more uninterrupted conversations with my partner instead of us both sitting glued to our phone while watching TV. Or even gotten through an extra book or two if I did want to ignore Mr R watching the football. Be more respectful of our time outside of work. Even if it works out at around 47 minutes a day.

Constructing the Connection

I know I won’t have convinced all of you. I may be lucky if those determined to maintain access to work on their personal devices have even read to this point. New features are available on our phones to help us manage application time more effectively, which either didn’t exist or I didn’t know about when I was a member of the BYOD club.

These days you will not find any reference to work on my phone, and I’ve never been happier

My viewpoint will definitely not resonate with everyone, so if you are in the pro-BYOD camp, I do have some tips to help you avoid some of the challenges I faced before I pulled the plug on BYOD:

Think about your role and the potential reasons people may wish to contact you. This can help you triage messages and decide which are DEFCON-1 panic stations compared to the sleepy normality of DEFCON-5.
Avoid blindly downloading all available applications or setting up all media on your phone. Take a moment to think about which applications you truly need to access based on the reasons you have previously identified.
Block out your evenings on your calendar to protect your evenings from calls. This is particularly important for those working for global organisations outside the US.
Set a limit of the amount of time you spend on these apps outside of work, both at evenings and weekends. Try setting usage limits or focus time settings for those applications to enforce your limits. Some apps allow you to do this within the software itself, but Android and iPhone have various wellbeing options that you can use to limit applications, and set do not disturb settings for overnight.
When using these applications outside of this time, be mindful of your own usage of chat versus email for any messages that you send to avoid distracting others. Try to respect the decision of others.
Preferably try to have access free days at the weekends to get a true break from work.
Consider having your phone number available in the company directory or shared with relevant colleagues for true emergencies. This is one that I have kept as a compromise.

Irrespective of your choice, no way is right or wrong. I know that having that separation is definitely the right decision for me. I wish I hadn’t rushed into connecting to the matrix so quickly. Together we need to respect the decisions of those who are unplugged versus plugged into work all the time. What is more important that we take care of the wellbeing of colleagues in both groups and be on the lookout for burnout in ourselves and others.

Thanks for reading! Best of luck finding the work connectivity that works for you. Do reach out if you would like to share your experience or want to discuss which option may be right for you.

People Power

Reflections From Lean Agile Exchange 2021

As both an agilist and software engineer, I enjoy attending a mixture of conferences. Yet in discussion with developers I sometimes am asked what kinds of topics are normally covered. Or even hear jokes about which methodology won in the battle of Scrum vs Kanban (sigh). Or even asking about the soft skills covered with derision, thinking that the lack of super technical content makes them less interesting.

The reality is that Agile conferences cover a myriad of content encompassing various domains, including but not limited to psychology, sociology, agile theory, leadership, testing, software engineering and others. While some may consider technical knowledge to be specific to programming and computer science concepts, I would suggest knowledge in these other domains shows technical expertise. Here I reflect on some of the amazing sessions I watched and presented this year, and what I learned.

Uncertainty Still Prevails in our Work and Personal Lives

The events of the global pandemic over the past 18 months were very much a theme in many sessions at the conference, including in the opening keynote by Sam Conniff, titled Uncertainty Experts. The reality is that uncertainly also impacts us within our day to day work and home more generally. Sam tells the story about how in the face of difficult personal circumstances he interviewed individuals who had faced significantly challenging times to discover how they handle uncertainty. This is an interesting concept as humans are not really wired to handle uncertainty very well. It’s not just me!

We face uncertainty in our work and personal lives

If you are curious, KPIs are business metrics that reflect the performance of the department or organisation. However, OKRs are goals you set yourself to improve you performance and drive the change you want to see. This piece summarises it well that KPIs measure performance and OKRs help you decide what to change or improve.

The people he interviewed have been through far more significant challenges than most of us have in our lifetime, including but not limited to prison time, abduction, undergoing gender transition and gang membership. Through these interviews and collaboration and a group of scientists, he discovered the 3 primary factors that affect our ability to handle uncertainty:

Through fear we default to automatic responses that have worked for us in the past. These are known as safety behaviours. This interesting fact sheet gives some very relatable examples of safety behaviours that I’m sure all of us have exhibited.
A fog comes over us which stops us from reacting, known as uncertainty tolerance. As a very risk averse person I definitely see myself as having an intolerance to uncertainty.
Conviction Narrative Theory enforces a level of stasis in us which leaves us struggling to adapt to the current situation.

Sam has since collaborated with scientists to produce an interactive documentary to help participants build resiliency when facing uncertain events. I’m definitely interested to see the impact as building resiliency following a bad case of burnout in 2020 has been a focus for me in 2021.

Our Bad Questions Impact the Response We Receive

Collaboration and communication are required elements for working in software development teams today. From some coaching training I’ve attended in the past I know that we need to embrace open questions to give people the space to speak their mind. However, through Priya Sinha and Ragan McGill’s session I discovered there are other types of questions that could be impacting the responses we get.

In Seven Sins of Questioning, they cover 7 other question types that we should avoid in our communications:

Question Stacking where we ask all the questions at once in a large brain dump. I see many people, including myself, resorting to this tactic.
Leading questions that you ask assuming the other person is wrong. These can come across as arrogant or annoying.
Why questions that put people into a defensive mode. I see these are commonly asked when things go wrong, and thinking to Mehmet Baha’s session on Psychological Safety, could impact the ability of a team to perform intelligent and improvable mistakes that we can grow from together.
Dirty questions that carry a subtle bias, but don’t carry the message that the other person is wrong. A good example is where your question implies an action.
Binary questions where responders can only answer yes or no. There are many shared of grey in this world, meaning that most of the time the answer isn’t simply yes or no.
Self-affirming questions. These are often binary, but carry a special motivation to coerce agreement.
Aggressive questions that provoke people to make assessment about the future before they are ready. The speakers recommend using the Present, Past, Future framework as an alternative to this approach.

We are all guilty of asking these types of questions. What’s important is to be mindful of these questioning antipatterns, and avoid them where we can to ensure respectful communications with colleagues.

We Should Embrace Being Blocked

Handling blocked work items is not specific to software development practices, but it does cause us all pain. Perhaps it’s down to the impact of interruptions on flow state, which is a rather unique construct of programming. I found an old article that suggests it takes an average of 40 minutes to resolve a blocker. This does overlap slightly with a recent talk given at Devoxx UK on the developer experience, which I’ll share my thoughts on soon.

The importance of being blocked by Nick Brown rightly points out that we become blocked for a variety of reasons. While I assume the aforementioned 40 minutes concerns factors within our control, such as breaks to search an error message, or perhaps struggling with our tooling, organisational dependencies are also a factor. Particularly for those working at larger enterprises where we can perceive particular procedures and bureaucracy to be unnecessarily hindering our productivity. I’ve been there!

Embrace being blocked!

I agree with Nick that most teams do not have a consensus on what blocked means or how to handle blocked work. This observation mirrors my own experience of using obstacle boards a few years ago, which I presented at LAX 2020. We found that by using an obstacle board for data integrity impediments that team members therefore only considered those types of impediment to be suitable for capturing, and failed to adapt it to include other elements that blocked their work.

We’re naturally conditioned that if we get blocked on something, we keep busy and move on to something else, which can be a bad idea. I was reminded of this only this morning, where I logged in to see 1 column on our Kanban board was breaching the item limit. Even a glaring red state can be ignored in our pursuit to be productive. It’s important to enforce limits, and focus on clearing these states together.

Technical Debt Is Difficult to Define

Einar Host’s session Technical debt isn’t technical was a session at the top of my watch list when I pulled together my initial list of talks I wanted to attend ahead of the conference. I find we struggle to agree a common definition as to what technical debt is. Discussions and debates with colleagues over the years show it is a wide ranging term, where we consider troublesome parts of the code, potential refactoring(s), infrastructure upgrades, architectural transformations and even regular library upgrades to be potential technical debt. Even at conferences I have similar discussions with individuals working at other technology firms, so no organisation is immune to this debate.

Rather than an amusing picture and text combination like this, the original definition of meme, or memetic refers to a term that has become ingrained in the collective consciousness

Einar interestingly refers to the term technical debt as a meme of sorts. Rather than an amusing picture and text combination like this, he is referring to a term that we have unconsciously picked up without realising it. In 1999, the Los Angeles Times likened these ideas as a kind of virus that is propagated through the population irrespective of it’s truthfulness or adherence to logical principles. I do agree that technical debt has become such a term, leaving us unable to determine it’s true meaning or origin. I’ve also found many terms in my time from both the technology and finance domains that people know and rhyme off without knowing the true definition. A key one from my first week as a graduate engineer was Defined Liquidity Group, which people used without thinking. Anyone who is curious about what a DLG is can check out this overview from the FCA.

Einar summarises that the definition of technical debt is that horrible spaghetti code containing many logical branches. His story from his own employer, a Norwegian TV company, definitely proved feed for thought for me. The different types of TV shows and their varying consumption methods, such as the news compared with a series compared with a docu-series, reminded me of similar issues I’ve seen in my time. Not only will you struggle with these as the system grows, but it will be a nightmare for those looking after your system in 10+ years time. I’ve been on the receiving end of both of these scenarios and neither are pleasant!

The Different Between KPIs and OKRs is Often Confused

I’ve struggled with the difference between KPIs and OKRs myself. Cansel Sorgens had a great talk on this, using her own experience of building her own OKR coaching and training function to explain the difference. The session was very interactive, with some polls to show the differing understanding in the room.

Think carefully about the KPIs and OKRs that you track

The Spotify Model Exists But Is Often Implemented With Antipatterns

I was really interested to see the keynote So you copied the Spotify model – here’s what you got wrong as a variant of the Spotify model was the transformation technique used by my current employer. Joakim Sunden was an Agile Coach at Spotify for many years, so I felt these insights would come from someone who had been there, done that, got the t-shirt. That was indeed the case.

In my own experience I already knew that we had adapted the model. I was also not surprised to hear his sentiment that many organisations exhibit many antipatterns in their adoption of the model. I’ve definitely seen many of them applied in practice, most notably using chapters to represent reporting lines. In my personal experience, organisations use this to mirror their existing structure over more radical change. It also leads them to struggle to reflect the technical disciplines that it should represent, leading to confusing jargon that tries to cover both bases.

A common antipattern of Spotify model role-out that I’ve seen is keeping the existing department structure but changing the names

While I’ve not used SAFe, this was also discussed as having some questionable adoption. Speaking to colleagues and family I’ve seen SAFe applied without much thought, leading to teething problems. I find putting scaling frameworks directly on top of an organisation without attempting to foster the collaborative and psychologically safe culture leads to much distress and frustration for people. His advice to identify pockets in your organisation that are adhering to the target ideals, and considering SAFe as a toolbox of techniques that don’t all have to be applied resonated strongly with me.

Loneliness and Bonding Affects Our Performance at Work

Emily Webber’s keynote The Magic of human Connections focused on just what the title states, which reflecting on how the pandemic has negatively impacted our ability to establish those connections. I was rather surprised to find out that loneliness impacts our performance at work. Thinking of my own experiences over the last year I do see that aspect in my performance, where as 2020 rolled on and I felt more isolated, I struggled more at work. She also highlights the are 4 key elements of modern teams that can increase loneliness:

Moving people in and out of teams
Encouraging segregation of duties which can leave people feeling interchangeable
Moving people to temporary secondments, or splitting their time between teams
Establishing short-lived teams to work on temporary projects

I hate to say that I’ve seen all of these antipatterns applied. Not only applied to myself in contributor roles from managers, but I’ve also performed the same sins as a prior manager as well. I definitely intend to avoid such patterns in the future as best I can.

Nobody wants to be lonely

Bonding within teams was also highlighted as a contributor to performance. People who feel connected to their colleagues feel less lonely and therefore perform. It has definitely been my experience that bonding is important for establishing and resetting teams, as I outlined in my own talk Confessions of a Sprint 0. People need to feel they belong to a community of sorts. I loved Emily’s story about setting up random coffee matches within her Agile In the Ether community as it shows a great way to expose people to serendipitous connections.

Final Reflections

Yet again I felt that I left LAX with more insights than I entered. There were so many other lessons that I learned at the conference, to the extent this blog could probably be double the length. So instead I encourage you to search for the videos when they are available on Vimeo in a month or so. Until then, consider a question we were all left with at the discussion session Shifting ways of working- what have the last 18 months taught us?. I am still asking myself How do we look out for those struggling who are not raising concerns in our organisations? I leave that for you, dear reader, as some food for thought.

Thanks for reading! Looking forward to (hopefully) attending LAX again next year.

Coming to the Stage

Comparing In-Person and Online Meetup Lightning Talks

I hear the buzz of murmurs for an excited crowd. The sound of glasses and beer bottles clinking as strangers meet and introduce themselves hums behind excited conversations. Heat from the lights and projector hits my face. The smell of wood from the bar floor fills my nose. A strong feeling of fear resting in the pit of my stomach rises towards my throat.

Speaking in public is a terrifying prospect for many of us

This might sound like the confessionals of a stand-up comic or breathy saloon bar singer. However, dear reader, this is the memory burned into my brain as I took to the stage for my first ever in-person meetup talk. My symptoms sound rather like those of a fear of public speaker, just as Deborah Frances-White outlines in her amazing TEDx Talk on stage fright. Deborah shares a great theory that fear of public speaking stems from our survival instincts, and the need to avoid being lunch. You might think this is not the biggest deal. It was a ten-minute lightning talk. Hardly an escape from a pack of lions!

Yet for me it represents a major milestone in my continuing speaker journey. I started dabbling in technical speaking just over a year ago, through the global pandemic. With many meetups and conferences taking place online through that time, all my experience is based in the online world. Often, I would stand in my spare room, talking at an empty screen. That is vastly different to the in person experience I have just described.

In the hopes of dispelling some fear and myths of those others who, like me until recently, have only presented online, I regale the experience of my first in-person meetup. I will discuss the key differences between these two formats. Finally, I will give some useful tips to help you prepare to step out into the physical spotlight and give your first in-person talk.

Back Stage Pacin’

Despite having given a longer version of the same talk at a couple of online meetups, I still felt exceptionally nervous ahead of this first engagement. Part of the reason was down to going to a new meetup, with a lack of familiar faces in the audience. Poor Mr R was subjected to two practice runs in twenty-four hours as I tried to prepare and adjust to the altered talk flow.

Those same nerves did not disappear on the train. As you can tell from the below tweet. Instead, I tried to think of the advice I have heard from many fellow speakers that nerves never go away, and that it is simply a case of embracing them.

As you can see from my pre-event tweet, I was feeling pretty nervous!

I got chatting to a couple of people when I arrived, which was a welcome distraction. When the time came for the session to start, I grabbed a seat at the front to make it easier to step up to the stage at my slot without worrying about tripping over others, or indeed my own, feet.

Speaking to a new group of people when you are establishing yourself contributes to your nerves. While waiting your turn in a group of speakers can build up your fear, when new to a setting it can also help you get a feel for the audience, as well as being useful for picking up presenting tips. Thankfully, I was one of Five speakers that evening, and the last to go. This gave me the opportunity to see how chilled out and welcoming this group were.

Stage Fright

Taking to stage felt like a surprisingly natural thing. Most likely my brain telling me this is the same as all the online talks you have given to your laptop before. I could not employ the trick of speaking to the friendly face because, not to say that this audience were not friendly, but they were strangers to me. So, my focus point tended to float around the audience to prevent me uncomfortably staring at one person for the entire talk.

It is far easier to gauge the interest of the audience as you speak when you’re in front of a live audience, compared to black boxes on Zoom

One of the key advantages to speaking in person if you gauge the interest of the audience as you speak. With online talks, there is a great disparity in the level of feedback you get as you are speaking. Depending on the audience and tooling of choice you can be speaking to boxes of nodding heads, black rectangles, or even a black void in the case of Webinars.

In person you can determine the reaction to segments of your talk. I discerned the nods and smiles as showing acknowledgement of a potentially insightful point. Laughs meant that joke I made landed well. Even the one about hurrying up so we could all get to the bar seemed to get a small chuckle! Thankfully I did not see anyone screw up their face in offence or derision, so no controversial points seemed to have been made by myself thankfully!

In my experience, answering questions are a common attribute to both types of meetups

One common attribute shared by in person and online talks is post-event questions and feedback. Online meetups normally include a few minutes for questions after a talk that can be asked directly or via the integrated chat feature. In person, while there was no Q&A segment, people were happy to approach me afterwards with any questions they had. I even got some great suggestions on how to improve my slides by a fellow speaker, for which I am incredibly grateful.

Online, I have found that feedback is normally submitted afterwards in forms or in the integrated chat. I have always enjoyed answering questions and using those perspectives to inform future talks. It was reassuring to find that common trait between these two formats.

She’s Still the Star

Overall, I found that many aspects such as questions, nerves and support are very similar between online and in-person meetups. Given that many in-person meetups have spawned from a need to move in-person sessions online to meet the needs of their communities, this makes a lot of sense. Online communities are very accessible to people who need to be home in the evening for caring or other commitments, and there is still a need for both formats as the state of hybrid working evolves.

In person meetups allow for organic conversations over a drink, which are missing from online forums

Nevertheless, one element of in-person meetups that I do not feel has been replicated successfully are the conversations you have after the talks are over. Talk questions organically morphed into full conversations into technology, best practices, and career experience. I have seen attempts to replicate this practice with post-event breakout rooms.

The unfortunate reality is that most people will head off from an online meetup as soon as the meeting closes. It is almost as if working remotely has morphed these jovial encounters into another meeting slot. I hope in time we will come to figure out how to integrate the social element into online meetups to preserve their accessibility.

All the World is a Stage

Overall, my first in-person meetup experience was a positive one. Much like the online communities I have spoken at, the audience wants you to succeed. I am not the gazelle that this pack of hungry lions wants to eat. They are actually more interested in pacing around the bar after I speak in search of a libation.

Meetup audiences, unlike a pack of hungry lions, want to see you succeed on stage

I am glad to have participated in this exercise. It serves as good practice for my next in person speaking engagement for when conferences resume. I am hoping to speak in person at Devoxx UK in November, assuming in person goes ahead. I am so excited to have that opportunity. This first in-person experience has been a good starting point focusing on a smaller audience, that I hope to build upon in future.

Thanks for reading! Do share your own experiences of lightning talks, in any format. I would love to hear how you get on!

Let The Record Show

Confessions of Creating My First Pre-Recorded Conference Talk

Recording yourself is hard! Recording yourself is downright uncomfortable! Nevertheless, with us all working from home for the past year it has become a more common format for conference talks. Live talks are still happening, and for tips and tricks for that format I recommend you read Helen’s amazing blog post on the topic.

Up until now all the talks I’ve given have been over Zoom. Despite those all being recorded, I’ve only once had the nerve to watch myself back. I’ll be honest, it was not comfortable.

Recording your first pre-recorded talk feels just as intimidating as standing in front of the mic for the first time

I recently had to record and edit my first talk. I made a lot of mistakes while doing it. And many of them seem completely daft now! Through sharing my Confessions of a Sprint 0, I’ve also uncovered a new set of admissions relating to the challenges of recording my first talk, and more mistakes that I have made along the way. Here I regale the lessons I’ve learned, as well as some right daft tales of getting your first recording wrong, to ensure that your first recording experience goes more smoothly.

What Makes These Talk Types Different?

In my continuing speaking journey, I have been fortunate enough to have given talks at various forums including speaker groups, meetups and one online conference. I have observed that there are several key differences between live and pre-recorded talks that make them more difficult to prepare for:

It may sound obvious, but they are due earlier than the conference. This means you need to be slightly more organised about preparing for the upcoming deadline.
There are stricter boundaries between the speaker and the audience. This can make projecting your natural energy and authenticity difficult.
It will take a lot longer than you expect to prepare. In addition to the recording, you’ll also need to spend time editing the recording as well.
Speaking of editing, it may be the case that as a new speaker that you don’t have any editing experience. You’ll also be unlikely to have any editing software installed on your machine. I fit into both of these camps!
Using some formats and mediums are no longer available. Techniques such as polling are not possible unless you ask the organisers to incorporate a live element at the start.

Tips and Tricks

Despite these challenges, I do have some tips that will help you pull off looking like a pro-speaker, even when recording at home.

How to Show Genuine Energy

As you can imagine, talking to yourself is pretty uncomfortable. It’s easy for that energy to translate badly in a recording. Even someone as bubbly as myself came across as flat when I did my first recording on my own. I was so unhappy with that version that I re-recorded the entire thing again before editing.

When giving a talk, you want to come across as genuine, and project your natural energy. I found practicing a few times before you even start recording helped me settle the nerves and find my flow. I did have simple notes up on the screen for each segment to keep track of where I was. However, I recommend you avoid running through a fully written script unless you are confident it won’t sound flat.

It’s difficult to show energy to an empty room, but there’s nothing stopping you having some moral support hiding behind the camera

No one really said you had to speak to just the camera. It is possible to try and elicit help from a friend. This individual could either join muted to a video call that you are recording. Or, in my case as my helpful husband did, stand attentively behind my laptop, so I could look like I was looking at the camera, but was speaking to him instead (thanks honey!).

How to Record Yourself

There are two key themes you need to be mindful of when recording yourself. The first, and hopefully more straightforward item, concerns the software itself. You can easily use the default camera app on your PC to record. However, if you need to apply a background for the conference, or in my case blur the background since my curly hair interferes with the background, you’ll need to use alternative software.

With us adapting to working from home through the global pandemic, we have had to acclimatise to video meeting tools such as Zoom or Microsoft Teams. Zoom specifically has a recording function, which can also be used with the free version. Simply join a new meeting, setup your background or blur, and hit the big recording button.

Consider your recording plan before you start recording, but it in parts or as a single run

Before you hit the recording button, take heed of whether you want to record in a single run or in sections. I initially took the advice to record my talk in batches, and split it into sections of a few minutes that would fit with my transitions and section slides. For me personally it didn’t work for several reasons.

Trying to record segments between meetings meant I didn’t have continuity of lighting through the recording. So be mindful that the segments need to be recorded at a similar time of day.
I would psych myself out when I made a mistake, meaning I would try again and get into a loop of making mistakes. Before you ask, I’ve now deleted the bloopers reel so unable to share these. Sorry, not sorry!
I would cut at the slightest mistake, rather than accepting the imperfections that show my humanity and leave them in. This meant rather than having a perfect video I would have loads of continuity issues that I had to address through transitions. It would have been better to keep the stutter over going from wide smile to concentrating brow in a single frame!
I struggled to keep to time, since I was recording in segments. This resulted in a far longer talk than I wanted. Editing the recording to time without introducing continuity errors was impossible.

In the end, I took the advice of my conference mentor and recorded the talk again in one take. Thankfully, since it was 15 minutes long I could do this. For talks longer than this I would try to break it into 10 minute chunks, that I would time, and included transitions to address the continuity issues. Also make sure to add a buffer of at least 1 minute to ensure you don’t run over. I would also add in transition time on top as I just squeezed in at 30 seconds under time when this was taken into consideration.

Editing Tips and Tricks

Unlike some friends and colleagues that have experience of video editing from their side hustles, this was my first time doing any form of video editing. Whenever I’ve had to record sessions in work, I tend to air on the side of hitting upload. Mainly because sessions included Q&A segments where I wanted to share the questions and answers. But there was also a part of me that dreaded watching myself back and saw a direct upload with "Och it’ll be fine!" to be a way of avoiding an uncomfortable experience.

Watching yourself is hard! You’ll spot imperfections like your hair being out of place. The non-mirrored view may be rather confusing. And you will not be able to stop yourself wondering "Wow, do I really sound like that?!". Although many have told me it gets easier over time, I’m still not quite there yet. And when you’re having to watch segments over again to try and perfect alignment with slides or to add in transitions, it becomes and even more uncomfortable experience.

Watching yourself while recording can be quite an uncomfortable experience

What will help with the discomfort is trying to avoid editing excessively to make yourself sound perfect. Editing out ummms, brief stutters and embarrassing moments when the dog walked in or the doorbell rang can have a negative impact on your continuity when cut.

We’re often given feedback in presentation workshops that ummm is a bad word, that should be avoided to achieve presentation perfection. The reality is the occasional one is not a big deal. We’re all human after all! Embrace the occasional imperfection in your recordings and focus instead on ensuring continuity of flow, particularly when it comes to hand gestures and positioning.

How to Produce a Quality Video

Editing my first recording was very much a learning experience for me. I was fortunate to attend a workshop that gave some tips on recording and editing. Examples were editing using Camtasia, and it initially looked very simple. But upon seeing the high cost, and not having any other need for editing software, I began scouring the internet looking for a free alternative.

Free trials for many popular tools, and some other free to use tools were out as they added a watermark on the video. You definitely don’t want a tool watermark in your for a conference recording! I settled on OpenShot, an open source editing tool that doesn’t add a watermark.

I had to redo my edit a couple of times as I dived straight into editing my video after watching a couple of tutorials on YouTube. Looking back on the experience now, I wish someone had shared the below tips with me.

Managing Layers

Firstly, try and keep each content type on its own track. I found it helpful with ensuring transitions between my section slides and video segments were clean. It also helped prevent situations where the accompanying slide hid my video, especially in the segments where I am visible at the bottom corner of a slide.

I had a slides layer, a video layer and a section transition layer to keep myself right

Splitting Video

There will most likely be small cuts that you need to make. One possible reason to remove segments is to eliminate trailing segments at the start and end when you’re pulling your concentration face to find the start or stop button. Another reason could be removing segments to meet time constraints or that must be removed even to keep with our not so perfect ideal. Or even just splitting video segments apart to make transition management easier.

Most tools, including Open Shot, have a paddle that allows you to forward through segments. From this point, you can select the video segment you would like to cut, right-click and select the slice option. You will be able to keep both sides, or just the left or right as you can see from the screenshot.

You can slice video segments and keep either one or both segments

Separating voice and video may be something you want to do if you have busy segments such as animations or content showcasing an interactive workflow. I initially experimented with this technique, which is very simply in most video editing tools. If they are anything like Open Shot it’s a case of right-clicking the video segment you want to split, selecting one of the separate audio options (most likely single channel) and deleting the video segment to keep only the audio.

*You can choose to separate video and audio to keep audio only*

In my case I kept myself on the screen throughout, alternating between the bottom corner and full screen. Ideally you want to present yourself on the screen throughout. It is you and not the slides that are the main event!

Slides and Transitions

Producing a simple recording of yourself on video with no other content will be far more straightforward. However, to give your talk a more polished look, to show materials or references for the audience to capture, or even to walk viewers through more technical concepts, you will need to add additional content.

In my case, I added slides to my presentation to fulfill three objectives:

Separate sections of the talk
Showcase key resources
Reinforce the tips and tricks I gave at key points in the talk

Camtasia would make slides easy to include as it has a Powerpoint plugin. However, Open Shot does not have such a feature. Instead I had to export my slides as images and import the images to Open Show as project files so I could include them on the desired track.

To ensure a more polished finish, you’ll also need to add effects to ensure a clean transition between the video and slide content, or to accommodate any continuity errors.

Open Shot allows you to add transitions onto a media element. This is done by selecting the transition effect of choice and dragging it onto the media element which you want to apply it to. I generally found using fade with a duration of 1.75 seconds worked for me.

*Drag a transition from the panel onto the media to apply it*

I would also suggest adding the same transition reversed on the other side for symmetry, which can be done by right-clicking the transition and selecting the Reverse Transition option.

You can also reverse transitions at the other end of a particular media type for symmetry

Video Exporting and Profiles

You might think that once you’ve gotten past the challenges of editing and watching yourself repeatedly that the hard part is over. However, there is one gotcha left that rather badly caught me out. It concerns editing and exporting profiles.

Conferences will specify a format to provide your talk, most likely MP4. But there are various different profiles that correspond to that format relating to size, pixel density and frames per second of the video.

Initially I found that my recording audio had a 1 second delay compared to the video. It turned out I needed to specify the same export profile as the profile in which I edited the video.

Look for something like Choose Profile from the File menu, which is exactly how it is made available in Open Shot. The same profile should be selected in the export dialog, accessible using the Export option under the File menu.

Check what profile you are using while editing…

…matches the export video profile

Closing Comments

Looking back now, recording my first talk was not as stressful as I thought it was going to be. Setting yourself slightly earlier deadlines and checkpoints, just like any work deliverable will give you additional time to try and redo any segments that you later decide are not quite right. If you are representing an organisation that would wish to view the recording before it is sent, also factor that time into your deadlines to ensure you’re not late submitting your talk to the conference.

I hope that by sharing my experiences of my first pre-recorded talk that you will feel better prepared for your own. In addition to the guidance I’ve outlined here, I strongly encourage you attend any support session the conference runs to help you with recordings. Also ensure that you read any recording instructions the conference gives you prior to hitting the record button.

Thanks for reading! Do share how you get on with your own pre-recorded talks. I would love to hear how you get on!