Kevin Lewis

Kevin's Operating Manual

Last updated: April 30 2024

This is an operating manual which introduces me and how I like to work with others. It's goal is to remove ambiguity and set up a relationship for success.

This document starts with some background about my personal life and work history, then moves into my working style and communication preferences, and finally provides some background context for how I view the responsibilities of Developer Relations.

Personal Background

  • My name is Kevin, but I’m also happy to go by Kev. I use he/him pronouns.
  • I am British and lived in London most of my life, but moved in October 2022 to Berlin with my family.
  • Adi (pronounced A.D.), my partner, uses they/them pronouns. They work at music tech company Ableton (reason we moved) and heads up efforts to make their software, hardware, and commerce experiences accessible to those with disabilities. They have a PhD from the University of Nottingham exploring Accessible Digital Musical Instruments. They are a pianist, and all-round awesome person.
  • I have two daughters - Sage (born 2020) and Nova (born 2022).
  • I absolutely love tabletop gaming (board and card games) and have quite a collection. If you ever want a recommendation, I’m your person. Also happy to facilitate online sessions of games with good clients.
  • I really love teaching, with an affinity for early-career developers. I believe you can have the most impact at this point in someone’s journey.
  • While I am a self-taught (mostly JavaScript) developer, I did end up taking a break from freelancing to do a bachelors degree in Creative Computing to learn new ways to apply my skills and build my creative muscle. Talk to me about building escape rooms, weird Furby-based art installations, and publishing a short paper on social deception games.
  • My biggest skills are
    • Seeing the bigger picture - I understand how my team’s work impacts across the organization, and seek opportunities for collaboration with other teams.
    • Teaching & learning - I love helping others upskill. If I have knowledge and you want it - I can find ways to share it in a way that works for you. I know how I learn best, and when I’ve learnt enough to be effective.
    • Being a “doer” - I take pride in my ability to take on a problem and solve it either collaboratively or alone. I’m happy to work with and support others, or independently if needed.
    • Building Efficient Processes - I love building systems that allow for the minimum viable admin while allowing for scale.

Professional Background

  • I got into programming by being encouraged to attend a hackathon by a friend. While I couldn’t code and didn’t contribute much that was meaningful, I had an excellent time at the event and started to teach myself how to code starting with front-end development.
  • I attended many more hackathons (mostly run by one company), using them as a test bed to learn new skills. I started volunteering to help run them, and eventually joined the company as an intern evolving eventually into their Developer Relations role.
  • That was in 2014, and I’ve been almost exclusively in Developer Relations since spanning almost every responsibility in the job family. Some notable roles:
    • I ran a developer events agency for two years and I am very opinionated about how to make events successful both as external contributors (sponsors, partners) and in the first-party design and delivery.
    • At Vonage I worked in the 40 person Platform & Developer Experience team as a EMEA Developer Advocate. I created a learn-to-code course which was used both internally and externally - taking people from zero knowledge to proficient-enough to hack something together.
    • At Orbit I got to think about meta community-building - principles that work in companies at many stages with differing goals. I also built out developer tooling for working with the API and integrating third-party platforms.
    • At Deepgram I ran Developer Education - working cross-functionally to determine content strategy, and then ensuring it was delivered by me, a member of my team, or facilitating creation from other staff or community members.

Current Side Projects

  • I am the sole operator of You Got This - a learning hub dedicated to core skills. We run 6+ community events a year including a big January conference, and maintain a free-to-access content library so people can have a happier, healthier work life.
  • Hack Labs Inc. is a R&D consultancy I co-own where we run hackathons with our network of expert developers and designers. We create the right groups of hackers to answer specific client challenges, and pay them for their time. Most clients are government agencies and charities.

Working Style & Communication Preferences

Working Hours

  • I value flexibility in working hours, and that cuts both ways. Sometimes I’ll be away from my desk, but I’m equally happy to work late if needed. I believe work has to mold around life - not the other way around.
  • I am chronically-online, meaning that I will check in with emails and messages throughout the day, even outside of core working hours. I will always aim to be clear about how much headspace I can give a request if I’m not at my desk.
  • I don’t mind taking ad-hoc late meetings and recognise this is part of working in a global company, but recurring meetings should be within my core work hours.
  • I will post links/thoughts/updates at any waking hour. I absolutely do not expect you to respond or engage until you are working.
  • I use the availability feature in our company's chat app extensively and it should be trusted.

Asking For Help

  • I am absolutely shameless about asking for help and support where needed, and value that in others too. We are all working towards the same goals, and that means pooling our collective knowledge and expertise. I certainly don’t know everything, but I am very happy to learn.
  • If you have a specific request - be explicit. While it’s no problem for me to ask more questions to gain context, it’s easier and quicker if you are clear upfront.
  • Even with clear requests, always provide relevant context. I am swift to act when asked for opinions or solutions, but I can only be effective in offering suitable solutions if I understand all of the context.
  • I tend to be action-oriented. If you ever need me to just listen without offering solutions/advice, just tell me.
  • Indicate urgency. If something needs a quick response or has a short-term deadline, let me know.

