In a recent blog post, Johanna Rothman wrote about paying it forward in our careers and in life. (Read it here.) Through paying it forward, she says, we offer people lucky breaks. When others pay it forward, sometimes we get the lucky breaks.
I add this: sometimes when you pay it forward, it goes full circle and creates lucky breaks for you. Here’s a story of a time that happened for me.
In my first management role, more than 20 years ago, I got to build a small team from the ground up. I wrote that story here — that team and the work we did remain one of the brightest memories of my career.
I wanted to build the kind of team I’d want to work in — one of transparency and autonomy, where we could do very good work yet go home to our families at a good hour each night.
I hired Mary Ellen first. She lacked the technical skills I was looking for, but was otherwise qualified — and whip smart and deeply resourceful. So I took a gamble and hired her.
She was a home run hire. She picked up every needed technical skill quickly. Her work was nuanced and of impeccable quality. She even helped define team processes that let us run more efficiently and effectively. We couldn’t have done it without her.
The team was quite sad after a few years when I was promoted to a different role and was no longer their manager. It was a great compliment when they told me that our time together had been the best at-work experience of their careers.
That company didn’t make it through the dot-com bust and we all went our separate ways. I wasn’t very good at keeping up with my network then and lost touch with Mary Ellen. Seven years later, I got an email from her. “There’s a leadership role open where I work now, and it looks perfect for you. If you’re interested, I’ll put in a good word with the VP, because I’d love to work with you again.”
I was ready for a change so I interviewed, and I got the job. It was a fabulous role for me and I was very successful in it. The company itself was successful enough that the founders took an exit. I was a late enough hire that my cashed-in stock options didn’t change my life. But the founders and all the VPs ended up being movers and shakers in the startup scene in my area. Those contacts have helped me immeasurably as I’ve continued my career, offering coaching, introductions, and even job offers.
The moral of the story is to treat well the people who work for you! Treat everybody well. You never know when it will come full circle.
I’ll never forget the revelation it was when I figured out how to write computer programs. You mean, I thought, I can make this machine do what I want it to?
It was a watershed moment in my life.
I was a teen then, shy and introverted. People often frightened me, at least a little. I struggled to interact with people I didn’t know well, and to assert myself with people I did know well.
And then here was this machine that I could order around. It had limits, but within those limits, it was all about what my mind could imagine and then code. I wrote games that my dad and my brother played. I wrote programs that illustrated concepts of geometry, which I demonstrated to math classes in school. I wrote a payroll application for my aunt’s small business. I even wrote a very rudimentary operating system once – it was terrible, but I learned a lot.
So I went off to college to learn more about how to make software. When I graduated the job market was terrible, so I took the only software job I could find, which was writing user guides for a software company. Later in my career I moved into testing, and into management. I’ve delivered a lot of software since I started 29 years ago.
Here’s the crazy thing I’ve learned: The hardest thing about making software is not the technical stuff. The hardest thing is getting people aligned and pointing the same way!
I’ve often said that it’s a modern miracle when a software project succeeds. Any software development project that involves more than about two people will have coordination challenges, differences of opinion, and all the other normal issues of working together. My experience has been that the programmers and the testers can do whatever you need them to, short of, say, developing a telepathic user interface. They will work hard at it and they may struggle to get it right. But those struggles can pale in comparison to how hard it is to get everyone to agree on what to build, how to build it, and what it means to be done. Here’s how code is better than people:
Once coded, code stays coded and reliably does the same thing over and over.
You think you have people all organized and then they go off and do whatever they want anyway.
You will sometimes struggle and work hard to make your code do what it needs to, but you can almost always get the job done.
Sometimes you simply can’t influence people. Drat their free will.
Change your code, it doesn’t mind. It knows no fear.
People hate change! When change is thrust upon them, they often resist it or even run away, screaming.
By the way, the WordPress editor doesn’t offer a way to create tables, so I wrote some quick HTML to generate one. Fear my mad, l33t sk1llz.
Unfortunately, even if you have the best coders in the world, if you can’t get them to work together their projects will fail. Fortunately, I understand geeks, for I am one. I know what makes us tick. I’ve learned how to influence us and get us all reasonably pointing the same way. And I’ve built on these skills to learn how to influence non-geeks such as upper management, salespeople, and customer service folks to get them all working together. It’s not easy, and it’s impossible to ever get it perfect, but I’ve had pretty good success over the years and it’s contributed strongly to any number of successful software releases. And it’s helped me come out of my nerdly introverted shell.
I can’t remember the time I last wrote any serious code. I don’t miss it. To my astonishment, I’m having much more fun and success on the people side now.
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.
After eight years writing and editing software documentation, I itched to make software again, like I did in college. So I took a job with a software company as a tester.
The company made a sprawling product for an industry I knew nothing about, so I had lots to learn. Given my background, the first thing I did was reach for the manuals. They were incomplete, inaccurate, and poorly organized. There was online help, but it was unnavigable. Nobody was ever going to use the documentation to successfully learn the product. My boss managed the technical writers too, so I marched into his office to complain. I wasn’t delicate about it. “This stuff is terrible! I can’t believe you ship this to customers! It’s an embarrassment.”
He leaned back in his chair and calmly said, “What would you do to fix it?”
“I would throw it out and start over,” I began. And then over the next ten minutes, off the top of my head I outlined a project that would create new manuals and online help that would actually help users not just use the product, but get the best value from it.
Three days later, he called me back into his office. “Remember that thing you said you’d do with the documentation? You are now manager of the Documentation Department. Make it so.”
It was a bold move for him to take a gamble on me. I’d never managed people, and my project management experience was limited. What I didn’t know was that every year the company surveyed its users about product quality – and every year the documentation got the most complaints. My boss had been told to fix this problem, but had no idea how. Then I walked in with a solution that sounded like it just might work.
Most of this story is just the nuts and bolts of the project – hiring and coaching staff, creating plans and schedules, doing visual and information design for the new manuals and online help, managing the project, reporting to management, and even doing some of the writing myself. The details would be interesting only to another technical writer. Much of this was new to me, but I had excellent support from a boss who needed to see his gamble pay off. He also helped me navigate the inevitable office politics, including another manager who kept trying to torpedo my efforts. Also, the program manager helped me master the project management tools we used, none of which I had ever even seen before. My team and I worked on the project for a year and a half. It’s not often a technical writing team gets an opportunity to do a clean-sheet rewrite like this, and they were all enthusiastic about it. I worked hard to clear their roadblocks, respond quickly to their concerns, and generally be a good guy to work for, and it paid off in the excellent work they delivered. When we were done, we had written over 3,000 pages and had created a seven-megabyte context-sensitive online help system.
I was invited to demonstrate the new online help at the annual user conference. 600 people flew in from all over the United States, and there I was before them on the opening session’s main stage. My presentation was the last of a series about new features in the product. When I finished, to my astonishment the online help received enthusiastic applause – and then one person stood, and a few more, and several more, and soon the whole room was standing and applauding. That moment remains the pinnacle of my career; I can’t imagine anything else ever overtaking it. The icing on the cake was when I overheard the VP of Sales say to my boss, “All the blankety-blank new features we pushed you to put into the product, and everybody liked the blankety-blank online help the best! The online help! You’ve got to be blankety-blank kidding me!”
I used to think I was just a grunt paid to trade the words I wrote for a paycheck. Through this project I learned just how interdependent everyone is at a company, and how everybody is important. Specifically, I learned:
If you want to see your great ideas implemented, they need to solve a big problem the company thinks it has. The problems your company thinks it has may very well be different from the problems your company actually has. Frame your ideas in terms of solving the problems the company thinks it has.
When you’re doing something you’ve never done before, find people who can coach you through it. I don’t care how far down the ladder you are at your company, your success helps determine other peoples’. Look for someone who both knows how to do the thing you need to learn and whose success depends in part on yours – that last bit motivates them to help you. In my case, it was my boss and the program manager.
Work for people who clear roadblocks out of your way so you can be most effective. I now leave situations where the boss doesn’t help me in this way. It’s that critical.
Your success always depends on other people, so treat them well. In giving my team an exciting assignment and creating an environment in which they could focus, they happily turned out huge quantities of good work. Also, after we shipped the new documentation, I promoted every writer. They deserved it.
A footnote: That company went through tough times a few years later and so we all moved on, some for better positions and others (like me) because they couldn’t afford to pay us anymore. One of the writers who had worked for me called me one day seven years later, by which time I really had moved into software testing. She said, “We have an opening here for a test manager. I’d love to work with you again, and this is a good place to work. You really should apply.” I did, and I got the job. I found out later that just before my interview, she went to the VP and said, “He’s a great boss. You don’t want to let him get away.”
Sometimes the good things you do come back to you!
“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
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.
I’ve heard it again and again at work. “We need to hire a real A player for this job, a total rock star.”
This statement usually comes at a time some critical task or function isn’t being done well (or at all) and it’s causing projects to fail. “If we can just bring in a super-skilled specialist,” the thinking goes, “it would solve all of our problems!”
Sometimes this gets stretched into a one-size-fits-all approach to hiring. “Let’s hire only A players,” someone proclaims, “and then get out of their way and let them perform.”
No doubt about it: A players are extremely talented and deeply experienced. They are heavily self-motivated and especially hardworking. They are creative problem solvers who focus on getting the job done.
But don’t assume that putting A players on the job is like sprinkling magic fairy dust that makes problems go away. That’s setting them up to fail – and setting your company up to fail, too. Companies are much better served building high-performing teams.
A players are no substitute for leadership. The most important step in that leadership is to help your people form solid teams.I’ve been in software-company leadership roles for more than 15 years now. I’ve delivered many, many successful software projects with teams made mostly of B players. But those successes came after company leadership:
Created a shared, common vision that everybody rallied around and focused on
Built a process framework within which team members worked, which set standards for workflow, quality, and completion
Praised and rewarded team members for jobs well done
Hired for fit within the company culture, as well as for skill
A players are hard to find. A reason why I often hire B players is because most people aren’t A players. I’d say less than one in ten people I’ve ever worked with are that good. I make software in Indianapolis, which we sometimes call the Silicon Cornfield. Many of the truly outstanding geeks move to California, North Carolina, or Texas, where the opportunities are greater. But even in those places, there are only so many A players to go around. Sooner or later you have to hire B players too. Those B players will work best under strong leadership and in highly functioning teams.
A players often have the biggest egos. A little swagger is part of the A-player territory. If you don’t lead well and help them gel into a team, conflicting egos will put your projects at risk.
A long time ago I followed rec.music, a once-popular Internet forum about music. In a recurring discussion thread, members wrote about which musicians they’d put in the best supergroup ever. The debate raged – Eric Clapton on guitar, and Neil Peart on the drums, and Paul McCartney on bass, … no no, Phil Collins on drums and Jeff Beck on guitar! …no! It must be John Paul Jones on bass!
It was fun to fantasize about such things. But do you really think a band with some of the biggest egos in music would gel? I’m reminded of We Are the World, the 1985 charity song recorded by a supergroup of pretty much every popular musician of the time. The famous story goes that someone taped a sign that read, “Check Your Egos At the Door” on the recording-studio entrance – but that didn’t stop arguments over many of the recording’s details, with at least one musician walking out and not returning.
Don’t let that be your team.
Still, A players can be mighty useful. There are times when it’s right to hire A players. Here are the times when I’ve settled for no less than an A player:
Lead roles – I needed someone to figure out some thorny problems, and to set the pace and point the way for the team.
Lone wolves – I needed someone for a highly specialized job where I was unlikely to need more people in that role for a long time, especially a role where I lacked the skills to do it myself and therefore would have a hard time managing its details.
Really, I’ve never not hired an A player just because he or she was an A player. Who wouldn’t want their skill and determination on the team? I’ve only passed on A players when they would be a poor cultural fit in my company and in my team.