Skip to content

What I’ve learned from a weekly newsletter

I run a weekly newsletter focused on customer identity and access management (CIAM), and it just hit 53 issues, which means I’ve been writing it for about a year.

Thought I’d share things I’ve learned.

Weekly is a big commitment

Make sure you want to do this.

Writing a post every week is a bit of a grind. However, just like with blog posts, you can batch up newsletter posts. There are some weeks when I write three or four posts and schedule them out. This means that I can regularly take a week or two off.

Scheduling will vary based on your topic, of course. If I were writing a newsletter about news or current events, scheduling wouldn’t work.

But for many topics it’s a great way to keep the content flowing while not being tied to the keyboard every week.

Great way to keep on top of an industry

There’s a reason there are many newsletters with this approach. It’s a way to keep in front of interested readers, but it also forces you to keep on top of the particular industry you are writing about.

Due to the deadlines mentioned above, you’ll be forced to regularly think about new trends, find articles and books, and read people writing about the industry or topic you are writing about.

The corollary to this is to make sure you love the area you are committing to. If I wasn’t interested in CIAM, it would be a lot harder to write it. (Of course, nothing is forever, and when it makes sense, I might wind this newsletter down the same way I’ve stopped other projects.)

Have some way to keep track of good ideas

You never know when inspiration might strike.

I like to mail myself content and ideas that I think might apply. I write ‘for ciam weekly’ somewhere in the message.

Then, when I have time to sit down and write, I can search my email for ‘for ciam weekly’ and see all my proposed topics.

You could do something more organized like having a spreadsheet or a folder, but I feel like this works for my level of commitment.

You have to promote it

You have to promote the newsletter. You can’t expect people to find it. Places I’ve promoted it:

  • Hacker News (here’s a podcast I was on where I talk about how to interact with that site)
  • Various slacks I’m a member of
  • In other substacks (referrals)
  • My LinkedIn and Twitter (often scheduled)

Your list might look different but don’t forget you have to do this.

But. Don’t be a drive by promoter. I don’t post in places I don’t frequent.

You can vary between original articles and commentary

I have written some long form posts, in particular a series about the multiple ways user data gets into a CIAM system.

I have also written commentary, where I look at a blog post about password honeypots or other articles that discuss CIAM topics, and reflect on that content.

Both work fine; varying up the content is a great way to keep things interesting for me and my readers.

It’s a long game

I have 80 subscribers with an open rate that is around 50%. Some might look at that and say “after a year, you only have 80 subscribers” and shake their head.

I look at it and say “there are 80 people who want to read what I have to say about CIAM!? And at least half of them read it!”

Newsletters are powerful because they deliver your thoughts to your readers’ inboxes, but they are a long game, especially when niche.

Tech talk checklist

When you do a software related talk at a conference or a meetup, there are lots of things to consider.

This is a checklist so that next time I do a talk, I have something to reference.

My target audience is technical folks at meetups and conferences where the audience size is 5ish to 100ish. I’m sure things change as audience size and content types do.

Slide content

  • Have a QR code for slides
  • Have a QR code for any other action you want
    • “Apply for a job with us”
    • “Try our software”
    • “Read our content”
  • End on QR code slides and include “thanks” and contact info
  • Have a resources slide with more info
  • Display your twitter/social handle on every slide in the corner
  • The infamous about me slide
    • Make it quick (> 1 min)
    • Even “who cares”
  • Have a conclusion slide just before the QR code/Thanks slide
  • Ranking of content (all other things being equal)
    • Fewer words is better than more words
    • Pictures or memes are better than words
    • Animated diagrams are better than pictures
      • Easy implementation: have multiple slides that you arrow through
    • Demos are better than animated diagrams
  • Audiences are forgiving of demos, but you can always record a video for backup if the stakes are too high
  • Make code big enough to read
    • Including if you are displaying it from your IDE
  • Highlight important code bits with color
  • Add code to liberally licensed repo
    • Include on the resources slide
  • If presentation is long, break into sections and have section nav on the main section pages to orient audience
  • Don’t be afraid of too many slides
    • Be afraid of people reading your slides
    • Be afraid of boring people

