zachgoldberg / startup-cto-handbook

The Startup CTO's Handbook, a book covering leadership, management and technical topics for leaders of software engineering teams

NOTE: As of October 2023 I'm still working on porting the book content into markdown. Everything is in there (via a .doc to .md auto-converter) but the formatting is all over the place and needs a lot of cleanup still, apologies for my mess in the interim!

The Book

You can view the latest content of the book in markdown here

You can buy the book on Amazon or Audible

(Coming Soon) Link of the latest version of the markdown rendered to PDF

The original manuscript (now outdated) can be found as a Google doc

Welcome

Hi, thanks for checking out the Startup CTO's Handbook! This repository has the latest version of the content of the book. You're welcome and encouraged to contribute issues or pull requests for additions / changes / suggestions / criticisms to be included in future editions. Please feel free to add your name to ACKNOWLEDGEMENTS if you do so.

The Author

Linkedin / Website / Email

Licensing

See the LICENSE file, but tl;dr - you're welcome to make copies, changes, redistribute etc. so long as you're not reselling, you keep my name/attribution attached, and you keep future versions open under a similar/the same license.

startup-cto-handbook's Issues

typo

Under TWO TYPES OF DECISIONS there is " ey " instead of "It"? not sure. Just search " ey " with trailing spaces and it shows up

typo

Line 1971 in md: and standardizing the document looks like. --> and standardizing what the document looks like.

Help w/markdown formatting

Saw this on Hacker News today. Good stuff! It seems like you’re open to PRs with format and spelling fixes [1][2]. At a scan it looked like a lot of the fixes from the .doc conversion are needed from the section “EASY DEVELOPER EXPERIENCE WINS” through the conclusion. I was starting to volunteer some fixes but it frequently isn’t clear what the desired formatting should be. If you’d be willing to add the .doc to the repo, I’d be happy to use that as the target format and offer fixes through PRs.

[1] https://news.ycombinator.com/item?id=37971795#37973166

[2] “As of October 2023 I'm still working on porting the book content into markdown. Everything is in there (via a .doc to .md auto-converter) but the formatting is all over the place and needs a lot of cleanup still, apologies for my mess in the interrum!”

Topic Idea: Transitioning out

Best practices in how to transition out of a role/company gracefully -- setting the organization up for success.

