A new manager arrives on the scene. Or a new employee joins the company. What kind of person is the manager? What will he or she expect?
It takes time for any manager and employee to build a trusting working relationship. But you can jump-start the trust by sharing your basic philosophies and rules of engagement in a slide deck.
The title slide from my manager infodeck.
This deck quickly lays out the things you care most about: what you believe about management and about the kind of work your teams do, what makes you crabby, and how you operate day to day.
It’s also an opportunity for you to tell your story in thumbnail. It humanizes you and helps you be more approachable.
It also lets you lay out nuts-and-bolts expectations such as how much notice you want of vacations.
I’ve used my manager infodeck for a few years now to good effect. If you’re curious, you can see it here. You can even use it as a starting point for yours.
It’s annual review season where I work. I wrote and delivered my team’s last week. But my heart wasn’t in it.
It’s because if I’ve done my job as my team’s leader, they already know what I think of their performance. It’s been an open conversation all along, happening most often in our weekly 1-on-1 meetings but also through in-the-moment praise and coaching. Nothing I tell them in their review should be a surprise.
And we should have also had occasional discussions about what excites them about their work, what challenges they’re facing, how well they’re working with their teams, how they’re experiencing me as their boss, what they need from me to be happier and more effective, how they do and don’t enjoy the company’s culture, and what they want from their career and their life. Hearing their full perspective on their work, the company, and their career, I have what I need to promote the best balance of happiness and productivity for them.
That’s because as their boss I am only as successful as they are. The more and better they do, the more and better I do and the company does. Giving feedback and coaching for ever greater performance is one of the primary two things a manager is for. (The other is promoting conditions that enable the best possible work to be done.)
And let’s say someone on my team had a bump in the road during the year — an incident where things really went poorly on their watch, or the quality of their work went south, or a particular behavior needed correction. If those issues have been resolved, it is often hurtful to remind them of them at review time. “I gave you a Needs Improvement rating here because of that thing earlier in the year. You know, the one you fully recovered from.”
Bah. I’d like never to deliver another performance review.
Unfortunately, every company that has employed me has based raises on review scores. (Amusingly, a couple of them have sworn review ratings weren’t coupled to raises — but every time I asked for a larger-than-normal raise, the first question asked was whether their review score justified it.) So I still do reviews.
But if you’re doing the valuable (and time-consuming) work of giving feedback and coaching to your team all year, reviews take little time to write. You don’t have to think as hard about their performance all year because it’s been an ongoing topic of discussion. Just summarize what you’ve talked about all along, give some examples, assign appropriate ratings, and you’re done.
I lost my job a month ago. The software company where I worked cut expenses to fit revenue. That’s business.
I was Director of Quality Assurance. I built and led a team of functional testers, software engineers (writing code-based tests), and technical writers, and developed the strategies and processes the company used to test and deliver its products. It was a role my whole career had prepared me for, and I was glad to have it.
But now I’m working my network, looking for my next gig. It’s been fun. I’ve spoken to a few dozen CTOs, VPs of Engineering, and even CEOs so far in my search, usually from startups and young companies.
I’ve delivered so much software using waterfall and “scrum-fall” (the developers sprint, and testers try to keep up, but final testing still happens after developers are done) at various well-established companies that I thought that full-on agile was a myth, at least here in Indiana.
Endangered.
But the startup leaders tell me they’re all in: it’s agile, continuous integration, and continuous delivery all the way. And while all of them have or will soon need testers, they are all hedging on hiring specialized managers for them.
One CTO, a fellow I worked with several years ago, told a typical story: “I have a few scrum teams, each with one tester. But I can’t imagine ever hiring somebody to run QA as I don’t consider it to be a separate function. Testing is part of the scrum team. I’d have to think QA management jobs will eventually dry up everywhere. I’m sorry; I’m sure that’s not welcome news for you.”
When waterfall ruled the world, it made sense to have a QA department with its own leadership hierarchy. After all, the testers truly were a separate team with their own schedules, methodologies, and needs for care and feeding. But in agile, testers feel fully part of their scrum team rather than part of the team of people who test.
I admit to some anxiety over this evolution, entirely because I’m unexpectedly on the job market after several years of being Manager and Director of QA. But I think these changes are good for quality software delivery.
And these changes are creating opportunity, because there are things a good QA leader knows how to do that a CTO or VP of Engineering probably doesn’t. I networked my way into another startup CTO’s office just to introduce myself and ended up walking out with a short-term consulting job. It turns out that he’s ready to hire his first tester, but wants guidance on how testing should integrate into his team and how the tester should approach the work to find the most important bugs early. So I’m testing alongside his developers for now to get a feel for their context, and will develop a strategy and process his team can follow after I’m gone.
In my conversations, over and over CTOs are telling me they need people to coach and guide on functional testing strategy and technique, or on building test automation and performance testing practices. One VP of Engineering I’ve talked to had an unusual take: that I should be able to help him build and manage his end-to-end software delivery process, including engineering and testing, because he sees process as key to predictable and reliable software quality.
I certainly have experience in all of these areas. I imagine many Managers and Directors of QA do.
I don’t want to count my chickens before they hatch, but I feel pretty good that at least one of these threads will lead to a full-time job soon. And with it, I’ll step out of the waterfall/scrum-fall past and into a present I previously didn’t know existed.
“You multitask like a madman,” my boss said to me.
She meant it as a compliment, but it brought me down. I was exhausted, teetering on the edge of burnout precisely because I had been multitasking an enormous workload.
Not a skill to be praised
I managed 15 people across four teams: testers that delivered monthly bug-fix releases, test automation developers, performance testers, and technical writers. My teams were solid and I had great leads in place, which freed me to work with a security-testing vendor to start doing regular penetration tests of our product, and with a translation company to translate our product user interface into five languages each release. I had a lot going on, but I was handling it.
But then the company decided to lean hard into more international markets. The executive team asked me to gather quotes to translate our product UI into even more languages, and also to translate our giant online help system, which we had only ever offered in English. The costs were an order of magnitude more than the executive team imagined, and so I was called into endless meetings and hallway discussions to provide more data as the executives squabbled with each other over strategy. This all sucked down more than a third of my time – but I could never focus on this work for more than ten or twenty minutes because I was still managing four teams with leads who had questions and needed me to remove roadblocks.
My performance began to suffer. While I had my eye on one ball, another would drop. I started making silly mistakes. It all wore me down to a nub. To keep sane, I ended up not asking, but telling my boss to take things off my plate so I could survive. I really wanted the translation stuff to go, as I didn’t enjoy it very much. But instead she gave the technical writing and bug fix teams to other managers.
I really mean task switching, not multitasking
Everybody calls what I was doing multitasking, but it really wasn’t. Real multitasking is when we do more than one thing at a time, such as driving and talking, or walking and chewing gum. But when two things come along that require focused attention, most of us can’t do them simultaneously. We work on one task, and then we work on the next. That’s really called task switching, and it happens every time we stop testing a feature release to test an emergency hotfix, or even get interrupted to answer a question. I’ve just called it multitasking here so far so that Google’s sweet, sweet searches can find this post.
Task switching makes tasks take longer overall. It also hinders learning – all that switching from one task to another keeps things from sticking in our brains. It really is better to work on, and finish, one thing at a time. We are so much more productive that way.
The hidden costs of task switching
Say you’re working on task A when task B arrives. If you want to avoid task switching, you finish task A and then work on task B.
But say task B is hot, and your boss needs you to work on it right now. Task B goes out sooner, at the cost of delaying task A.
But there’s a hidden cost: unless a task is automatic or menial, it takes time to get oriented to it, even when you’re returning to it after only a brief interruption. You must at least try to remember where you left off. That orientation time delays overall completion.
This cost mounts the more you switch tasks. If you switch repeatedly among tasks A, B, and C, not only do all tasks finish later, but tasks A and B finish much later.
Task switching hinders learning
Dairy Queen photo
One of my first jobs was working the counter at a Dairy Queen. It took me a couple weeks to learn the technique for creating their soft serve’s signature shape, but then I could do it without even thinking about it. It had become a habit.
Making software isn’t the same as making ice-cream cones. Being effective and productive is much more about deepening skills and knowledge than about building habits.
Single-tasking helps deepen skills and knowledge because it stimulates the hippocampus, which is part of the brain that puts information in long-term memory. Task switching hurts this because it stimulates the basal ganglia, which is the part of the brain that is good at building habits.
In software development, you simply get better at what you do faster when you single task.
What to do then?
It’s impossible to entirely eliminate task switching – emergencies will arise, questions will need to be answered. And I do believe in the power of collaboration to deliver better software. But it’s a good investment to minimize task switching as much as you can.
If you’re in management, make singletasking a value. Demonstrate it by removing obstacles so people can focus on one thing for long periods:
Can you have “do not disturb” periods or let people work from home when they need to complete a critical task?
Can you give people private offices?
Can you schedule meetings that involve your team members so they don’t interrupt work as much, such as first thing in the morning, just before lunch, or at the end of the day?
Can you organize your teams so that you have people dedicated to handling customer emergencies (in a prioritized way, so they can focus on one at a time) and people dedicated to building new product?
If you’re not in management, you can still do a lot to clear your decks so you can concentrate:
Adjust your work schedule so that you arrive earlier or stay later than most others. (My normal work hours have been 7:30 to 4:30 for more than 20 years. The first 60-90 minutes of the day are my most productive because few others are in the office.)
Stop responding to e-mail as it arrives; instead, set aside specific times when you read and respond to it.
Work out a do-not-disturb convention with your team. In one group I worked with, we placed a little blue flag on our desk when we needed to go heads down.
Ask if you can work from home when you really need to concentrate.
At least put on your headphones, which many people interpret as a sign that you don’t want to be disturbed.
And of course, when your boss pulls you in too many directions, be sure to ask him or her to help you prioritize your work so you can focus on one thing at a time, or to assign work across your team in ways that balances the load. Multitasking alone doesn’t usually lead to burnout, but it absolutely brings you there faster when you have too much on your plate.
Jim Grey 