I'm no stranger to work. I'm what some might call a workaholic. However, recently I've been working too much. Between my day job, writing, and AST I'm a bit frazzled. One of the nice things I've found about our community is that when the going gets tough, people are there to help.

In AST, Scott Barber and Cem Kaner have picked up some of my slack, and I'm very appreciative. In my writing, my now long-time co-author has been patient and encouraging as we work through (yet another) dry spell. And at work I've recently had the pleasure of interacting with Alex Podelko as I've tried to struggle through too many projects (often at odd hours).

I've been doing a lot of multi-project multi-tasking (read more about that here). It's kinda like putting your brain in a blender. A couple weeks ago I remember interacting with one of my team members and them stopping the conversation because I couldn't focus long enough to process the information they were giving me. Not good...

Recently, these behaviors became manifest as I was working with one of our performance testers to create some performance scenarios for Hyperion IR Web Client. We couldn't see traffic in the recording for the scenarios once the Web Client was loaded. Thinking we had an incorrect setting, like all performance testers we turned to Google for the answer. You can't throw a rock and not hit Alex's name if you Google performance testing and Hyperion. I've read plenty of Alex's writings, so I figured this was as good a time as any to introduce myself.

Alex was incredibly helpful in helping me work through my problem. He asked questions, sent me code, and looked at my screenshots. At one point Alex very gracefully took at step back and asked me what exactly was I trying to record. I think he figured out that I clearly wasn't thinking, and he very nicely pointed that out. Web Clients run on the client side (hence the nifty naming convention); after you load a document nothing is communicated to the server until you request data. Data conversion, building graphs, filtering, etc… all happen on the client side.

I was trying to record client-side activity with a performance test tool. I would like to think that on a good day, I would know better. As I continue in my transition from technical leader to manager, I wonder if this is one of the common ways in which managers lose their ability to contribute productively to technical solutions. It's not that I don't still possess the technical skills; I'm sure I do. It's that I can't focus on anything long enough to get the clarity of thought one needs when solving difficult technical problems. I'm sure Rothman's written about this phenomenon extensively (and I'm sure I've read it – I just can't remember right now).

Last year I read Behind Closed Doors: Secrets of Great Management by Johanna Rothman and Esther Derby. The book is well written and is told in an interesting way. In the back of the book, there is a section titled Techniques for Practicing Great Management. In that section, I found a list of questions designed to help managers make the progress of any project contributor more visible. You might try asking questions like the following:

• How will you know when you're done with that?


• What steps will you take?


• Which part will you work on first?


• Can you provide a picture or a measurement of work to date?


• Do you need to collaborate with anyone else on this?


• How will you know you're making progress?


• Who needs to be in the loop if you are unable to finish this on time or run into problems?

When I finished reading this list, I noticed that some of these questions were eerily familiar. In fact, a past manager had asked me those questions before. I remember thinking about why he would be asking me those questions because I always report my progress.

After reflecting on the questions a bit more, I began to recognize that I had not been effectively communicating my progress. Without even being aware I was doing it, I had stopped. Not only have I not been communicating progress, I haven't even been telling my manager what I've been working on.

I see three reasons as to why this might have been:

1. I didn't yet really understand the scope of the work I was doing. I knew what I wanted to do, and I knew how I wanted to do it, but I was still trying to work out the steps to get from point A to point B. Because I didn't truly understand the work yet, I couldn't think of a way to explain my tasks to my manager yet. When he asked what I'd been doing and what I planed to do, he was looking for a level of precision that I just didn't have yet.

Mark: "Which part will you work on first?"

Me: "I don't really know what the parts are yet. I'm still trying to figure that out."

Mark: "How will you know when you're done with it?"

Me: "I don't know yet. I'm still not sure what 'done' means. It's a complex set of tests and I still don't know what they will look like."

Mark: "Do you need to collaborate with anyone else on this?"

Me: "Of course, I just don't know who yet."

As you can see, I was very vague.

2. My manager was new (to me). The old manager just rolled off the project and this manager had not yet been 'tested in battle.' We didn't yet have a history or a working relationship. It's hard to develop a working relationship with a new manager. We didn't know to communicate yet and we both had different expectations for what the person in our roles should be doing.

Therefore, much of what he asked me smacked of micromanagement. When in truth, it was more likely that he truly didn't know what I was doing and he was just trying to learn the only way he knew how - asking questions. Nothing wrong with that...

3. Finally, I was moving off the project in the near future (or at least my status with the project was rapidly changing). That meant that I didn't really want to take the time to build the relationship like I normally would have. It's hard work getting to know how to work with someone new and I just didn't want to put in that effort.

Once I recognized my behavior, I needed to fix it.

Starting the Monday after I finished the book, I took the time to invest in the new relationship. It was not his fault he was new, I was just being silly (to put it nicely). I worked with him to provide more visibility to my tasks and progress. I struggled with him to understand the work. I included him in my brainstorming sessions and talked with him more about the nature of the testing I was planning.

Oddly enough, that process of explaining it to someone else helped me better understand the problem. The investment was worth it.