Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Most Important Piece of Advice I've Ever Gotten

DZone's Guide to

The Most Important Piece of Advice I've Ever Gotten

All good things must come to an end. Fortunately, so must all bad things. Read on for advice on how one programmer dealt with his business relationship's demise.

· Agile Zone ·
Free Resource

10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile

In May 2010, I had been at BioWare for about 2 years, and was ready to quit. Actually, I had quit. My Art Director at the time set up a meeting between myself and Gordon Walton, a the General Manager for BioWare Austin. Despite being at BioWare for 2 years, I had never spoken to Gordon (do you see why I was ready to leave?). Someone told me Gordon likes to hear suggestions and not people whining, so I made sure I came with complaints and solutions.

I really loved Austin, I loved the people I worked with, and I didn't want to leave. But work had become such a struggle, such an unhealthy environment for me, that things needed to change or I needed to go. The necessary change wouldn't even be so difficult! I wrote down pages of notes and even rehearsed a bit in the mirror. I had good ideas and I wanted Gordon to listen. At worst, he would listen and disagree. At best, he would put me to work fixing some of the very fixable problems.

So the day came. I showed up at Gordon's office. His office was always on the interior; I was told it was because he doesn't want to seem 'better' than other employees with a windowed view in a corner office, though it could be that he disliked sunlight. I sat down. We made some chitchat about my situation, and then he asked me what my problems were. I went on for a few minutes. He listened. When I was done, Gordon gave me some advice that to this day continues to be the most important of my career.

Well, Robert, you're not compatible here and you don't have a future here. You are a valuable team member and we want you to finish the game, but after that, you need to either find a place that fits your culture or start your own. Don't bother burning yourself out over something that isn't yours, that you can't change anyway.

Hearing that from the Studio General Manager was...profound. The importance of the advice dawned on me after the meeting, the rest of which I barely remember. The Truth I heard from Gordon was absolutely liberating. And, in hindsight, obvious. I thought I'd be happy if I fixed the problems with the studio, so I made that my mission. That was a mistake. My mission should have been to find professional happiness.

Gordon's advice changed the course of my career. Though some folks advised me against it, I fought to join the Tools Programming Team, since I knew would give me "street cred" as a programmer and help my career. This led to some of my darkest times professionally, hating the codebase and hating the project managers.

I knew I was whipped. The war was lost. Even winnable battles weren't worth fighting. But that was ok! I knew what I was in it for: my time as a "real programmer" would open up new opportunities. And it worked! I took a much better job at CCP, and eventually followed Gordon's advice towards the end of my time there.

Ok, the preceding was written 6 years ago. Having lived Gordon's advice at multiple companies over 7 years, I'm ready to augment it with some advice of my own: how to be most effective and productive when you find yourself fighting a losing battle, but you feel obligated or unable to give up, usually for financial or career reasons.

First, it's essential to accept that you're beat. If your bosses, in words or actions, disagree with you on how to run the company or team, you have lost.

Second, you should realize that your underlying goal has always been to improve the lot of your coworkers. All of the policies you are pushing for have this mission behind them.

Third, understand that policies without genuine executive support are worthless. There are usually individuals who are going to be the primary obstacle to the changes you've been pushing for. If they remain, any policy changes are worthless. A corollary to this is that you should not expect the makeup of management to change.

This may paint a depressing picture, but in my personal and observed experience it's accurate for folks that are chained to a toxic environment. This situation doesn't mean you roll over. It does mean you need to change tactics.

You must accept root causes. Accept that things will get worse. What you have right now is as good as it's going to get for everyone struggling. If your company's culture is going to have a bright future, it's not one you're a part of. The future will be a different group of people with a different group of priors and antecedents.

Instead of worrying about causes or implementing policies for the future, focus on treating symptoms. It is the only way you and the people you're fighting for will get anything worthwhile out of the experience. I'll give some suggestions I've used myself, and counseled others on:

  • Fix problems bugging the most underserved employees. This is a great way to make a positive impact and earn the long-term appreciation of your coworkers. Prioritize what your coworkers think is a problem over what the business tells you is important.
  • If you see a struggling junior employee, ask to be a mentor. It will give you good leadership experience, and give them a better chance to succeed in the short term.
  • If the senior employee on a team leaves, advocate for hiring a more junior replacement. A senior employee is likely to come in and rewrite a bunch of stuff. The mid-level employees can instead grow to learn and evolve the work the senior employee was doing, mentor the more junior employee, and are likely to take a lot more away from the experience.
  • Sharpen your team's technical skills. Carve out some "professional development" time for doing weekly code katas. It is valuable training for a team, and happens to be very similar to a technical job interview.
  • Support and advocate for each other to work on the stuff you want to work on, rather than what management may want you to work on. But do spare a thought for future programmers and please don't introduce a bunch of new technologies.
  • Avoid getting pulled into anything that doesn't help your experience or resume. Most employers are only going to be able to evaluate your technical skills, and get a sense for your other contributions. They probably don't want to hear about the drama you got pulled into.
  • Do not shame or be ashamed. Understand that others may be having a worse time than you, and do not invalidate their experiences or try to convince them they should be feeling different. Likewise, don't tolerate someone doing this for you. Complaining about things that suck that you have been forbidden to change is not a waste of time. It's a logical result of a company's decision to effectively forbid you from changing things that suck.

The most important thing I'd keep in mind during all of this is: You are not the reason you are in this situation. This is also the reason I adamantly believe there is nothing dishonest about any of the above behavior. Your employer made their choices. There is nothing you can do, in good faith or bad, to meaningfully change anything at this point. Your employer has decided to ignore a whole host of problems because it's convenient. They have not sacrificed for you. You are not required to abandon your integrity and ideals for them. Understand the inevitable nature of your relationship at this point. They are getting the most out of you they can before you're discarded, and you should do likewise.

I hope that helps someone who needs it.

Also published on Medium.

Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.

Topics:
agile ,advice ,job satisfaction ,professional development ,corporate culture

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}