Very honored to be today’s guest blogger at Pinal Dave’s blog Journey to SQL Authority; check out my post here:
MARS
Managing a Technical Team: Act Like a Good Developer
This is one of my favorite pieces of advice from my Managing a Technical Team presentation that I’ve been doing at several SQLSaturdays and other conferences: act like a good developer, with a different focus. Most new managers, especially if they’ve been promoted from within (the Best Operator) model don’t know how to improve their management skills. However, if you were to ask managers what makes a good developer, you’ll probably get a series of answers that are similar to the following broad categories:
Good Developers have:
- a desire to learn,
- a desire to collaborate, and
- a desire for efficiency.
I could probably say that this is true for all good employees, but as a former developer, I know that the culture in software development places a lot of focus on these traits; system administrators usually have different focus points. However, all technical managers SHOULD emulate these three traits in order to be effective. Let me explain.
Desire to Learn
Let’s imagine Stacy, a C# developer in your company; by most accounts, she’s successful at her job. She always seems to be up on the latest technology, has great ideas, and always seems to have a new tool in her toolkit. If you ask her how she got started programming, she’d tell you that she picked it up as hobby while in college, and then figured out how to make a career out of it. She’s an active member of her user group, and frequently spends her weekends reading and polishing her craft; while not a workaholic, she does spend a great deal of her personal time improving her skills. She’s on a fast track to managing a team, in part because of her desire to learn.
One day, she gets promoted, and is now managing the development team; she struggles with the corporate culture, the paperwork, laying out a vision, and can’t seem to figure out how to motivate her team to the same level of success that she was achieving as a developer. The problem is that her desire to learn no longer syncs up with her career objectives; Stacy needs to invest her educational energies into learning about management.
Ask a new IT manager what books they’re reading, and typically the response will be either none at all, or a book on the latest technology. We tend to cling to that which is familiar, and if you’ve got a technical background, it’s easy and interesting to try and keep focusing on that background. However, if you’re serious about being a manager, you need to commit to applying the same desire to learn that you had as an employee to learning more about management. Sure, pick up a book on Big Data, but balance it out with a book on Relationship Development. Podcasts? There’s management ones out there that are just as fun as the development ones. Webinars? Boom.
Desire to Collaborate
Bob’s a data architect. Everybody loves Bob, because he really listens to your concerns, and tries to design solutions that meet those concerns; if he’s wrong about something, he’s quick to own up to the mistake, and moves on. He works well with others, acknowledging their contributions and adapting to them. In short, Bob is NOT a jerk; nobody wants to work with a jerk.
Bob gets promoted to a management position, and he too struggles; he’s still hanging out with his former teammates, and is still going to the same conferences. Everybody still likes Bob, but he’s having trouble guiding his team in an effective manner. He hasn’t really built relationships with his new peers (other managers that report to his director), and hasn’t found ways to manage more effectively. He’s collaborating, but with the wrong people.
As a new manager, you should continue to maintain relationships with your directs, but you need to build a relationship with your new team of peers. Understand their visions, and find ways to make your team valuable resources to them. Reach out to other managers at user groups and conferences; build a buddy system of people based on your management path, not just your technical one.
Desire for Efficiency
If you sat down and had a conversation with any development team that was effective and producing results and asked them about their methodology, it wouldn’t be long before they started talking about frameworks. Efficiency in development is derived from reusable patterns and approaches to problems; they’re tough to implement at first, but the long term gain is enormous.
As you’ve probably guessed, there’s management frameworks that can be very effective in a technical environment; investing time in implementing them can yield great efficiencies when faced with making decisions. In my current environment, I use three:
- MARS – my own self-rolled approach to system operations; it’s not perfect, but it helps focus efforts.
- Kanban – allows me to see what our WIP (Work In Progress) is, and helps queue up items for work
- ITIL – we’re just starting to adopt this, but we’re working on isolating Incident Management from root cause analysis, as well as implementing robust change control processes.
The challenge with management frameworks is similar to that of development frameworks: bloat. It’s too easy to get bound up in process and procedures when lighter touches can be used, but in most cases, the efficiency gained by having a repeatable approach to decisions allows you to respond quickly to a changing environment.
Summary
Management is tough, but it’s especially tough if you continue to focus on your technical chops as opposed to your leadership abilities. Act like a good developer, and apply those same basic principles to your team.
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:
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.