Today I begin my 29th year in the software industry. Actually, today’s a day off where I work. But it wasn’t at the company where I began my career, also on Monday, July 3. It’s why I remember the date: my second day was a paid holiday!
In 28 years I’ve worked for nine different software shops, small and large, serving many different industries and kinds of customers.
What surprises me is how little correlation there was to how good my co-workers were and success of the companies. I worked with some brilliant and visionary people at companies that struggled, and with some average people at companies that did well.
Does that surprise you? As I look back, it certainly surprises me.
Here’s what did correlate to the successful companies in my career:
A product vision and company direction that did not change wildly, but did evolve to meet the evolving market
An executive team in unity on that vision and direction
Good communication to everyone about that vision and direction
Reasonable planning to execute that vision and direction
Good execution in engineering and in sales
A work environment where people felt safe and valued
Transparency into company financials
Notice how none of the adjectives I used above are superlatives? No excellents or flawlesses or bests or outstandings. Everywhere I’ve worked, when people are aligned to a vision and direction, “good” and “reasonable” have been enough.
These things give brilliant engineers and visionary product people a solid platform to do pioneering work. But even the best people haven’t been able to overcome the lack of these things.
Where I live and work, it’s difficult to find experienced developers and testers. Demand outpaces supply. So one strategy I’ve been using to grow my testing team is to hire people who have never tested.
Obviously, that means they need to be taught how to test. It so happens I like doing that! But this means I have to be able to identify non-traditional candidates who are apt to be good students.
I look to my company’s customer-service team for candidates, as those people know the software and understand the customer. But that’s not enough; I need to know whether they can be taught to test.
Fortunately, I’ve figured out four key traits someone needs to be able to learn to test and to enjoy it. The new tester must have a knack for troubleshooting, which means they are curious and persistent, can create mental models of the system they’re examining, and can develop and investigate theories of why things are broken.
Be curious: A tester needs to notice when something is wrong and feel compelled to investigate. “Wait, what? Why did the software do that? I’d better dig in and find out.”
Be persistent: But sometimes the investigations take a while. A tester needs to keep feeling compelled, even when the investigation stretches on. (Bonus points if they recognize when they’ve reached a point of diminishing returns, and choose a different avenue of exploration.)
Create mental models: Building a mental model of a system, even if it’s incomplete or partially inaccurate, helps a tester orient themselves to a problem and generate ideas on how to work through it.
Develop a theory of error: Thinking about how the current problem is creating or exposing a flaw in the system informs the steps taken to prove or disprove the theory — and isolate bugs.
A person who’s not curious won’t troubleshoot. A person who’s not persistent won’t keep going when the troubleshooting gets rough. Troubleshooting doesn’t get very far if you can’t see how the thing you’re troubleshooting is a system and imagine reasons why it’s not working.
So when I interview testers, I ask this question, which gets at all of these things:
Think of a time you had a problem with software or electronic equipment when you tried to solve the problem. It might have been trouble with your home network, some difficulty upgrading your PC or your phone to a new OS, a misbehaving printer, or anything that went wrong with technology you use. Tell me how you assessed the problem and tried to figure out what was wrong, and what steps you took to try to fix the problem.
I ask candidates to tell me two or three stories in answer to this question. Many people can come up with one story, but someone who enjoys, or at least doesn’t mind, getting to the bottom of technology problems will have more than one story.
I’m discouraged when I hear these things in answers:
Trying nothing beyond obvious troubleshooting steps, such as rebooting
Giving up after a couple steps: “I tried a couple things and then just called support”
Trying things randomly in hopes one of them works
Fear of trying things because they might break things worse
I’m excited when I hear these things in answers:
Developing a theory of how the system works, including applying knowledge from other systems — “I wonder if this thing I’m trying to figure out is like that other thing I know very well”
Some logical, systematic method for exploring the problem, generally starting from the simplest, most probable causes and moving stepwise through successively less likely and more complicated possible causes
Research, usually via Internet search but also by asking someone who might know
Evidence that they learned something about how the system worked, and felt some satisfaction in that
It’s fine if the candidate didn’t successfully resolve the problem. What I’m listening for is whether they systematically eliminate possibilities and move toward finding root cause.
Good answers can be mundane. One candidate told me about sitting down one night to watch Netflix, but his movie kept failing to stream. He was used to experiencing a little of that on Friday and Saturday night; he knew Netflix drew a lot of Internet traffic on those nights. But because it was a weeknight he wondered whether the problem might be within his home. He knew that rebooting the Roku usually solved connectivity problems, but it didn’t work this time. So he went over to his AT&T Uverse modem to check out its blinking lights. “I don’t know much about those lights,” he said, “but I do know that if most of them aren’t blinking, especially the INTERNET light, there’s a problem.” Sure enough, the INTERNET light was out. So he tried rebooting the modem, but the INTERNET light wouldn’t come back on. He found his modem’s manual, but it didn’t cover the situation. He tried a couple Google searches for this condition, but found no useful information. Out of ideas, he called AT&T, which reported intermittent outages in his area.
The candidate’s answer showed that he created a mental model of how Netflix and the Internet work and tried the most likely causes first. I especially liked that he confidently used his incomplete technical knowledge to narrow down the problem. And I didn’t mind it a bit that he ended up calling for help — he’d first done all he reasonably could.
The rest of my interview questions look to gauge technical experience and fit for the company and the team. It’s pretty standard stuff. But without good answers to the troubleshooting question, the candidate goes no further.
So look for these four traits. They give you trainable team members.
Thanks to Rick Grey for his valuable feedback that helped shape this post.
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.
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?
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.
I had lunch recently with a fellow I worked for several years ago. He gave me my last job as a technical writer and my first job as a software tester. He’s currently leading product development at a different software company. “Times have changed,” he said. “I don’t have any technical writers anymore. These days, I want the UX to be good enough that documentation isn’t needed.”
A few days later I had a drink with another former boss. I managed testers and technical writers while I worked for him. Since then, he’s started his own consulting company. “Technical writing is dying off,” he said. “It’s all about clean, engaging UX now. I have talked to more than a hundred startup and small software companies as I’ve built my business. Almost none of them have technical writers, and almost all of them have UX designers.”
Smart tech writers see the writing on the wall.
It’s clear: companies are leaning into good user-interface design and stepping away from online Help systems and printed/PDF documentation.
It’s a relief. Nobody wants to have to read something to learn how to use a software product. When usage falls right to hand, users are happier and more likely to use the product more. Good UX really can reduce the documentation burden.
My last company had mighty good UI design. One technical writer worked for me, and she kept up with about ten developers. In past companies with lesser UIs, I needed one writer for every four or five developers. It took more words to explain those products’ cumbersome usage.
Admittedly, the latent technical writer in me wants to holler, “Users need instructions for even the best designed products!” Some interactions are incredibly hard to design well enough to forego usage instructions. And users will always need usage reminders for seldom-executed tasks.
But the writing is on the wall. If you’re not finding fewer technical writing job openings yet, you will soon. Fortunately, your skills transfer to other jobs in software development organizations. You will need to build some new skills for many of these jobs, but you might be able to land that first new job without them and build them as you work.
Tester or quality assurance engineer
Testers explore software systems looking for bugs. In some shops, they write and execute detailed test cases; in others, they explore based on high-level test charters. The goal is to report, usually by writing bug reports, on the level of quality the developers have delivered so that decisions can be made about when to ship.
Technical writers routinely find product bugs. At my last company, my lone writer routinely found really important bugs. The VP of Engineering even noticed: “She finds outstanding bugs,” he said. “It must be because she thinks like a user.”
When I shifted into testing 15 years ago, I designed my tests in much the same way I designed online help: by first asking what tasks users would perform in the system. Then I set about making sure those tasks worked. You can do this too. You’ll have plenty more to learn about testing, but this is a great place to start.
Existing skills you will use: Creating and articulating mental models of software systems. Exploring software to discover how it works. A basic understanding of how software is built and delivered. Writing.
But build these skills: Database skills, especially writing queries. Light coding or scripting, to help you automate tests. System administration, to help you better understand and manipulate the environments the software lives in. (Don’t be daunted. I’ve seen many writers surprise themselves when they quickly start to learn these things. It’s as if they soaked up technical abilities by osmosis, just by being around lots of people who have them.)
Product owner, product manager, or business analyst
All of these jobs involve understanding customer needs and translating them into user stories, specifications, or requirements that the developers and testers use to build software. They may involve building a vision for what a product needs to be to meet its market’s needs. These people usually work closely with developers and testers to make sure the vision is realized, and to resolve implementation challenges.
Existing skills you will use: Understanding of customer needs. Creating and articulating mental models of software systems (though, in this case, often systems that have not been built yet). Writing. A basic understanding of how software is built and delivered.
But build these skills: Negotiation, as you might need to manage expectations of customers, the development team, and sometimes even management. Estimation and project management, as you might have to participate in sizing work and projecting delivery dates.
Various UX roles
The UX field includes a number of jobs that, together, create the way the software works and feels for the user. Typical titles include UX Designer, Information Architect, Visual Designer, Interaction Designer, and Content Specialist. These roles involve work such as creating wireframes of screens, designing user workflows, performing usability testing of prototypes, interviewing users and sometimes even shadowing them as they work, writing field labels and error messages, and choosing typography.
This might seem like a real stretch for a technical writer. But my experience is that writers often have innate insight into bad UX: if it’s hard to write about, then it’s hard to use. I find that technical writers can often extemporaneously evaluate product usability and give very useful ideas on how to improve UX.
Existing skills you will use: Interviewing. Understanding of customer needs. Creating and articulating mental models of software systems. Writing.
But build these skills: This depends heavily on the role, but: Design, in general. Graphic design. Usability testing. Prototyping.
These jobs crackle with career growth. But if you’d rather stay true to writing, you can shift into marketing communications, instructional design, or even good old-fashioned business writing (policies and procedures, disaster recovery plans, and the like). My town’s biggest employer is a pharmaceutical manufacturer; lots of software writers here have shifted into validation writing, which is an FDA compliance activity. You might even be able to move into writing technology articles and books; I’ve done a little of that. And some software technical writing jobs will likely always remain in regulated industries, and on government contracts, and for highly technical products.
Nostalgia for my former technical-writing career makes this a sad passage for me. But I think this trend toward effective UX is better for the user, and gives writers good paths for growth.
I had lunch with a favorite colleague recently, someone I worked with several years ago and think the world of. She’s among the best at what she does, and is fun and warm and genuine while she does it. I’d work with her again in a heartbeat.
She moved here from elsewhere to take her current job, and finds herself wishing to be better connected in our city’s software industry. So she has been talking to everybody she knows to find out who the movers and shakers are, and try to get introductions to them.
She met angel investors – not this kind.
She ran through the litany of people she has met and wanted to meet, a dozen names or more. We were both astonished that I had worked at some point with all but one of them, most of them as they were on their way up to enormous success. It made me realize I may have let something valuable slip through my fingers.
I told her funny stories about some of these people. One fellow owned a software company where I was a first-level manager. He was a veteran bathroom talker — you’d be standing there draining the tank and he’d come up next to you and start a conversation. And it wasn’t always small talk. You could end up making important business decisions right there at the urinals. Men everywhere know that this breaks the Guy Bathroom Code: no eye contact and absolutely no talking. In, out, move on. But not this CEO.
He sold his company and started a venture capital firm. Through his investments sits on the board of pretty much every growing software company in town. I hadn’t seen him in four or five years when he spotted me in a restaurant last year and came over to say hello. And my colleague said he was hard to meet because he’s so sought after.
I’ve worked with scores of people in my 25-year career, but keep up with just a handful. If I used to work with you and sometimes meet you for lunch, you’re not just a colleague, but a friend.
But lunch with this friend and colleague made me realize that I am very well connected — and I’ve let those connections languish. It’s a shame not only because these people might help me into a better gig someday, but primarily because they’re interesting people who do big things.
When I worked with many of them, there was no way to know that they would do so well. Most people I’ve worked with have not risen so far, actually; most of them are still writing code, or testing, or writing documentation, or leading teams. But so many of them are interesting, too.
But I’m an introvert of working-class roots — a fellow who prefers to keep to himself and let his work speak for itself. At least that’s what I tell myself so I don’t feel so bad about not reaching out to the good people I know. But if I could go back to the beginning of my career and give myself one piece of advice, it would be to not lose contact with the people I enjoyed or admired.
Fortunately, even though a quarter century has slipped by, it’s not too late to start now. I can reach out to people I’ve worked with recently, and rekindle some long-ago connections. I’d like to build a habit of keeping in touch. Maybe I’ll be able to help someone along in their career, or maybe someone will help me along in mine. If not, simply catching up and swapping stories will be ample reward.
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 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.
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.
I’ve heard it again and again at work. “We need to hire a real A player for this job, a total rock star.”
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.
Jim Grey 