Communication Preferences

  • Async is preferred. Because I work so many hours away from most of my team (Eastern +6), it’s not reasonable to expect I can regularly make calls throughout the whole US working day. For this reason, I like simple asks to come as messages and I will be able to respond more appropriately.
  • Meetings only when meetings are needed. Avoid meetings which are simply status updates - I can read these. Make the most of our synchronous time.
  • Open, honest, and direct communication. We’re not robots, we’re people, and we have thoughts, feelings, and concerns to balance. Tell me how you’re feeling and we can keep finding opportunities to repeat things that make you feel good, and manage things that don’t.
  • Fact vs opinion. I am highly trusting, so if you present something as fact I have no reason to disbelieve you. If the difference between fact and opinion is relevant, make it clear what your statement is.
  • I’m a bit scatterbrained when brainstorming. If I’m going off in a direction you don’t think is useful - tell me. I won’t be offended and it’ll help us stay effective.


  • Strong teams have trust, and that means developing a good relationship that is centered on more than just getting the work done. I value time to talk about more social topics, especially as a fully-remote worker.
  • Disagree and commit. We might not always agree, and regardless of where we land, I expect everyone (inclusing me) to get fully behind a decision once made and deliver to the best of their ability. To make this successful, we should explicitly agree once the point to commit has been reached.

Working Style

  • Developer Relations is a very varied field and there will always be many ongoing pieces of work. I thrive in this environment and will move between tasks rapidly while ensuring deadlines are met and urgent tasks are prioritized.
  • Done is better than perfect, to a degree. Once a project reaches a point where further effort doesn’t improve the outcome by an equal amount, I will question whether further work should be done.

Meeting Etiquette

  • Please try to not be late to meetings. If you are running late, communicate this ahead of our meeting start time so we can adapt.
  • If I haven't heard from you before the meeting starts and you are late, I will message you at 3 minutes to check in, and at five minutes I will suggest we reschedule to free up the immediate time.
  • Try to book an appropriate meeting length for the topic. If we are approaching time try and wrap-up so people can leave on-time. If it's an urgent topic, gain consensus about whether people can stay. If even a single person can't, it's a sign we should stop the converastion to make sure they are included.
  • I prefer a "one and done" style of meeting. There are times where having time to think on decisions is valuable, but where possible I like to see a topic through to it’s conclusion in one go.
  • Summarize action points at the end of meetings and make sure everyone knows theirs along with deadlines and urgencies.

Developer Relations Principles

Developer Relations is a broad discipline ranging many responsibilities. At its core, DevRel is a about helping developers (as peers) discover, understand, and be successful with using our product.

Developer Advocates are developers with a high degree of communication skills and empathy. We understand how developers work and feel, and use this to further business goals. Developer Advocates are generalists and can complete many of the tasks below, but often have specialisms. Here is how I group the responsibilities:


  • Third-Party Community: finding initiatives where other people have built the audience, and engaging in them. Research, event/podcast/newsletter sponsorships, speaking opportunities, being good community members.
  • First-Party Community: building our own community of people who opt-in. Running events, ambassador programs, newsletters, community forums.


  • Online content
    • Contributing to documentation: conceptual learning, getting started, feature explainers.
    • Blog posts, videos, livestreams, podcasts: use-case, reputation-building, partnership, inspirational.
  • Event content
    • 5 minute demos
    • Booth engagement tools
    • Workshops

Tooling (Engineering)

  • SDKs/Helper Libraries
  • CLIs, Code Editor Extensions
  • Extensions/Plugins/Integrations


  • Supporting developers in core usage
  • Advising developers on specific implementations
  • Gathering explicit and observed feedback and communicating internally

For more information on the "why" to these activities, take a look at the AAARRRP Developer Relations Strategy Framework, which I use to rationalize what I work on.

What is Developer Relations not?

DevRel work is relevant and impactful to many other teams in a business. While it’s inevitable that occasionally our time may be borrowed and the items below are done, or that our work implicitly supports other teams’ goals, DevRel is not:

  • Sales - DevRel should not be assessed against sales metrics, including generating PQLs. This is a byproduct, not the core goal.
  • Sales/Implementation Engineers - our work deals with the masses and often feature-incomplete projects. We generally don’t work with customers on their specific implementation because this work can only impact one project at a time.
  • Customer Success - most DevRels are not solely on a support function, answering submitted inbound questions from customers. Instead, we observe common questions or misunderstandings, and generate content to support self-serve troubleshooting or lessen time-to-resolution.
  • Social Media Managers - DevRels may advise or tone-check, but rarely are fully-responsible for social output.
  • Pure Engineering - DevRels use their experience and empathy with developers to be part of product decisions. They are not engineers who just answer tickets.

I look forward to reflecting on this document throughout time and adjusting it as I think more about how I work best, and how I can enable others to be happy and successful.