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:
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.
Today I will do a presentation on how Leaseplan digital was able to introduce Datadog to monitor an application platform based on kubernetes.
This allowed the platform team to configure monitoring in such a way that the users of the platform do not need to do any extra configuration in order to have visibility over the applications that are running.
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!
Everybody installs a Kubernetes cluster on raspberry pi … so why not me … let’s play :)
First of all you’ve to pick your hardware and that’s where you’ve to do some choices. And my choice was to avoid buying a switch because I like it to have less cables and items lying around. Obviously not as reliable but it’s just a game.
Here you can see the difference. This is the only wifi version:
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.