How to Interact with Your Team as a Manager

As one moves from being a lead (manager whose reports are individual contributors) to a manager (manager whose reports are leads), there is an important decision to be made about how to interact with your skip-level reports. That is, how should a manager handle his interactions with the individual contributors reporting to his leads. There are two ends of this spectrum and managers often gravitate to one end or the other. The first option is to bypass the leads and go directly to those on the front lines. The second is to route most interactions through the leads. Both have their advantages and disadvantages. Where to position yourself between these two ends of the spectrum is not an easy decision to make.

If a manager decides to bypass her reports and go directly to the individual contributors (ICs), she has direct knowledge of how things are progressing. She develops a direct relationship with the ICs. Things are more likely to be done the way she wants. However, there are some significant downsides to this behavior as well.

First, it is hard to scale to this level. The fact that the organization chose to have leads should indicate that the work is too big for one person to manage. If the manager can handle all of the ICs directly, the lead position is extraneous and harmful. The reality is that this manager is unlikely to have enough time to closely monitor the work all of the time. Her interaction with the team will then tend toward drive-by management. She will swoop in and give direction on a particular part of a project but then lose focus before the results of the direction become evident. This can lead to poor decisions being implemented and frustration among the individuals carrying out the instructions.

Second, it can lead to discontent among the leads. They will have particular ways they want work done and a priority order for what they want done. Having their manager go directly to their reports means these instructions will be contradicted. This causes confusion among the ICs who will have conflicting priorities and goals. The lead will also feel his role being undermined by his manager. When she goes to his reports and gives them instructions, he is out of the loop and will begin to feel unnecessary or even frustrated. This can cause the lead to stop performing the duties of a lead and allowing the manager to do that work. As the manager is unable to give the same amount of attention, this often leads to a situation where no one is paying attention.

What about the alternative? Routing work through the leads. When a manager wants her team to do something, rather than going to Fred the IC with instructions, she asks the lead to ask Fred to do the work. This allows for the lead to always be in the loop. It allows the lead to ensure that there is a clear message (see blog past on providing clarity) so that the IC only has one set of priorities. It also allows the manager to scale. Rather than having to check in on Fred's progress, she can just ask her lead in their 1:1 how things are going. The details of the work can be left to the lead and the manager need only bother with the end goals. This may sound good, but there are downsides as well.

First, going through another person in communication always risks the message getting distorted. As anyone who played telephone in elementary school can attest, the more people that retransmit a message, the more it will change. In the elementary school game children are asked to sit in a line. The first child is given a message and asked to tell the next child in line. Each child in turn is to repeat what they heard to the next child. The final child will announce to the group the message he received. With rare exception, the final message is not even related to the initial one.

Second, going through another person can limit the amount of feedback received. If Jane the manager tells her lead Marcus to have his team make the iWidget program interface with the new build process, there is some chance that Jane will not learn that this is more difficult than initially conceived. If Marcus does his job poorly, he may not relay the message to Jane. This leads to frustration on all fronts. Jane is upset because the project is taking too long. Fred the IC is upset because he is being asked to do the impossible. Marcus may even be frustrated because both his manager and his report are frustrated.

The third and perhaps most insidious downside of this management approach is the lack of relationship that gets built. People will subconsciously distrust those who they do not have a relationship with. Their natural tendency is to distrust until they have reason to trust. The reason doesn't have to be large. It could just be seeing that the manager treats others fairly or having casual conversations which convey the sense that the manager is a “real person.” The result of this psychological phenomenon is that until a manager has built up social capital via relationships, she will not get the benefit of the doubt from her team. Subtly, the team will interpret ambiguous actions in a negative light. Asking for a code review will not be seen as a way to strengthen the team's coding skills but rather as a way to check up on people and “get them” if they aren't doing well enough. Mail sent asking about the status of a bug will be viewed as accusatory rather than merely inquisitive. The most insidious part is that the manager will probably never realize this is happening because she doesn't have the relationships that would provide the necessary feedback channel.