Delivery

  • Sections of audience won’t be paying attention
    • Focus on those who are
  • Remember that you are the expert and people want you to succeed
  • Pause for questions
    • Include a slide or time at the end
    • Incorporate answers into talk if you get them regularly
  • Be good about time limit
    • Practice
    • Cut stuff in the middle (questions, other sections) to get to conclusion

Prep/Followup

  • Promote on socials (schedule it)
    • 2-3 weeks out
    • 2-3 days out
    • same day
    • after (include slides)
    • Tag the organizer or conference/meetup if you can
  • Don’t plan on doing anything intense the hour or so before your talk
  • Download a PDF of your presentation in case you don’t have internet
  • Get to the presentation room at least 15 minutes ahead of time
  • Test AV connections including mic if needed
  • Bring your power cord for your computer
  • Connect to people who attended talk if they send a request
  • After talk, hang out for a bit if you have time, to chat with folks. Many won’t ask questions during talk, but will after.

I’ll plan to add more to this as I think of it, but this is a good starting checklist for me.

New adventures, same company

I recently shifted roles at FusionAuth. Where I was previously head of developer relation (devrel), I’ve relinquished this role to Tony Blank, who is now leading that team. I can’t wait to see what Tony and the team do to help developers build on and learn about FusionAuth.

But why did I switch roles? I’d been leading the devrel function for almost four years and built the team to:

  • two full time employees
  • one part time contractor
  • three agencies

Last year, I took a long hard look at what I was doing and what I wanted to do.

I noticed I didn’t want to be on a manager’s schedule and didn’t want to spend a large chunk of my workday in meetings. I enjoyed the impact of the devrel team and am very proud of everyone who was a part of it.

Yet I also noticed a pattern in my career. I have often:

  • been hired in an IC role
  • had an opportunity to take a management role, because the business needed it and I could do an okay job
  • took the opportunity
  • didn’t enjoy it but also didn’t see a way out
  • started looking for a new job
  • quit the company

I can think of three times this has happened in the last decade.

When I started to build out the devrel team at FusionAuth, especially when I was hiring the full-time employees in the last year or so, I communicated clearly to my managers that I’d build the initial team because I saw a business need. Devrel and market awareness go hand in hand and I think the latter is what FusionAuth needs right now.

But I was also clear that I wanted to hand team management to someone who cares about that as a discipline. I’ve learned enough about myself to know that I like some parts of people management, but that I don’t compare well with others working toward mastery of that craft.

I’m happy to report that my managers at FusionAuth heard me. They were willing to allow me to hire someone who has built out a great devrel team in the past and who really loves to do so; that would be Tony. (Raising our round helped with this too.)

So, where does that leave me? My new title is principal product engineer. What I’ll be doing is high impact individual contributor (IC) work. Combining my knowledge of CIAM, my understanding of the company based on my tenure, and my software skills, I’ll be working on processes, code, and integrations to help solve FusionAuth’s business problems.

At a company growing as fast as we are, there are always bumps to smooth out. Because of my history and skillset, I’m a good person to help. The first thing I’m doing is building out a training program to help employees sell more effectively; it’s been fun to evaluate and select a learning management system, create the curriculum, and build out the training modules.

I’ll miss some pieces of devrel, but I expect to continue to do some devrel-esque tasks. For example, there are several long-form guides and example applications that I can’t wait to write. In fact, building out the training has unearthed holes in our documentation that I can’t wait to fill.

When I look back, I often spun out of a company because I didn’t see a way out of a management role. This is because managers are among the most highly paid employees. Once I was promoted, I didn’t think that my superiors, who were in some cases the owners of the company, would see a place for me. I wasn’t sure there was a high impact IC role at these companies.

But I made a mistake. I didn’t talk to them about alternatives. Part of this was due to my immaturity but a larger part was due to my fear and distrust. After all, if I mentioned I wasn’t happy managing a team, but that was what the business needed, I feared I wouldn’t be needed. But jumping to this conclusion without discussing options removed any agency from my managers. It is possible that I could have moved laterally within the company or found another path forward.

I’m ashamed that I didn’t trust them enough to explain how I was feeling and discuss the job shift I wanted to make.

