Forem: Lynne Tye

What developer advocates do

Lynne Tye — Wed, 20 Feb 2019 18:45:28 +0000

Originally published on Key Values.

Photo by Joshua Coleman on Unsplash.

There are countless career paths for a software engineer, and I'm not just talking about different flavors of engineering management or individual contribution. I've met several engineers who, after years of coding, transitioned to developer advocacy. I think more people would do the same if they knew what it was.

Developer advocates (who are sometimes called "developer evangelists" or fall under their company's "developer relations" org) are technical people who also excel in communications. What makes developer advocacy so intriguing is that it welcomes a broad spectrum of people and backgrounds: bootcamp TAs, enthusiastic bloggers, passionate technologists, and theatre performers are all well-positioned for success in this line of work.

As a burgeoning field, there are many people who still haven’t discovered what developer advocacy is and some who have already drawn false conclusions. (To be fair, that’s easy to do when you only have one or two data points.) This is why I talked to 15 developer advocates about their day-to-day responsibilities and the common misconceptions people have about their jobs. [Spoiler alert: It's not all glamorous travel, they're not all extroverts, and yes, many of them still code.]

Here is an introduction to what developer advocates do, what kinds of people do well in these roles, and how to become one yourself:

What is the biggest misconception people have about what developer advocates do?

Alex Lakatos

JavaScript Developer Avocado at Nexmo.

People see us traveling to give talks in all of these cool places around the world and they think that's all we do. But no one understands that out of these cool places, I mainly see the airport, the hotel, and the venue. And while I may be on stage for only an hour, a lot of work goes into preparing for that. In between all of that is figuring out how to work from planes, trains, and automobiles. I still haven't figured out how to remote out of a car yet :)

Don Goodman-Wilson

Developer Advocate (EMEA) at GitHub.

The need for technical ability is overstated. The ability to make human connections is by far the most important aspect of this job. I think you need to be technical enough to participate in the kinds of conversations that come up, but the perception that developer relations people (aka devrellers) have to be engineering rockstar ninjas in order to be taken seriously is, to me, a bunch of self-aggrandizing, gatekeeping hooey.

Ex-teachers are my favorite people to hire into this role. I'd take someone who has experience teaching high school over a senior developer any day. I say this as an ex-teacher, but also as a developer with >20 years experience.

Brian Rinaldi

Director of Content at Progress Software, previously a Developer Advocate at Progress Software.

The biggest misconception is that we spend our days coding. I've seen many people who love to code leave this type of role because, as it turns out, it is probably only 10-25% coding (and I'd generally say on the lower end of that range). I like to think of it as, when we get the chance to code, it's usually to learn new things, experiment, and be creative. A lot of the job involves things like meetings, writing, travel, presenting, and other non-code activities.

What do developer advocates do on a day-to-day basis?

Ihor Dvoretskyi

Developer Advocate at the Cloud Native Computing Foundation (CNCF).

The Cloud Native Computing Foundation is the home for a few of the most fast-growing open source projects in the world, including Kubernetes, Prometheus, Envoy, Helm, and others. CNCF is a non-profit, community-focused organization, and in my case, my job is an organic combination of community program management and technical developer advocacy.

I’m focused on advocating (i.e. blogging, public speaking) for the CNCF projects (specifically, Kubernetes and Helm), together with the wider Cloud Native ecosystem. Besides that, CNCF runs some community-oriented programs including Ambassadors Program, Meetups, and CNCF’s participation in Google Summer of Code, which I help to curate.

Being a Developer Advocate at a community-focused organization is an amazing experience, especially for someone as passionate about Open Source as I am.

Amara Graham

Developer Advocate at IBM.

I write digital content (how-tos, tutorials, blogs, and code snippets) as well as develop and lead in person workshops and lecture style talks. Occasionally I have more customer focused meetings where I work with dev teams and show them how IBM Cloud and/or Watson API Services work. All of these activities generate feedback from the external dev community that I look to bring to internal teams to make sure we are building the right stuff.

David Needham

Developer Advocate at Pantheon.

The majority of my time is focused on education and training, but I also actively contribute to the Drupal and WordPress communities. I feel like we’re doing it right with programs like Pantheon for Trainers (free stuff for educators) and workshops like Getting Started with Drupal 8 (a class we run in-person at conferences and online for Drupal Global Training Days).

Pantheon expects the DevRel team to “know” the community, and we do this by being active members ourselves. We volunteer at the camps and conferences we attend. Sometimes that means speaking or organizing, other times it’s a less glamorous job like the cleanup shift. There's no better way to get to know a group of people than to serve alongside them.

Developer Advocacy is the perfect job for me. I'm not selling anything, I'm just sharing what I've learned, contributing what I can, and seeing first-hand that it makes a difference.

What kind of person does well in a developer advocate role?

Josh Dzielak

Co-founder of DeveloperMode, formerly Developer Relations Lead at Algolia.

A person who enjoys using their left and right brains simultaneously. Developer advocates are a bridge between the code and the people writing it, so they need to understand both. The best advocates all have a innate desire to help developers solve problems even when it's not directly related to their company's product. An insatiable curiosity and entrepreneurial spirit are two characteristics I'd add to the list. A lot of DevRel is exploring brand new territory without a playbook.

Zan Markan

Developer Evangelist at Pusher.

Engineers who can work well autonomously, and like people and developer communities. I think that generally people who like sharing knowledge and enabling other people can be great for the job.

Since the individual roles and responsibilities vary a lot from company to company and even from team to team, it's important that your ideas of the job are compatible with those of the company.

Nicolas Grenié

Developer Advocate at Typeform.

When developer advocacy was newer, companies were looking to hire people who would do everything. However, today, there is more specialization for each devrel role. One could be more focused on the community side, creating content, or dedicated to building/coding.

I believe the best person for a Dev Relation role has to be curious: curious to hear people's stories, curious to meet new people, curious to try new things. This person has to be humble, too, putting themself in other people’s shoes.

Not every outgoing person would make a good dev advocate. Introverts that like to write and tell stories fit perfectly too, in fact many of us are introverts.

How did you come to be a developer advocate, and what advice do you have for folks interested in becoming one?

David G. Simmons

Senior Developer Advocate at InfluxData.

I 'fell into it' about 25 years ago because I was bored being a full-time engineer and wanted to get out and talk to people. For engineers interested, practice talking about what you do in ways the anyone can understand. Don't talk 'down' to people, but find interesting ways to explain things, tell stories, etc. And learn to listen. Really listen to what other developers are telling you.

Lorna Mitchell

Senior Developer Advocate at Nexmo.

