Author: Jim Grey

Writer. Photographer. Leader of geeks.

Categories
Career

Communication: Throwing the ball so others can catch it

By Jim Grey (about)

“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.

Handley, WV
Handley, West Virginia, pop. 350 — where my dad’s family is from

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.

Categories
Project Management

The Donald Rumsfeld School of Agile Software Delivery

By Jim Grey (about)

I often quip that when you plan and manage a sprint, as a leader you have to channel your inner Donald Rumsfeld.

You remember ol’ Don, don’t you? He was twice the Secretary of Defense in the United States, first in the Gerald Ford administration and later in the George W. Bush administration.

Rumsfeld is famous for having said, “There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns; the ones we don’t know we don’t know.” Here, listen:

He said this in answer to a reporter’s question about a lack of evidence linking Iraq’s government with supplying weapons of mass destruction to terrorists. It sounded so absurd at the time that the media had a field day ridiculing him.

But over the years, we’ve come to realize how much sense his statement makes. In anything you set out to do, you know what you know, you might know or be able to guess some things that you don’t know, and you certainly don’t know many things that you don’t know.

In agile software delivery — heck, in life:

  • You plan for the known knowns.
  • You make contingency plans for the known unknowns.
  • When unknown unknowns happen, all you can do is manage through them.

On a team I once managed, we wanted to build a feature to email end users the day after they abandoned a transaction on our site. We hoped to reengage them to finish their transaction.

We wrote and groomed the stories. Most of them had a clear implementation — plenty of known knowns. They were easy to estimate.

A few stories had known unknowns. One was, “It’s been a while since we’ve been in that repo, and it was written in our wild-west days. I might find some cruft in there that I’d need to straighten out to be able to finish this story.”

Another known unknown was, “I’d have to do a deep dive into that module to be sure, but if does this certain thing in this certain way, I’d have to do considerable extra work to stitch in the code I need to write there.”

In each case we discussed whether that work, were it necessary, would add meaningful complexity to the story and inflate its estimate. Sometimes it was yes, sometimes it was no. When it was yes, sometimes we wrote a dive story to find out and other times we thought the impact would be small enough that we could just accept the risk.

As we planned sprints with those stories, we believed we had accounted for everything we could think of, and were confident in our sprint plans. But two things went wrong we didn’t foresee — unknown unknowns bit us hard.

One story involved writing a job that would check overnight for abandoned transactions. The engineer who picked up that story encountered five or six serious unexpected difficulties with writing the job and with getting the job runner to pick it up properly. A story that we thought he would wrap up in two days spilled well into the next sprint.

Then it turned out that our email service was never built to handle the volume we threw at it, and it failed immediately in Production. One engineer devoted all of his time, and another part of his time, to solving the problem. A lot of our tester’s time went to troubleshooting with the engineers. The situation was surprisingly thorny. The engineers implemented several successive fixes over several days before finally getting past the problem.

Thanks to these unknown unknowns, we missed a couple sprint plans by a mile. Here’s how we managed through them: I worked with the team to prioritize stories and figure out which ones we were likely not to deliver. The engineers watched for stories ready to be tested, and helped our tester by picking some of them up themselves to keep the revised plan on track. Finally, I reset expectations with my management about what we could actually deliver, and how that would affect delivery of other work that depended on it.

You could argue that these should not have been unknown unknowns. Writing a job should have been cut and dried. We should have thought about volume in our planning, and tested for it.

Hindsight is always 20/20. Retrospectives are where you explore that hindsight and make improvements for the future. After you experience unknown unknowns, improvements generally take two forms:

They become known knowns, or maybe known unknowns. We learned a lot about the complexities of jobs in our world. We knew we needed to write a few more in upcoming sprints, so we broke them down into several smaller stories that we could test incrementally. Also, we now expected that there might be challenges in writing jobs we hadn’t encountered yet, and to lay in contingency plans for them.

You can lay in plans to neutralize them as unknowns in the future. We found out that other teams had been having trouble with the job runner. We met with the team that owned that code to figure out how to make the job runner more reliable. They put tech-debt stories in their backlog to handle it. We also researched how we might make the email service more robust and investigated third-party email services. We ended up going with a third-party service.

Categories
Career

Sometimes you have the tiger by the tail, and sometimes the tiger has you in its mouth

By Jim Grey (about)

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.

Thinking about what you'd taste like

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.

Categories
Project Management

Your cloudy crystal ball

By Jim Grey (about)

Your crystal ball is cloudy, but you can sort of predict the future. As long as the future isn’t too far away.

In other words, if you take it in small chunks you usually know enough about the work before you to guess reasonably accurately how long it is going to take.

Mr. Blue Sky

