Categories
Managing People

Too soon to declare victory on distributed work

By Jim Grey (about)

It’s a foregone conclusion that my company will keep us working from home through the end of the year. There’s no compelling reason to go back. We are delivering as well now as we did before mid-March, when the office closed. But more importantly, no amount of office safety precautions can eliminate our risk of the virus.

A group of voices in our industry has said for years that we would all be more productive and have a superior work-life balance if we all worked from home. Now that we’re all working from home and it’s basically working, they are crowing victory.

Office

I say, not so fast. We’ve been at this only four months, not long enough yet to be sure. Let’s see how we feel in mid-November when it’s been another four months. Given the virus’s resurgence, it doesn’t seem far fetched that this could last even longer than that. Let’s see how we feel at the one year mark, four months later in March.

A software engineer on my team said to me recently, “I really miss everybody. I wish I could get a group together to go to lunch, like we did every day in the office.” I miss that, too. I used to bring my lunch, but anytime I wanted lunchtime camaraderie I knew I’d find some group of engineers going out, and I’d be welcome to join them. Many of those engineers are on projects I’m not involved with and I haven’t seen them in months.

He said he especially missed the in-person dynamic of our seven-person team: “I know I see you and the other engineers on the team on Zoom in our daily check-in meeting and in our regular tech discussions, but I miss our energy in the office. I feel isolated here.” Then he asked, “Do you think it would be possible to get us together, maybe for lunch at some restaurant outside? If people want more distance than that, maybe we could all bring our lunch to a big park?”

I checked in with the rest of the team and they were all enthusiastic about getting together, as long as we keep physical distance. We’ve laid in plans to spend some time together this Thursday, outside, at a place where we can stay spread out.

I also manage the managers of three other teams. Our four teams work toward common corporate goals, but we’re set up so that each team has its own backlog of work. It’s efficient. But part of what makes it work is that in the office we all sit in in adjacent groups of desks. This is deliberate. It lets us see each other all the time so we can stay in frequent contact.

It’s been harder since we started working from home. We’ve done our best to stay in touch, but haven’t found a replacement yet for the random, organic, quick check-ins we were used to. I’ve noticed an undercurrent of tension growing among the managers. Recently, there have been a couple spots of friction among them.

We needed to talk things through. My gut told me we’d be better off meeting in person rather than over Zoom. I asked the managers if they’d be comfortable meeting in a park with masks and good distancing. After they thought it over for a while they agreed — the benefit outweighed the (mitigated) risk. We met Thursday afternoon. We talked through the challenges we’re facing and came up with some collaborative and creative ways to stay aligned, both with each other and with some key peers we work with. All of the managers told me that it was good to be able to see each other in person, and to read body language as we interacted. They wished we could do it more often.

The distributed tech companies will all tell you that meeting in person from time to time is essential. But they tend to do it in big annual or semi-annual whole-company gatherings.

Also, these companies either built a distributed culture from the start (such as Automattic, which makes WordPress, the software that runs this blog) or shifted to a distributed workforce a long time ago and evolved their culture to fit it.

Companies like mine — most tech companies finding themselves with a COVID-driven at-home workforce — have not completed that evolution, if they’re even trying. We are used to the dynamics of working together in person.

Several people I work with closely tell me they’re perfectly happy and could keep this up forever. But the rest of us are still figuring out how to adapt. I can think of a couple people on my teams who might never fully adapt. They might need an office environment to work best.

I don’t look for my teams to meet in person regularly. We are all best off limiting our exposure to people we don’t live with. But during these summer months we can meet in person if we need to. There are plenty of wide-open spaces in our city parks, for example. But what happens when the warm-weather months end? This is Indiana, after all. It’s cold in the winter, and we get a lot of snow. For those of us who feel isolated now, just wait until winter takes away all of our reasonably safe options to connect in person.

All tech companies need to keep intentionally evolving toward more effective ways of working while distributed. I think it’s a long journey, one that is unlikely to be accomplished in the short term. I wish us all luck during the long winter.

Originally posted on my personal blog here.

Categories
Managing People

