managing

Where’s your slack?

I’ve been rereading the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency recently.  As I alluded to in my last post, my life has been rough for the last few months.  My nephew’s passing took the wind out of an already saggy sail; I’ve spent a great deal of time just trying to balance work, family, and life in general.  Some people turn to counselors; I turn to project management books.

The premise of the book is that change requires free time, and that free time (slack) is the natural enemy of efficiency.  This is a good thing; if you are 100% efficient, you have no room to affect change.  Zero change means zero growth.  I’ve been a proponent of slack for a while (less successfully than I’d like); it makes sense to allow people some down time to grow.  Just to be clear, slack isn’t wasted time; it’s an investment in growth.  Slack tasks include:

  • Research into interesting projects.  Lab work allows you to experience the unexpected, which gives you time to prepare for the unexpected in production
  • Building relationships. Teams are built on trust, and trust is earned through building relationships.  Teams that like each other are more likely to be successful when it comes to problem solving.
  • Shadow training.  Allow team members to work in other teams for a while; learn how the rest of the company operates.

In short, slack is necessary in order to promote growth; if you want your organization to stay ahead of it’s competition, cutting resources in the name of efficiency is sure-fire plan for losing.  The best advice for slack time is the 80/20 rule; run your team at 80% capacity, and leave 20% for slack.  In the case of emergency, slack time can be temporarily alleviated, but it’s the responsibility of management to return to normal work levels as soon as possible.

So what does this mean for me personally?  In the name of efficiency, I let slack time go.  I work a full time job, a couple of different consulting gigs, act as a chapter leader for AtlantaMDF, and am an active father.  I have no hobbies, and suck at exercise.  I love to travel, but trips are planning exercises in and of themselves.  In short, I have zero slack to deal with emergencies.  When something goes wrong and time gets compromised, I immediately feel guilty because I’ve robbed Peter to pay Paul in terms of time.  That’s not living,

I’m done with that.

Change is incremental, so I’m not planning on upsetting the apple cart just yet, but I am trying to figure out ways to make my slack time more of a recharge time.  Don’t get me wrong; I waste time.  I sit and stare at Facebook like the rest of the modern world; I binge on Netflix when new series drop.  That’s not slack, and it doesn’t recharge me. Slack is using free time to grow, to change.  My goal is to find an hour a week for growth-promoting free time.  I’ll let you know how I’m doing.

 

2016-04-11 by Blogging is FUN! Professional Development 0

MaTT: The MARS framework for DBA’s

So, as usual, I’m struggling to sit down and write; I know I should (it’s good for the soul), but frankly, I’m struggling to put words to web page.  As a method of jumpstarting my brain, I thought I would write about something simple and relevant to what I’m doing these days in my primary capacity: management.

When I took over the reins of a newly formed department of DBA’s, I knew that I needed to do something quick to demonstrate the value of our department to our recently re-organized company.  We’re a small division in our company, but we manage some relatively large databases (17 TB of data, with a relatively high daily change rate; approximately 10 TB of data change daily).  My team was comprised of senior DBA’s who were inundated with support requests (from “I need to know this information” to “I need help cleaning up this client’s data”); while they had monitoring structures in place, it wasn’t uncommon for things to go unnoticed (unplanned database growth, poor performing queries, etc.).   One of my first acts as a manager was to put in a system of classification I called MARS; all of our work as DBA’s needed to be categorized into one of four broad groups.

Maintenance, Architecture, Research, and Support

The premise is simple; by categorizing efforts, we could measure where the focus of our department was, and begin to allocate resources into the proper arenas.  I defined each of the four areas of work as such:

  • Maintenance – the efforts needed to keep the system performing well; backups, security, pro-active query tuning, and general monitoring are examples.
  • Architecture – work associated with the deployment of new features, functionality, or hardware; data sizing estimates, upgrades to SQL 2012, installation of Analysis services are examples.  To be honest, Infrastructure may have been a better term, but MIRS sounded stupid.
  • Research – the efforts to understand and improve employee skills; I’m a former teacher, and I put a pretty high value on lifelong learning.  I want my team to be recognized as experts, and the only way that can happen is if the expectation is there for them to learn.  
  • Support – the 800 lb gorilla in our shop; support efforts focus on incident management (to use ITIL terms) and problem resolution.  Support is usually instigated by some other group; for example, sales may request a contact list from our CRM that they can’t get through the interface, or we may get asked to explain why a ticket didn’t get generated for a customer.

