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:
- 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.