I’m so over performance reviews

By Jim Grey (about)

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.

Bump

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.

Categories
Career

Three things I wish someone had told me when I started my career

By Jim Grey (about)

It’s summer, and the college interns have arrived in software-development shops everywhere. Here’s a story I wrote for my personal blog a couple years ago about some advice I gave a young intern who worked for me.

offtowork1988
Me in 1988, almost 21 years old, leaving for my summer job. (Those were my heavy metal years.)

I felt like a fish out of water when I got my first career job. I’d had jobs before, the kind anybody could do — ushering at a theater, working the counter at a Dairy Queen, driving for a courier service, that sort of thing. But my new job as a technical writer for a software company involved a specialized skill, it created real value for the company, and it had a future. It felt like the big time, the real thing — and it sent my anxiety off the charts. I didn’t know how to behave!

This summer I hired an intern to test my company’s software product. This bright engineering student from Purdue started a couple of weeks ago, and was he ever nervous. He had a hard time looking anybody in the eye and when he spoke, his voice always trailed off. His body language was shouting, “What the heck am I doing here? I have no idea what I’m doing!” So I took him aside and gave him some advice — three key tips I figured out on my own over the years, but that I wish someone had told me back when.

Act like you belong here. Have you seen the film Catch Me If You Can, based on the true story of master forger Frank Abagnale? In it, he forged and faked his way into jobs as an airline pilot, a chief resident pediatrician in a hospital, and as an attorney. He was not trained for these jobs, but he skated by because he behaved confidently, as if he had earned his right to be there just like his colleagues who actually did. Stop short of breaking the law, of course – but anywhere you go, take this one play from Abagnale’s book. And you have an advantage over Abagnale: We know you legitimately have what it takes to do the job. You made the cut, and we want you here. Stand confidently on that.

Know who to call. I turned 22 shortly after starting that first career job and someone threw a small party in the office. When I revealed my age, all the middle-aged guys just shook their heads and wouldn’t say a word. I’ve been through that a few times now that I’m their age — they realized that they had been working longer than I’d been alive. It makes a man feel old. But that age does bring some wisdom, and those guys showed me the ropes. Lots of people helped me get better at what I do over the years, and I still reach out to some of them for advice. Everybody knows you don’t know anything, so relax and ask all the dumb questions you want. Even after you leave here, don’t lose track of the people who were the most helpful. They might stay helpful to you — and it will surprise you one day when you find yourself able to help them.

If nobody is leading, you do it. There is no shortage of people who will simply wait to be told what to do. If you want to distinguish yourself, be someone who figures out what to do and does it. Don’t be afraid to do that when working directly with others, either; it’s startling how often people in a group will stare at each other hoping someone else will take the lead. But be sure to ask what your team’s and your company’s goals are, and make choices that help achieve them. You are bound to make some wrong decisions, but you will learn and grow from them.

The fellow seems to have taken my words to heart; at least he seems a lot less uncomfortable around the office.

What advice do you wish someone had given you at the beginning of your career?

Categories
Career

Twenty-five years in the software salt mines

By Jim Grey (about)

Tomorrow it will have been 25 years since I started my career in the software industry.

It might seem odd that I remember the day only until you know that I started work on Monday, July 3, 1989, making my second day a paid holiday. The office was nearly deserted on my first day. My boss regretted not having me start on July 5 so he could have had an extra-long weekend too.

I was 21 years old when I joined that little software company in Terre Haute. I’m 46 now. I have worked more than half my life in and around the software industry.

taught myself how to write computer programs when I was 15. When I was 16, my math teacher saw some of my programs and praised my work. He encouraged me to pursue software development as a career. He began to tell me about this tough engineering school in Terre Haute.

I graduated from that tough engineering school hoping to find work as a programmer. Jobs were hard to come by that year, so when a software company wanted to hire me as a technical writer I was thrilled just to work. And then it turned out I had a real knack for explaining software to people. I did it for twelve years, including a brief stint in technology publishing and five years managing writers.

