I hired a software developer right out of college. He had a lot to learn, but he learned it steadily. Yet he admitted to me privately that he wasn’t sure he belonged. He thought that the other developers spoke so confidently and delivered so competently. He compared himself to them and, in his mind, came up wanting.
What he didn’t know was that I was leading developers for the first time. I’d been in management roles in the industry for a very long time, but always of testing and communications teams.
Worse, I hadn’t written a meaningful line of code in about a decade. Even then, most of that code was test automation. That’s not the same as writing product code.
Yet here I was, leading developers. The CTO who hired me wanted my skill in managing people, leading projects, and refining process. But I had so much to learn about modern software development. It was embarrassing to need the developers to explain the basics to me.
I told this young developer this story and admitted that I felt like an impostor, too. But I’d experienced impostor syndrome before. I knew that with effort and time I’d learn what I needed to learn and the feeling would abate. More importantly, even with all I needed to learn, I knew I had something valuable to offer right now. He did too, I told him.
We all figure it out as we go. In time, we build experience that lets us get it right more often.
What I wish I’d told him, what I’ve learned since then, is that there are three kinds of impostors. There are the impostors who don’t know they’re impostors. They’re so self-possessed that they overestimate themselves. There are the impostors who know it but do everything they can to hide it. They live in fear and anxiety that they will be found out. And then there are the impostors who know it, admit it to themselves, and sometimes even admit it to others. They’re the ones who can grow the fastest.
This young developer was the best kind: he admitted it. It let me tell him my own story, which helped put his mind at ease. Then it let us talk frankly about the areas where he felt like he didn’t know what he was doing, so I could pair him with other engineers who could level him up faster.
“You are unusually direct,” Elsa said to me. She was one of the first people I hired in my first management role, in the late 1990s. She said this to me on a few occasions as we worked on a large project together. I took it as a compliment then, but with hindsight I see that Elsa found my forthrightness to be challenging.
I say half-jokingly that I was this direct because I have hillbilly and blue-collar roots. My dad grew up in the hills of West Virginia. His family moved to Indiana to find factory and construction work. Dad worked in a farm-equipment factory while I grew up. In the culture I came from, anything less than saying it straight — no matter how much the words hurt — is seen as being untrustworthy.
I was proud of my direct manner. I believed that my forthrightness was good and valuable. It came from a place of wanting good outcomes for the company, customers, and my co-workers. I wasn’t trying to be a jerk, but that’s how I was sometimes perceived.
I’d been a manager for about 10 years when the fellow I worked for at the time said it to me: “Jim. You’ve got to stop leaving dead bodies behind when you talk. Learn some tact.” He told me he’d like to see me move up in the organization, but not while this behavior stood in my way.
That got my attention. I had been pitching fastballs at peoples’ foreheads. That boss coached me in throwing drifts that others can catch. I’ve practiced it ever since, and have built reasonable skill. It has unlocked all sorts of opportunity for me. It has helped me build influence and trust.
It took a long time for more nuanced communication to not feel wrong. It turns out I’m not among my hillbilly family, and I’m not working a blue-collar job. I’m working with midwestern professionals, and the rules are different.
I revert to my natural form when I’m anxious, over-stressed, or very tired. Those are not my finest moments.
But there are times when speaking directly is valuable. Emergencies are one such time. A couple companies ago I ran QA. Production went down while all of the ops managers were at a conference. I was ranking manager, so I dove in and, using my natural directness, led the team to quickly find root cause and get Production back up again. One engineer praised me: “You came outta nowhere and crisply and efficiently drove the train back onto the track. I’ve never seen this side of you!”
Another time is when I think I see something critical that nobody else does, and nuanced communication is not getting the ball across the plate. A flat statement can grab attention and change the conversation. It can also blow up in my face, so it’s a calculated risk. I’m hoping it works because it seems so out of character. “Whoa, Jim is really strident about this one. He’s usually so collegial. Maybe we should listen a little more closely.”
Finally, sometimes you have to say a flat “no” to a challenging request. I try very hard to find a way to say yes while highlighting the tradeoffs I or my team will have to make. “Could you deliver this feature two weeks earlier?” “Yes, if I pause work on this other feature.” Or, “Yes, if we trim scope and accept greater quality risk.” Or, “Yes, if we can flow some of the work through this other team.” But if scope, quality, and team are fixed and don’t support the timeline, I’m left to say no, and I do so plainly.
I will always wish I could be direct all the time. It’s how I’m made. But I care more about being effective than leaning into my basic nature.
This post expands on a comment I left on another post on this subject, on Johanna Rothman’s blog, here.
Lots of people in our industry have accomplished much, made a lot of money, and even achieved status or fame. It seems like lots, anyway. It’s probably a small but highly visible percentage. Whichever it is, it’s easy to wonder in this industry of plenty why that can’t be us.
When I remove the incredibly successful from the picture, it’s easy to see that I’ve done well for myself. I’m a middle manager of software engineers making a product you’ve probably heard of, in an engaged and positive workplace. We all make an upper-middle-class living.
Yet I sometimes wonder why I’ve made it only this far, why I’ve not gone farther. And I wonder whether I’ll be able to sustain my career as it enters its waning years.
You see, today marks 30 years that I’ve worked in the software industry. It boggles my mind that I’m only two-thirds of the way through my career — I still have 15 years to go before I’m of normal retirement age.
Fortunately this is all I’ve ever wanted to do, ever since I taught myself to write code in the early 1980s. I went to engineering school to get the credential I needed, but graduated during a recession when jobs were scarce. In a nationwide search I couldn’t find coding job. I managed to land job in the software industry writing manuals and online help, and I was grateful to get it.
I liked the work and became quite good at it, so I kept at it for eight years. Then I transitioned to QA, where I led functional testing, test-automation, and performance-testing teams. I did that for 17 years. And now I’ve transitioned back to my roots in a way by leading engineering teams.
I’ve lived through crazy growth and sudden downturns in the industry. Several times I’ve needed to find a job when one ended unexpectedly; several times I’ve been poached away to a better opportunity. I’ve worked with good people who have taken good care of me, and with charlatans and egomaniacs who stabbed me in the back.
Sometimes I’ve had the tiger by its tail, and sometimes the tiger’s had me in its mouth.
Dozens of people have reported to me since I shifted into management. It’s a small tech community where I live; I bump into many of them a lot. Some of them are still individual contributors, some of them have become managers and leaders, and a few of them have gone on to even greater careers than I’ve had, reaching VP levels or reaping tidy sums when their startups exited.
But I’ll bet every last one of them has had good luck and setbacks all along the way, just as I have. We all sometimes have to figure out how to move forward from here in our careers. We all have to figure out how to stay relevant and vital, especially as we age.
I’ve been in management for 20 years, during which time I focused on being the best leader I could be. It has served me well.
I couldn’t both become a strong leader and keep my technical skills current. I struggle a little bit to swim as fast as my peer engineering leaders, most of whom have written code recently. I can see it’s time to rebuild my technical skills. I don’t expect, and I won’t try, to become the equivalent of a senior engineer. But to have a solid understanding of the technologies involved in my company’s product, to better evaluate the code of someone on my team and maybe even to be able to fix a bug, to be able to write a SQL query more complicated than SELECT * FROM table_name; — it’s time. I’m a little daunted, but in I go nevertheless.
I’ve learned a lot in 30 years. In many ways, I’ve become wise. But I’m still trying to figure things out as my life and career unfold. I can see that this never ends.
When you leave a job, you leave behind the relationships and reputation you’ve built, and the mastery you’ve gained over the work. It’s hard to leave them behind, and it takes a lot of time to build them back in your new gig. Even when you’re positive it’s time to go, it’s hard to lose all of that. It might make you hedge your bets and stay.
It’s said that people don’t change until the pain of staying the same is greater than the pain of changing. I think it’s similar when you contemplate changing jobs: the difficulty of staying or the benefit of the new job needs to be greater than the challenge of rebuilding relationships and expertise.
Bad reasons to stay
You might also resist leaving because you feel you’d let your coworkers or customers down. But if you stay for that reason, you are taking on too much responsibility for the company’s functioning. It’s the company’s responsibility to make sure it can function if anybody exits. I’ve seen people at all levels move on, from associate engineer to CTO and even CEO. Every time, the company found a way forward.
Moreover, nobody expects you to work there forever. The day you were hired, your boss knew he would one day accept your resignation — unless he were to resign first. If you’re good at what you do, your boss will be wise to work to delay that day as long as possible. But it will eventually happen.
The 90-day countdown
Changing jobs is a big decision. Give yourself time to be sure it’s the right choice — whether you’re fed up and ready to ragequit, or hedging because you want to keep the good things you’ve built up.
I use a 90-day countdown a colleague shared with me long ago:
When you think it’s probably time to leave, set a 90-day counter in your head. Decrement the counter each day until one of two things happens: conditions improve or you see a good path forward, in which case you stop the countdown; or the counter goes to zero, in which case you update your resume, reach out to your network, and get out.
90 days — one calendar quarter — gives you enough time to avoid acting out of pure emotion so you can think it through clearly, and gives difficult circumstances a chance to change.
Thanks to this song for giving me a great post title.
I leave jobs. It’s what I do; in my career’s 29 years I’ve worked for ten companies. My longest tenure has been just over five years and my shortest was 14 months.
(To my boss, and to my team, who are almost certainly reading this: no, I’m not thinking of quitting!)
Usually I’ve moved on to gain new experience or a higher position. A few times I’ve quit because the situation had become untenable — once for a relentlessly crushing workload; another time because of a micromanaging and mean-spirited boss. Twice I’ve been laid off when a company fell on hard times.
During my father’s era, loyalty to an employer was lauded. But today, and especially in our industry, spending too much time at one employer can make your skills look stale. That makes it harder for you to land a next gig.
But when is the right time to go? It’s often hard to know, but it’s hardest in the first job you take after college. It’s easy to form an attachment to the employer and your experience there, and stay too long. I did that myself.
It is easier the second time you quit, and the third. Soon you get a good sense of when it’s time to go. Here’s what I’ve learned.
Sometimes a company pushes you out:
You struggle to get behind major changes. Companies regularly adjust course, sometimes dramatically. When it happens, can you get behind the new direction? If you don’t think the new strategies will work, or if you find some of them to rest in a moral gray area, make your concerns known. But if things don’t change, you should probably find a different company where you can be all in.
You are constantly frustrated with the way you have to work. If you’re comfortable in a high-process environment, low-process environments will feel too chaotic for you. If you enjoy high autonomy and low structure, you’ll feel strangled in a company with rigid hierarchy and lots of rules to follow. Or if you are highly competitive, an environment that values close collaboration and shared success will drive you nuts. Try to adapt to the environment, to grow through your limitations, and to influence change where you think things can be made better. But if you constantly have to be someone you’re not, find a company where you can be you.
The company seriously struggles financially. Every company goes through tough times, so don’t be quick to bail. But you should see your company making strong steps to bring good results back. Some companies aren’t transparent about their finances or strategies, so keep your eyes open. Look for new initiatives that gain traction. Watch your sales team — their growing happiness or deepening despair is a bellwether. But no matter what, persistently poor financial results will result in layoffs, or worse.
You don’t get along with the boss. Try hard to work things out first. Get some feedback from trusted colleagues about how you might be contributing to the difficulties, and fix those things. But sometimes you and your boss will just never be a good fit. And once in a while you will simply work for a truly awful boss. In both cases it’s time to go.
You see or sense moral rot in the company. I once worked for a company where the CEO was unable to not sexually harass his assistants. Finally one sued him; he got his entire executive team to lie about it in court and he got away with it. I worked for another company where the sales team would go to the annual user conference and spend their off hours, it was strongly rumored, drinking too much and sleeping with each other and with customers. It can be hard to separate hearsay from fact, and don’t spread rumors. But watch closely for signs of bad behavior, because moral rot will do your company in. It absolutely undermined the first company, and just the rumors in the second company seriously damaged the culture.
Sometimes your needs pull you out:
You aren’t growing in skills, pay, or title. Your career should progress. What that looks like depends on what motivates you. I like to get better and better at what I do, and if that’s not happening I get bored and leave. You might just want to make more and more money or rise to the top of the corporate ladder. Your growth might stall for a while in any job, but if it stalls for too long first ask trusted colleagues and managers what you might be doing to block your own growth, and fix those things. If that well is dry, perhaps you’ve gone as far as you can go and to grow you’ll need a new opportunity.
You need a job that won’t challenge you. This might sound strange. But if your personal life ever goes seriously sideways you might need to put career aspirations on hold for a while. In my mid 30s my first marriage ended in an awful mess. I ended up working in IT for a large insurance company, where the pace was slower and the work itself wasn’t that hard. I came home at night with the energy to focus on getting my life back together. Eventually my life restabilized and I wanted to grow in my career again, so I left.
You want to work for a company whose culture or product aligns with your values. Where I work now we build a product that aims to make the work life better for employees everywhere. We attract people who want to be a part of that mission. If you see another company with a mission that resonates with you, by all means, find a job there!
You want to work with more modern technologies. You might follow one tech stack through your career, or you might become a polymath and ride the cutting edge. If the latter appeals to you, get out when your company’s technologies become widely adopted, and find the next new thing.
You want to work for a company that is succeeding wildly. It might matter to you to be a part of the next big success story. If you sense another company is a rocket on the launch pad, and that excites you, what are you waiting for — get in over there!
In my next post, I’ll give some tips about how long to wait before you launch a job search, and how to manage your feelings about leaving.
Thanks to this song for giving me a great post title.
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.
Yet I’ve noticed that I’ve continued in my career that I work increasingly with people much younger than me. Today I lead a team of software engineers mostly in their 20s. I know of only one fellow on the team who’s older than 30. It was much the same in my previous job, and in the job before that.
I’ve long assumed that engineers my age all still worked in .NET shops. .NET was new, hip, and cool when I was in my early 30s. Where I live (central Indiana), companies adopted it readily and so most then-young engineers built their careers on it. I worked for several .NET shops in a row. Some of those companies still exist, and their products are still built on .NET.
So I searched LinkedIn for names of people I worked with years ago. Some of them are still writing code. A few of them are in some level of management. But the rest aren’t on LinkedIn or have left the industry.
I don’t know why. Do you? Especially if you’re older than 35: where have all the older engineers gone?
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.
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?