Back in the old waterfall days, we’d plan months and months of work at a time. The printed project schedules could be 100 feet long. The trouble was, work more than a small number of days away often depended on work that had not yet happened. We needed to know how that work turned out before we could be sure of the work that would follow, and have a good idea how long it would take.

From a straight-up project-management perspective, this is why agile is brilliant. It lets us break big projects down into small chunks of usually two weeks in duration, where ideally we have to give our best estimates only for this short period. This respects that we don’t know what we don’t know about the work that follows.

You might still need to estimate how long an entire feature will take to build. Some companies need some idea when the feature will deliver. But it has to be a projection, not a promise, because your crystal ball is too cloudy.

The current sprint’s estimate matters most. When you plan a sprint, fill it with just the work you are confident you can finish. You want to deliver all of the work in the sprint, barring unforeseen technical complexities, critical customer-reported bugs, team-member illness, or late reviews.

Then check your gut: do you think your team can really deliver all of those stories? If not, please say so, and discuss why. When you leave sprint planning, everyone on the team needs to agree, based on what you know then, that this body of work seems doable in two weeks.

Categories
The Business of Software

Failing to automate routine tasks is a waste of human potential

By Jim Grey (about)

I enjoy the Signal v. Noise blog from Basecamp. Recently they published a post about the human touch in customer service. Read it here. Its thesis, in short: automating any part of support is akin to saying the company doesn’t care.

I am charmed by the work ethos Signal v. Noise espouses: work at a sustainable pace on things that are interesting to you, and get plenty of rest. It’s very appealing. But sometimes I think they take the contrarian position as if it’s their brand, and this is one of those times.

There’s nothing wrong with a good robot providing routine customer service. As long as the experience is good, and can seamlessly hand off to a human when things go off script, it’s a win.

That’s because so much of customer service work can be rote and repetitive. One of my career stops was at a company called MOBI, which provided mobile-device management services to large companies. One customer was a global manufacturer that had something like 10,000 mobile phones deployed to its executives. MOBI helped them manage cost by keeping each phone on the least-expensive plan for its typical usage, and also provided a help desk with the promise of answering a request in 30 seconds and staying on the case until it was solved. (Try getting that from your carrier.)

But it was too expensive for MOBI to hire a bunch of new customer-service reps every time they took on a new customer. It cut the profit margin too thin.

Mechanical Man
Not this kind of robot

Moreover, a large percentage of the customer-service work was simply boring and repetitive. After you’ve done a handful of password resets, equipment orders, and plan changes, you can do them in your sleep.

MOBI has devised a number of robots (“Mobots,” they call them) to take away the drudgery.

If a MOBI customer user jumps on a chat, Mobot Audrey answers. She can handle many of the common, repetitive tasks. The minute the customer asks something she can’t handle, she seamlessly transfers the chat to a human, who handles the case from there.

I had lunch a few weeks ago with MOBI’s CTO, my former boss, who told me that the customer-service team was apprehensive at first, but is happy now because they are working on things that tap into their deep knowledge of the product, and that require them to solve problems creatively. As a result, they are more engaged with their work.

This resonates with me from another perspective. I was on the team that built the call-center software that Medicare customer-service reps use nationwide. I led the test team. Our contract required us to do a “full” regression test on every release — meaning we had to run thousands of written test cases. It took almost 24 person-weeks to execute those tests! This was about 15 years ago when automation tools weren’t great. But I hired a couple engineers to automate those tests anyway, and they finished after a few months. It took just 0.6 person-weeks to execute those tests forever after. My functional testers were free to spend more time performing  targeted, complex, and exploratory tests, using their experience to find critical defects the automation couldn’t find. It was much more interesting and meaningful work for them.

But back to customer-service robots: we all remember how bad the early ones were. That Medicare customer-service center had an early voice-response robot for callers, and it was awful. It didn’t understand callers right most of the time, it took a long time to navigate, and once navigated the caller found that the robot couldn’t help them and they needed to speak to a human anyway. Callers hated it.

But the technologies have begun to mature. Some of them claim to be able to learn, even, although I’m skeptical that it’s true, full-on AI or ML. At least it’s possible to create a good experience now. MOBI’s Mobots have done it; their user testing bears it out: most users have no idea that they are interacting with a Mobot.

So why wouldn’t a company like MOBI manage support costs and increase employee happiness by automating away the boring, repetitive tasks? I’m for it.

Categories
Managing People

The manager infodeck: Quickly helping new teams and new employees get to know you

By Jim Grey (about)

A new manager arrives on the scene. Or a new employee joins the company. What kind of person is the manager? What will he or she expect? 

