- The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, Jeff Cox
- SQL Performance Explained by Markus Winand
- Staff Engineer by Will Larson
- Crossing the Chasm by Geoffrey A. Moore
- Monetizing Innovation by Madhavan Ramanujam
- Become an Effective Software Engineering Manager by James Stanier
Eliyahu M. Goldratt, Jeff Cox
It's a business fiction that explains the ideas which underline the Theory of Constraints (TOC). In a nutshell, the theory states that in any given system, one component is the constraint/bottleneck for the whole system and it restricts the system output. Any optimization of any part of the system other than the constraint is a waste of time and resources since it will not improve the throughput of the system.
Some of the quotes from the book:
A measurement not clearly defined is worse than useless.
KPIs, KRs, the North Star metrics - all these need to be very precise and well understood by everyone, otherwise they only harm.
The Five Focusing Steps when applying the TOC on your system:
1. Identify the system's constraint(s).
2. Decide how to Exploit the system's constraint(s).
3. Subordinate everything else to the above decision.
4. Elevate the system's constraint(s).
5. If the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint (aka Repeat).
"What are we asking for [in a manager]? For the ability to answer three simple questions: 'what to change?', 'what to change to?', and 'how to cause the change?'. Basically what we are asking for is the most fundamental abilities one would expect from a manager. Think about it. If a manager doesn't know how to answer those three questions, is he or she entitled to be called manager?"
... to construct and check solutions that really solve all negative effects without creating new ones? And above all to cause such a major change smoothly, without creating resistance but the opposite, enthusiasm? Can you imagine having such abilities?
I am very excited about TOC and will continue learning and researching.
Who should read it
Everyone interested in organizational excellence and performance. I believe that the Theory of Constraints can be applied anywhere and I will continue learning it :)
The book gives not only a good overview of what influences the performance of the interactions with the databases (from basic to more advanced) but also the comparison of different database management systems (MySQL, PostgreSQL, Oracle, SQL Server, and even a bit on DB2). So it's mostly about indices, how they work and when they do help and don't.
In general, the author does a great job of putting together the conventional knowledge as well as his own experience. The book balances between fundamentals and deepness very well. This makes it easy to read and also applicable. I read the book, made the notes, however, I am sure that I will grab it again from my bookshelf.
Who should read it
It's a great concise read on SQL for developers, as well as Data Engineers/Analysts. There might be quite many aha-moments and/or "did not know that". Of course one can say that nowadays developers rely on ORMs and with a basic idea about indices is enough to get the average job done + CPU is cheap, "let's grab a larger instance!". And for Analysts, it's even simpler, because the companies are fine to pay a lot for the Data Warehouses SaaS - they are super powerful and everything is indexed there. But... I beg to differ! It's pretty easy to make less waste and save some CPU cycles 🌳
The book is a compilation of the blog articles Will Larson wrote over the years, his mailing list + a set of interviews he did with accomplished engineers from the top startups.
It's very common nowadays even in Germany that companies have a dual engineering career ladder. A senior individual contributor (IC) who is not keen on taking the Engineering Management path, now has an option on developing and growing into Staff-plus roles (Staff, Principal, Distinguished, etc). Even though it is an option, there is still a lot of ambiguity about what does Staff means. Is it just an Architect or a Tech Lead? Yes, no, maybe. So the book does the following well:
- dissolves myths about what the Staff-plus title means and what it doesn't
- describes how to grow into a Staff-plus role and get the title officially (focus areas, "Staff projects", visibility, sponsorship, etc)
- tells inspiring stories of the high-performing engineers (all experiences and paths are unique)
Who should read it
I would recommend it to all engineers that want to be intentional about their careers and potentially make fewer mistakes along the way. Regardless of the level, there is a lot of information in the book on how to be a better engineer. To make a list:
1. Engineers who are not sure on which development path to focus on - IC vs EM.
2. Engineers that feel stuck at the Senior level, cannot break the "glass ceiling" and do not know why.
3. Engineering Managers who what to support the development of their reports.
Ofc reading the book is the best before recommending it :)
Actually, it is available online for free on the author's website. Nevertheless, this is the book with the bunch of notes and highlights that I want to have on my bookshelf 📚
Geoffrey A. Moore, Regis McKenna
The main idea of the book is quite clear from the title and the image on the cover. After you define the market for your innovative product, the authors convincingly say you need to focus on the market segments (potential B2B customers):
- Innovators/enthusiasts appreciate the competitive advantage of a new product and simply like to try everything new first.
- Early adopters/visionaries are not looking for improvement, but for a breakthrough and ready to forgive mistakes and "bugs".
<here is the chasm to cross>
- Early majority/pragmatists do not like risk and want to buy from the market leaders.
- Late majority/conservatives is a large 1/3 part of the whole market and if they buy they like to do it in pre-assembled packages, with discounts and only the whole solution.
- Laggards/skeptics - they not gonna buy :)
The authors talk quite deeply about each of the segments, how to approach them, and how to cross the chasm from early adopters to the early majority. Besides that there are some real-world examples, convincing information about how the positioning is important, and at the end, the framework for digital consumer adoption:
- Acquire traffic.
- Engage users.
- Enlist the faithful.
- Monetize their engagement.
It was a bit unexpected recommendation given to me, however, I am glad that I came across and read it.
Who should read it
If you are working on a product, no matter what is your role. The book will help you to understand what is important at each stage of the product growth and how successful B2B companies making it to the top. I've worked on some unsuccessful products and some successful, with the knowledge from this books I can more clearly see the reasons in both cases. No matter how cool and well-architected the tech is, there will be no product without proper need, marketing, and sales.
The main idea of the book is that companies need to refocus from internal product ideas to external customer needs and from the product costs to buyers' willingness to pay. In other words, the recipe for the successful monetization of the innovation is to:
"...put the customers's willigness to pay for a new product at the very core of the product design."
This statement makes sense even intuitively, however, the author gives a lot of examples when companies fail to leverage this. Pretty classical - a product is expensive because it has lots of useless features, or the product is sold at a price that is much lower than customers would pay for it anyway.
"Market and price, then design, then build. In other words, design the product around the price."
Also the author advocates for a framework or a list of rules for innovation success, in not exact words:
- Have the "willingness to pay" talk with customers early in the product development (or even before any).
- Do not force a one-size-fits-all solution (it's about segmentation).
- Product configuration and bundling is a science, do it right.
- Choose the right pricing and revenue model (how over how much).
- Develop your pricing strategy (max out short and long term).
- Draft your business case using customer willingness-to-pay data (price, value, volume, and cost).
- Communicate the value of your offering clearly and compellingly.
- Understand your customers' irrational sides.
- Maintain your pricing integrity (control discounting).
Who should read it
People who are either involved in product development or thinking about starting a company or new corporate innovation. However, the information in the book is helpful to everyone to understand better the high-performing companies and how they approach new products development.
This is a very very good read for fresh new engineering managers (EMs) or senior engineers who want to develop into one. Why is the a great read:
- it goes fairly deep into the main EM topics (e.g. 1:1s, hiring, performance/development management, strategy, communication, culture, project management, how not to burn out yourself and others, etc.);
- the author’s style is humble and caring, the narrations are not prescriptive nor educative, it's like advice from a thoughtful mentor;
- well structured; the list of content is convenient to navigate and come back to any specific topic.
It was a bit unexpected to see notes on Stoicism, which I am learning and trying to live by, in the book about engineering management, but it fits very well there!
It's been just a couple of weeks since I read the book and I already grabbed it from the bookshelf about 10 times.
Who should read it
As mentioned above, I think it's a must-read for all new EMs or senior engineers who want to develop into one. But even seasoned EMs would find some useful and actionable advice in the book. Even if you are usually reading from a device, I would still recommend getting the hard copy, sticky notes, and a pencil ;)