It is a series of small chapters / stories of an experienced manager and has made a nice collection of personal learnings and battles and summed them up for our pleasure. Some chapters are hilarious so there will be some fun time involved.
You can expect a wide range of topics which will be about
how to manage and live meetings
how to interact with people, what are the agendas of people
how to see and tackle corporate dramas
and so much more
If you’re into management books take a peek. It’s definitely a good read.
Many times I find myself in a meeting where attention of all the attendees is drifting and they are discussing all kind of matters, not always related to the meeting. This can have many causes like:
the stage was never set for the meeting. Attendees are not aware what the scope of the meeting is. If You Fail to Plan, You Are Planning to Fail by Benjamin Franklin
attendees were never trained to use focus, sometimes they are not aware this is one tool they can have in their tool belt (consciousness)
there is little awareness of people on what a meeting actually is. Who are the actors in the room? What do they want? What is expected from the meeting. Who should be invited? And the list of questions goes on. (awareness)
With this article I wanted to share a learning I got from a former mentor of mine. He called this technique the fish model. Fancy naming .. very catchy :)
I will refer to a meeting now that is meant to take technical decisions. This meeting very probably will start with some problem to solve like: how the heck are we going to implement this feature?
So people will start discussing context on the feature, there will be questions of the attendees. This is the phase where attendees will gather information. So we will be a state of diverging. We are literally expanding our knowledge on the matter. It is clear at this point that the information grows and grows and that at some point this needs to stop. This is when a next phase will need to be explored the converge phase. See the picture to have a visual effect on this:
As you can see by gathering information you make room to have more choices available for your decision process. After that you will narrow down your choices that will translate into actions. Being conscious about this dynamic will help the attendees, because they know exactly when and what they should raise at any moment and help a natural and efficient flow of the meeting.
What the heck was the fish thingy about then? Well let me show it you with a different perspective:
The famous fish
At the beginning of meeting is the head of the fish. Information is low and alignment and information gathering is needed. The more into the meeting you move to the body of the fish. That is when we’ve a lot of information and choices on the table. Finally we arrive at just before the tail of the fish where we’ll decide and narrow down the choices. This is where you’ll have your action items to translate into concrete tasks. At this stage the meeting is over.
The tail is already the implementation phase, engineers will dig into deep technical knowledge for the implementation but at this phase the choice was already made and the engineer continues to implement and document the feature.
Take it with a grain of salt (fish tastes better with salt), it’s not a perfect technique but it surely helps meetings to go smoother if everybody is aware of the game.
This book talks about how to design teams inside an organisation. This is a very important topic because of Conways law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
This means that when you design an architecture of a system or when you design a platform you better take into account the communication flows of the company and people involved. The team structure will be an imprint for your product architecture.
This book will give you options on how to structure teams. There are several ways defined in the book, ranging from a collaborative team to platform teams serving self service products. A must read before attempting to scale any teams or organisation!
If you are on a DevOps transformation journey this is not doubt a good a read. It will give you the strength and some material to share with your coworkers.
The book remains quite high level (not too deep in the technologies) so it will give you an overview of DevOps practices and why they’re so powerful.
I would recommend the read to engineers but also to managers that want to understand or rollout DevOps practices to improve organisations.
This is also about creating a better workplace for you and your coworkers.
This book is really nice. It describes how many people do work that is not actually useful to anyone. People are actually quite smart, even if they are not 100% aware that they are doing fake work they somehow feel it.
Almost nobody wants to do fake work, it is not gratifying that’s why many companies have big turnovers in job positions. The book gives insight and helps defining a strategy to get rid of the wasted time that we spend every day on fake work.
I advise it to anyone, it’s a good read for leaders that want to shape the environments and the culture they live in, and workers that have their part of responsibility in creating the same environment.
My Aikido master told me once: I’ve not created the dojo, everyone each of you has.
Just finished reading “The phoenix project“. It’s a quite nice book, that talks about how good practices can make a huge difference in a working place. I would recommend it to anyone who works in IT, Dev or business departments.
