Technical Management

Technical management seems a contradiction in terms. Software is everywhere, but hardware and firmware create a somewhat different game.

Tools for managing your technical team don’t matter if you don’t use them: a self assessment

Posted by:

|

On:

|

Isaac Davenport, Nat Crutcher, Matt Zenthoefer 2023.10.23

To get a sense of how you stack up against other technical managers, see how many boxes you can tick for these vital tools and techniques. 

Over the course of a couple months, the twelve senior technical managers I surveyed would use on average 17 of these 29 tools.  Beyond that, they also averaged six additional tools they would use on a longer interval. Active listening, encouraging documentation, and providing context were the most frequently used. Some of you may wonder why these are even considered tools, since you use them instinctively. Some of you may see this as a checklist to use after being thrown into a position requiring a vastly different skill set than that of a technical individual contributor: where you previously had to apply your understanding of how systems of things work, as a manager you now need an understanding of how systems of people work. I’ve included some brief explanations after the list to help make sure we’re using the same language. 

The skills, techniques, approaches, and frameworks listed here are those deemed most useful for shifting into a managerial mindset by a group of senior technical leaders.  If you are up for adding to our dataset, you can answer the questions in the survey.  A special thanks to Sharon Pitkin, Mehdi Sedighi, Bird Marate, Rick Saltzman, Kent Sabin, John Duane, Steve Simske, Jeff White, Charlie Danaher, Michael Minneman, Reiner Kraft, Eric Kampe, Jenny Shedd, Ala Stolpnik, Cody Henderson, Mark Goth, John Butare, Jeanne Atwell, Ross MacGregor, Vic Rompa, and Greg Krisher.

You’re free to use this material–including copying, adapting, and developing it–as long as you give appropriate credit and link to the CC-BY-SA license. If you transform and share this material in any way, you must indicate how you did so and distribute the final product under the same terms.

In the last sixty days as a technical team manager I have deployed:

 COMMUNICATION SKILLS

  1. [  ] The five whys: getting to root cause 
  2. [  ] Active listening: repeating for understanding and helping them to be heard
  3. [  ] Manage Expectations
  4. [  ] Over-communicate with influence, not direction
  5. [  ] Shuttle diplomacy and meeting hygiene

TECH SPECIFIC SKILLS

  1. [  ] Mindful work chunking: breaking down and assigning tasks for long term efficiency
  2. [  ] Review work and interfaces
  3. [  ] Optimize process: improving a teams informal and formal ways of doing things
  4. [  ] Ensure the right systems, equipment, resources and supplies
  5. [  ] Medium and long term planning
  6. [  ] Revisit Estimates: calibrating for better business decisions
  7. [  ] Revisit the critical path
  8. [  ] Encourage documentation
  9. [  ] Surface underlying risks and assumptions 
  10. [  ] Encourage external help out of the weeds

PERSONAL DEVELOPMENT

  1. [  ] Manage up
  2. [  ] Say no
  3. [  ] Have heartburn conversations early
  4. [  ] Reframe: give people the benefit of the doubt and problems another angle
  5. [  ] Make your boss look good

TEAM DEVELOPMENT

  1. [  ] Cheerlead, Team promotion, and Celebration
  2. [  ] Personal check-ins 
  3. [  ] Develop people formally and through teachable moments
  4. [  ] Socratic method: teach through questions
  5. [  ] Regular observational feedback
  6. [  ] Delegate
  7. [  ] Shades of gray: help engineers out of black and white thinking
  8. [  ] Provide context: give the big picture for better heads-up to heads-down connection 
  9. [  ] Team customer exposure

COMMUNICATION SKILLS

1. The five whys: getting to root cause 

Ask why five times to get to the root cause of things. A truer understanding can help increase perspective, connect tactical actions with high-level goals, and enable better decision making and compromise. 

2. Active listening: repeating for understanding and helping them to be heard

Build a habit of repeating back what you’ve heard to be sure you’ve heard it correctly. This enhances your understanding and provides ego massage to help the other person feel heard–an important human need. 