It takes time for any manager and employee to build a trusting working relationship. But you can jump-start the trust by sharing your basic philosophies and rules of engagement in a slide deck.

The title slide from my manager infodeck.

This deck quickly lays out the things you care most about: what you believe about management and about the kind of work your teams do, what makes you crabby, and how you operate day to day.

It’s also an opportunity for you to tell your story in thumbnail. It humanizes you and helps you be more approachable.

It also lets you lay out nuts-and-bolts expectations such as how much notice you want of vacations.

I’ve used my manager infodeck for a few years now to good effect. If you’re curious, you can see it here. You can even use it as a starting point for yours.

Categories
Quality The Business of Software

Love your salespeople because they make your paychecks not bounce

By Jim Grey (about)

He was a salesman at the company where I had gone to work after graduating from engineering school. And he routinely made my life, and the lives of the other engineers with which I worked, crazy difficult as he made wild promises during the sales cycle that we then had to fulfill in our product on impossible deadlines.

It was the classic tension between sales and engineering. There should have been a class on it when I was in school. I might have called it “Sales Douchebaggery 101” but perhaps the topic would better have been wrapped into a larger course on life as a working engineer. Cost constraints out the wazoo. Adding features to a product under pressure without doing necessary redesign of existing features so they scale and perform. Being bogged down by the avalanche of customer support that follows releasing the resultant buggy product. And all the while, salespeople promising crazy stuff to prospects to get them to sign on the line. Sales happily wrote checks, if you will, that engineers then had to figure out how to cash.

This particular salesman was the king of signing us up to build stuff on impossible deadlines. He seemed to take special glee at doing it. Cynically, we all grumbled to each other that it was about making his commission check as fat as possible. One of the engineers delivered this classic line: “He’s in sales. That means he’s coin operated.” I’ve gotten a lot of mileage out of that one.

LincolnMarkA

And then one day he showed up at work in a brand new Lincoln Mark VIII. It was a stunning car in a pearly white. Lincoln called it “white opalescent,” and it was impossibly deep, almost liquid. I expected that if I touched the car, my fingers would ooze into the body and come back wet. It was mesmerizing.

Yet I was angry and jealous. Here was this guy blithely, happily making engineer lives miserable while piling up a crap ton of dough. I wasn’t going to make that kind of money anytime soon; no new Lincolns were in my future. But this wasn’t really about financial injustice. No, this was about him never suffering any consequences of his actions while living a lifestyle that reinforced his bad behavior. Such bullshit.

That was in the early 1990s. Since then I’ve worked for many other companies, successful and not, and have learned a few key things about sales. First and foremost: celebrate every sale, because they keep your paychecks from bouncing. I’ve lived through that and never want to again.

But second, that company had a lot to learn about product marketing and sales. The sales team was left to fend entirely for itself, with only a vaguely identified target market, no coherent story to tell about the product line, and nothing that generated qualified leads for them to pursue. They earned every closed deal from the ground up: cold calls, relationship building, and then doing what they had to do — including making stuff up — to get a yes so they could meet their quotas. It had to be brutal for them. So no wonder this guy was so giddy every time he closed a sale. He worked his butt off for it.

And third, and most importantly, back then I was content to grumble and that didn’t help my company at all. Learning how to estimate, negotiate scope, determine minimum viable product, set and manage expectations, and manage projects has been much more effective for me and for the places where I’ve worked. It’s helped sales teams know that Engineering is in their corner helping them succeed — and helped them better understand what Engineering is capable of delivering so they make fewer bad promises.

LincolnMarkB

Today I don’t sweat that fellow his Lincoln. Seeing this one in a restaurant parking lot recently in sort of sad condition reminded me of him. I looked him up on LinkedIn. He’s still selling in that industry, for a company we all derided then as being the last place you’d want to work. Looks like his career had a similar trajectory to this Lincoln: still going, but not looking all that great. Fortunately, I’ve grown up enough to have empathy for him.

I regularly take photos of old parked cars and write about them for Curbside Classic, a site that tells these old cars’ stories. This post is heavily based on a post I wrote there a couple years ago; read it here.

Categories
Career

Moving on is a simple thing; what it leaves behind is hard

By Jim Grey (about)

In my last post I shared how to recognize when it’s time to find a new job. But I don’t mean for you to rush into it. In every job, you’ll go through rough patches that might clear if you work for it, or even just wait.

But how long to wait?

Time has come today

Counting the cost of moving on

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.

Categories
Career

Knowing when to leave may be the hardest thing that anyone can learn

By Jim Grey (about)

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.

Indiana State Road 45
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.

Categories
Career Managing People Teambuilding

The good you put into the world often comes back to you

By Jim Grey (about)

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.

Heslar Naval Armory, IndianapolisI 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.