Internal CLI That Saved 15 Hours/Week Across Engineering
Led the development of a custom CLI tool that unified repetitive engineering workflows — deployments, log tailing, secret management, and scaffolding — saving 15 hours per week and reaching 85% adoption in the first month.
Challenge
Repetitive operational tasks like environment setup, deployments, and log tailing consumed 15+ hours per week across engineering teams.
Solution
Custom Python CLI tool unifying common workflows into a single, well-documented interface with consistent patterns and guardrails.
Result
15 hours/week saved across teams, 85% adoption within the first month, and a measurable reduction in deployment-related errors.
The Problem
At a mid-size data platform company, our engineering teams had accumulated a patchwork of scripts, aliases, and tribal knowledge for everyday operational tasks. Deploying to staging required running four commands in the right order. Tailing logs across services meant remembering different incantations for each environment. Rotating secrets was a manual, error-prone process documented in a wiki page that was always slightly out of date. I estimated that across our 30-person engineering org, these repetitive tasks consumed over 15 hours per week — and they were a frequent source of mistakes, especially for newer team members who had not memorized the unofficial playbook.
What I Did
I led the design and development of an internal CLI tool — built in Python with Click — that unified the most common engineering workflows into a single, consistent interface. The tool covered five core commands: deploy for pushing to any environment with built-in safety checks, logs for tailing and searching logs across services, secrets for managing environment variables and rotating credentials, scaffold for generating new service boilerplate from approved templates, and env for spinning up local development environments.
Each command was designed with guardrails. The deploy command required confirmation for production, automatically ran pre-deploy checks, and posted to Slack. The secrets command enforced rotation policies and logged every access. I worked with each team lead to understand their specific workflows and edge cases, ensuring the CLI handled real-world usage rather than just happy paths.
Documentation was baked in — every command had help text, examples, and error messages that told you what to do next. We also built an update command so the CLI self-updated, avoiding the classic problem of engineers running stale versions.
The Outcome
We launched the CLI with a brief demo at our engineering all-hands and made it available via our internal package registry. Within the first month, 85% of engineers had installed it and were using it regularly. Time tracking showed a consistent 15-hour-per-week savings across the org. Deployment-related errors dropped noticeably because the CLI enforced the correct sequence and ran validations automatically. New engineers especially loved it — their setup time dropped from half a day to under an hour. The CLI also became a forcing function for standardization: when a workflow was added to the CLI, it became the canonical way to do that task.