As a software developer, I really enjoyed blogging and I also gave a lot of conference talks, then wrote some books ... so I became an advocate to fund my writing and speaking habits! For all engineers I'd say it's both important and rewarding to get out in the community in some way, such as writing a few blog posts or improving the README on your favourite project.

Tim Falls

Director of Developer Relations at DigitalOcean.

I stumbled into my career as a Developer Relations professional. I was an early employee at SendGrid, and a friend of mine at the time, John Sheehan, happened to be launching Twilio's developer evangelism program. As I realized that our two companies were aiming to achieve the same business goals by working with the same communities (ie, devs), it just made sense to combine our powers, team up in our Dev Rel efforts, and work closely together. The rest is history.

Advice: If you're interested in getting into Dev Rel, the simplest way to explore and find your path is to start doing it. Be an active representative of your employer’s technology, get involved in developer communities that interest you, contribute value to those communities, and build your personal brand within the dev community.

If you’re not currently employed by a company with a product/service to evangelize, then identify a technology, product, company somewhere in the market who might gain value from Dev Rel and who aligns with your interests and values; then simply engage with them as a community member -- interact on social, build something using their tech and showcase it in a blog post, mention them in a meetup/conference talk, etc. Your contributions will be noticed.

PJ Hagerty

Founder/Chief Community Officer at DevRelate.io.

Accidentally :) A friend who is a professional speaker signed me up to do a lightning talk. It went well and was requested as a full talk at a separate conference. The company I worked for took notice and we used it to launch a Community Engineering team.

Shawn swyx Wang

DevRel/DX Engineer at Netlify.

In 2017 I made a resolution to Learn In Public and focus specifically on frontend development. I repackaged everything I learned into a blogpost or cheatsheet or talk or tweet series and these got me noticed both by people who knew more than me and people who were interested in learning the same things. Despite being in a dull big-company job nobody cared about, I was able to grow my knowledge, network, and profile on the side by serving the community I wanted to be a part of.

For me, it was just a career/learning hack, but it turns out employers want people to speak their language, build demos, be beta testers (this is literally in my job description), and represent the end user at the table, too.

Chloe Condon

Cloud Developer Advocate at Microsoft.

I have a degree in theatre performance, and worked as a musical theatre actress nights and weekends (while being an admin in tech by day) before eventually discovering programming and applying to Hackbright (an all female software engineering bootcamp). My DevRel epiphany happened when we presented our final projects at Hackbright to an audience of potential employers. I realized that while many of the women in my cohort were very strong technically, many were terrified of public speaking and presenting technical content.

Once I discovered that Developer Relations was a specialty, I knew it was my niche. It takes a certain type of human to juggle content writing / presenting / teaching / tweeting / empathizing with engineers. My experience in the performing arts is now my secret weapon for meet-ups, videos, marketing, and networking.

I view almost all my developer relations tasks as putting on a performance. I think sometimes we forget that engineers are people, too – they like to laugh, have fun, and be entertained. My advice to anyone considering becoming a developer advocate is to not be afraid to think out of the box. For me, that was making a camp-themed meet-up with s’mores, songs, and giant squirrel costumes (vs. the typical cold pizza/warm beer meet-up I was so used to yawning through). Use your background and experience as a developer (or musical theatre actress, in my case) to think through how to make developer experience better!

So, what now?

If you're at all interested in learning more about developer advocacy, or how to break into it yourself, try reaching out to any one of the wonderful people quoted in this article. After putting this post together, I can tell you firsthand how welcoming (and tight-knit!) this community is, and how happy everyone is to share their stories and help.

Thank you to everyone who contributed to this piece, and special thanks to Josh Dzielak who introduced me to the world of developer advocacy. This article wouldn't have happened without your help! 🙌

Engineering whiteboard interviews: yay or nay?

Lynne Tye — Wed, 29 Aug 2018 15:11:04 +0000

Photo by Mark Rabe on Unsplash.

Software engineers hate whiteboard interviews. How do I know? We continually tell complete strangers just how much we hate them. But it's not that simple.

The problem is that we often conflate several issues: using random CS trivia/riddles to assess candidates, interviewers deliberately creating a stressful environment for interviewees, competent humans who happen to interview poorly, and the job search sucking in general.

"Whiteboarding" has become too large of an umbrella term, one that groups together everything that's wrong with the interview process. The truth is more complex, which is why I talked to hiring managers at several tech companies to get their opinions.

Are whiteboard interviews the best way to evaluate engineering candidates?

Jamie Karraker

CTO at Alto, previously engineering at Facebook (Parse).

I don't believe in the traditional whiteboarding questions on data structures and algorithms, at least not for our business. An interview should be designed to test as closely as possible for the skills an engineer would be using day-to-day in the job. For us that means being extremely productive, given we are an early stage startup and need to build a lot of product and make a large impact with very few engineers. But for Google they have to be able to solve very few, but very complex, technical problems, and productivity is less of an issue given their limitless resources. So for them the whiteboarding question might be the right fit, as it is an efficient and scalable way to test for performance on solving complex technical problems.

Eugenia Dellapenna

Engineering manager at Medium, previously engineering at Pivotal Labs.

I don't think they're the best way to evaluate candidates, but I also don't think they're as useless as some blog posts make them out to be. I actually think that they're the best way to ask certain kinds of interview questions, such as high level system design questions, but that they aren't the best way of asking coding questions since it's pretty different from how people are used to writing code on a day-to-day basis.

Nowadays, I tend to favor using collaborative coding environments, like CoderPad, for coding interviews. CoderPad is nice because it allows you to run the code, so you can quickly test the code with different inputs to see if all edge cases are handled. This also allows you as the interviewer to see how the candidate debugs real code and how well they're able to interpret things like compiler errors and runtime exceptions. It usually takes a bit longer to complete interview questions in this coding environment though (because of the time spent debugging) so you tend to not have as much time to build on the initial question or discuss further improvements, which is one caveat.

I still usually give candidates the option to write their solution on the whiteboard if they really want to, since some people specifically practice that when they're preparing for interviews, and I want people to feel as comfortable as possible. I think in general, it's your job as an interviewer to set candidates up for success so you can get as much signal during the interview as possible. Doing that well is more important than if you're asking the question on a laptop or a whiteboard.

Brian Wheeler

Senior Director of Engineering at Braze, previously engineering at Microsoft.

I'd say "best" is an overstatement, but I do think they can be a valuable component of an interview process. When done properly they can be a reasonably consistent evaluation of problem solving ability, communication skills, and preparedness. Some questions are not suited for whiteboard interviews, but for all others the more important factors are what you ask, how you ask it, and how you dialogue.