That’s why I’m proud I had this tough conversation at FusionAuth. I was able to because:

  • I had seen the pattern enough times to know that I could do management for a while but would eventually become unhappy enough to leave
  • I knew I didn’t want to leave because of the team, the problem and the overall opportunity
  • I was in a unique position, having been there for most of the growth yet not having a C level role
  • I’d seen other folks in difficult situation be treated fairly

This conversation could have resulted in a departure for me if there was no budget or need for a high level IC role. The fact that it didn’t have that result gives me hope that there is a path, and a budget, for non-managerial technical leadership, even at smaller companies. In fact, I’m hoping this inspires other folks at FusionAuth, who may want to increase their impact without managing people, to stick around.

I also look forward to solving tons of problems as we keep growing.

Here’s to new adventures!

Don’t just build a backlog, share it too

I have started sharing more blog posts and podcast episodes on Twitter, LinkedIn, email lists, slack channels, and other places. It’s kinda fun to look back over past work and find something that resonates. I’ll often discover this when I’m engaging in a discussion or see a post on a related topic.

This is one of the benefits of blogging. You can lay out your thoughts on a complex subject in detail, considering various points of view before coming to a conclusion. When someone brings up the same subject, you can share your thoughts with a single link copy and paste, rather than retyping all your thoughts.

There’s also value a backlog of stream or podcast guest appearances. Don’t just share the podcast when it first comes out (though you should do so). Share it repeatedly! You and the host had a good conversation, right? Most conversations are just as valuable a year later as it was a day later. Even if you are talking about the news of the day, your analysis should have long term value. And podcast hosts love to see someone share an old episode; it helps raise the profile of their efforts.

I like to use scheduling for some of this backlog highlighting, as that lets me batch i tup.I have successfully scheduled out posts using native tools. Both Twitter and LinkedIn let you schedule posts. Twitter lets you schedule out posts up to 18 months out. LinkedIn is more limited and only lets you schedule out three months. But if you are posting two times a month, that’s still six posts/pieces of content you can share.

Don’t rely entirely on scheduled posts. Engage spontaneously. However, having these posts scheduled means you are still sharing your past work even if you have a busy week or a vacation.

You can highlight a backlog of short form content too. With Twitter, I also do “still true” posts where I retweet one of my posts that I feel is timeless. Here are some examples.

Finally, a public backlog of your thoughts is a great way to show your expertise and growth over the years.

You know who likes to see that?

Employers.

Should your customers be your devrels?

Saw this spicy take:

If Twitter goes away, this is from Stefan Avram, who said “You shouldn’t have devrels. Your customers should be your devrels”. (Stefan is a cofounder of Wundergraph and head of growth. Good on him! It’s hard to found a company.)

I wanted to talk about this statement because, well, I’m a devrel (a developer relations professional) and I don’t agree with it.

First, let’s rule out a few obvious points.

  • If you aren’t targeting developers as users, you shouldn’t have devrel as a function.
  • Even if you have a devtool, if your main sales channel is top-down, devrel is not super useful.
  • If your product doesn’t have some kind of free version, devrel is going to have a tough time. Not everything has to be free, but it’s really tough to get a developer to offer both time and money to learn about your product.

I hope this goes without say, but it is fantastic if your customers are advocates for your product.

However, I think this approach is a bit naive. It’s a bit like saying “You shouldn’t have sales people. Your customers should be selling your product.”

The truth is that there will be some subset of your users who are enthusiastic and advocate for your product if it is good enough to buy. I have interviewed some for FusionAuth. You should do everything you can to encourage this behavior, including:

  • talking to them
  • learning about their companies and successes
  • giving them swag
  • sharing their stories far and wide

But these folks’ job isn’t to promote or support other users’ use of your product. They’re busy building their product, company or project. As they should.

A high functioning devrel team can offer:

  • quality content
  • support for a community
  • up to date, relevant code

This team should be working to improve all of these and make the experience of all of your potential users better and better.

And they’ll care about the company’s overall mission. And they’ll have inside access to the codebase, the engineering team, and the product roadmap. And they can offer reified, constructive feedback from users to your teams.

That’s a large number of important business functions. If they are performed by customers, who are, again, busy working on their own stuff, they’ll be done at best haphazardly and at worst not at all.

Think about it. How many blog posts have you written about a product? How many of them were deep dives?