3. Managing Expectations

It is frustrating to work on a project when the customer or management have unrealistic expectations. Nobody likes to fail and this sort of project sets everyone up for failure. The feeling of frustration stems from disappointment and failure, which can sap a team’s energy and eventually its existence. It’s essential to be real and open and clear with your team, and with those who consume their work product to keep everyone’s expectations in line with one another and with realistic probabilities. If you can manage the expectations in both directions, your team will be more motivated and confident. This is not always easy if the corporate culture encourages unrealistic deadlines.

4. Over-communicating with influence, not direction

The communicative servant leader will outperform the terse dictator every time.  Leading means ensuring everyone is rowing together.  Often this requires repeating ourselves, explaining from more than one angle–and supporting each team member’s human drive for autonomy, to approach their work in their own way.  Don’t communicate with sentences that are commands (irony intended).  Instead, I am hoping you will share the outcome you are looking for and collaborate on how they will help get there. 

5. Shuttle diplomacy and meeting hygiene

Instead of having a meeting where everyone hashes things out–which could take a great deal of time or send emotions running high–it’s sometimes more effective to use shuttle diplomacy and your own time and cachet.  Then, did you check that meetings had agendas beforehand, a person committed to taking notes and distributing action items, and someone to watch the clock and ensure each topic and each voice–soft or loud–got a reasonable amount of time? Did you draw out the quiet members?  Bonus points if you learn to read individuals’ body language to invite more engagement. 

TECH SPECIFIC SKILLS

6. Mindful work chunking: breaking down and assigning tasks for long term efficiency

Understanding the team members, skills, and technology involved in the work product helps us break that work into human-sized chunks, assign those chunks to the right people (on or off the team), and set up integration points.  We need to balance: 

  1. The schedule
  2. People’s task preferences
  3. Cross training for risk mitigation
  4. The need to challenge team members
  5. Management of technical debt

7. Review work and interfaces

If you have the in-field expertise, you can review your team’s design work yourself, or at least check in to ensure that git pull requests aren’t just getting rubber-stamped. If you don’t, bring in an outside expert or schedule a real-time or offline peer review. Managing product interfaces pays disproportionately. Whether it’s software, circuits, slide joints, or jeans–when things come apart, they come apart at the seams. Even if the mix of disciplines on your technical team doesn’t allow for continuous integration, set up as many integration points as possible and let team members know they are on the hook to bring certain things to the table for integration on certain dates.

8. Optimize process: improving a team’s informal and formal ways of doing things

Your team has its own way of doing all sorts of things: reviews, procurement, prototyping, architecting, documentation–even communicating internally or with customers. One of your key productivity tasks is developing the reflex of asking, how do we do this better?

9. Ensure the right systems, equipment, resources and supplies

It is the manager’s responsibility to ensure your team has the resources they need to be effective. This might be a software library, second monitors, oscilloscopes, a quiet work area–sometimes you can ask what they need, and sometimes they won’t even know yet.   

10. Medium and long term planning

While individuals typically need to plan to be effective, your team has medium- and long-term activities (product planning, infrastructure buildout, migration paths, team augmentation…) that require your higher-level perspective. While it is true plans quickly sink to zero value, the act of planning is invaluable. 

11. Revisit Estimates: calibrating for better business decisions

We don’t do this often enough. Since business decisions are made on estimates, you need to review them and why they were or were not met. In your history of estimates you can find patterns that can help calibrate your estimators. Ferret out the underlying assumptions that went into them so you can identify risk types for future estimates.  Bonus points for communicating estimates as ranges rather than single numbers executives can latch onto.

12. Revisit the critical path

Assuming you’re not in a full-matrix organization, the odds are that you’re responsible for your technical team’s projects along with its members. Even if your group uses agile and not waterfall methodologies, it pays to be aware of the critical path toward your goals–so you and your team don’t get bottlenecked waiting on one component. 

13. Encourage documentation

