20 Jul

Feature Toggling On, Three Years In

Wow, three years goes by in a blink of an eye. Three years ago John (LaunchDarkly co-founder) and I both started working full time on LaunchDarkly. We had an idea that we could draw on both of our experiences in software development to help make better software. Funnily, John and I had wanted to start a company together for a long time, but thought we didn’t know enough about any field. So, in the meantime, we’d both continued to work in software for decades. As it turned out, we know a lot about software development lifecycle and managing features effectively.

Now we have customers all over the world (literally) who use our software to eliminate risk and for feature management. One of the favorite parts of my job is to visit customers – I love hearing how they’re using LaunchDarkly and how we can help them manage features. Just in the last four weeks I’ve visited customers in Singapore and Switzerland. And amazing to me, their use cases were very similar – moving away from long lived branches, getting code out more quickly. A CTO in Hong Kong made a brilliant analogy of feature toggling to “lean manufacturing”. The idea of lean came from Toyota; if you circulate through your inventory more quickly, you can be more productive. The same can be applied to code – the quicker you can get it out to the real world, the more effective you can be in validating your ideas and honing its quality. I’m proud that not only do customers love us with a high NPS, but we were also recognized by Gartner this year as a Cool Vendor in DevOps.

Also, the company itself has grown. We have our own office now in Oakland! It’s in a beautiful Art Deco tower, and we are still able to enjoy eating lunch together every day. One of the happiest things the team did lately was rotate all the lunch tables so we had one long table (Hogwarts style). The team didn’t want anyone to have to sit alone if there was no room at a table. Adam Zimman, our VP Product, summed up why he liked working here with “I feel like I can bring my whole self to work; and I’d like to build a culture where everyone feels that way.”

What’s next for LaunchDarkly? We’ve got more functionality coming to help you with effective feature management. We’re hiring! And we’ll also be on the road more – we’ll be at NDC Sydney and Atlassian Summit. I recently met Jeff Lawson from Twilio – he mentioned to me he tries to meet with three customers a week, a worthy goal. My goal for the next year is to meet with at least two customers a week. Come by, say “hi!” We’d love to hear how you’re doing feature management.

28 Jun

To Be Continuous: Giving Founders Feedback, Outsourcing Early Development, Giving Gifts, Flat Orgs, Hacker News Comments

In the latest episode of To Be Continuous, Edith and Paul discuss 5 topics that are relevant to most startups. They first examine how you can constructively tell someone that their startup sucks. They then look at why it’s a bad idea to outsource early stage development. They also discuss what makes a good gift and delve into the downsides of flat organizational structures. Paul also shares his impression that Hacker News comments are becoming too Redditified. This is episode #33 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Giving Founders Feedback, Outsourcing Early Development, Giving Gifts, Flat Orgs, Hacker News Comments” »

20 Jun

What’s the deal with Custom Roles?

At LaunchDarkly we believe that the ability to finely tune access controls in the fast-paced developer space is mission critical. We’ve introduced custom roles, modeled after Amazon Web Services’ IAM service, to all of LaunchDarkly’s enterprise customers, allowing admins to control permissions at a granular level. Yet custom roles are more powerful than plain access control restrictions in that they allow you to extend functions inherently reserved for engineering teams to other stakeholders in your organization.

Let’s assume your organization has the following teams: Engineering, Customer Support, Sales, and Marketing. We’ll define policies for each that allow the organization to become more efficient and less dependent on the engineering team.

Customer Success

The value of custom roles is demonstrated quite well in the case of the customer support team, so we’ll start there.

Let’s say a team member has received a support request where a specific user has reported broken functionality on a new feature that is impacting other core features and the team is scrambling to investigate. In an organization without LaunchDarkly the customer support team would have to provide the engineering team with steps to reproduce the bug and wait for them to implement a fix. With LaunchDarkly and custom roles, the support team member can disable the problematic feature for that particular user to temporarily resolve the issue, and depending on the prevalence of the issue elect to kill switch (turn off) that feature for all users.

The support team member is empowered to remedy issues in-real time. Moreover, the engineering team is no longer launched into emergency response mode; features toggled off can be resolved at a later time.

Here is a simple custom role to support that new value:

This custom role would also be useful to sales team member, allowing that stakeholder to turn a feature on or off for a specific user based on customer plan selection. It’s less likely that the sales team would need access to the kill switch, so we would remove that in this case:

 

Marketing

The marketing team can also benefit from custom roles. Let’s say the team wants to A/B test  a new logo or design assets. Without LaunchDarkly and custom roles, the marketing team would have to coordinate this process with engineering releases. With LaunchDarkly and custom roles, engineering could implement flagged features to allow them to do this on their own schedule and tag the features with a marketing tag. This tag could be used to identify marketing features and also double as a custom role requirement.

When the marketing team is ready to run the A/B tests, it has full control over the features and goals with that marketing tag, relieving the engineering team of the burden of supporting marketing once it has implemented the features. The engineering team can move on to exciting new features while the marketing team tests and analyzes its theories.

This marketing role is also very easy to create:

