Monday, July 27, 2009

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.

Wednesday, July 1, 2009

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.