I can say that I’ve done it for a few products (stripe, zapier, AWS, lob) and none of those are deep enough to qualify as anything other than the briefest introduction to a product. A developer who encounters posts like these will either be intrigued and want to dig in further or bounce, but they certainly won’t have enough info to make a decision or use the product.

By making documentation, community and code examples the developer relations team’s problem, you’ll get more focus and better results.

And more users and happier customers.

How to solve the “this application is slow” type of problem

How do you feel when your boss says “the application is slow, please speed it up”?

Personally, my heart sinks and then I get excited. Though they can be frustrating, this kind of thorny performance issue is fun if you look at it the right way.

Whenever I’ve tackled problems like this, the first thing to do is define the start and the finish line, as precisely as you can.

This requires understanding the application’s behavior and architecture. Where is the data stored? How is it presented? How is it modified? Are there types of operations that happen regularly? What exactly is “slow” about the application?

Try to avoid jumping to conclusions here. I understand the temptation to make a change as soon as you think of one that might help, but it’s better to approach this systematically.

Suppose you find out the issue is the database. Operations are too slow and the CPU is not pegged. You know the type and version of the database, how the application calls it, and more.

Here, a good finish line might be “we need to be able to handle updating the main table with 50k items in 1 second”. If you don’t have a precise finish line, this type of work can be endless and frustrating. After all, it is almost always possible to “make it faster”, but you will reach the point of diminishing returns.

If possible, set up a test scenario/system that you can run through repeatedly as you make changes. If not, figure out some other way to test that changes have a positive impact.

Next brainstorm possible solutions and think of two numbers for each: level of effort and hoped improvement. Doesn’t need to be too precise, a scale of 1-5 is fine. Here’s an example for a database bottleneck:

  • upgrade the size of the database. LOE low, impact medium
  • increase the disk speed: LOW low, impact high
  • running explain plans and adding suggested indices: LOE medium, impact high
  • offloading operations to read replicas: LOE high, impact high
  • …etc, etc

Then start doing low effort, high impact changes. Run through your scenario and tests after each one. See if you get closer to the finish line. Rinse and repeat.

This type of performance issue is a case where hiring an outside consultant/contractor can make sense. You don’t have to spend a lot, since the scope of work can be limited. They can work with you to define the start and finish lines as well as possible steps if you don’t have the time or knowledge to do so. Then have an internal team take the specific actions and test each change to see if it helps.

Advice for startup founders

On an email list I’m on, someone was recently accepted to an incubator program. They asked for advice about startups. I couldn’t resist!

I wrote this (lightly edited) and wanted to post it here so it’d have a permanent spot on the internet.


I’ve been a founder or early employee/contractor of six startups over my two+ decades. Some are still kicking, but none have had an exit. Please consider that when contemplating my advice.

When building an early-stage startup:

  • talk to customers, talk to customers, talk to customers
  • revenue > funding
  • know your business domain. If possible, co-found with someone who is an expert in the area if you are not
  • choose boring technology whenever possible
  • choose technology that you know whenever possible
  • be prepared to consult or find other ways keep the company alive if you don’t have immediate revenue
  • take advantage of in-person support systems to keep your spirits up
  • exercise: it’ll help you be a better founder
  • when you have an ask for someone, make it easy for them to say yes (be specific, do your research, scale the ask to the relationship strength)
  • remember, building a company is a marathon not a sprint (but sometimes you need to sprint!)
  • VCs and founders have shared incentives (both want a successful business)
  • VCs and founders also have misaligned incentives (you get one bet, they get N bets; you need $X, they need $10X-100X)
  • understand your financial runway
  • understand your emotional runway
  • if you have a spouse or partner, make sure they are on board with the big decisions you make
  • being lucky is usually more of a factor than being good
  • you can sometimes make your own luck through hard work
  • all founders should take part in the sales process, no excuses
  • your company’s biggest competitor is customer inertia (or Excel)
  • all advice is contextual, always understand the context of the giver
  • talk to customers
  • talk to customers

Best of luck!
Dan

PS Talk to customers.


Thoughts on a freemium software product

At FusionAuth, we have a free software product that is a critical part of our business model.

A free product is pretty common in the software space because of two things:

  • Software needs to be used to determine its efficacy; a software package is not like a shovel. With a free option, money is no longer a barrier (though time is).
  • Software has zero marginal cost; once you put the effort in to build the first copy, you can create 1M copies for essentially the same cost.