After about a year of data gathering, I went back and thought about the categories a bit more, and realized that I could associate some descriptive adjectives with the workload to demonstrate where the heart of our efforts lies.  I took my cues from the JoHari window, and came up with the two axes: Actions: Proactive – Reactive, and Results: Delayed-Immediate.   I then arranged my four categories along those lines, like so:

 image

In other words, Maintenance was Proactive, but had Delayed results (you need to monitor your system for a while before you grasp the full impact of changes).  Research was more Reactive, because we tend to research issues that are spawned by some stimulus (“what’s the best way to implement Analysis Services in a clustered environment?” came up as a Research topic because we have a pending BI project). 

Immediate results came from Architectural changes; adding more spindles to our SAN changed our performance quickly, but there was Proactive planning involved before we made the change.  Support is Reactive, but has Immediate results; the expectation is that support issues get prioritized, so we try to resolve those quickly as part of our Operational Level Agreements with other departments. 

After a couple of months looking at our work load (using Kanban), I see that we still spend a lot of time in Support, but that effort is trending downward;  I continue to push Maintenance, Architecture, and Research over Support, and we’re becoming much more proactive in our approaches.  I’m not sure if this quadrant approach is the best way to represent workload, but it does give me a general rule-of thumb in helping guide our efforts.

2014-01-28 by SQLServerPedia Syndication 4

MaTT: You have to start somewhere

So, January came and went, and no post from me.  I continue to suffer from writer’s block, but I’ve finally cobbled together enough ideas that I feel like I can put a couple of quick posts out there.  I’m still struggling with learning how to manage a technical team (MaTT) as opposed to being a technical person, but here’s another concept I’m beginning to grasp.

You have to start somewhere.

When I began managing my team, I was tempted to rush in and save the day.  I know where a lot of the problems are, and I know which ones are big, and which ones are not.  I kept thinking that if I could just motivate the team to start attacking the problem, then we’d be sitting pretty in a year.

I was wrong.

Most people are already motivated to do their jobs; if they’re not, then they’re in the wrong position, and it’s hurting them as well as hurting the company.  What a team is usually looking for in a manager is to help them make priority decisions, and to back them up when they need things to change.   Here’s the conundrum: Technical people often (logically) focus on changing the things that hurt them the most.  Your DBA may say “I keep having to babysit this query for the boss because it’s slow, and it’s slow because the developers don’t know how to normalize a database; can we refactor everything?”.  Your developers may say “If we had more time to rebuild everything, we could fix that query; can we hire another person or put these features on hold so we could tune everything?”.  Your boss may say “We need to make a profit; what’s the most cost-effective way to manage our database architecture moving forward?”

If you focus your energy on addressing the technical issues without giving consideration to the profitability of your company, you’re spinning your wheels.  However, you MUST figure out a way to ease the pain of your technical team by addressing their concerns.  It’s no secret that I’m a Lean/Agile kind of guy; I truly believe that these philosophies can help balance the scales between support/development/operations, but you have to start somewhere.

“Somewhere” for me is the small fixes; don’t tackle the big projects head-on.  Focus on being successful at a couple of small things (e.g., reduce the number of support calls in a measurable fashion, or refactor some small but essential bit of code).  Make sure that these changes are measureable, and make sure that you report the changes to your boss AND to your team.  This accomplishes two things:

  1. It shows measurable progress (in my experience, bosses love metrics), and
  2. It encourages your team by giving them a couple of quick successes.

If your team doesn’t see progress, then in their mind, “nothing is being done”.  Your boss wants to know how you’re improving efficiency and effectiveness in terms of dollar signs; your team wants to know that they’re solving a technical problem.  Make sure you can address both of those needs.

More to come.

2013-02-06 by Professional Development SQLServerPedia Syndication 0