Are whiteboard interviews the best way to evaluate engineering candidates?

Dan Erickson

VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer.

No, not at all. Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. Engineers on my team never have to code on a whiteboard (whiteboards are really bad at running code), why would I make candidates do something that I don't ask the engineers already on my team to do?

Some argue that whiteboard interviews can help you understand a person's "soft" skills (a term I hate because it downplay's the importance and difficulty of emotional intelligence skills). In my experience, there are better ways to evaluate these skills, and often times directly asking the candidate to give examples of these skills is more effective.

Desmond Brand

Director of Engineering at Flexport, previously engineering at Khan Academy and Microsoft (Bing).

Whiteboard interviews might not be popular with the median candidate, but I think Kevin Lacker nails it in the example at the bottom of this blog post.

There's nothing special about the medium of a whiteboard itself, however. At Flexport, we give people the option to write code on their own laptop if they prefer, and some take us up on that. This works better for those who use a TDD-style process or who just like to insert text before other text :)

But how and where code is written is incidental. The important part of these interviews is communicating (using words & diagrams) about a problem and approaches to solving it, and then also communicating (using words & code) about teaching a computer to solve that problem too.

There are more drastic changes we've experimented with, e.g. a take-home project, but those tend to impose an asymmetric time investment upon the candidate, which some people greatly dislike. So in practice, projects can only be an option at best. However, having different styles of interview can be problematic too because it increases noise in evaluations of candidates, which then increases the risk that unconscious bias creeps into hiring decisions.

Sandy Jen

Co-founder of Honor, previously founded Meebo and sold it to Google in 2012.

From a functional perspective, it's not very useful... no one will be producing code on a whiteboard as their primary job. However, it is a good way to learn how a candidate communicates, expresses ideas, and takes feedback. The expectation is not to ace the whiteboard question, but to learn more about you as a potential team member.

David Chang

Engineering Manager at NerdWallet, previously engineering at aboutLife.

There’s no one best way to evaluate engineering candidates. All interview processes have their own strengths and weaknesses, and it’s important to understand how much (or how little) any given question can tell you about a candidate.

At NerdWallet, we usually conduct architecture and design questions on a whiteboard. It helps us to better understand how candidates structure and communicate complex technological solutions and the broad strokes of the design are more important than the specifics of any particular line of code. We also normally ask a couple laptop coding questions, for obvious reasons. Recently, we incorporated a pull request question, because working with other people’s code and giving feedback is a key part of being a productive engineer at NerdWallet and we were missing that from our previous interview process.

None of the questions are perfect, though. Some engineers feel uncomfortable designing completely new systems on demand, coding questions may just happen to hit on a candidate’s blind spot, and understanding a PR for code you’ve never seen before can be challenging. We’re big believers in feedback and data-driven decision making, so we’re always working to better understand what our interview process can tell us about a candidate and determine ways in which we can improve it.

Are whiteboard interviews the best way to evaluate engineering candidates?

Zeesha Currimbhoy

Director of Product Engineering at Branch, previously VP of the Augmented Intelligence Team at Evernote.

I have spent my entire professional management career debating what the best way to interview candidates is. In my ideal world, a candidate should never have to "prepare" for an interview and an interview is just as simulation of a day in the life at work. In this vein, I have played around with different formats, the take home challenge, the white boarding interview, the algorithms and data structures sections, a live coding session, a debugging session and the list goes on. I have a lot of opinions on this topic (much like any other manager). But to sum it up, whiteboard interviews, in my opinion is a great "tool" to use while evaluating candidates.

Thats right, in my opinion a white boarding session should be thought of as "a tool" to enable you to problem solve with a candidate. What’s great about a white boarding session is that it is a blank piece of canvas, where the interviewee can effectively think out loud, collaborate, draw diagrams and also brainstorm with the interviewer. It doesn’t have friction between your thoughts and being able to communicate them. At the same time, it shouldn’t be the only way to interview candidates and is definitely not a one-size-fits-all. An effective interview is an assessment across several different dimensions with different ways of evaluation. Whether we like it or not, a whiteboard represents a large part of technical communication not just in an interview but in day to day operations as an engineer.

Larry Salibra

Engineering Partner at Blockstack, previously founded Pay4Bugs.

I don't think whiteboard interviews are particularly useful in that they don't reflect the reality of performing the job. Open-ended coding challenges that involve using our software to build something give us much more information about the skill level of a candidate and his or her interest in the project.

As an open source project, we're lucky in that candidates really interested in our project can prove themselves by sending pull requests or building apps on our platform - in some cases this means we're comfortable making an offer without asking the person to do an additional coding challenge.

Derrek Harrison

Engineering Manager at Samsara, previously the Director of Engineering at Kinetic Growth.

Great engineers have many tools to choose from when solving a problem — great companies also have many tools at their disposal when searching for and evaluating talented team members. A whiteboard interview is an excellent tool when the candidate needs a large canvas to diagram out a problem or design a system. This is particularly true when asking a system design/architecture question or asking the candidate to describe the interaction between multiple systems.

However, whiteboard interviews are not a fitting format when testing a candidate’s ability to write code. If you take away the ability to debug and test during an interview, you are left with a scenario that is not an accurate representation of day-to-day engineering. A collaborative coding environment is a better choice here — it gives the interviewer the ability to clearly define a problem in writing and gives the candidate the ability to write, debug, and test in a familiar setting.

We strive for an interview format that allows a candidate to shine and gives us the best possible signal on how the candidate would perform as a member of the team. This means that sometimes, but not always, a whiteboard interview is the right format.

Adam McKerlie

Director of Engineering at G Adventures, previously an Engineering Manager and Developer at G Adventures.

After years of iterating on our interview process, testing out different ways to evaluate a person's skill and personality, I've found that whiteboards add very little to the overall interview process. They can be useful at understanding how someone works, but more often than not, I've found them to weed out really good candidates who haven't had the opportunity to do whiteboarding interviews before. I much prefer to talk with a candidate over a problem and have a conversation with them, similar to how we'd discuss a problem in real life when scoping out a project. I find people are generally more at ease with this approach and don't get tied up on syntax, their messy writing, or talking aloud while "coding."

Looking for a new job?

Everyone quoted in this article is a hiring manager at a company on Key Values. You can learn more about their engineering culture by reading their team's profile, and if you're still interested, I encourage you to apply or even reach out to them directly.

Should tech companies use quotas to increase diversity?

Lynne Tye — Wed, 08 Aug 2018 16:39:12 +0000

Photo by Patrick Fore on Unsplash.

Setting clear diversity targets has become a common practice in tech, whether it’s to ensure that women of color make up half of the speakers at a conference, or that 25% of a company's interviews be with black and latinx candidates.

