New book release: Go for Gophers
Why don't we discuss if an engineering manager should be technichZzzZz
Hello 2025, between discussions about AI productivity gains and product management impact on tech companies, I still talk to people in my mentoring practice that ask the same question “Should an engineering manager be `technical`?”
Whatever technical means - hands on, proactive, empathetic with the team, the face of engineering for the company - it is a thing strongly linked with perception of productivity, quality, gains vs payroll spend, politics even. I wrote about that before both in this post and this other post.
But this time I want to talk about my new book, Go for Gophers, the motivation behind it and how it is connected with the discussion of these posts.
Besides the management duties that engineering leaders perform, there this hands-on, frontline work of training the team. Living what the team lives, incidents, building software, tools. One of the aspects connected to engineering managers expectations we read as to be “technical” is directly linked to this basic work: setting the team up for success, owning it.
Teams that are still learning to work together, companies with complex systems in a hard-to-hire scenario and tech startups got me in the same situation over and over: I had to train the team, define engineering guidelines, pick a simple and boring stack, get productive. Knowing enough of tools that could help individuals to get productive is part of the definition of successful leaders. Not being the best programmer or architect, but be able to support the team in practical ways.
This is why I wrote this book. Since 2013 I've been using Go for my projects and progressively in the companies I've worked. In the last 9 years I got involved with startups with smaller teams that needed a quick path to get productive, not vendors or frameworks but simple ways to build their software.
I've adopted Go to do that as it is simple enough that I could create a playbook, help them get started and get out of the way but not too complex that would tie them to a single stack. I think the same of typescript and NextJS for frontend, flutter or react native for mobile. Their advantage is that they were tailored to bootstrap a developer or a team.
The book progress quickly from the basics to real examples and a guided project, with plenty of code examples and a non-traditional flow. This is not a traditional programming book, in the sense of exploring syntax, commands and the standard library. It is an applied playbook to help your team get up and running.
I also wanted to write this book after The CTO Field Guide to complement the journey of engineering leadership. We discussed a lot of external connectors as teams, metrics, budget, data, infosec and so on. We discussed internal connectors as careers, ladders, productivity metrics. But after all that, in the days between these deep discussions, your team has to be productive so I felt that there were still missing parts into the CTO toolkit.
If you are interested in the book and for any reason can't buy it, drop me a line to get you fixed. I invite you to check its website at https://goforgophers.com, see the sample chapter, the code at github and the final project at https://github.com/gleicon/go-tinycache.
Thanks !
I have released a new book: “Go for Gophers”. It is a progressive, hands on book for teams and engineers that are adopting Go and look for an idiomatic path forward. Quick, practical and loaded with useful examples. Check it out.
For CTOs, Tech Leads or Product Leaders check The CTO Field Guide. It is a book to help product engineering leaders of all levels. If you seek personalized help, check the mentoring program based on the book at https://ctofieldguide.com/mentoring.html.