In the past year I made the transition to manager and faced this exact quandary. My decision was to route most interaction through my reports. When I needed work done, I would ask the manager to have the work done instead of going directly to the report. I knew the downsides of not letting leads do their job and wasn't going to make that mistake. Instead, I made the mistake of being too distant. I built up relationships with my direct reports, but not as much with the teams reporting to them. Based on this experience, I will be trying a more mixed approach in the future.

I still believe it is important not to bypass the leads when giving work instructions.  Yes, this has the telephone problem, but the consequences of avoiding that are too great.  At the same time, it is important to build a relationship with the individual contributors.  This means ensuring direct contact.  At the lower edge contact should be made at the individual level by wandering the halls and by skip-level 1:1s.  At the higher edge, contact should be made by sending out broad mails laying out high-level vision, by all-team meetings even if there is no business demand for them, and by occasionally attending your team leads' meetings.  The middle (direct business communication) should be left to the leads.  In initiating contact at the individual level for personal contact and at the vision level for business, you should generate enough “human capital” that the team will come to trust you and give you the benefit of the doubt.

Be Intentional

My old manager used to always say, “Be intentional.”  It took me a long time to comprehend exactly what he meant by this, but eventually I did and have come to appreciate the advice.  What he meant was to always make active, conscious decisions rather than just letting things happen.  It also means to verify things rather than assuming they are a certain way.  For example, if you don’t have enough time to do everything on your plate, think carefully about which items will not get done rather than just working on items in no particular order.  It should be your intent which specific items go undone.

This is a good principle to act by.  All too often people think about what they *are* doing but don’t consider what they *are not* doing.  It is just as important to be conscious about what you are not doing as it is to be aware of what you are.  If you don’t actively choose that which is not done, it is likely that the wrong things will drop off your plate.  It is easy to be busy working on something that is important to the detriment of something that is really important.  It is best to make all decisions, both positive and negative, conscious ones.  I’ll often ask my team when something goes undone whether that was intentional or not.  If there is only time to do 3 items and there are 4 that should be done, I’m fine with the 4th being dropped.  It is a poor manager who is upset when the impossible isn’t accomplished.  I do, however, hold my team accountable for that 4th item being something they intend to not get done rather than whatever just happened to be left at the end of the day.

I’ve seen this come up in testing features.  I recall a time when a report of mine was testing a particular feature with two aspects to it.  For good reasons he started working on the first part, a complex parser for device attributes.  Being complex, this took a long time to thoroughly test.  In fact, it was taking long enough that he was not going to be able to get to the second aspect of the feature at all.  I inquired whether this was really the right approach.  Did he think it was better to thoroughly test the parser and test the other part none or would it be better to test the parser to some level, then test the other aspect, and finally return (in the future) to cover the less important parts of the parser.  Upon reflection he decided it was a better idea to cover both to some extent than one fully and the other none.  The trouble here is that he wasn’t acting intentionally.  The test plan called for testing both aspects thoroughly.  The plan didn’t call for ignoring the second part.  It was just because of the unexpected difficulty of testing the parser that the second was going to be missed.  He needed to step back, re-evaluate, and decide intentionally rather than just letting events dictate what was going to be dropped.

This principle is also good to apply when dealing with other people.  Instead of just assuming that the other party will do the right thing, being intentional means specifically outlining expectations of them.  It is easy to think you’ve told someone what to do without them realizing that you did.  Being intentional means verifying that your assumptions were communicated and following up later.  It means being explicit when handing work to another person.  Make sure they understand that it is your expectation that they now have the action item before you clear it from your to-do list.

Five Books To Read If You Want My Job

This came out of a conversation I had today with a few other test leads.  the question was, “What are the top 5 books you should read if you want my job?”  My job in this case being that of a test development lead.  At Microsoft that means I lead a team (or teams) of people whose job it is to write software which automatically tests the product. 