However, supporting a free software product sure isn’t free. This post covers what you need to think about in terms of investing in a free product.

If FusionAuth were a public company, this is where there’d be lawyerese talking about forward looking statements and safe harbors and whatnot. Suffice it to say that this entire post is my personal opinion.

Side note: a free product is often but not always open source. Free can mean a tier of a SaaS, an open source project, or a downloadable product. Open source has additional complexities, so I’m going to focus on products that are “free as in beer” in this post. FusionAuth has a downloadable product that devs can run for free, within constraints.

We have internal discussions about tweaking the free version of the product. Options include:

  • Keeping the product as-is, but making investments in the community version. This includes bug fixes and feature improvements. Since our free product is production ready and feature rich, this is a solid choice.
  • Improving the free product. There are multiple dimensions to doing so, including:
    • Improving discoverability of the free option, such as highlighting it more on the website, advertising it, or investing in additional documentation around its features and usage.
    • Changing the license to make it usable across a greater number of use cases or with different limits.
    • Move features currently restricted to paid plans to the free product.
  • Degrading or limiting the free product. These are basically the flip side of improving it:
    • Increasing friction to find or use it.
    • Modifying the license to prohibit currently allowed use cases.
    • Clawing back features from the free plan, focusing on features useful to businesses who are likely to pay. For example, the free plan currently allows unlimited SAML connections, which many competitors throttle.

For the foreseeable future, we are following the first path, improving the free product. The free product is usable and robust, and we get substantial benefits from the community’s usage.

Let’s dig into these benefits.

The value of the free users

First, if developers are using our free software to solve their authentication needs, they aren’t using someone else’s. While you can’t pay a mortgage with developer attention, that doesn’t mean it has no value. Such attention expands our mindshare and market share. More mindshare means that people are learning about our solution. Gaining market share means they aren’t using someone else’s solution. Therefore they are neither paying a competitor money nor getting more familiar with their solution.

Second, such users spread the word about our solution. Sometimes they talk about it on social channels and sometimes on a review site. But often it is prompted by us; here is an example of one of my favorite set of blog posts, entirely drawn from community experiences. Talking to community members has opened up my eyes to the wide variety of ways our product is used. Community stories are not, however, useful as case studies for the sales process. They aren’t detailed enough. But they are still helpful to spread the word about the product, highlight our community members and catch long tail keywords.

Third, free users improve FusionAuth. They do this by:

  • Finding flaws in FusionAuth, such as bugs or regressions. Here’s an example issue, including workarounds.
  • Requesting new features. We leverage the community further by asking users to upvote such requests so we know what the community wants from the product.
  • Exercising the software by performing integrations that we would never have done. This is a variant on finding bugs. For example, a free user reported we aren’t to spec with regards to the SAML relay state; that’s never been an issue for the existing SAML integrations.

Finally, free users also offer each other support. While not all community members are active all the time (our community is more of a Google than a Facebook), a few have a presence on our forum, slack and GitHub issues.

The conversion of free users to paid users

Free users may purchase the software in the future. Once someone needs paid features, they may stop using the free plan and buy. We’ve built up trust as a solid solution in their mind and they have already integrated us. So a free user will consider paying you when they are looking to purchase.

Of course, you need  a product worth paying for above and beyond your free offering. At FusionAuth, we accomplish this in three dimensions:

  • Operating the product. Many of our customers are fine with the features of the free plan but don’t mind paying us to run it. This can include service level agreements (SLAs) as well, which are like catnip for enterprises.
  • Paid features. These are either features good when you are at a certain size (like SCIM) or enhancements of features available in the free tier, such as a more customizable registration form or MFA policy. Choosing the features to charge for is critical, but is really hard to get good data for since it is very business specific.
  • Support. Knowing you can ask questions of the engineers behind the product is valuable, especially for larger businesses.

There are two ways for free users to convert.

They can do it directly, where they use the free version to evaluate or run a “proof of concept” to ensure that our product meets their needs before they ever engage with us. We have plenty of customers who say “we’re already a few months into integrating with you” on our purchase kickoff call, and that ability to “get going” with the product without talking to a sales rep or pulling out a credit card makes the decision easier. Again, they trust the solution will solve their problem. They can also see how the company treats the free users and the community in general too.

