Voice of the DBA

Last year, I read Surrender, a book by U2 lead singer, Bono. Bill Gates listed this as one of the top books to read at one point, so I picked it up and dove in. I have enjoyed U2s music since I was in high school, and was interested to hear what made Bill Gates recommend his book. The book is partially a journey of U2, but mostly a look at how Bono’s view of the world and life has changed over time.

Bono grew beyond music in his life to become an activist and try to shape the world into a better place. Whether you agree with his efforts or focus or not, it’s admirable that he has tried to be more than a rich and famous singer. He’s had to build more skills around how to communicate with others, convince them to take a course of action, and educate himself about the world. In trying to build these skills, he’s founded or worked in organizations around his time with U2.

As a part of that, he had a great quote about leaders who are busy elsewhere but try to be involved in different parts of the business. He called this seagull management, and it was something he tried to avoid doing as he only comes into the office periodically.

Seagull management is where you fly into the office, shit over what everyone is doing, and fly off again. I wonder how many people in management do this but think that they are motivating, helping, or improving their workers’ efforts. Trying to bring their view, experience, knowledge, etc. to others, but invariably doing so in a way that doesn’t resonate with workers. Perhaps it’s not even helpful if management hasn’t taken the time to understand why people are working in a certain way.

I also see this with technical leads or senior engineers who come into a situation, often with strong opinions. They might express how they would have coded or architected something completely differently. Perhaps even informing existing staff that they are doing something wrong. Whether good intentioned or not, seagull management doesn’t help improve any situation.

We make bad decisions, we may build something without considering all the information, or perhaps the situation changes. We all find ourselves in situations where the technology doesn’t seem to be well matched to the environment. We might wish things were different. However, no matter how we arrive at our present situation, we are there. Extracting ourselves from any legacy environment takes time and has to be a journey that is undertaken with support from both technical staff and management.

Most of us want to build great systems that work well for our clients and are admired by others. We rarely find ourselves in a place where we have the time and resources to do that. We can refactor, evolve, and grow our systems to be better, but it does take time. We need a goal, direction, support, and understanding that change is a journey, not something that a manager can fix on their rare visits to our environment.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.