• Behind Closed Doors by Johanna Rothman – One of the best books on practical management that I’ve run across.  1:1’s, managing by walking around, etc.
• The Practice of Programming by Kernighan and Pike– Similar to Code Complete but a lot more succinct.  How to be a good developer.  Even if you don’t develop, you have to help your team do so.
• Design Patterns by Gamma et al – Understand how to construct well factored software.
• How to Break Software by James Whittaker – The best practical guide to software testing.  No egg headed notions here.  Only ideas that work.  I’ve heard that How We Test Software at Microsoft is a good alternative but I haven’t read it yet.
• Smart, and Gets Things Done by Joel Spolsky – How great developers think and how to recruit them.  Get and retain a great team.

 

This is not an exhaustive list.  There is a lot more to learn than what is represented in these books, but these will touch on the essentials.  If you have additional suggestions, please leave them in the comments.

Some Programming Languages to Consider Learning

Learning a new programming language can affect the way you think.  While most modern languages are Turing Complete and can theoretically all accomplish the same things, that’s not practically true.  Each language has its own strengths of expressiveness.  For instance, trying to write dynamically typed code in C++ is possible, but a pain in the neck.  You would have to implement your own type system to do so.  Each language makes certain things easy and other things hard.  Learning different languages then exposes you to different approaches.  Each approach provides a different way of thinking and a set of tools supporting that way of thinking.  What follows are some of the languages I’ve learned and what I think they provide.  This list is limited to languages I’ve studied in at least a little depth.  There are many more languages out there that may be useful.  If you have additional suggestions, please make them in the comments.

• C – This is coding very close to the metal.  Learning it promotes an understanding of memory, pointers, etc.


• Lisp/Scheme – Once you get past your parenthesis-phobia, it’s a very elegant language.  The big learnings here are treating code as data, metaprogramming (writing programs that themselves write programs), and recursion.  Lisp is also a dynamically-typed language.


• Clojure – A variant of Lisp that runs on the JVM.  In addition to what you can learn from Lisp, it adds persistent data structures and transactional memory.  Persistent data structures are ones that *never* change.  Once you have a “pointer” to one, it will never change underneath you.  This makes parallel programming much simpler.  Clojure also is more of a functional language than Lisp/Scheme.  It is not purely functional, but allows for the functional style to be followed more easily.


• Smalltalk – Much of modern programming originated in this language.  Modern GUIs are based on the Xerox Parc Smalltalk systems.  Object Oriented programming was first popularized in Smalltalk.  Extreme Programming, Agile, and Design patterns all found their initial formulations in Smalltalk.  In addition to learning about OO programming, Smalltalk is great to understand message passing.  This gives object-oriented code a different feel than the function call semantics of C++/Java/C#.  Smalltalk is also a dynamic language.


• Perl – Perl was once known as the duct tape of the internet.  It ran everything.  It has since been surpassed (at least in blogosphere popularity) by other scripting languages like Ruby and Python.  The biggest thing to learn from Perl is regular expressions.  They are built into the core of the language.  Other languages support them but often as a library.  Even those that do support them in the syntax do not usually utilize them so pervasively.


• C#/Java – These languages both solve the same problems in almost the same ways.  They are a great place to learn object-oriented programming.  It is built in from the ground up.  The OO style is one of function calls and strong interfaces (which distinguishes it from Smalltalk).  These languages also have the largest accompanying libraries.

Inbox Zero, Take Two

A year and a half ago I tried to get to “Inbox Zero” and failed.  This is the idea that you get your inbox down to zero mails every day.  I’m making another run at it and this time have been a little more successful.  I’m not perfect, but I haven’t fallen off the horse yet either.  Here’s what I have found to work.