When it comes to hiring, many companies are implementing diversity quotas. However, it's unclear how effective they are, what hidden costs they might have, and if they’re necessary to achieve more diverse and inclusive workplaces.

Truthfully, I didn't know how to even start answering these questions myself, so I set out to learn more. To be better informed, I reached out to thought leaders and experts in the diversity and inclusion (D&I) space. I share their thoughts on the question below:

Steven Huang

Head of Diversity and Inclusion at Culture Amp | LinkedIn

Disagree, but obviously the real answer involves a lot of nuance. Companies need to have a portfolio of diversity management strategies in order to achieve their goals. Quotas and targets can be a part of an effective strategy, but will have limited effect if done in isolation.

For example, we’re beginning to fully understand the psychological processes behind stereotype threat. If you have employees that don’t understand why setting targets and quotas are effective at making up for systemic discrimination, they are likely to believe that a “white disadvantage” exists in the organization; one that threatens their livelihood. “Modern Racism” is the belief that Black people and other minorities are no longer the disadvantaged group in society and they receive unfair advantages. It sounds wild to me, but it’s a prevalent racial attitude in America today.

Alex Rose

People Programs at DataDog | LinkedIn

Two years ago, I would have said that I unequivocally disagree: setting hiring quotas shifts the attention from building a diverse and inclusive company to doing whatever it takes to hit another number.

I later learned about affirmative action plans for federal contractors and realized that quotas in some instances are actually required. After seeing various stages of D&I initiatives at Series A-D companies, I now think setting quotas is a good place for companies to start. By setting goals at the beginning, companies can build momentum behind their D&I efforts from the get-go.

Research your industry and the locations where you pull talent from to understand the general demographics of your talent pool. Use those benchmarks to set your quotas company-wide, and once you hit those, turn your attention away from the numbers and towards becoming a truly diverse and inclusive company. Cut the data by department, location, and tenure. Challenge your team to think about diversity in terms of underrepresented people in tech instead of diversity candidates. Redefine demographics in an inclusive way by researching the latest categories and even ways to define those that are already commonly measured like gender, age, and level of ability. It's important to remember that D&I work never stops - quotas or not!

Bill Umoff

Director of Technical Recruiting at Flexport | LinkedIn

Agree. If you don't have some type of goals in place, whether it's at the top of the funnel, bottom, or both, you will default to what is easiest and/or in greatest supply.

Aline Lerner

Co-founder and CEO of interviewing.io | LinkedIn

What do we want to accomplish with diversity quotas in the first place? Are we trying to level the playing field for marginalized groups? Or improve optics so the press can write about how good our company’s diversity numbers look? Unless diversity quotas are truly an exercise in optics, I firmly believe that they are at best a band-aid to cover up the underlying problems in hiring. In their worst cases, they do more harm than good, keeping us complacent about finding better solutions, and paradoxically undermining the very movement they’re meant to help.

From a practical perspective, one of the downsides of diversity quotas is the tokenization of candidates, which often manifests as stereotype threat, one of the very things we’re trying to prevent. I can’t tell you how many times people have asked me if I thought I got into MIT because I’m a girl. That feels like shit… in large part because I DON’T KNOW if I got into MIT because I’m a girl. Stereotype threat is a real thing that very clearly makes people underperform at their jobs… and then creates a vicious cycle where the groups we’re trying to help end up being tokenized and scrutinized for underperformance.

Practical failings aside, let’s pretend that quotas work perfectly and bring all the desired results. We still have to ask ourselves if we did the right thing. Any discussion about leveling the playing field shouldn’t just be about race, but also socioeconomic status, age, and the myriad of ways people are marginalized in tech. Since we can’t ask, “Were your parents poor?” in applications and it’s illegal to ask about age, we often focus on race and gender because they’re relatively easy to spot. So even if quotas worked perfectly, they’d still be a band-aid solution that’s not doing enough and ultimately covering up the fact that your hiring process sucks.

Instead of trying to manage outcomes by focusing on quotas, we should get at the root of the problem and create the kind of hiring process that will, by virtue of being fair and inclusive, bring about the diversity outcomes we want. I already wrote at length about how engineering hiring/interviewing needs to change to support diversity initiatives, but the gist is that fixing hiring is way harder than instituting quotas. Low-hanging fruit isn’t going to get us to a place of equal opportunity, but better screening and investments in education will. At interviewing.io, we rely entirely on performance in anonymous technical interviews - not resumes - to surface top-performing candidates, and 40% of hires are people from non-traditional backgrounds and underrepresented groups. The companies that we’ve hired for that have benefitted from access to these candidates have been willing to undergo the systemic process change and long-term thinking that effecting this level of change requires. We know our approach works. It’s hard, and it takes time and effort, but it works.

Michael Kyle and Jane Nguyen

Manager of Talent Success and Head of People Development and Impact at Redbubble, respectively | LinkedIn, LinkedIn

Intentions are only worth something if you can hold yourself accountable to them. We do not expect our products to be better just because we intended them to be. We set KPIs, milestones, and release deadlines. There are rewards for exceeding expectations and consequences for missing the mark.

The same level of accountability that we place on the development of our products and user experiences needs to be placed on making an impact with our objectives with building more diverse teams if progress is to happen faster.

We believe in a diverse “top of funnel” strategy that helps us avoid the inherent problems of gaming in a quota environment or tokenizing individuals. When talent is done right, you are cultivating a community for the long term, so focusing top of funnel AND in your actual hires helps sustain progress. Diversity hiring takes longer (because the system wasn’t created overnight), and it can get more efficient with time if you invest in the appropriate short and long term mechanisms to attract people to your brand.

Amy Cherette

Talent and People Operations Lead at Hipcamp | LinkedIn

I agree that companies need to make a real effort and be held accountable to goals and metrics that you’re reporting on. It’s important to remember that no one person is “diverse,” and to avoid language such as “this person is a diverse person.” I think the better language you can use is “this person will help contribute to building a more diverse team.” Anyone can be diverse in the context of different groups. As for metrics, you can start with something simple like the Rooney Rule.

I am not a fan of end of the funnel hiring number quotas as I think it can have the potential to dehumanize a person and make them a number. I do think you can have quotas when it comes to different metrics throughout the recruiting funnel such as how many underrepresented candidates come through your pipeline, how far they make it, where do they fall off, how many did you interview before you made an offer? I also think you can place sourcing metrics around the top of the funnel to again, make sure you’re casting a wide net.

Liz Kofman-Burns

Sociologist at TalVista, a D&I hiring platform | LinkedIn

