Tech Manager—A Recap: Advice I Give Myself, Part 2
It is always good to review. So let’s review last month’s article (Tech Manager—A Recap: Advice I Give Myself, Part 1). We covered seven traits that I keep reminding myself need attention. I suggested that you think of these as approaches, habits, mindsets, ways of thinking, modes of practice, leanings, frames of mind, perspectives, and so on.
Last month I reminded myself of some items such as providing great customer service, the value of communication, sharing knowledge, taking initiative, being proactive and organized, and, finally, planning as a way of life.
Here is the next batch. These are the things that I keep telling myself. They are posted on my bulletin board. They are reviewed from time to time when I need some refreshing of my focus.
Be Quality Driven
Take pride in the work you produce. Work to a level that is beyond “good enough.” You should not think you have done a great job just because no one complains. You may have done a lousy job and they may be complaining to others. Test and verify solutions. Strive for best outcome. Stay with a task or problem until the end user is satisfied. Avoid “do overs.” Do not have an attitude of “I can just fix it/finish it later.” Act as if your name is stamped all over the work you are doing (it actually is—make it a good thing).
Documentation
Document and share processes, procedures, access, and controls. This is so hard to do—going back at the end of a job and writing down what you did or what you set up takes time. Yes, this is time that could be spent elsewhere, but not time that could be spent better. Understand that everything that is done in a shared environment of support needs to be documented and stored in a shared location, secured as needed. Create documentation that non-support staff can also use as applicable. Develop “cheat sheets” to help end users. Go on a deep dive for the tech heads out there that might come after you. Get it out of your head and on (digital) paper.
Reporting
Notify stakeholders of progress, problems, and completion. Keep stakeholders informed as the project progresses. Notify everyone about delays and roadblocks. Understand that a job is not done until all stakeholders know that it is completed. If you finish something and do not tell others, then they are delayed in taking the next steps, so they need to know about completions. Fixes must be reported so others can then move forward on cascading efforts that were held up. Producing progress reports in a timely manner helps others know that you are still focused on their issues. Quick reports can help others focus on other things and not worry about what you are doing.
Have a Plan B
Yes, a Plan B, and C, and maybe D. Defining back-out strategies as part of planning is wise. We talked about planning in the March 2018 article. Planning contingencies in case of failures is a good idea. Plan B might come into play at any time. Quickly developing options if things derail comes from good prep and working contingencies into your planning. Don’t be overly optimistic to the point of not thinking about things going wrong. Something always goes wrong, takes too long, does not work, or breaks. You need to have a Plan B and know when to put it into action.
Be a Team Player
Working well with others is part of everyday work processes. You have to know when and how to hand off work and delegate to others. Teamwork can be defined in many ways. Here is a synopsis of what I once wrote on my blog.
- Good team players work toward a common goal. This may seem like a commonly understood perspective, but I have seen teams drift off track and lose sight of the goal. I have seen teams that do not agree on the goal at all. These should be the first questions asked and the ones that are reviewed from time to time to see if you are still heading in the right direction. What defines success?
- Good team players share common methods. They are not little robots, programmed to do just one thing, but they do share a common approach to getting things done. Teams may not start this way, but they need to agree on how the goal will be reached. The teams that operate the best are those that first agree on how they will tackle the process of reaching the goal. Sometimes the process is defined up front and other times it is defined as you move forward. Either way works, as long as the team understands who is doing what.
- Good team players document the process and the results. This goes back to my documentation topic. The goal is not the only milestone that is achieved as the team progresses. It may be formal or informal, but you need to document what is agreed to so that everyone stays on the same page. Writing it down and distributing it causes you to clarify and review as you go. Everyone contributes and reads the notes from a meeting and they are verified so all agree to the decisions that are written and not just what they think was said. I have found so many times that written reviews force people to see what was said.
- Good team players work as a team. An obvious statement, but so often not applied. Every member of the team stands or falls on the collective outcome of the team. But many bring personal agendas and goals that counteract that effort. Ferreting out these silent agendas may be tough, but they need to be uncovered and addressed or corrected. And don’t bring your hidden agendas into a team process. Not good.
Some of you may have taken a few tips from this article that can be put into place. Or at least pondered. More to come next time. Until then, keep on thinking.