Many teams have not made it a sufficient part of their rituals and formal processes to document how they solve problems. Looking at instances where the team struggles to pick up projects from the past can give you clues about where to encourage more or better documentation. Bonus points if you get authors to include “commander’s intent” or TLDR.

14. Surface underlying risks and assumptions 

Often you’re the manager because you have the most experience in the group–if you don’t, this might be a role for your senior team members. Expertise is needed for looking at (and testing, and mitigating) the risks and assumptions you’ve built your team’s success on. Bonus points for remembering to ask “what else could derail us?”

15. Encourage external help out of the weeds

Technical people can easily wind up in the weeds. Rather than reading stack overflow or googling around, encourage team members to approach someone else in the company with more context or experience around the problem they’re working on–or to pick up the phone and call the vendor or outside expert so they can stop spinning their wheels.

PERSONAL DEVELOPMENT

16. Manage up

Part of managing up means acting as a shit-shield so the shifting priorities, chaos and ambiguity raining down from above doesn’t distract or demoralize them. Ambiguity and imperfect knowledge are realities of business, but technical people often do not deal well with this reality.  You need to set expectations and guidelines for your superior. Developing the trust of your superiors–trust in your competency and trust you are looking out for them–is essential.

17. Say no

Saying no is one of the key productivity skills for individuals and for managing teams.  It can be hard to refuse other departments, your team members, or executives with pet ideas. This skill requires tact and refinement, which might be a struggle for those of us with a technical bent.  Are you saying no on your team’s behalf often enough?

18. Have heartburn conversations early

Those of us in tech are frequently conflict avoidant, but there are always disappointments, scary risks, broken systems, and unreasonable demands to manage. As an individual contributor you may have put these off too long, but as a manager you need to have these anxiety-inducing conversations sooner than later so they don’t balloon on your team.

19. Reframe: give people the benefit of the doubt and problems another angle

When things aren’t happening as they should, it’s easy to slip into thinking this guy is trying to sabotage me, but this mindset erodes relationships and wears you down. Hone the mental habit of imagining factors beyond others’ possibly negative intentions.  Give the benefit of the doubt to people on your team, and model giving the benefit of the doubt and possible positive motivations to people outside the team.  Take your time in framing the problem.  Is it really that after a failed ad campaign a hot sauce company needs an ad that gets more sales, or could a larger hole in the bottle inspiring customers to use more be a lower cost way to get more sales? 

20. Make your boss look good

Making your boss look good is a winning career strategy.  It also helps your team when those higher up the chain  associate your team with their own positive self image within the company.

TEAM DEVELOPMENT

21. Cheerlead, Team promotion and Celebration

You’re the ambassador for your team and the cheerleader for what they’re doing. When’s the last time you advocated for them to someone other than your direct supervisor? All the stakeholders should understand why your team’s work is worth the investment. Technical people seem to be disinclined to celebrate, but celebrating achievements goes a long way. While some teams actually appreciate a pizza party with cake and ice cream, a few public (or private) words of appreciation and encouragement is the kind of ego massage that goes a long way toward team cohesion and people feeling valued.  Bonus points if you know your team members well enough to praise them in their preferred manner.  Encouraging and spreading optimism inside and outside the team is important. What we expect tech teams to do is daunting. We need to be encouraging and appreciative.  

22. Personal check-ins 

As engineers and technical leads, it’s useful to think of our teams as subsystems of a company–but the subsystem’s elements are humans with human needs and human problems. How often do you have one-on-one discussions with your team members about their work situation and job? Bonus points if you talk somewhere offsite where they’re more likely to share their feelings. 

23. Develop people formally and through teachable moments

When fires break out at work, you need to use all of the steps:

  1. Put out the fire
  2. Learn the cause of the fire
  3. Put fire prevention strategies in place

Taking your team members, especially the younger ones, along for this ride can help them learn to avoid accidentally setting more fires of their own.  It can be difficult to consider a work meltdown as a valuable teachable moment but the emotional charge of fire fighting can help people see and remember how a situation fits a wider pattern of failures. IF YOU PRACTICE THE LAST TWO STEPS.  It is valuable to provide enough autonomy for others to have their own  mistakes in the first place to have teachable moments.  It requires creating a psychologically safe space. Though starting with teachable moments from your own mistakes is useful.  Beyond the ad-hoc, regularly spend some time developing your team members. Some leaders use formal courses; some use regular lunch-and-learns or book clubs where team members can take turns selecting and leading discussion of an article or book chapter.

