ct smith

I'm CT. I've been working as a technical writer since 2012. I love working with developer-focused docs using a docs-as-code workflow. I have special interests in API definitions, writing for AI consumption, tinkering with doctools, and cleaning up wretched doc sets. I get all my energy from finding solutions for big problems.

I'm always working on career development and learning new skills because when I get bored I get behavioral problems, like a Husky.

short version

Put me in charge of something. Trust me to get my work done. Give me room to find opportunities to be challenged or upskill. Tell me when I'm doing well or doing poorly. Approve my time off requests.

long version

I do my best work in organizations where I am given autonomy to get the job done in the way that makes the most sense.

I like a hands-off management style: my manager should be a blocker-remover and a course-corrector, not someone who seeks to micromanage my to do list.

I need to feel an extreme degree of ownership over my work and my product area, and I like interesting and challenging sidequests that help keep me engaged in my work.

I need to be in an organziation where frequent, two-way feedback and opportunities for ongoing education is the norm.

I have extensive docs-as-code experience and specialize in developer-focused documentation. I've leaned all the way into AI-augmented technical writing and writing for AI readers, and I'm having a blast embracing the new kind of knowledge engineering role that AI technology has created for me.

• UI text
• Help video scripts
• Contextual help
• PDF guides
• API docs
• SDK docs
• Blog posts
• Training modules (Trailhead)
• End user help docs
• Internal documentation
• Style guides
• Postman collections
• Print manuals
• Doc tooling CLIs

• Markdown, HTML, CSS
• CLI, git, Perforce
• AI tools / AI augmentation
• DITA / XML authoring
• Fern Definition, OpenAPI
• Static site generators (MkDocs)
• Vale and wrangling Vale rules and stretching it to the max

Really, none of this actually matters except the version control stuff. I learn new tools on each job. A core part of my personality is my inclination toward learning new tools and tech.

• Getting along with UX, engineering, product, support, and marketing to get docs out
• Thriving in remote, async environments
• Managing open-source doc content and contributors
• Leading massive migrations and tool improvement projects
• Writing for AI

Overview

Employee #24 at Payabli. I was hired to build a docs program and have been building ever since.

I own docs.payabli.com and manage a super tiny team of 2 (including me). It's startup chaos and sometimes I'm an information architect, sometimes an artist in residence, sometimes a QA analyst.

I'm a team lead and an IC who does a LOT of writing and building tooling.

Things I do at Payabli

• Manage the docs site at docs.payabli.com
• Manage our wildly successful Inkeep implementation (AI chat and more)
• Mentor and manage a single writer-cum-devRel person
• Manage a massive API specification that we use to build API ref docs, Postman collections, SIX auto-generated SDKs, mock servers for demos and more
• Lean so hard into AI-augmenting technical writing teams that we have all the tooling and components we need, and I can build anything I dream up
• Do some wild things with docs and engineer tooling cause no one has ever told me "No" here

Highlights

• Implemented Fern in record time and then wrote a case study
• Led my team to release 6 SDKs built off our API definition
• Invented a whole new-to-us content type called Decision Guides
• Built a lot of cool tooling like a CLI for the docs team that bundles all of our home-grown preprocessing scripts. I wish I could show you but they're proprietary
• Did some mad scientist stuff with arbitrary page frontmatter. Like this knowledge graph visualizer or this changelog generator
• I've built some neat components like this ACH timeline calculator that helps users understand the factors that affect ACH processing times, and this transaction lifecycle visualizer that shows how all the statuses work together

Publicly available portfolio pieces

• The docs site. Nearly every part of this, with very few exceptions, I did solo
• My GitHub: it's mostly private work but you can see that I stay shipping
• Blog post I wrote about how I 10xed the documentation team

Overview

I started as Amplitude's first developer doc writer in December 2021. Their developer docs had been created and maintained ad-hoc, and were scattered across three different websites that used two different toolsets.

Developer center project

I was hired to fix a documentation quagmire and create a scalable developer doc program. After talking to my stakeholders about what kind of doc tools they wanted, I went with a docs-as-code workflow built with GitHub, Material for MkDocs, and AWS Amplify. I stood up a new doc site from nothing, and got the whole engineering organization contributing to docs within my first 6 months at the company.

Highlights

• I unified three different developer doc sites into one docset and workflow.
• I created a docs-as-code workflow with input from my contributors in the engineering organization.
• I created Vale styles for Amplitude, and was able to scale my editing output using the linter.
• I set up and manage our CI/CD pipeline and AWS instance for the developer docs.
• I had no resources for this project, so I learned enough AWS, CSS, and JavaScript to implement the solution we have in place.

Publicly available portfolio pieces

• Video overview: The old Amplitude developer doc experience compared to the new one.
• Dev docs repo: The Amplitude developer docs repo. I built this. They've since archived it and moved to a new solution, but I'm the Caseyamp GitHub user.

Postman

I created a fully-documented public Postman Collection to help increase API adoption. Our customers were pleading for more useful examples, and Postman helped us cover this gap efficiently. I gathered existing collections, cleaned them up, organized them, documented them, and saved dozens of example requests and responses.

The collection is no longer available but it was #17 on Postman the year I released it.

After the migration

After launching the developer center at the end of June 2022, I shifted my focus to improving documentation quality and creating methods for identifying documentation gaps. I implemented linting for links and markdown prose, and helped implement robust user-behavior tracking.

Overview

I spent seven and a half years at Salesforce as a technical writer for Pardot (now known as Marketing Cloud Engagement), a marketing automation product. I left at the staff level, where I managed Pardot's developer and admin content. At one point, I wrote for 7 product managers and supported 27 scrum teams.