As the GM of Vitals from 2016-2019, I got re-immersed in the world of search engine optimization: SEO. Engaging an SEO can be a valuable exercise in taking their experience and applying it for what can result in tremendous outcomes. But as a product-leading CTO, I was always uncomfortable with the explanations as to why certain tricks worked. I began to compile a list of why certain SEO tricks work, and developed a general thesis of how Google works.

I have been on both sides of so-called "pilot" projects. Like the pilot episode of a new show, we want to test whether or not something new will work. But what does it mean to have a successful pilot?

There are great projects. You can go to the moon. You can build a house. You can write a novel. Completing a project does not mean that there is a product.

The code review is a long-established "first line of defense" so that engineering teams don't unleash hell upon the world. Years ago, the code review literally was a developer printing out their code, handing it to a senior engineer, and having it marked up with red pen like it was a college essay. The code review has come a long way - it has been established part of development workflows everywhere largely because of the pull request feature at GitHub. Code reviews were part of the job description for senior developers and development managers everywhere - a pedagogical function that promoted stewardship over a code base. But that was then. It's time to pour one out for the code review.

I spent two years between WebMD and Vitals taking on a monster for the business - optimizing for organic traffic. Once I sorted through a lot of the misunderstandings in the organization, the paranoia, and the downright hopelessness - I presented the business with one option to fix their issues with organic acquisition: make Vitals a better experience for users.

The Chief Technology Officer. The maker of things. The knower of stuff. The solver of problems. The guy who probably has to fix their parents computer each Thanksgiving. But how often should they be coding?

My wife and I were loyal, sheepish players of Alexa's Jeopardy game. Every weeknight like the moths to flame that we are, we would flock to our Amazon device (well, an Alexa-enabled Sonos actually) and commanded Alexa "Play Jeopardy!"

The Scrum Master - a mainstay in Agile culture, particularly Scrum. Heralded by consulting firms, conferred certificates by training academies - here's why you don't need a Scrum Master and why if you have one, they are hurting your agile efforts.

Waterfall. Scrum. Spiral. RAD. XP. Software methodologies are plentiful, all in an effort to make it so that timelines and budgets are predictable. They are an attempt to create repetition and commonality within software development. But they are a lie.

In a place far away and long ago, teams used to be asked "when will this be done?" which at some point go confused with "how much time will this take to finish?" Business stakeholders and software engineers - forever separated by semantics and the inability to communicate were united by consultants who came up with an abstraction: story points. Ever since, we have been in hell.