Voice of the DBA

Tag: business

  • Seagull Management

    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.

  • Under the Bus

    I’ve had a good career in database work. I’ve had success, and I’ve had some failures, fortunately the former far outpacing the latter. In my career across many companies, the code I’ve written has tended to work well, or at least well enough. I’ve managed systems and ensured a high uptime, and solved issues quickly. I have left quite a few jobs in technology, some because I was unhappy, some for better opportunities.

    I was asked to leave one job. I disagreed with my boss, thought he was a jerk, and our CTO told me this person was more valuable than I was at that time. The CTO suggested I move on, so I did. That day.

    I’ve been a manager of both development and operations groups at different positions. I learned as a manager that I praised my staff publicly and criticized them privately. That included taking blame for issues, but passing our kudos for success. A leader is responsible for the team, and that includes accepting the failures of individuals below them. That’s what I believe.

    In the last few years, there has been a bit of a trend where managers blame individual contributors. The Equifax ex-CEO blamed a single person for not patching their servers prior to the attack. Solarwinds CEO blamed an intern for an issue with posting a password to GitHub. There are other examples, but in many cases, senior management is blaming someone far below them for a mistake.

    I know technical people sometimes make decisions that are poor, they click the wrong thing, adjust the wrong server, or make some other mistake. However, in many cases, managers know about the work their people are doing. If they don’t, then isn’t that a management failure? While a manager might not know about patches, they know patching is important. It’s a manager’s job to place a priority on patching systems if this is important, and then ensuring someone verifies patches.

    I don’t expect managers to check repos for passwords, but certainly there are tools to help detect his. I certainly get alerts about a few passwords in my test scripts posted to some repos. Again, a manager should ask that controls, checks, verifications, etc. are a part of any processes that need security.

    I know that often the paychecks of senior managers are far above those of technical staff. I know it’s easy to blame someone making $60k a year and not accepting blame as a VP being paid $400k a year. I know that manure rolls downhill, but it’s disturbing that these executives aren’t being held accountable for the mistakes of their staff. It’s up to them to ensure that staff prioritizes what’s important, security, maintenance, whatever.

    As an individual contributor, I find this behavior is a symptom of a poor culture. We’re not a team when upper management throws people under the bus. To me, it’s a sign I need to seek new employment.

    Steve Jones

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

  • Advice for Business

    During the last few months, I’ve seen a few different advice posts that caught me eye. One was Kevin Kelley’s blog (and his book) on life advice that I previously wrote about, I look at the book once a week or two, read 1-2 items, and think about them. I think some of them are geared more for younger people growing into life, but quite a few are still things that I appreciate as learnings or reminders.

    Recently I ran across another one, Sam Altman’s post looking back from a business point of view. I’ve worked in business for a long time, used to own one, and I tend to enjoy smaller businesses than larger ones. While I enjoyed my time at JD Edwards, I prefer companies with a few hundred people rather than 10,000 or more.

    This is an interesting list and one that looks at the world more from a startup perspective. Sam Altman was the CEO of OpenAI (maybe still is), and has worked in several small tech companies in his career. Some of these items are things that I’ve seen or used. Maybe one of the more interesting ones from a business perspective is about incentives. These really do drive and change how people work, and often management gets this wrong by incentivizing one thing, but saying or preaching another.

    However, the advice I think resonates more with me, as someone who works inside of an organization and with others, are the items that relate to people. One is about cohesive teams, and how they can get things done with both calmness and urgency. I’ve always wanted to interview with and know who I work with at many companies because having a team I enjoy and work with is powerful. I think Grant and Ryan are amazing, and I wish our jobs were a little more closely aligned. Unfortunately, we all tend to work on slightly different things most of the time, and work more solo, but I do appreciate the projects we tackle together.

    Another is that things that matter are important. You (and I) need a sense of purpose, which is why hard things that matter are easier than easy things that don’t. In life and at work. I also think that recruiting is important. I do look for people who I like, appreciate their views, and can work alongside more than those who know all the skills. We can learn from each other and teach each other when people have that potential (in addition to intelligence and drive). That’s why I think it’s almost always worth hiring good people, even if you don’t have a specific use for them. Too often we hire people for a need, and they’re way less qualified than others.

    Maybe my view is summarized well in the last entry: working with great people is one of the best parts of life. We spend so much time at work, so it better be enjoyable.

    By the way, if you want to find and enjoy great opportunities, learn to be better. Better at your profession, better at learning, better at being part of a team.

    Steve Jones

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

  • A Staffing Disaster

    There was a failure recently at an Azure data center in Australia when a utility power sag caused equipment to trip offline at one of the Azure data centers in Australia. You can read about it here, but essentially the headline is that there were only three people on site when the incident occurred, and that caused them to be unable to restart the equipment in time before an outage occurred.

    In a little more detail, there weren’t enough people to quickly restart the equipment chillers after the incident. The staff had to access the equipment on a roof when 13 of the units didn’t restart. They were able to get to 8, but when they got to the last 5, the temperature of the water had risen to a level that wouldn’t allow a restart. So they had to power down some computer equipment and go through a more lengthy process to get everything running.

    This sounds bad, but in reality, this is exactly the type of thing I’ve seen in private data centers, who almost never have all the staff they need, or the knowledge necessary, to deal with large-scale failures. While I haven’t seen the chillers, I have seen people trip electrical systems and be unable to restart or reset UPS’s or generators for hours until qualified staff could come in. If you read the incident history, there is a good retroactive of what happened, and then some actions taken to try and prevent this in the future. They increased staff levels but also identified some places where the previous staffing level would have been fine with some equipment and protocol updates.

    I wish more organizations would review incidents and examine them with an eye towards not only what happened and where there were failures, but how to prevent issues in the future. Too often I see people going through this exercise in order to blame someone and “prevent this from ever happening again”, which usually means we fire someone and don’t change anything else. We need psychological safety in reviews of actions to get better.

    As we build more complex systems, or even more complex organizations with lots of teams, people, equipment, procedures, etc., it’s easy to build in lots of points of failure without realizing there will be problems in the future. My goal often these days is to assume I’ll have some inexperienced or less capable staff and design processes and systems to survive issues. To keep things simple, and not get too cute with engineering. I like robust, resilient systems that anyone can operate, not those that require me to ensure my senior superstars are always on call.

    Of course, it often takes the senior superstars to design and test these systems and protocols, which is a good use of their time.

    Many businesses struggle with staffing, in many areas. Technology groups are no different, and we have to learn to work smarter, not assume we will just get more staff and solve our problems.

    Steve Jones

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