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:
- It shows measurable progress (in my experience, bosses love metrics), and
- 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.
