If you can't go through your own documentation and produce the exact result you want other readers to, you haven't read your documentation.


COVID-19 is going to be the last straw for inefficient organizations that relied on proximity and the status quo to protect their sacred cows. The emperor wears no clothes in a world that is socially distant yet still continues to move forward.


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.


Technical debt is the work we don't do when we build and maintain software. In a world filled with tradeoffs, technical debt is a tool to descope projects to stay on budget and schedule. Technical debt can get projects to the finish line but like any other form of debt - can be crippling in the long term. How do you recognize technical debt? How can you ensure that it doesn't ultimately undermine its intent?

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.

For technology companies, the Chief Technology Officer is second to the CEO - often the visionary behind the product, the person who has created the asset that the organization will commercialize. But for most companies - technology is there to build an efficiency. The CTO serves a wholly different purpose from building technology and instead helps companies strategize for how technology can help the company and product scale. This is when a Fractional CTO can be an attractive option. What is a Fractional CTO?

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?


Software project estimation may be an exercise in guesswork, but it is imperative for almost any company in the business of developing software on a fee for hire basis or teams looking to plan budgets to develop a software project estimate that from the ground up has reasonable assumptions, scientific wild-ass guesses, and an accounting for things that could go wrong. Let me save you some time and share with you how I've estimated for projects in the past.

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.