If you believe the current system is biased, that diversity is beneficial, and you want to increase the representation of underrepresented groups then you should consider using quotas. Call it something else if you want—guidelines, goals, targets, the Rooney Rule—but don’t ignore the concept completely just because it’s uncomfortable.

There is a mountain of evidence that bias exists in hiring, performance evaluations, promotions, and pay. That means tech jobs are not currently distributed based on merit alone. Research also shows that diversity produces positive outcomes for teams and companies. So more diversity would raise the bar in tech. Quotas seem to work in increasing diversity (for example, female representation in government is almost twice as high among countries that have some kind of gender quota compared to countries without quotas).

The current tech jobs landscape is broken. It will take radical changes to make things better. That said, I think the impact of quotas on inclusion is still an open question. It’s possible that quotas will lead to a backlash and feelings of tokenism in the short-term. But that short-term pain might be worth the price of more inclusion in the tech industry in the long-term.

Amber Madison

Founder of Peoplism, partnering with companies to build inclusive workplaces | LinkedIn

Messaging is so important when it comes to any D&I initiative. The second you use the word "quota," you not only risk alienating many people at your company, but you also risk undermining the ability of people in underrepresented populations to do their job well.

There is no point in building a diverse workforce if it's not going to be inclusive. If team members think that someone was hired to fill a quota, they aren't going to be as inclusive of that individual because they aren't going to be able to fully trust that individual's talent, intelligence, and expertise.

If you care about diversity, the most important question to be asking is, "Why are some populations being systematically left out of our company?" Want to change the demographics at your company? Good. But then you have to address the root cause of why your company looks like it does...otherwise you're trying to fill a leaky bucket.

Considering quotas because you want a more diverse company? I'd recommend these steps instead:

Work to confront, challenge, and change your own biases - not just become aware that biases exist.
If you're a recruiter, commit to filling the slate of candidates for any given role with at least 2 people of underrepresented genders and 2 people of underrepresented races/ethnicities.
Make D&I a priority and set goals for yourself. Maybe some of those goals are around increasing representation, but take a wholistic approach to achieving that goal by seeking to understand why certain groups are underrepresented in your company (or on certain teams) and taking a range of actions to address the issue. If you are reading this with a face palm thinking, "Damnit...we just put quotas in place," balance this out with lots of messaging to your workforce that "the best person for the job is always who we hire," and then go through the above steps.

Before you go...

Several people that I reached out to didn't feel comfortable sharing their views on this polarizing and sensitive topic. In some cases, they failed to get approval from their legal and HR teams to comment. For these reasons, I'd like to give an extra big thanks to the folks who did contribute to this piece:

Your stories, experience, and insights have helped me become a more informed member of the tech community, and will encourage more open discussions about how we, as an industry, can become more diverse and inclusive.

Can't get engineering interviews? Try the side door.

Lynne Tye — Tue, 03 Jul 2018 18:37:46 +0000

If you're applying for new engineering jobs and are struggling to get your foot in the door, consider looking for other ways in.

Imagine a big crowd of people in front of a building, pushing and shoving to get inside through the main door. A few people, tired of the mob, decide to explore the premises and come across a side entrance. They knock, someone opens, and they walk right in. Wouldn't it be nice to use that side door, too?

The many ways into a startup.

In a tall pile of applications, there aren’t a lot of ways stand out aside from simply "being better” or “doing more impressive stuff.” Most people work hard to get ahead by fortifying their resumes and portfolios with more work experience and more projects. Others wait patiently for their turn. Some just brute force it by applying to hundreds of companies until one eventually says yes.

What if instead of competing directly with everyone else, you could just redirect your energy into finding a side door?

Here are a few things that I’ve personally done, or seen other engineers do, to jump the line, get interviews, and land jobs at tech startups:

Use the product.

Many B2C companies hire directly from their user base. Startups with consumer products want to hear from their users, especially those who have ideas on how to improve UX, performance times, or fix the bugs they encounter. Be proactive in reporting issues. If you have a solution, you might speak directly with their engineers. Voila! You’ve cut the line.

Many B2B companies have products that you can also use, especially if you’re working on a side project of your own or your previous employer was a customer.

Make a PR.

Sure, you can build your own projects and make them open source, but you can also find companies that have open source projects and contribute to those. Make a PR and engage with the current engineers maintaining it. You’re demonstrating ability and interest without it even being an interview.

Tweet.

I begrudgingly started using Twitter for real a little less than a year ago, and I can't believe how much I've been missing out on. The software engineering community is extremely active on Twitter, so it's a huge advantage anyone can easily get. Engage with current team members at your dream company on Twitter. Answer questions they ask. Comment on articles they post. Contribute to the conversation.

Don't know who to follow? Start with the technical founders quoted in this article.

Fun fact: I got my second contract web dev gig on Twitter.

Meet in person.

Why not have conversations in person? Many startups host meetups, hackathons, and/or workshops, sometimes in their own offices. Attend them. Talk to everyone, especially current engineers at the company. Not only do you get to casually ask questions about life at Company X, but in many cases, they'll want to refer you because of something called internal referral bonuses.

Worst case scenario: you'll meet all sorts of new people who will help expand your network.

Ask questions via Key Values.

Finally, if you’re interested in any of the engineering teams on Key Values, I’ve created a small side door for you on each company's profile page. You can leave thoughtful questions for current team members at the bottom left corner of the page, along with your email address so that they can get in touch.

There are so many side doors out there, and I love discovering them. So I ask my fellow DEV peeps: what do you know that the rest of us don't? 😜

If you want to get in touch, you can email me (lynne@keyvalues.com) or find me on Twitter (@lynnetye, @keyvaluesio). Also, I haven't decided what I should write about next... so if you have ideas or requests, holla!

Cover photo by Samuel Zeller.

What technical recruiters want from engineering candidates

Lynne Tye — Tue, 22 May 2018 20:33:59 +0000

I recently asked internal recruiters at different startups, "What makes an engineer stand out from the applicant pool?"

Straight from the horse's mouth, here's what technical recruiters want from engineering candidates.

Their responses helped me think about what the application process looks like on the other end. It's an extremely noisy process, and as an applicant, we should make it easy for tech recruiters to see us.

I also shared this post on Hacker News, and found the comments to be equally eye-opening.

If you're curious about a very different perspective on how engineers can/should approach their job search, I also asked six technical founders a similar question. Their responses are here.

How engineers can stand out from the applicant pool

Lynne Tye — Mon, 30 Apr 2018 19:23:37 +0000

What have you done in the past, or seen other engineers do, to stand out from the applicant pool?