I then returned to my technical roots, testing software and managing software testers. I learned to write automated functional and performance tests – code that tests code – and it has taken me places in my career that I could never have imagined.

Office
My office at one of my career stops

I’ve worked for eight companies in 25 years. The longest I’ve stayed anywhere is five years. I left one company in which I was a poor fit after just 14 months. I’ve moved on voluntarily seven times, was laid off once, and was fired and un-fired once (which is quite a story; read it here). Changing jobs this often isn’t unusual in this industry and has given me rich experience I couldn’t have gained by staying with one company all this time.

I’ve worked on software that managed telephone networks, helped media buyers place advertising, helped manufacturers manage their business, run Medicare call centers, helped small banks make more money, enabled very large companies to more effectively market their products, and gave various medical verticals insight so they can improve their operations and their business.

Some of these companies were private and others were public; so far, I’ve liked private companies better. Some of them made lots of money, some of them had good and bad years, and one of them folded. Some of them were well run and others had cheats and liars at the helm. Some were very difficult places to work, but those were crucibles in which I learned the most. Others have brought successes beyond anything I could have hoped for a quarter century ago.

I did, however, hope for a good, long run in this industry, and I got it. But I’m also having a hard time envisioning another 25 years. It’s not just because I’d be 71 then. I really like to work, and – right now at least – I plan to do so for as long as I am able. But I’m starting to have trouble imagining what mountains I might yet climb in this career. Maybe that’s part of reaching middle age – indeed, many of my similarly aged colleagues, some with careers far beyond mine, have gone into other lines of work. I’m still having a lot of fun making software, though. I currently manage six software testers, one test-automation and performance-test developer, and one technical writer. I get to bring all of my experience to bear, and encourage my teams to reach and grow. I don’t want to stop just yet.


If this sounds familiar, it’s because it’s an update of an eariler post. Cross-posted to my personal blog, Down the Road.

Categories
Project Management

The power of continuous reestimation

By Jim Grey (about)

Not long ago a software developer I work with suggested that building software could not, and so should not, be managed to a delivery date. “You can’t know everything you’re going to encounter while you build it,” he said, “and so it just takes the time it takes to get it done.”

I said that I agreed: you don’t know what you don’t know, and the work takes the time it takes. But I couldn’t agree that projects should be open-ended, finishing when they finish.

Capitalism interferes. Pesky, pesky capitalism.

Most of us make software that achieves some corporate goal about making piles of money. Because the company has plans for that money, it needs to know when it will start rolling in. The money can’t start rolling in until you ship.

Or maybe you’re making a prototype that will be demoed at a trade show in hopes of attracting investors, or you’re fixing a batch of bugs that have angered a key customer who is threatening to walk, or you have to deliver some fixes to comply with some new regulation that’s about to go into effect. Point is, your company has good reasons to ask when you’ll ship.

So you need to set expectations about the size and duration of your work. But fortunately, these guesses don’t have to lock you in and enslave you to your keyboard. That’s because every day you can check your progress, adjust for the things you’ve learned, and see if you need to set new expectations.

You’re driving to a destination

Getting your work done is a lot like taking a road trip. I love road trips! You never know what you’re going to encounter. Road construction, bad weather, mechanical failure, and even fun roadside attractions can all slow you down. You have to steer your way through all of these things.

The road to Madison

When you’re on the road, it’s pretty easy to know at any time about when you’ll get where you’re going. It involves answering these three questions:

  • How will you know when you get where you’re going? On the road, you just recognize your destination. But I’m going to fit this metaphor to your work, where it isn’t always as clear what it means to arrive.
  • How far do you have left to go? Watch the signs; they’ll tell you.
  • How fast are you going? Just check your speedometer.

Every time you see a sign, divide the number of miles to go by your average speed, and you have the best case for how long it will take to arrive. You can’t control what might go wrong on the road ahead, of course. But after something on the road does slow you down, you can just recalculate and get a new arrival time.

You can manage your own work in much the same way. But it means you have to build some skill at estimating.

“Uh, two weeks”

Here’s how not to estimate. My first post-college job was as a technical writer in a software company. My first assignment was to convert a thick product manual from an old publishing platform to a new one. It was hardly a mission-critical project, but I was green.

