- Have you ever been to a dinner party with a group of people who began talking about another event which you didn't attend? Or a movie you haven't seen? It can be very difficult to feel part of the conversation because you don't have the same level of knowledge as everybody else. Managers of technical teams can sometimes feel this way if they don't have the same technical expertise as their team members. That is because managers of technical teams arerequired to spend the majority of their time operating at the tactical level rather then beingfocused solely on technical detail.
As a manager operating at the tactical level, you need to channel your interest inunderstanding the business and techinclal trends that might impact your department. Your concern with how to respond to the demands placed on your technical teams, you manage budgets, and ensure technical deliverables are produced in accordance with estimates for costs and schedule. This tactical focus can be very interesting or very frustrating, particularly if you are once producing technical deliverables yourself.
The emphasis, focus, and skills required to work as a technical manager are very different from those of a technical team member. The adjustment can be very stressful so as part ofbeing a manager of technical team members, versus being a technician yourself, here are a few tips to help you along. First, develop trust in your technical experts. Allow the experts to determine the best way to do things. Their approaches might be different from what you would do, so try and be patient and understand that the best way for them to accomplish things is the way that's most comfortable for them. Not necessarily the most comfortable for you.
Second, focus on outcomes. Be focused on ensuring you are clear on what has to be achieved to meet your customer's needs. Third, focus on eliminating obstacles that may hinder your team from accomplishing their tasks. Ensure they have the tools and training they need. If you have relevant experience from your time as a technical team member, share that experience.However, don't insist your team mirror your own history. Let them use your experience and build upon it for themselves.
Good technical managers ask good questions, such as, Have you done this before? Does my team know enough about the business and environment to make their approach or ideas fit?Are there inconsistencies surfacing in their ideas or deliverables that can introduce risk, such as unconfirmed assumptions? Does my team have enough details about what the business wants or needs? Here is an example. Let's say your team is manufacturing cars and the business asks them to make the car safer for pedestrians by making the hood more flexible upon impact.
Someone might come up with what seems like a great idea, like, let's start making the hoodfrom more flexible aluminum. Jumping in and starting this might achieve the objective of making the car safer for pedestrians. But that is not the sole purpose of a car. We may end up causing greater problems. There are other considerations that we would need to look at. The hood still needs to provide crush zones for the passengers and also must protect the engine. So, to create a solution that not only makes the car safer for pedestrians, but also protects the passengers and the engine, we need to find a balance point.
Clear assumptions, getting the details, and thinking through actions to prevent inconsistenciesis your role as the technical manager. Not to know everything about the technology. That way you can produce that car that everyone is happy with.
- Have you ever heard the saying "It's all about balance"? Sometimes it's about balancingshort-term versus long-term activities. Other times, it can be about spending money now, and balancing that with the potential cost of spending money later. With technical teams, the balancing game consists of having your team work on technical solutions, versus spending time working with the businesses you support, to understand their needs. When managing a technical team, technical needs and desires and the requirements of managing a business can run on a collision course.
Understanding where to focus is important. It's all about ensuring focus is on producing the best technological solutions, but also ensuring they're pragmatic, and can be easily used by your customer. Where to focus can be very tricky because your technical team members probably have a lot of knowledge about your organization systems and processes, and therefore, can propose creative solutions to problems. A good technical manager knows that he or she must encourage and support that creative problem solving talent.
Sometimes, however, a technical team member may propose a solution that focuses too heavily on technical elements, and it may not appear to work well for the business. As a technical manager, you will have to make some decisions about whether to jump in, to fix this situation. Or, allow your team member to continue to progress their ideas. Here are some questions to ask before determining whether or not to jump in. Is this technical team member familiar with the specific technology they're working on? Is this team member familiar with how that technology is being used by the business? Does the proposed solution fit with the overall architecture of the system? Does the proposed solution fit with the overall direction being taken by the business? Is it possible to alter current business processes easily, to make the solution work effectively? If the answers to the above questions are yes, you should encourage your team member to proceed, and help manage the change management concerns that may surface with the business.
It's all about intent. If you cannot answer yes to the questions I've posed, you need to adjust the focus of your team member. To do this, kindly and clearly, inform the technical team member of your concerns, and persuade him or her to look for another solution. This helps prevent mismatches between your technical team's ideas, and what is pragmatic for your customer. If you find mismatches surfacing frequently, encourage and support your technical team members to spend time working with the business, to understand their processes and requirements more thoroughly.
By taking the focus off the technical solution, and putting it on the processes and requirements of the business, your team's technical solutions will improve in the long run. So, sometimes not focusing on technical solutions is the best way to create better technical solutions. A final note about helping your team focus on the business, as well as their technology, your communication style is important, to ensure the message is delivered effectively. A fine balance will be required to ensure the technical team member feels valued and supported, and that the best solution for the business is produced.
Emphasize that business knowledge provides background, which can elevate and expand their importance to the business. This gives you the means to focus your efforts, and the efforts of your team, to ensure the business consistently benefits from the solutions you've produced.Now, that's a goal that deserves your focus.
- If you've ever watched a child eat a cupcake, you would know that they tend to eat the frosting first. Why? Because that's the good bit. On the other hand, adults tend to take a bite of both cake and frosting together to achieve balance. Sometimes, technical team members really enjoy the fun technical bits of a project, such as developing a creative solution, while tending to neglect some of the more mundane tasks associated with it, like the documentationor product reviews.
However, it is the balance between these creative and administrative tasks that makes your team the most effective. Administrative tasks are necessary to facilitate the support of teams, such as testing and maintenance. Documentation of quality assurance activities is required to ensure testing can be completed. A technical product review may involve having someone else read some application code and critique its structure. It could be showing somebody else the mock-up of a screen, or it could be showing somebody how to manage the controls on a piece of robotics.
Good technical team management is about making sure that you have covered the administrative tasks as well as the creative tasks. Here are some tips for focusing on the Administrative tasks without making the processes and standards so burdensome that it stiflesthe creativity of your technical team members. Use the "administration now" approach.Administrative tasks have a way of being left until later as technical team members focus on the creative technical work.
The problem with that is that often the administrative work never gets done. As a result, your project ends up with no documentation or no product review information. Insist that the administrative tasks are completed as the team progressed through its tasks. Wear the other team's shoes. Have the technical team work with people from other teams, so they understand how important the administrative tasks are to them. If your technical team has produced a new piece of customer relationship management software, have them work with the help desk staffwho will be using the software.
Have the technical team be part of the overall solution implementation, not just the product itself. Find the balance point. Make your expectations for the administrative tasks clear, but allow your teams members to be part of the decision making for processes and standards that they're then expected to adhere to. Consider hiring a technical writer. If your project requires a lot of technical writing, a specialist to produce this product may be required.
As a rule of thumb, I don't expect my technical team to spend more than 15% of their time on documentation as it reduces their creative capability. Consider hiring a business analyst. They can be useful in helping to integrate changes into the business. Consider hiring a trainer. Just because your technical team knows the product doesn't mean they have the skills to teach others how to use it. There are special skills associated with teaching and learning, such as adapting teaching strategies to learning styles.
However, your technical team should play a role in the preparation of training materials and supporting the business until the change is fully implemented. Set clear boundaries and establish communication standards. Ensure the entire team is working from the same information, and team members are interpreting things consistently. The work of the technical team is about producing a product that is not just technically sound but also capable of fulfillingthe longer term business needs.
You can have a great technical tool, but without a manual to teach staff how to use it, it won't be helpful. Coaching your technical team in this way helps ensure that your team and your customers get a bit of cake and frosting with the products you create.
- Voltaire is credited with saying, "Perfection is the enemy of good enough." Perfection implies that there is no degree of error that is acceptable. Whereas, good enough implies that what you have is usable, or in other words fit for the purpose you require. While we should strive to be more than just good enough, perfection is usually an unreasonable goal, and no matter how good your organization is at what it does you should never assume that its systems and processes can be perfect.
Technical team members can and should have some form of perfection in mind as they enjoy the art of creating innovative solutions to business problems. The fun part of their job is making these improvements happen. Although a perfection mindset is good to a point, there can be a temptation to achieve perfection at the expense of other important tasks such as documentation and missing deadlines. The mundane task of documenting technical work is typically put off until later, the trouble is later never comes.
If your technical team is in the middle of their creative work it may be wise to allow them to continue unabated. However, the purposeful delay of documentation should only be accepted when there are systems in place to ensure it does actually happen later and does not become forgotten. As a good technical manager you should enforce business process while minimizing its impact on positive creative processes your team may use. There are times, however, when certain processes are not negotiable and need to be enforced.
To determine this you need to ask is the process and the outcome mandated, or regulatory, or just the outcome? Sometimes the outcome is regulatory, but the processes used to achieve that outcome are not. The preparation and filing of your income tax return is a regulatory outcome, but there are many different ways of achieving that outcome that are not regulatory.You might prepare your own income tax return, or you might engage the services of an accountant to prepare your income tax return on your behalf.
In contrast to this, sometimes both the process and the outcome are regulatory. For example, when testing a new drug there is a prescriptive process that pharmaceutical companies must follow to produce an outcome, so sometimes the process and the outcome are both regulatory,but sometimes just the outcome is mandatory and the process is flexible. As a technical manager this is important to keep in mind. You should seek to strike a balance betweenallowing people to have flexibility in the process, while not allowing them to bypass certain nonnegotiable approaches because they simply want to take shortcut.
If the processes can be flexible ensure you allocate time for people to focus on the most important outcomes, and perform other supporting tasks such as documenting their approach later. Most organizations have change management processes which usually require documentation of the change before it is implemented, as well as justification of the change,and assessment of its impact on business processes. These should be followed, but how to develop those change artifacts can vary.
One thing to keep in mind, however, in emergency support situations standard and reasonable business processes can sometimes be bypassed to enable fast resolution of an emergency issue, like a broken IT application. When something is broken you may need to bypass the change management process, and invoke an emergency process which allows for documentation to be produced after the urgent issue is resolved. This should only be done where there is very good reason to do so, and not just when people are attempting tocircumvent change management processes.
If an organization has 20 percent of its change being handled as emergency changes this indicates something is broken. Emergencies should be a low percentage of your team's work.Look at your processes, focus on the outcomes you need and what is mandated by your company or the law, and produce what is good enough first. Then take a step toward perfectionif and only if it's reasonable to do so.
Balancing stakeholder needs
- When creating technical products to solve a business problem, there is often more than one solution available to us. The solution we choose needs to be based on the requirements of our customers. Usually people have some idea of what they want and don't want. The problem is so does everybody else, and they don't always agree. The saying goes I can offer three approaches to a product: good, cheap, and fast.
Pick any two. The point of this quote is that at times we will receive conflicting direction,needs, or requirements from our customers. When your customer's requirements are in conflict, your technical team will need to find balance. Let's take a car, for example. There may be a set of requirements for the door. The customer wants the door to be light enough that it can be opened and closed easily. But they also want it to be reinforced enough to provide some protection from side impact.
In addition, they want it to make a solid sound when they close it because that makes them feel safe. By making the door from a lighter material, it can be opened and closed more easily,but the sound the door makes when it closes is less reassuring. The lighter material offers an inferior level of protection from side impact. If the door was made from a heavier material, the sound the door makes when it closes is more reassuring. The heavier material offers a superior level of protection from side impact, but the door is harder to open and close.
So how do you approach this? I suggest the Quality Function Deployment or QFD approachrepresented by a clever one-page graphic called the House of Quality. Let me share the objectives of QFD first by describing the House of Quality graphic. QFD helps you to do some fundamental things. Highlight customer requirements. Ensure your technical team is focusedon a specific business outcome or a short set of customer outcomes.
Summarizing your full requirement set into a few concise statements can be revealing for your customer and help you set direction for your team. Identify the characteristics of your proposed solution. This helps keep your technical team from creating things that aren't needed and helps your customer picture what you're creating to satisfy their needs. Identify the relationships between customer requirements and your solution characteristics. We show this on the roof of the QFD graphic.
This is vital for a couple of reasons. First, it confirms that what you're producing in your workaligns with your customers needs. Second, it helps you easily demonstrate when you have received requirements that could present competing priorities. Here I have symbols for compatible, unrelated, and potential conflict. Resolving these competing priorities is based on importance ratings in the House of Quality because these ratings give you and your customerperspective on the critical nature of each requirement.
In the event conflicts exist with your requirements, you can use the importance ratings to develop a solution that satisfies the most important requirements for your customer. Using QFD can be very powerful because the approach represented by the House of Quality can show your customer a lot of information without requiring pages of text. In a world where it can be difficult to confirm if your proposed solution will meet your customer's requirements, this can be a lifesaver.
No comments:
Post a Comment