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.