• Let all interesting mail fall directly into the inbox.  Don’t use separate folders for stuff from your boss or an alias/list that is important.
• Move non-interesting mail into a separate folder by a rule.  I have rules to shunt off aliases I find merely interesting but not important into their own folders automatically.
• Read or skim every mail that is in your inbox.  For each, make one of the following decisions:
• Respond.  Read it and take the appropriate action.  If you can do this in a minute or two, just do it.
• Delete it.  You have the information or it wasn’t interesting.  Either way, you don’t need to keep it around.
• Archive it.  You may need to refer back to it later, but you don’t need to take any action on it.
• Mark it for further reading.  It’s not critical to act on it, but too long to read now.  Put it in a folder to read later.
• Mark it for further action.  It will take longer than you have to respond, but a response is necessary.  Put it in a folder for later response.

Following these rules makes my inbox look something like this:

• Inbox
• Action Required
• Archive
• Read Later
• Interests
• Various subfolders for the non-critical aliases I am part of.

I also have a rule to move all mail sent to: or cc: me directly to my inbox.  This way mail intended for my eyes won’t get filtered into an “interests” folder.

I have found this system simple enough to keep up with it.  It also means I no longer miss mails which got filtered into some folder I haven’t yet read for today.  I now see every interesting mail and am at least aware of it.  It also helps me keep track of the mails I really need to go back and respond to.  My old system was just to leave them unread, but this got unwieldy very quickly and I never made it back to most of them.

Don’t Worship at the Altar of Accuracy

Earlier today I found myself faced with a common management situation.  I had been sent an e-mail which showed that a piece of data we were using was inaccurate.  The specific issues was what percentage of a certain test run was automated.  We had said we were at 100% and it turned out there were a handful of tests that were being run on our behalf by someone else and those were not automated.  My initial response was to investigate how big the non-automated block of tests was, why it wasn’t included, etc.  Then I stopped and thought about it.  Even if the number were as large as reported, that number would be 10% of the total test suite.  That is almost certainly an over-exaggeration.  When we make the numbers more accurate, it probably slips to 1%.  Whether we are 90% automated, 99% automated, or 100% automated, does that change anything?  Is that number going to change what I ask of my team?  Probably not.  In all cases the items that are manual are intended to be that way.  I won’t stop running them or try to automate them.  All that I will gain by going through the process of making the number more accurate is a more accurate number.  Is there value in that?  I assert that the answer is no.  A number’s accuracy matters only to the extent that the difference will change behavior.  Within some range, different numbers won’t change behavior and so are not worth expending effort increasing the accuracy.

This isn’t to say numbers don’t matter at all.  They do—but only when decisions will be made based on them.  Effort is not free.  Spending energy refining a value that is accurate enough means not expending that same energy on something that might bring more value to the team.  It isn’t hard to find something which brings more value because the value an increasingly accurate number brings is zero.  This is especially important to note as a manager.  A manager typically does not spend a lot of effort making data accurate.  He or she merely asks others to do so.  In this way the costs are hidden and thus the tradeoff not as apparent.  Beware the cost of obtaining accuracy for its own sake.  I know it is in our DNA as engineers.  Suppress your inner urges and don’t worship at the altar.  Get to good enough and stop.

Simple Management Tip: Tracking 1:1 Conversations

Here’s a quick tip I’ve found very handy.  When doing 1:1’s with your team (you are doing these regularly, right?), take notes to keep track of the conversations from week to week.  I currently use a 5-tab notebook with one tab for each direct report.  Each person has their own section.  Each week when we meet, I take notes on the next page in their section.  This makes it really easy to refer back to last week’s notes and follow up on any ongoing issues.  Each week I circle the items I need to follow up on the following week.  This makes it trivial to pick them out.  Having one section per person means the previous week is only one page back.  I tried just keeping a continuous set of notes on everyone, but then finding the last time we talked could be difficult. 

Another advantage of having each person in their own section is it provides a space for next week’s agenda.  During the week as things come up, I jot them down on the next week’s page.  Then when it comes time for the 1:1, I already have a list of items to follow up on.  This also helps stop my subconscious mind from dwelling on these items (ala Getting Things Done) because I know they will be handled.

I have also seen OneNote used successfully for this purpose, but I prefer not to have a laptop between myself and the other person in our meetings.  It is a matter of taste.