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.
A career is a winding road, and nobody issues you a map.
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, or if you just don’t want to be a part of those changes, 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, be promoted to some level in your company, or move into a different kind of role. 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 elsewhere.
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 in a role where I could meet expectations with very little stress. 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.
Since I last posted here, I had a major life milestone: I turned 50.
I wrote a personal reflection about it on my other blog, but in short, being 50 is a pretty good gig. This stage of life offers its challenges, to be sure, but they come with the maturity to handle them.
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.
Because I’m in management I get to be tech-stack agnostic in ways that working engineers, testers, and technicians don’t. Especially as an engineer, it can be challenging to move to, say, a Ruby on Rails shop after having worked for years as a JavaScript developer.
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.
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.
Jim Grey 