24. Socratic method: teach through questions

I have fallen into the trap of giving my reports the specific answer or specific next step.  It’s  quicker and easier. But in the long run this means they won’t develop.  My availability started to bog down the team’s productivity. Taking time to ask them questions helps them create their own answer or next step. This fosters their confidence and decision making. 

25. Regular observational feedback

For a long time, I assumed other people were like me and just needed to know what’s wrong or in need of change: I was very mistaken. Team members, especially the younger or newer ones, desire more regular and specific feedback than an annual review–and it needs to include what they’re doing adequately or well. For instance “I noticed you had annotations for all the most complex parts of the schematic although the lack of page numbers made the sheet connectors hard to follow” rather than “I liked your schematic, it looked good, but the sheet connectors confused me”.

26. Delegate

Delegating is what allowed me to lift myself from the mire of details and operate my team at a higher level. I had to let go of how something gets done and focus on clearly communicating the result I expected. Delegation also builds team member’s confidence and increases their skill level so they can tackle increasingly complex tasks.

27. Shades of gray: help engineers out of black and white thinking

People doing heads-down work often have a tendency to see things in black-and-white, good-or-bad. As a team leader, it’s useful to help others see alternate narratives; this helps improve the nuance your people can bring to a situation.  It isn’t that Ron is “bad”, it is that Ron has difficulty articulating how he architects things in addition to being good at unit test coverage and variable naming.  It isn’t that team gopher’s module doesn’t meet the spec and is broken, it is that they interpreted things differently and would benefit from better insight into our constraints.

28. Provide context: give the big picture for better heads-up to heads-down connection 

Whether in the moment or during a huddle after, it pays off to help your team understand the bigger picture. When providing detailed, written instructions also provide a why to give them perspective to make better heads-down decisions.

29. Team customer exposure

Even if your team creates internal tools, someone consumes their work or their work wouldn’t matter. Many engineers are introverted, but being in touch with customers before and after product delivery improves your team’s perspective and priorities.  I often send engineers together or with a sales person.  Sometimes the engineer doesn’t even speak directly with the customer.  I have had engineers meet customers, observe them using the product live or in video reviews, or man the support lines for a few hours.  Sometimes I solicit written feedback from customers.  It helped my team find small and easy ways to increase customer satisfaction and to manage requirements. 

IN CONCLUSION

The techniques in this survey can help you level up your skills as a technical manager. Check back at www.isaacdavenport.com for deeper dives into each topic–and many more drawn from my own experience moving into technical leadership, and mentoring others through that shift. Managing technical teams is a tough road.  Don’t go it alone.  Find a mentor, a mastermind group, peers willing to do a monthly lunch and learn, a meetup, or a Linkedin group where you can talk to others who understand.

3 responses to “Tools for managing your technical team don’t matter if you don’t use them: a self assessment”

  1. Which tools do you think are missing? Senior managers deemed delegation the most important, with having heartburn conversations early, planning, active listening, and reframing also being very important. Revisiting estimates, making your boss look good, and cheerleading were the most likely to be seen as less important.

  2. Good list. I can only suggest that the items mentioned pretty much apply to teams whether technical or not. Non-technical teams have their own “technical” issues that require similar management. As an example, Finance has a number of compliance issues that some are black and white and others are very gray. Business model creation has many gray areas that are not straightforward. Another example is Legal. The agreements developed highly depend on the flavor of risk that management is willing to bear. No company can tolerate zero legal risk as it bogs down all processes. I could go on.

    • Good point. Most good management techniques apply across team disciplines. Many of the unique pieces of technical management seem to stem from the unique personality traits of technical people.

Leave a Reply

Your email address will not be published. Required fields are marked *