Voice of the DBA

Tag: syndicated

  • Book Review: A Radical Enterprise

    I grabbed this book over the 2024 holiday season as it was on sale and recommended by the DevOps practitioners over at ITRevolution.

    A Radical Enterprise looks at a new way of building organizations, actually a few way, where the power and decisions are decentralized.

    I am pretty open to trying new things and experimenting, but I was very skeptical this would work in many places as I started this book and remain so after finishing it. I kept thinking this felt like a feel-good, kumbaya approach to running an organization. Giving responsibility, devolving it from management to individual teams and having them collaborate together and with other teams.

    While I am skeptical, there are some large organizations doing this, and the description says 8% of corporations do this, which I find hard to believe. In any case, a few of them are:

    • Haier – USD$38b in revenue
    • Morning Star – processing about 40% of the world’s tomato products
    • Buurtzorg: – over €427 million revenue
    • Nearsoft – $80mm consultancy
    • W. L. Gore & Associates – makers of Gore-Tex products, over US$3b in revenue

    Those are some impressive organizations. Maybe 8% isn’t wrong, but it feels high. I’ve worked in a few organizations, and all of them have a more central control organization. Even at Redgate, where I think we give a lot of autonomy to teams, I wouldn’t think we’re in the category of a radical organization.

    There are some principles to this idea, and some imperatives. The imperatives are:

    • Team autonomy – giving control to small groups in terms of how they practice and schedule work as well as allocate themselves.
    • Managerial devolution – trying to allow individuals or teams to manage themselves
    • Deficiency Gratification – gratifying our higher level needs. Not things we need, but we want and desire. I’m not sure I completely understand this.
    • Candid vulnerability – being open and transparent. Even for someone like me that is fairly open, this is asking a lot.

    Ultimately, I’ve worked with too many people who aren’t motivated, who don’t try and drive forward, who don’t want to make decisions, or who don’t want accountability. I think many of the people I’ve worked with wouldn’t thrive in this type of org and would get booted. Maybe that’s OK, and maybe this is only suited to some types of people.

    It’s an interesting idea, and I found myself fascinated and rooting for success, but always thinking this wouldn’t work in most places I’ve worked. Maybe all the places I’ve worked.

    Give it a try if you want a different way of thinking about work, and if it’s for you, maybe look for a job at one of these organizations.

  • Advice I Like: Investing and Growing Rich

    Investing small amounts of money over a long time works miracles, but no one wants to get rich slow.  – from Excellent Advice for Living

    This is incredible advice, and something my parents instilled in me at a young age. I’ve had mixed financial success here, but I do think about this in a different way.

    Learning new things and growing your career are things that happen slowly as well, but so many people don’t see the value of small things learned every day. Or managers don’t see the value of having employees learn constantly vs taking a week for a class.

    Note, they sometimes don’t even want to give you a week to learn.

    Whether you want to grow your finances or your career, regular investment is slow, but it pays incredible dividend over time. Learn, experiment, and practice your skills regularly. It works in music, in sports, and it also helps your career.

    I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

    To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

  • The London Redgate Summit

    In a week I’m heading to London for the Redgate Summit. I enjoyed these last year and had some very interesting conversations with customers, prospects, and a few Redgate fans.

    This year the event is on Mar 11 at the Tottenham Hotspur Stadium, which should be fun given that I’ve been re-watching Ted Lasso (I still need to make a pilgrimage to Richmond…).

    The schedule has a variety of tracks for leadership and tech people. There are even some breakfast sessions if you want to learn more about Oracle or PostgreSQL. I’ve got the keynote session and a panel for leadership on my agenda.

    Check out the video from last year, and register to come this year. I’ll see you in London next week.

  • T-SQL Tuesday #183: Improving Permission Management

    This is my (late) answer to my own invitation for T-SQL Tuesday #183. I was very busy a few weeks ago when the invite when out (glad it was scheduled) and I never got this done. This post looks at how I managed permissions in the past.

    Large Enterprises

    Many of us would like to think that large enterprises have standards and they’ve learned about best practices. My experiences in 3 of them were that so often large enterprises were small ones that grew, often with lots of tech debt and busy staff. Even when there are limitations to ensuring good security, often we can’t just fix things because we might break something.

    In one large company (5000+ employees) I found that many of the database servers I managed had permissions set in a variety of manners. Often this included lots of individual permissions granted to logins and users, which was a mess.

    Even when AD groups were in place for departments, they weren’t used as logins in SQL Server since not everyone in a department needed to access the database.

    Cleaning Up

    I hated managing permissions by user. When I started and got a ticket to add a new person to a database for access, I watched someone train me by looking up another similar user in the database, scripting out their permissions, and then search/replace to change the user or login name.

    Not a bad solution, but one that doesn’t scale well over time. What I started to implement was to create an AD group (for Windows users) or a database role (for SQL Users) and then add the login/user to this group or role and assign the permissions from my “other” user to the role. I’d also often move the user to the new role and revoke their specific permissions.

    While this seemed like more work at first, this quickly started to scale well as we had a way to add new users to roles that matched the access they needed.

    Slowly over time we moved a lot of access to AD, which allowed us to remove the burden of disabling users in SQL Server. Plus, we could easily see which access a variety of users had by looking at a role rather than checking multiple accounts. Auditors liked that and it helped us pass various audit checks over time.

    Use roles and groups. They’re not hard and they make things cleaner and easier over time.