When the boss asked when I’d be done, I had no idea, so I shrugged and said, “Uh, two weeks.” Then the task turned out to be enormous and tedious. I had to put in a ton of extra time to finish in two weeks.

When my boss asked “how long” on my next assignment, I guessed a number – and then doubled it to account for the unknown. Success! I worked no extra time and finished my project before the deadline.

Except that I hadn’t learned anything of value. My “guess” estimating technique became “guess and pad like crazy.” And I still had the problem that if I didn’t pad enough, my only recourse was to work tons of extra hours. I had no way of knowing on any given day whether I was on track to finish when I said I would. I just had to work hard and hope.

It’s okay that you don’t know what you don’t know

If I could tell my 21-year-old self something, it would be this: Ask the boss if you can get back to him in two days. Then use your two days to do this:

  • Think about what done looks like. What must you do to finish the work? How will you know when you’ve gotten through it all? In this case, I had about the easiest possible situation: “Done” meant running out of pages to convert. You may have a number of requirements to code, or a batch of test charters to execute, or a set of stories to complete – there are any number of ways to chunk the work.
  • Do some of the work. Pay attention to how many chunks you complete in your two days. Then note how many chunks you have left. There’s your speedometer and your miles-to-go sign. Divide to get your rate: chunks per hour or chunks per day.
  • Calculate how long the rest of the work will take. Divide your rate into the number of remaining chunks. Lay that number out on a calendar to find your finish date. Tell that to the boss.

And then as you work, recalculate every day based on how much you got done that day. If you need to put in a few extra hours to stay on track, just do it. But when the amount of extra effort needed to stay on track starts to edge toward heroic, it’s time to negotiate.

That’s right, negotiate. You are the master of your own work, after all; nobody knows the reality of it better than you. Your estimate is what you believe it takes to reach Done, and you need to stand up for it. This is true, by the way, even when your boss has given you a due date.

So go to the boss and ask which is more important: the due date or this body of work? In other words, can you change what it means to be done, removing enough work to hit the date? Or can you move the date out to get all the work done? Or can you do a little of both?

Sometimes the answer to this question doesn’t go far enough to make the remaining work match the due date. So ask yourself if you can give some of the work to someone else, enough to hit the due date. If so, ask for people to help you.

What you’re doing is giving the boss and all of your project’s stakeholders as much runway as possible to understand the probability that you’ll deliver the originally defined Done on time. Should that probability drop, your negotiations give them the opportunity to change course, change expectations, or both.

Sometimes, you’ll get no answers to all of these questions. Sometimes, you’ll get yes answers to some or all of them and it still won’t be enough. But asking these questions is your best chance of avoiding working heroic hours.

An estimate should not be a commitment

If no is always the answer, or your bosses just expect you to rise heroically to every occasion, or your initial estimate is interpreted as a contract or an iron-clad promise, you just might be an in environment with dysfunctional beliefs about accountability. Consider finding another place to work.

Your estimate is only your best (and, hopefully, educated) view into when you will finish. It assumes that you don’t know what you don’t know. When you learn more, your estimate is obviously going to change. You’re better off working someplace that has at least an elementary understanding of this.

And now you understand it. Estimate based on what you do know. Go ahead and pad a little (a little!) for the unknown.

But then steer your work to successful completion.

I thank my brother, Rick Grey, who tests software for his supper, for contributing several key concepts to this post.

Categories
Managing People Quality

Four critical tips for getting your ideas implemented at work

By Jim Grey (about)

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.

My corporate mug shot from those days - yes, long hair and a beard
My corporate mug shot from those days – the Grizzly Adams years

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!

Categories
Career Managing People Teambuilding

I believe in “A teams” over “A players”

By Jim Grey (about)

I’ve heard it again and again at work. “We need to hire a real A player for this job, a total rock star.”

crayolaqa
A test team I once belonged to, dressed as crayons for Halloween. I’m the gray crayon, natch. Our colorful dunce caps do not mean we weren’t A players!

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.