Meet Ashwin

Helping Engineers To Become Tech Leaders

Blog

Book review : The Almanack of Naval Ravikant

by Leave a Comment

Despite my lack of expertise in writing book reviews, I felt compelled to share my thoughts after finishing ‘The Almanack of Naval Ravikant‘ by Eric Jorgenson this weekend.

It is one of those books sprinkled with words of wisdom, without preachiness.

This book reminds me of other wisdom-filled works like Charlie Munger’s ‘Poor Charlie’s Almanack‘ and Clayton Christensen’s ‘How Will You Measure Your Life‘.

Let me be clear – this book is a collection of tweets and other thought nibbles, neatly organized by topics.

But it brings out Ravikant’s wisdom and experience shine through, offering us a fresh perspective on life.

The book is divided into 2 broad categories:

  • Wealth
  • Happiness

In the section on wealth, Naval delves into various aspects of financial success, including wealth creation strategies, leveraging resources effectively, choosing the right career path, developing crucial mental models, and honing decision-making skills.

He posits that happiness is a choice available to everyone, and he explores habits that foster joy, as well as methods for personal growth, self-care, and achieving inner freedom.

The book concludes with a philosophical exploration of life’s meaning and the importance of aligning one’s actions with personal values

Allow me to share some of my key takeaways from the book. These highlights only scratch the surface of the wisdom within these pages – I highly recommend grabbing a copy for yourself to fully appreciate its depth and insights!

  • Learn to sell. Learn to build. If you can do both, you will be unstoppable.
  • Specific knowledge cannot be taught, but it can be learned.
  • Intentions don’t matter. Actions do. That’s why being ethical is hard.
  • If you don’t own a piece of a business, you don’t have a path towards financial freedom.
  • Earn with your mind, not your time.
  • Retirement is when you stop sacrificing today for an imaginary tomorrow.
  • Hard work is really overrated. How hard you work matters a lot less in the modern economy.
  • You don’t get rich by spending your time to save money. You get rich by saving your time to make money.
  • “Clear thinker” is a better compliment than “smart.”
  • What you want is principles. You want mental models.
  • Read what you love until you love to read.
  • Happiness is the state when nothing is missing.
  • First, you know it. Then, you understand it. Then, you can explain it. Then, you can feel it. Finally, you are it.
  • The greatest superpower is the ability to change yourself.

I dabble around with a lot of books and there are many unfinished ones in my reading list. This book is one of very few I managed to finish in recent times!

Thanks, Naval for sharing your wisdom with all of us! Please keep writing…

Communicate your Software Design better with C4 Model

by Leave a Comment

As engineers and tech leads, we often underestimate the need for our software design to be understandable.

The simpler the design, the higher its utility and purpose.

The C4 model is one of the popular and proven ways to visually communicate your design to a wide range of audiences. Its beauty is the “drill down” method, making it usable by technical and non-technical audiences.

What is a C4 Model in Software Design?

C4 models are a hierarchical abstraction of software systems, achieved through a set of diagrams. They are designed to be notation and tool-independent, which can be applied to almost all type of systems.

It is an “abstraction-first” model, that reflect how software architects and developers think about building software.

C4 stands for:

  • System Context
  • Container
  • Component
  • Code

In ascending order of granularity, each of these diagrams gives a more detailed view of the software system that’s being built.

What are the C4 Model Abstractions?

4 levels of abstraction are at the core of a C4 Model.

  1. Software system – the highest level of abstraction of any system that has some utility (e.g., a maps application)
  2. Containers – a software system is made up of one or more containers (e.g., applications, data stores, etc.)
  3. Component – each container is made up of several components (e.g., relational data store, NoSQL data store, etc.)
  4. Code – finally, each component is implemented by software code using a tech stack (e.g., MySQL, DynamoDB, etc.)

Each of these abstractions is represented as C4 diagrams.

C4 Model Diagrams

System Context Diagram

  • The system is visualized as a single box which is at the center
  • This diagram shows how the system interacts with its environment and users
  • Focus is on the people and interacting systems, not on technology or tools
  • Everyone, irrespective of their technical acumen, must be able to understand this diagram
System Context Diagram (https://c4model.com) for Software Design
System Context Diagram (https://c4model.com)

Container Diagram

  • A container view represents various applications that constitute the system
  • This diagram can show the major technology choices and how the containers interact with each other
  • It is intended for a technical audience, but anyone with a need to know how the system works can use this diagram
Container diagram (https://c4model.com) for Software Design
Container diagram (https://c4model.com)

Component diagram

  • In this diagram, the container is decomposed into structural building blocks and their interactions
  • Each component’s responsibilities, interaction with other components, and technical details are called out here
  • Software architects and developers are the primary intended audiences
  • It is not recommended for all teams, so use it only if you think it adds value
Component diagram (https://c4model.com) for Software Design
Component diagram (https://c4model.com)

Code diagram

  • Represents how each component is implemented as code – using UML diagrams, ER diagrams, etc.
  • Usually generated using IDE or UML modeling tools
  • This level of detail is normally required only for complex components
Code diagram (https://c4model.com) for Software Design
Code diagram (https://c4model.com)

In summary, C4 diagrams improve the communication efficiency of your software design. The level of detail and type of diagrams is contextual to the system under design.

Understand your Stakeholders with a Stakeholder Map

by Leave a Comment

Understanding your stakeholders is essential for any project’s success. Stakeholder maps offer a visual way to make it happen.

Who is a Stakeholder?

A stakeholder is someone who has a vested interest in the outcome of a project or a program.

Not all stakeholders are the same.

They come with a variety of needs and expectations.

As a tech leader, you must:

  1. Identify them
  2. Analyze and learn about them
  3. Map them based on their interests
  4. Prioritize and manage

One useful tool to do this is a stakeholder map.

What is a Stakeholder Map?

A stakeholder map is a visual matrix that identifies and categorizes stakeholders based on 2 dimensions – influence and interest.

Influence is the degree to which a particular stakeholder can impact the execution and outcome of a project. For example, a project sponsor is someone with a high influence, who can drive key decisions.

Interest, on the other hand, is about how much a stakeholder is impacted by the project outcome. For example, if you are building an HR application, the end-users in the HR team have high levels of interest.

Once you have established this, the stakeholders can be mapped on a matrix.

  1. High influence, High interest – stakeholders that must be managed closely, as they can steer the direction and outcome of the project
  2. High influence, Low interest – these are key leaders in the organization who may not be directly interested in the outcome of the project, but must be kept happy (no escalations, firefighting, etc.)
  3. Low influence, High interest – these are folks usually part of the project team or the intended end-users. They have a high interest as the outcome with have a direct impact on them but often their influence is limited
  4. Low influence, Low interest – these are enablers or other enterprise bodies, who are not directly involved in the execution or outcome. But they may expect to be “kept in the loop”

Here’s a sample stakeholder map for a project. Do note the categorization is highly opinionated, it can vary for every project or initiative.

A sample stakeholder map
A sample stakeholder map

How do you create a Stakeholder map?

There is no single way to create a stakeholder map and it highly depends on your organization’s culture and operations.

However, here is a 5-step blueprint that works in most cases.

  1. Start with the purpose of your map
  2. Brainstorm and build the stakeholder list
  3. Determine each stakeholder’s level of involvement
  4. Determine their interest and goals in the project
  5. Create a stakeholder map and establish an engagement plan

In summary, a stakeholder map helps you understand the landscape, know the stakeholder interests, and create an engagement plan that works.