• Managing commitments responsibly (don't make promises others have to keep without their knowledge)
• Documentation
• ...

Explain necessity of testing

Hi Zach,
Thank you for writing this book. I think it can help increase the pace of innovation.

Section 3.4 "Testing" is written with the implicit assumption that the reader understands why a startup needs to do some testing. Unfortunately, in my experience, some startup CTOs need to learn this. I have seen some make critical errors like un-staffing testing or migrating to a Service-Oriented Architecture without integration tests. How about enhancing "Section 3.4 Testing" with information on why testing is a necessary part of the software engineering process?

I think it would be good to teach the reader:

1. The function of testing in the software development process is to catch problems earlier in the process, when they are cheaper to fix. Compare the costs to fix a problem while coding, in CI, after code review, in production. Use this to introduce the terms that show the point in the development process where the test runs: "release" test, "continuous integration" test, and "manual" test.
2. Signals that the team is underinvesting in testing work
   • production incidents
   • increasing bug count
   • accumulating tech debt
   • reducing engineering velocity
   • worsening engineer morale
3. A prioritized list of what kinds of tests to set up
   • Manual tests when the product has few features.
   • End-to-end happy-path feature tests that gate releases. These prevent production incidents.
   • Integration tests. A team uses integration tests to make sure that other teams don't break their system. Without such tests, every team must spend energy keeping aware of changes all other teams are making, so they can catch breaking changes early. Integration tests become important once the company has engineering teams with separate standup (status) meetings.
   • Unit tests.
     1. Write good unit tests for any code that has ever had bugs, even if those bugs only occurred during initial coding. Assume that code that handles dates and timezones has bugs until it has full coverage.
     2. For code that has a complicated API, write a single test, with literal input and output data. This test teaches future readers about the shape of the data that the code accepts and returns.
4. Tests are excellent documentation. They never get out of date. They teach readers how the system actually works. Engineers spend most of their time just figuring out how the system works. Therefore investing in testing pays dividends in developer velocity.
5. Define the terminology of testing.
   • a "unit test" (already defined in the book)
   • an "integration test" runs code that is normally deployed separately and makes them talk to each other. A test that mocks all of its dependencies is not an integration test.
   • a "feature test" pretends to be a user and actually uses the feature. For a web app, this test runs the app in a browser and clicks buttons and checks for correct changes to the page and correct changes to the data in the backend.
   • a "test" that runs before deployment
   • a "check" or "monitor" runs on production, after deployment
   • ...
6. Monolith testing is cheap and fast. Service-Oriented Architecture uses many deployment units, so unit tests can cover very little code and most tests must be integration tests, which are far more complicated and slow.
7. Flaky tests harm engineer velocity and morale. Therefore, put someone in charge of getting flaky tests fixed.
8. Test Dev UX is important. When tests are easy to run and run fast, people write more of them and will fix flaky ones faster. Invest in making tests easy to run and fast on engineer laptops.
9. Systems with no tests are "legacy" systems. Only the original authors can safely modify them. If the original authors leave, then the new people must add tests before they can safely add features or fix bugs.
10. Some engineers love to clean up tech debt and will do it eagerly when such changes are low-risk. Test coverage reduces the risk of all code changes, especially code cleanups. Therefore, investing in test tooling can allow your startup to benefit from these instinctive code cleaners.
11. If a system is hard to test, it will be hard to deploy and manage in production. Follow KISS and YAGNI in deployments and reap the benefits in devops and testing.

Thanks again for writing this book. I hope these suggestions can help improve the book.

Sincerely,
Michael

Letting somebody go checklist

Consider adding a checklist of things for letting someone go

• Assuming the nature of the underperformance is potentially correctable, give sufficient feedback and opportunity for the employee to improve
• Identify whether the role will be backfilled, and on what timing.
• Identify and plan for what will happen to in-progress work that might be dropped by this person's departure
• Work with HR on determining severance plan, taking into account tenure and other factors your company choses
• Work with HR to coordinate timing
• Have a communications plan for the rest of the team
• Have 1:1s with all of the let-go employee's coworkers / your direct reports to check in with them

and so on

Dead link: https://ctohb.com/samples

Hey,

Thanks for a great book!

I noticed that the link https://ctohb.com/samples in the book leads to a non-existing page.

Topic idea - "product focused" engineers

The idea of the “product focused engineer” I think, as a phrase, assumes that some engineers can think about product and some can’t. My hypothesis is that, for the most part, that’s not actually how the world works. Individuals have different interests and passions, and it's when you align the passion of the individual with the problem when you get the output that we all think of as the “product focused engineer.” Said another way - if the person is passionate about the business problem, and they’re empathetic with the user, they’re far more likely to spend time using the product as a user and find the bugs/opportunities to accelerate product quality.

Audio book version

Hi Zach
I have just read the first quarter yet but I really like it. Since I prefer audio books though to listen while computing, I created one with OpenAI tts-1-hd. I had to split the file in chunks and merge it but the end product sounds quite nice. Just listened to the first few minutes. I could upload it here if you want but wanted to ask first. As you also sell the book on Amazon it would also be understandable if you don't want that. Just let me know.

It's an AAC with 207 MB (64kbit/s mono).

Best
Berny

Topic idea - "Standard" vs. "non-standard" eng roles

Try and define the idea of "standard" -- where many companies use the title in the same way to represent the same sort of work, vs "non-standard" which is more likely to exist at a startup where people where multiple hats. Non-standard roles requiring additional thought/effort into how to write a JD and how to interview/qualify for.

"Standard" roles

• Frontend engineering - primarily building UI flows
• Backend engineering - building APIs and Services
• Devops - building infrastructure, pipelines etc.

"Non Standard" roles

• Devops AND product engineering
• Engineering AND design
• Others..

oughtworks typo a few places

Thoughtworks typo to oughtworks a few places.