There are also people who “kick the tires” with the free product and discover that it doesn’t meet their needs. We don’t hear about as many of those, but I have talked to a few. In this case, both parties win; getting to a quick no is not as good as a “yes” but is still pretty good. There are also people who do a self-led POC and incorrectly determine it isn’t a fit. They might miss features through lack of docs or a conceptual mismatch. We keep trying to improve our docs, education and product, but you can’t win them all!

There’s also an indirect conversion path, alluded to in the above mindshare point. Free users may use our software on a side project or to learn about authentication and OAuth in general. This lets them add FusionAuth to their toolkit. Then, later, perhaps years later, they can bring us into a project as an option to evaluate or to recommend us for purchase.

In general, free products let you build trust and de-risk purchases.

Keeping up with the Joneses, err the competition

Finally, competition matters. Lots of our competitors have a free offering. Again, this is due to the nature of software. Yay to zero marginal cost!

This is also compounded by the nature of developer tools. Devs are looking for tools to solve a problem, but once they’ve integrated one, it sticks around. One time I picked a bug tracking system in a few days (phpbt, what what!) and it was used at our company for years. This means if you have a friction free evaluation process, you stand a good chance of being embedded.

Offering a free product matters for our market positioning.

Nothing sells quite like free.

In conclusion

When you make a free product available, you are offering users something of value. Resources are scarce, and supporting the free product isn’t free.

Determining how much time and effort to expend supporting it depends on the value your company gains. You won’t always be able to calculate it in dollars and cents, but it exists nonetheless.

20 years

Wow, it’s been 20 years since I started this blog. The world and my life have changed quite a bit, but I still like to muse on technology, business and more.

Thanks for reading! I appreciate everyone who takes the time to listen to me, whether you scan it, share it, or reach out to me to let me know.

Still think blogging is one of the best things you can do if you want to:

  • engage with people
  • understand a subject
  • build a business
  • create a name for yourself
  • think deeply about a topic
  • find a job (but not quickly!)

Thanks again for 20 great years!

Docker thoughts

Docker is amazing tech for developer productivity.

You can package up the dependencies for your application into one file (a Dockerfile) or more than one file (a docker-compose file). You might use the former for an application or service and the latter if your application depends on a database, cache, or other external architectural component.

I am definitely late to the Docker party, as I remember Eric Norlin interviewing Solomon Hykes in the early 2010s at Gluecon. In 2018 I used it to stand up some consulting projects, but wondered at the value and the required investment.

I’ve recently been using it extensively at work to set up quickstarts. These tutorials let folks stand up our software quickly for evaluation purposes. Docker is a fantastic fit for this use case.

I’ve been a big fan of detailed documentation and readmes for setting up development environments, but Docker takes all that documentation (including tedious things like ‘install python 3.8.12. 3.8.11 doesn’t work’) and puts it into code that is accessible with single command.

I have a foggy memory of detailed readmes, hours of setup and dependency hell, but Docker removes all of that. Doesn’t mean your Docker images/compose files can’t get stale and won’t need love and attention, but it does mean you can control when you test and upgrade such dependencies, rather than discovering it when a new developer comes on the team and can’t get their environment set up.

Shipping software to production via containers (Docker or otherwise) has operational benefits, but I’m less familiar with those. One of the nice things about developer relations is you’re separated a bit from operations. (It’s one of the downsides as well.) I haven’t recently worked with a production system where containers were used, but I have read nice things about the approach. Here’s an article from Google which covers the technical benefits.

What about the licensing? This business model change rocked the world of happy Docker users, but when you take funding, you have to make money. Actually, if you want to survive as a company, you have to make money, but if you take funding, you have to try to make a LOT of money. That’s the game, make sure you know before you start to play. But that’s a different post.

As far as Docker licensing, as a Docker user, you have two options:

  • pay docker when you reach the threshold
  • use a docker alternative such as finch or podman

As the previous paragraph implies, Docker is a subset of containers. The benefits I mention above apply to container based systems, not just Docker systems, but Docker is the solution I’m most familiar with.

Docker, and containerization in general, feels like as big a leap as Stackoverflow, git or memory managed languages in terms of developer productivity.