Engineering

Defining custom roles for the engineering team is probably the least interesting topic in that custom roles don’t quite offer this group anything it didn’t have before. Nevertheless, we can use roles to avoid destructive operations that might affect other team members or end-users.

Imagine a scenario where a flagged feature exists in a production environment and a developer accidentally deletes that flag. An action like this would disable the feature for all end-users. Ideally we would restrict this permission to designated decision-makers.

For this purpose, we’ve created a slightly modified version of the built-in “Writer” role which does not allow for deletion of resources:

For a full list of resources and actions, and more details about the policy creation process, check out our custom roles documentation.

16 Jun

To Be Continuous: Finding Co-Founders, Engineers vs. Artists, Funding Napkin, NPS, Hiring

In the latest episode of To Be Continuous, Edith and Paul discuss 5 topics that are top of mind at most startups. First, they examine approaches for finding a good co-founder. Next, they delve into Michael Dearing’s course on the artistic side of engineering. They then move on to discuss the SaaS Funding Napkin and why 27% of companies that raise series A have no revenue. They also share their experiences using Net Promoter Scores and consider the pros and cons of hiring fast vs slowly. This is episode #32 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Finding Co-Founders, Engineers vs. Artists, Funding Napkin, NPS, Hiring” »

07 Jun

Tim Wong launches the Technical Account Management Program at LaunchDarkly

I’m just getting started. (Image credit: Viktor Hanecek)

I’m excited to join the LaunchDarkly team after spending the last nine years at Atlassian Software. At Atlassian, I was one of the founding members of their Technical Account Management team. In a scant three years, we grew the program from two people to twenty, representing companies that are household names across the globe. I hope to take my experience and build a rockstar program here at LaunchDarkly.

What is Technical Account Management (“TAM”)?

The purpose of the TAM program is to help our customers get the absolute most out of LaunchDarkly’s capabilities. No two companies have quite the same needs, so we offer directed, proactive, and strategic guidance that is suited to each company. We take the time to learn how your teams work, to understand the various use cases that you have, and to collaborate with you to develop solutions to your needs.

One way to understand how new technologies come to be adopted is through the lens of People, Process, and Technology — the technologist’s version of the three-legged stool. Within this analogy, the LaunchDarkly platform is the Technology leg. It offers a new and powerful capability, but it is only useful if the teams adopting it understand and internalize both what it does for them and how to implement it.

Particularly as teams scale and usage expands across the organization, there needs to be an ever-expanding center of knowledge. The learnings from the early wins with the platform need to evolve into a program of change. We’re building the TAM program to help teams move from reactive troubleshooting and problem-solving to making proactive and strategic choices. I like to think of it as the difference between asking “What was this flag supposed to do?” to “How can we know that a release will be successful even before we launch it?”

Our aim with the TAM program is to be a trusted advisor. To be successful, we know that we first need to understand what you’re trying to achieve before we can collaborate with you to get it across the line.

What else do you do?

I’ve been working in tech for over a decade, and I can spend far too much time talking about the viability of various tech trends and movements. I’ve lived in the Bay Area for close to 30 years and am a bit of a foodie. In my spare time, boardgames have been a passion of mine for the last decade and a half: I’m mrwong on boardgamegeek.com.

Finally, I make a great mojito.

02 Jun

Week n+1

Start? This is just the next step in the journey (image credit: Andrew Lipson)

I recently wrapped up my first official full week at LaunchDarkly. Although, I’ve been working with the team as an advisor/consultant for a number of months. Over the past year I have been advising and consulting with various start-ups looking for a good fit. I would often remark to folks that I was “company dating.”

More like introductions from friends than tinder. (Photo credit: Reddit post)

Honestly, I have very little dating experience. My wife and I met my 2nd (her 1st) year in college and haven’t looked back. Similar on the job side, I started at EMC a year after graduating and then was the first internal transfer to VMware. For almost 15 years I enjoyed the stability and resources of a large company. But, then I started to feel the need to grow and participate in the changing landscape I saw in software development trends.

Since leaving VMware I have spent a lot of time thinking about the gap between the old school development frameworks (e.g. waterfall) and newer practices (e.g. agile, scrum, continuous deployment). Tools like git, continuous integration, and automation have radically changed how we release. At EMC and VMware we measured our releases in years, or sometimes months (the same way a parent refers to their 22 month-old toddler). Compared to GitHub where we released multiple times a day.

This whole cloud thing is likely just a fad. (Photo credit: Twitter)

Recently, I’ve started to bucket these tools into three phases of for software development: Concept, Launch, and Control. I’m working on a blog series to discuss each of these in-depth, but this framework is what got me excited about LaunchDarkly. Feature management, while not the shiniest tool, provides the foundation for eliminating risk and delivering value as teams push to move faster and to be more reliable.

In addition to my passion for our product, this intelligent team, my carless commute, I did have one additional objective: to be a part of a diverse and equitable company. Not simply an organization that accepts diversity, but one that actively pursues a more diverse and inclusive team as a imperative for building better products and services. So far a great start to my next long-term relationship.