I asked six technical founders this same question, and thought I'd share their answers with the DEV community in case anyone here would find them interesting/useful/helpful.

If you have your own answer to this question, by all means, share it with us!

Nevertheless, Lynne Tye Coded

Lynne Tye — Thu, 08 Mar 2018 21:28:58 +0000

I began to code because...

Coding is powerful. I decided to learn how to code when I was 26 years old. I was nervous to change careers (again), but knew that being able to build things on my own was a super power I wanted to have. I learned to code because I didn't want to depend on others to fix bugs, build features, or bring ideas to life anymore.

I look up to...

Any woman who has made a difficult decision in order to stay true to herself. I grew up with great examples of strong women. My mother was one of the first female faculty members at Cornell University, and my sister is currently a professor in Neuroscience at MIT.

I want to show off...

Key Values which helps developers find teams based on the values they care about most. I'm also proud of Culture Queries which provides engineers with the best questions to ask during their job interviews.

I'm a solo, female founder and am proud to have started a business on my own. I've written a couple of articles on dev.to:

my journey launching my first product (yes, Key Values!)
what developers want in a job

My advice for allies to support women and non-binary folks who code is....

Listen first, and continue to ask how you can help. Everyone has a different story and different people need help in different ways. Engage rather than pull away.

Finding work/life balance in the tech industry

Lynne Tye — Thu, 15 Feb 2018 23:15:30 +0000

People are constantly asking me if work/life balance exists for developers. While it's certainly not the norm, there are companies who have built their culture around having it.

I put together a page listing all the companies that selected "Work/Life Balance" as one of their top 8 key values, and thought I'd share it. People's definitions of work/life balance vary wildly, so you can see how different teams talk about what it means to them, and make your own judgment.

👉 Finding work/life balance in tech.

Hope it's helpful!

Picture of the Inntopia team skiing

The best questions to ask in your job interview

Lynne Tye — Mon, 08 Jan 2018 19:13:22 +0000

The one question every interviewer asks is, "Do you have any questions for me?"

Most of us forget to prepare questions, so we make up generic ones on the spot, or say, "Mmm... well... no, I think you covered everything!"

It's an incredibly important part of the interview, which I why I went ahead and compiled thoughtful questions for you!

Culture Queries gives you the best questions to ask your interviewer.

Here's an example:
👎 Don't ask: "Is there work/life balance here?"
👍 Do ask: "How responsive are people to emails/Slack over the weekends and after 6pm?"

Why? Because some interviewers will interpret the first question as an unwillingness to work hard. Plus, a yes or no question that is so direct will almost certainly get you a canned response. Instead, ask a more specific question that gives you an idea of what the expected working hours are and how team members communicate with one another without sounding like you're already trying to cut corners.

I'm still making improvements and adding content, but I hope it'll be a useful resource for anyone preparing for interviews. Culture Queries is made for developers, by a developer (aka me 🙋🏻), so all feedback (good, bad, ugly) is welcome and appreciated.

Good luck on all of your interviews! And remember: you're evaluating the company as much as they're evaluating you. 🙌

What developers want in a job

Lynne Tye — Fri, 20 Oct 2017 06:15:15 +0000

Six weeks ago, I launched my first product: Key Values.

Three weeks ago, I wrote about my (long) journey leading up to that launch here in dev.to.

Today, I want to share some of the data I've collected from the 21,000+ users that have visited Key Values since I launched.

Key Values helps engineers find jobs based on shared values, and allows them to learn more about a team’s culture before applying. Job-seekers can visit the site and select from a list of 44 value tags including “Team is Diverse, “Light Meetings, and “Open Source Contributor (see full list here), which then filters the teams that have matching values.

I curated this values list after interviewing dozens of engineers who identify themselves as missionaries, not mercenaries. They believe that team culture and the people they work with are as important as (if not more important than) compensation or company reputation.

I then asked teams to pick the 8 values from this preset list that best describe their engineering culture, and qualify their selections in their profiles.

Whether people were actively looking for a job or not, these were the top 15 tags they selected when they visited Key Values:

Values selected between September 5th and October 15th, 2017.

What dev.to readers value most

Dev.to readers, like the other developers who came to Key Values, valued "Work/Life Balance" and "High Quality Code Base" above the other key values. In fact, these two values were consistently ranked in the #1 and #2 positions regardless of the community or country, (see more data here).

There are a lot of interesting discussions to be had about the top 15 values, but I find it most interesting where the dev.to community values differ.

Values selected by dev.to readers between September 5th and October 5th, 2017.

Users referred from dev.to prioritized "Good for Junior Devs," "Ideal for Parents," and "Pair Programs" much more highly compared to all visitors on Key Values. The dev.to community values these things more than "Impressive Team Members," "Engages with Community," and "Safe Environment to Fail."

Dev.to vs. Hacker News

Dev.to sent 2,933 readers to Key Values, but here's where it gets interesting.

My article (How I stopped procrastinating, learned to code, and launched my first product) was posted on Hacker News and likely drove significant traffic because it made the front page! (Thanks @rbanffy for posting it!) As a result, it's hard to know how many readers were actually referred by Hacker News.

Despite the clear overlap between dev.to and Hacker News readers, there were still differences between each community’s value selections. Notably, “Good for Junior Devs and “Ideal for Parents are at the top of dev.to’s list but not on Hacker News' list.

Comparing the most and least selected values from users referred by dev.to vs. Hacker News.

Yes, posts about learning to code and launching a product for the first time appeal to green devs, but it’s not as obvious why these same readers would be looking for workplaces suited for parents. Perhaps both junior developers and parents are better represented in dev.to’s readership.

More data and additional insights

So far, Key Values has received the most traffic from Hacker News, which is why I published a story specifically for the HN audience appropriately titled: What Hacker News readers want in a job. You can read more about what members of the Hacker News, Product Hunt, and dev.to communities value most and how them compare with one another. I also discuss how value selections vary across countries, and what we might learn about engineering culture at the national level.

I appreciate how supportive the dev.to community has been ––Â thank you!

If you want to get in touch, you can email me (lynne@keyvalues.com) or find me on Twitter (@lynnetye, @keyvaluesio). Lastly, I haven't decided what I should write about next... so if you have any ideas or requests, comment below! ðŸ¤—

How I stopped procrastinating, learned to code, and launched my first product

Lynne Tye — Mon, 25 Sep 2017 20:41:41 +0000

I've been reading about inspiring founder stories for years, wondering how people did it. I'd read posts on Hacker News, Indie Hackers, and other forums like DEV without ever sharing or posting myself. In fact, I wouldn't even leave comments. I was what I'm guessing many of you are: a lurker.

But a couple of weeks ago that changed. I launched my product Key Values, something I built all on my own, and got it to the top of Hacker News and Product Hunt, netting almost 30,000 pageviews in a few days.

There is a lot to say about what comes after that initial traffic spike (the post-launch trough of sorrow as they call it), but today I'll talk about what came before it.

Below, I discuss the six major barriers that I had to break through in order to go from lurking to launching.

Trust that slow progress is better than no progress.

I moved to San Francisco to go to grad school at UCSF and I didn't even know what a startup was until after I dropped out two years later. I was amazed by how people casually started companies, raised money, pivoted, folded, and then started new companies. It seemed like entrepreneurship was in everyone's DNA but mine.

Even after working at my first tech startup, I still couldn't see founder potential in myself. I wondered what I could have been had I been born into a family of business owners instead of a family of academics. I was 26 years old and had worked hard my whole life to pursue a career I no longer had interest in. It was a pity party mixed with mania, and I felt so behind compared to everyone else, I thought I'd never catch up.

Then I decided to embrace that.

I would trust that slow progress is better than no progress.

I decided I should learn to code. I mentally prepared for months of confusion and Lean Cuisines, signed up for a coding bootcamp (which I didn't actually finish), and started learning how to make something out of nothing. It was hard and I might have cried several times, but I knew this is what it'd take to catch up.

I don't even want to know how many Lean Cuisines I ate in 2015...ðŸ˜³

Even after I was able to get contract work, I still didn't have the confidence to start a business of my own. I didn't know when I'd feel ready or what kind of business I'd start, but I did know that whatever it was, I would need a marketing website.

I set out to find clients who needed a web developer to build a new website from scratch, but already had designers and a marketing team for me to learn from. I was looking for opportunities to get more exposure and breadth, and essentially bootstrap my education on how to become a founder.

Ironically, I needed Key Values to help me find jobs that aligned with my personal goals and values, but it didn't exist yet.

It took longer using the old-school method of waiting and hoping for the right opportunity to come my way, but I did eventually find work that paid me to round out my skill set and gain more confidence.

We all want to start at the finish line, but we can't. So start at the starting line and just focus on moving in the right direction. It doesn't matter how long it takes you.

Make sacrifices now to be a founder in the future.

I needed more than just confidence to try and start a business. I needed money. I needed time. There are tons of people who can work on passion projects after work or on the weekends, but I am not one of them. I've never been able to split my attention and focus on doing many things at once.

As a freelancer, I knew that I could start and stop at any time, but I needed enough of a cushion to work with focus, uninterrupted. People suggested I find an angel investor or raise capital, but... I didn't even have an idea yet. I needed a financial situation that would give me time to make mistakes and learn things slowly.

So I decided to hustle hard, double up on client work, and save money myself.

I worked over the holidays and on weekends, and went back to poor grad student living (I remembered how to live off of $32k/year in San Francisco). I stopped eating out, stopped drinking, and stopped buying things I didn't absolutely need. I even stopped taking Ubers and Lyfts and started biking everywhere.

I made sacrifices early so that I could later give starting a business my best shot. It took me more than 18 months, but eventually I saved up enough money to give me about 12 months of runway.

Everyone has a number of tolls to pay in order to get to where they're trying to go. It helped me to just focus on paying each of them, one at a time.

Stop trying to come up with a genius idea.

I was pumped to start my journey as a first-time founder. I knew how to code, I had money saved up, and felt confident that I'd be able to persevere through tough times. However, I was missing something pretty important.

I didn't have an idea!

Even as a web developer, I didn't see the world as a sea of problems that could be solved with technology. I'd often complain about things (why is it so hard to share bookmarks, I wish Spotify let me cut songs together in a playlist, it's so annoying when I forget my passwords!), but never thought if I could engineer solutions myself. Idea generation was a muscle I'd never worked out before.

So I gave myself homework to write down ideas every day, no matter how bad they were. In addition to writing down ideas, I also got in the habit of validating ideas to see if they were any good. Unfortunately, I ruled out each of them because I'd find out that someone else had already thought it before.

Then I had an incredibly important eureka moment.

Do not rule out ideas that there are already solutions for. I was driving, listening to a podcast of Laura Roeder talk about this and I almost had to pull over, it was such an a-ha moment for me.

It is one of the most recurring lessons on Indie Hackers, but it still took me a long time to understand it. If you look through each podcast episode and search for "competit" (for competitor, competition, competitive), you'll hear Wes Bos, Nathan Barry, Todd Garland, and others talk about the advantages of tackling a problem that already has solutions.

I didn't need a genius, never-before-done idea. In fact, I didn't even want one.

When I told people about Key Values, a product that helps engineers find jobs, everyone would name competitors. There are behemoths like Monster.com, LinkedIn, and Indeed, and at least a hundred more in this space. Previously, I would've given up on the idea immediately, but this time I didn't rule it out. Even in a crowded market, I still couldn't find an engineering team that shared my values.

I went further in validating my idea, making sure it was something I really wanted to work on.

Am I personally familiar with the problem I'm solving? Very. I literally spent the last couple of years working as an engineer, experiencing the pains of finding jobs myself.

Do I know if customers will pay? Yes! And this is part of the brilliance of not ruling out ideas that there are already solutions for. There are many competitors already making money from companies wanting to recruit, hire, and retain engineers.

Do I know of any effective channels to reach my target audience? Tons. As an engineer myself, I know that engineers hang out on Twitter, bootcamp alum mailing lists, Hacker News, and DEV.

Will I enjoy working on this every day for the next 2 years? I love meeting new people, talking about company culture, helping people find happiness and fulfillment, and learning about organizational psychology. I get to call this work?!

Is this a winner-take-all market? No way, Jose. It's a big pie and I only need a little slice. Nobody else has to lose in order for me to win.

If things go well, can I easily scale? Yes, I can automate the process of onboarding teams to my website by having them write their own profiles. It shouldn't require much, if any, extra money or manpower on my part.

Can I still walk away with a win even if my idea fails? Absolutely. I will learn so much talking to different engineering teams and building a product from scratch. More importantly, I can build an audience through Key Values and can take that with me even if the idea itself flops. Worst case scenario, I'm already researching which teams I'll apply to if this doesn't work out.

For anyone that isn't an idea person (ðŸ™‹) coming up with an idea is a massive barrier. I admittedly still suck at it. But you'll immediately be better at it once you stop ruling out your non-genius ideas.

Take pride in showing people the ugly behind-the-scenes.

Before I started building anything for Key Values, I spent weeks interviewing engineers, meeting with engineering managers, getting coffees with technical recruiters, and researching personality tests, dating sites, and match-making algorithms. Meanwhile, I was keeping up my indie lurker status.

I'd see other people ask for feedback about their products on Indie Hackers, and I'd think, "Wow. I'd be so embarrassed to show anyone that!" I was certain that my early versions would be prettier, better put together, and more thought out.

I promised myself to ask for feedback at the end of each week, and every week, I'd make an excuse and push it back. I kept delaying.

I spent almost 3 months working in a vacuum, obsessing over things like cool hover effects without having shown my website to anyone. I didn't even know if anyone wanted what I was making! I worked alone for so long that I went a little crazy. Don't do what I did.

Don't isolate yourself like this guy.

After months of lurking, I finally got the courage to make my first post in the Indie Hackers forum. I had 15 replies (okay, 6 were mine), but the feedback was so helpful and it sucked me out of the dark and lonely hole I had been working in.

I wish I had asked for feedback sooner. I wasted time and energy building out features that no one even wanted and spent many weeks feeling lost, spinning my wheels.

So what if your design sucks? Ask for design help! Not sure what your business model will be? Then ask for feedback about different pricing models! Don't be afraid to put yourself out there.

If you're doing it alone, you're doing it wrong.

If you're stuck, show people the ugly behind-the-scenes and tell them what specifically you need help with. Fellow makers and founders can help you get unstuck. You might not feel ready to put yourself out there, but I promise you that your product will never be good without your doing it.

Don't rely on one big launch.

I had never launched a product before and was incredibly worried that I'd mess it up. It was stressful thinking about when I'd launch, what I needed to get done before I launched, and how I'd recover if everyone who saw my product ended up hating it.

To get over my own anxiety, I decided to do a series of mini-launches first.
My first post in the Indie Hackers forum? I absolutely count that as a mini-launch. I incorporated everyone's feedback, graduated my key-values.herokuapp.com domain to keyvalues.io, and a month later, I mini-launched again with my second forum post in the IH forum..

The next week, I posted in a Facebook group for Dev Bootcamp alums and then the week after that, in a stealth-mode all-women's forum.

Launch, get feedback, improve your product, and repeat.

Truth is, you don't want to go from zero traffic to 10k pageviews overnight. Thinking this way will give you unnecessary stress wrinkles, and it also makes it hard to prepare for.

By removing the intimidating, anxiogenic, self-imposed deadline to launch Key Values, I let myself reap the benefits of the Always Be Launching lifestyle. Each mini-launch let me practice answering tough questions, fix bugs that people reported, and make improvements to the design, UX, and marketing of my website.

You don't have to start with one big launch, so free yourself from thinking this way.

Prepare for your first big launch.

I heard tons of horrors stories about failed launches: misconfigured websites, servers crashing, only getting negative feedback, and of course the worst one, having a product launch be a total dud. As a first-timer, I was sure there were other things I didn't even know to worry about!

It's hard to defend against the unknown, so I decided to focus on what I did know.
I set up Google Analytics and Amplitude to make sure I was tracking basic user behavior. I didn't want to drive a lot of traffic to my site and miss the opportunity to understand how people were interacting with it.

I also read Pieter Levels' launch advice and took it to heart. Key Values is a static website hosted on Heroku, and I set up server-side caching using Amazon CloudFront to make sure my server wouldn't crash. I had identified Hacker News as being a good channel months earlier (during my validation phase), and I decided to post in "Show HN" where I thought I'd have a better chance of getting traction.

I jumped right into the comments. I introduced myself and provided some context based on the questions I had been getting from my previous mini-launches.

I ended up getting Key Values on the front page of HN where it reached #3 and stayed on the front page for about 14 hours!

Another thing I did to prepare for my HN launch was rewrite my About page. I knew this would be a good idea but vastly underestimated just how important it'd turn out to be.

I did some research on what makes a good About page and made sure to hit the major marks. Open with the single sentence you want everyone to read. Include a photo of yourself. Make it personal. Provide a call to action to get in contact, subscribe, or both.

My About page ended up being the 2nd most visited page on Key Values.

There are plenty of things to worry about when doing your first big launch. My advice? Identify, analyze, and prepare as best you can. You won't be able to prepare for everything and that's okay.

Two things happened that I didn't prepare for at all.

First, someone posted Key Values to Product Hunt on my behalf and I wasn't sure what to do (I wasn't familiar with its community or what rules there were). While it ended up on the front page all day, I wished I could have coordinated my own Product Hunt launch. (You'll see that I didn't reply to anyone because I didn't even have access to comment on my own product. ðŸ˜‚)

Second, I hadn't prepared how I'd present Key Values to the press because it hadn't even crossed my mind. Matthew Hughes, a tech journalist, reached out to me over Twitter and since I didn't have a plan, I ended up forgetting some important things I wanted to communicate. It ended up alright though and he published an article about Key Values in The Next Web!

I prepared for my launch to the best of my ability, and looking back, can think of a few things I'd do differently if I had the chance. The takeaway though is that launches are a combination of preparation and luck. Focus on the things you can control and cross your fingers for everything you can't.

Final thoughts about launching my first product.

I did it! I launched Key Values. I built something I love and put it out there for other people to see and use. It feels like a rite of passage that I wasn't sure I'd ever go through, and I couldn't be more proud or happy.

When people ask me how I started Key Values, I tell them it was a side project that quickly turned into my full-time passion some time back in May. While this isn't untrue, it also makes it sound like something that happened overnight. Trust me, it didn't.

In some ways, Key Values started in 2012 when I left academic research to find a more fast-paced and risky profession.

It started at Homejoy (my first job at a startup) where I realized that a single line of code can be as impactful as having hundreds of 1-on-1 meetings.

It started when I made yet another career change to become a web developer, because I wanted to be able to start and finish projects without relying on others.

It started when I got inspired to create and innovate something of my own after months of lurking on the Internet.

It started when I learned how to adapt to the different working styles, goals, and values of my various clients.

It started when I became comfortable asking for feedback and engaging with my new community of founders, entrepreneurs, and indie hackers.

No one starts right at the finish line.

A lot of people are now asking me about what I'm going to do next. I've entered the post-launch trough of sorrow and the truth is that I'm still figuring out my next steps. I'm experimenting with different marketing strategies and exploring ways to turn Key Values into a revenue-generating business (I haven't started charging for my service). While I don't have all the answers right now, I'm optimistic and trust that slow progress is better than no progress.

I'll let you know how it goes. ðŸ˜‰

If you want to get in touch, you can email me (lynne@keyvalues.com), find me on Twitter (@lynnetye, @keyvaluesio), or better yet, comment below!