Consulting Chronicles #2: Fixing a Pile of Rubbish – Part 3

The following covers the balance between getting things done and playing politics.

Preface

I attempt to expose the harsh realities playing the politics game entails, as well as dodging it.  It may come off as disgusting in some parts.  I agree.  However, if you have strong character, good ethics, and are an honest person, you’ll be fine.  Whether you like it or not, in consulting you have to play some politics to ensure you’re actually allowed to code and do your job.  Think of it as a necessary evil, or a human game of chess; whatever works for you.

Introduction

My definition of Politics, one of the 5 P’s of consulting (Programming, Prowess, Politics, Positivity, and Patience), is basically anything not dealing with getting your job done via programming.  The only depreciating asset you have is politics; while great to have as a skill, the more you invest and spend, the less you actually get done.  Challenging balance, and I’d argue, the hardest thing about consulting (at least for me, I’m weakest in politics).

Consulting usually involves negative situations.  Your skills are why you are there, but not just your programming skills.  Specifically, you’re observation, communication, and mediation skills.  Anyone can code, but using good observation of the current situation, you can decide what’s best to code, and sell others and your team on the concept.  You may be the best coder for the job, and recognize what to code, but unless you can effectively communicate what you/your team is doing, and why it’s important, the “right thing to do” won’t happen.  Finally, mediation isn’t just about striking a balance between opposing factions in your client’s company; it’s about compromise.  Getting things done in programming is about compromise.  Getting things done in consulting through (and around) politics is what it’s ALL about.

Recognizing what to do, being able to sell it, and making everyone “happy enough” is how you get things done.  These are the 3 main effective skills you need to employ to navigate the politics of a company.  I’ve never really seen a common model that works in navigating client politics; I’ve just found those 3 skills can be broadly applied.  Sadly, while your original goal is to empower the client to succeed, sometimes the best you can do whilst navigating the politics is to barely get your own things done to ensure you don’t appear to be a leech.  In those situations, instead of viewing it as minimalist capitalism, view it as a learning experience.

Below, I’ll discuss what politics are (the broader definition of just company policies and procedures), why you play, when you don’t, and how to play the game.

Disambiguation of Politics

There are really 3 definitions of politics. We need to differentiate these first to set the stage for what we’re battling, and what game we’re really playing.  Specifically politics, political, and politic.  Politics is referring to someone/some group advancing their agenda via a devious way. Political is referring to pursuing that agenda in a self-serving way.  Politic is the only one that doesn’t have a government implication/bent.  It’s also more positive, implying someone who is intelligent in applying tact to situations to get them resolved, sometimes in a creative way.

When speaking of ” the company’s politics” in a negative context, it usually infers to all the drama surrounding a person, group, or child company in your client’s company that is vying to further their agenda; or multiple groups and their interactions.   When speaking about the “political situation”, it refers to the various ways those groups are resolving (or not) their differences, and hints at its ability to hinder progress.  Being politic towards those situations is what allows you to actually do your job.

Being Good at Politics vs. Good Enough

Being good enough at programming to be a consultant implies you like it, have a passion for it, and thus use that desire to get better.  Politics are the same way.  Those who shun it aren’t generally good at it, and aren’t the ones running for public office.  I’ve always loathed politics, and thus, this is why I’m not as good at it as programming.  I don’t get off on strategically thinking on how to place the interests of my group/organization within the current rules & regulations in such way to win.  I don’t like stepping on others to further my goals.  I don’t like saying one thing but doing another, and “knowing” that’s just “what you do”.  I don’t like chess.

As I gained more experience, I realized a few things.  First, you can play the game ethically, at least in business, but it’s hard.  Secondly, you don’t have to be a master at the game to get things done.  Third, as long as you recognize playing politics is a means to an end, and not an end of itself, you’re good to go.  Fourth, some organizations are so dysfunctional, that applying reason to the situation simply won’t work; you need persistence instead.  Fifth, don’t show weakness.  This means don’t be negative, don’t be cynical, and most of all, don’t lose control of your emotions.  Sixth, you can break the rules, get away with it, and people respect you because you got things done.  Other times, there is hell to pay for not playing politics.  Learning the when of both is key.

If you’ve done debate in high school/college, you’re good to go.

Why Play Politics?

You can either play the game or get played by it.  You can either deny the fact that the company requires 10 billion meetings before coding is approved, or accept it, and get the first of 10 billion done.  You play politics to get what you want.  What you want is usually something you need to get your job done.  It’s never as easy to go in and code (usually).  Hence, you don’t just go in and code; you go in and attempt to code in the company’s culture.  Sometimes that culture is not conducive to being productive, or perhaps it is, and you just haven’t figured it out yet. You’re the hired expert, and as such, know what needs to be done.  If you want to start checking in a company project to the company’s SVN, you have to get permission.  This requires asking permission, perhaps a meeting, a few emails, a justifying document, and maybe a follow up meeting.  All that just to do an SVN commit, I know.

When companies start out small, they don’t have policies and procedures.  They go on cross purposes, duplicate work, major balls get dropped, or large security holes come about.  That small and agile team comes at a price; lack of organization and little to no good operational procedures.  Policies and procedures are usually put in place to ensure everyone’s on the same page, no responsibility is shirked that could bring down the business, and people generally enjoy working at the company.  Emergency services have policies and procedures put in place to ensure they can save lives and not get sued after the fact.  Polices and procedures are important.

When they get large/numerous, they become “beuracracy” or red tape and start to significantly prevent productivity in some situations (or at least are perceived as such).  Wading through those policies amidst those who have their own agendas is how you guide your work on the right path.  If you don’t, someone will guide it for you, and possibly sabotage your efforts.  You were hired to guide the company in the right direction, not fix code on broken software.  …unless of course that’s all you were hired to do.  However, I challenge you to always leave a company in a better place than you found it.

You do that by engaging with them, positively.  Play their game by their rules to ensure their software gets back on track and is a success, WITHIN their culture.  No one is going to do it for you.   …unless of course you work for a firm who puts someone on site to handle this aspect for you.  I’ve worked for firms that do this, and no, I don’t mean I manager that shields you; I mean someone who basically deals with the politics so you can actually code.  That’s for pussies & amateurs, though.

How to Play?

Following Sun Tzu’s advice, you only fight a battle if you know you can win.  Since politics aren’t my forte like programming is, I need to ensure when I play (navigate/dodge), I win since my lack of passion for it puts my at a disadvantage.  Thus, I play to win.  I do this via the following ways in no particular order:

  • make friends
  • make good first impressions
  • respect the company
  • learn who has power
  • learn who makes who jump
  • respect others, even the jerks
  • identify problems, and sell tailored, already completed solutions
  • create a war room
  • do your research on the company
  • do your research on the players
  • do your research on your team
  • take people apart, find and press buttons
  • keep your friends close, keep your enemies closer
  • beware hollow allegiances
  • depend on yourself, not leaders
  • take calculated risks
  • get things done

That’s a large list.  Let’s break ’em down.

Make Friends

While I firmly believe you shouldn’t mix business and friends, you need to make friends at your client’s business.  You get more done with friends, and people who like you are more likely to follow you.  While one may only be able to lead a horse to water, yet not make him drink, one can lead others to out of their country to drink cyanide kool-aid.  You may have to make some very hard decisions, and if you have strong friendships, your allies will follow you no matter how strange, bold, or just plain crazy your path may be.

When at a client site, you should immediately befriend those you are working with, and those you are not.  This is one of the things I actually like about consulting a lot; meeting new people.  Of those people I meet, especially those I’m working with, I try to get on good terms, learn about them, and be their friends.  You may not like everyone you meet, but you should endeavor to be friendly, accept them for who they are, and come off as non-threatening.  If you’re an outside consultant, you’re an outsider.  You are NOT from the company, not perceived as on the same team, and an insult to the employee’s competence.  This usually isn’t true, but you need to assume this is how you’ll be perceived.  Forging sincere friendships helps nullify these negative perceptions & insecurities.

Having employee’s on your side helps you learn.  Your first order of business in any consulting gig is to listen.  You need to get the true story.  When you make friends, friends trust you, and you them.  With this trust often comes the “real” truth.  Alcohol helps here.  I’m serious, nothing loosens the tongue more, and gives you more insight to a company’s inner workings than alcohol.  If you’re dealing with someone who’s dry, even dinner or a lunch is a great place to put them in a more neutral setting where they will be at ease and more comfortable to talk openly.

You’ll also learn more context about relationships this way.  Learning about individuals is one thing, but learning the history and interactions between different individuals is better.  They can help you understand why the Development Manager is always extremely hostile towards others, why the Sales Rep you’re dealing with is always tired looking when talking to the PM, or why the Director always seems to disappear with your boss for hours at a time.  Learning about these relationships and interactions will prepare you for your own interactions.  They give you good recon, prepare you mentally for what to expect, and even give you insight into the individual who gave you the information once you match your interpreted reality with their perception.  If the sales rep isn’t tired, yet your new developer friend says he is, you’ll learn something new about your new cohort.  Is he projecting?  Does he have un-communicated expectations?  When you’re new cohort acts a certain way, you’ll know why.  Knowing your friends helps you predict how they’ll act in the future in certain situations.  This helps you strategically plan ahead.

Once you build respect, and gain power, you’ll start to become more direct.  You may state the truth, and that truth will often be uncomfortable.  It’s your job as a consultant to tell your client what’s really going on.  Even if they already know, they may have hired you to confirm what they already know as an outside opinion.  If someone is your friend, they accept you for who you are unconditionally.  Thus, if you make critical statements, and these statements may involve your new friend, they are less likely to take it personal.  It’s scientifically proven that if you make disapproving statements about someone, and later approving ones, they are more likely to like you vs. disapproving only, or approving only.  I’ve never found a good way to do this approach, however.  My point here is if you insult a stranger, they won’t like you, whereas if you make negative statements that may involve your friend, they’ll be more forgiving.

Finally, your goal shouldn’t be to make friends merely so you can insult them without retort and use them to get information.  Again, this is my favorite part about consulting; meeting new people and making new friends.  That said, this is war, and it’s easier to wage it with larger numbers than the enemy.  It’s also easier to ask for forgiveness than permission.  The casualties in this war are feelings and sometimes friendships.  It’s bloody, but it is what it is.

Make Good First Impressions

Pretty standard stuff here.  Your first 2 weeks (or more if you’re so inclined), you should dress for success, and have good hygiene.  If you are successful, you should look successful, and vice-versa.  If someone looks good, you are more likely to respect them as an authority.  If you go in there dressed all schlumpy, people are less likely to respect you and trust you.  You need to project you have your act together, and are professional.  Clothes make the man/woman.  Wear them, don’t let them wear you.  Carry gum/breath mints, and use them between interactions.  You want people to hate your truth and correct assessment of situations, not your breath.

First impressions will imprint on someone and affect their judgement of you going forward.  You only get one chance to make a first impression; make it count.

Respect The Company

We all make mistakes.  We’re human.  Bigger companies have bigger challenges managing their size.  It’s more challenging for them to think out of the box and be agile depending on their company culture.  Do not forget the mere fact they are big confirms they are (were) successful (depending on how you define success).  They are asking for your help, not your judgement.  There may be something, or a lot of things, you don’t particularly like about the company.  It doesn’t matter; you need to respect the company for who they are (unless they are Eolas or Monster Energy Drink; eff them).

If you respect the company, you thus respect the people who make it up.  If you don’t, you come across as arrogant & ignorant.  This doesn’t go very far in helping make friends and build trust.  If you appreciate what the company has done, you appreciate the work and effort the employees have put into it.  Some employee’s pour their heart and souls into companies, and your respect of that global effort goes a long way for them to respect you.  You also may miss out on learning opportunities.  Going into new companies and learning how they work, to me, is fascinating.  You get to see what makes them tick.  If you respect this, you may get opportunities not afforded to the common man, and be aptly rewarded.

Learn Who Has Power

Warning: This section comes off as quite dodgy; just keep the above points in mind with good ethics, and you’ll do fine.

Making friends is great.  If those friends can’t do anything to further your cause(s), asking them to do things for/with you isn’t going to help your political situation.  While those who are outgoing and smart may be great partners, they are worthless towards your goals if they can’t affect change.  You don’t necessarily have to be friends with those in power (obviously it helps), but if you want something done you need to be on good terms with them.

If you need your computer connected to the internet, ask the company’s IT department.  If they are slacking, get your boss on it, and clearly explain to him how you’re dead in the water, costing the company money while you’re unable to proceed.  If she/he doesn’t have the power, go above them.  This is often a very jerk move, but sometimes your boss/main point of client contact may not be able to move forward because they are just so busy, or just don’t have the pull.  Sometimes they do, but it’d be faster to get their bosses’ boss involved.  Great, get them involved, get shit done.  Be prepared for the backlash if you violate playing politics this way.  Sometimes, you can get away with it, or the slap on the wrist is forgotten in 2 weeks.

If you don’t like the design, find out who did it.  If the designer clearly explains they have better ideas that need to be implemented, find out who will help you get them implemented.  If the director of development can’t, then go find the director of user experience, and get them to approve the changes so you can move forward.  I once walked to 5 offices on 2 floors with a growing trail of employee’s till I found out who was in charge of something I needed fixed that was crucial to the project success.  Your goal here isn’t to identify who’s useless; rather, you’re identifying who can get what done, quickly assuming you can’t do it yourself.  If you don’t endeavor to push something through, either the ball will get dropped, it it just won’t happen for a long while.

Remember, those who claim they have power, and those who actually do are often different.  Learn who is responsible for what, who is actually perceived as responsible, and which individuals can help you get certain things done.

Also remember, you’re not an employee of the company.  While your boss may imply you’re at a certain rank, that means jack.  Your job is to get things done, and there comes a point where execution matters over procedure if you have any hope of actually succeeding.  The means in which you find those, and get them to do your bidding, is the most challenging part of consulting.  Some people you don’t want to know what you did.  You also don’t want to go above someone’s head unless you absolutely have to.  You can lose major points doing this; this isn’t playing politics.  Other times, you’ll get respect doing this because those below feel like they can’t say/do anything as employee’s.  You, on the other hand, have a free ticket.  You can’t get fired; you’re technically a contractor.  By verbally bashing your client, they’ll love you for it, yet fire someone of equal stature who is an employee.

A lot of times the above is just as benign as “following up all day”.  Instead of sending an email to IT and going about your day, you camp out at their desk until they “handle you”.  Instead of having a quick meeting with the designer & his manager, you start moving forward, forcing them to stop what they are doing and focus on what you need instead.  The point here is that you can force the hand of those in power by making you their priority.  Rather than you going to them, make them come to you.  A lot of times, these are valid political tactics; it’s just most people get so weighed down by the bureaucracy or 9 to 5 mentality, they don’t always have the wherewithal to follow through like you do.  Or perhaps they do, they just didn’t have the motivation until you came along to inspire them.

For the things you need done, find those who are capable of actually getting them done, and work with those individuals to bring those tasks to closure.  This may require a lot of hand-holding, repeating yourself, and persistence.  If you can’t do it on your own, find someone who can.

Finally, knowing who has power and who doesn’t helps you during negotiations and meetings.  Those who bluster about doing X, Y, and Z, you’ll know based on what power they have, and who likes/dislikes them, the actual chance they have in doing what they say.  This allows you to focus on what you really need to worry about vs. trying to guide others to your way of thinking who don’t matter.  If the server team claims they are going to change the entire back-end to be more stable, yet you know from your research that they’ve been saying that constantly for 4 months with no result, you’ll be confident in ignoring them, and proceeding with your existing plan to shore up your business/service tier in your app.  When they protest to this, you can bring up these facts, talk about the problems you’re solving now, make something up that is semi-truthful hoping they don’t call your bluff, or if you’re ballsy enough, challenge them on their record.  Don’t be afraid to call people out on their bullshit; if you’re made friends, and you know those in power will support you, you can feel free to ignore others who don’t produce anything of value whilst you move forward doing good.  If you’ve earned trust, you can move forward even when others try to hold you back.  Making enemies is really bad, though.  Only do this as a last resort; meaning the project won’t launch unless you do so.

Stand behind those who have bigger guns than you.

Learn Who Makes Who Jump

A lot of times, those in power are immoveable… or perhaps un-approachable.  Maybe you attempted to be their friend, but they’ll have none of it.  Perhaps you really are trying to help the project succeed and aren’t being a profiteer, but they are so angry you were hired to “fix their mistake”, regardless if that is an incorrect perception.  Yet, you NEED them to use their power to help you.

Everyone has a boss.  Everyone.  Sometimes, an employee won’t move until their boss’s boss dictates action.  Whatever it takes.  If you need someone to jump, find out who makes them jump.  Sometimes this is also done to ensure inaction.

Respect Others, Even the Jerks

Working with your co-workers on a project in a company is one thing.  Working with your client’s company and their employee’s is another.  Again, you’re often in really bad situations, hence you being there.  People will probably be pushed to their edges, and over.  Those who are typically nice, aren’t.  Those who are typically jerks, are worse, or perhaps take glee in all the chaos.

While people’s perception of the reality may not be accurate, their reactions to them are.  Understand what environment you’re going into, and recognize tensions will be higher than usual.  If you see a jerk, perhaps they weren’t always so, and it’s just this lame ass situation you and everyone else is in that has brought out their worst.  They are only human, and so are you.  A lot of times, you’ll need the jerks, and they you.  Respect their situation, and don’t be afraid to take a few hits.  Being the mature, professional person in times of crisis is what makes you a good consultant.  Breathe, think before you speak, and if you can’t say something nice, don’t say anything at all.  Kill them with kindness.

Identify Problems, and Sell Tailored, Already Completed Solutions

As a consultant, you’re technically supposed to listen, identify problems, and create a plan to fix them.  In software consulting, you’re often the one who helps implement the plan.  Sometimes, however, the cure appears to be worse than the disease.  A lot of times you don’t “provide options and solutions”, but rather have to sell the client on it.  “Selling” the number 2 as the answer to 1 + 1 may seem asinine, but a lot of times it has to be done.  Often this is because the client is too embroiled in bedlam to see reason, and it’s your job to help.  Other times, they just can’t see the forest for the tree’s, and while their employee’s have been screaming what your selling for months, it just takes an outsider to show them what’s been staring them in the face for awhile.  It’s hard, but that’s the 3rd part of consulting; creating & selling the plan of attack.

…some times, however, the client won’t do it.  Or, they won’t do a partial part.  Perhaps your client is game, but getting all the various stakeholders on board is perceived as too challenging, or something that you didn’t account for in your plan of attack.  Even if you did, they client may perceive it as too hard to sell “John’s back-end team on changing a crucial, very old web service merely to fix what they perceive as a minor bug”.  Other times, the risk seems to high.  Perhaps you didn’t do a good job of assuaging their fears in the time you’ve been there.  That, or it’s just too complex to distill in an actionable plan that seems low risk.

Whatever the reason, sometimes you just need to do it.  Again, it’s easier to ask for forgiveness than permission.  Other times, the client just needs that first push (i.e. analysis paralysis).  Still other times, they just can’t initiate it on their own, and need you to do it and appear successful to get other stakeholders on board.  It seems strange, but these things happen all the time.

This could be as benign as writing a demo over the weekend that proves that the technology stack that you’re proposing works as advertised, or as covertly as re-writing an entire library that causes more harm than good.  Sometimes a feint is needed.

One client I worked with had such a horrible View layer, I re-wrote the entire thing from scratch over 3 months.  I got the 4 developers I was working with on board to help, and we incrementally improved each section in turn.  While we accomplished our goals in re-designing/re-working sections of the large Flash website, we also gutted how they worked.  While management was privy the sections we were working on, the depth in which we improved the architecture they were not.  I’d work just a little extra each day to ensure everyone was productive the next day, creating components with other example or template code that would empower my team to succeed.  The depth at which we were trashing the original code base (if you’d even call it that), management didn’t really care because each week, we’d show progress.  I’m pretty sure they’d ask the employee I was working with without my knowledge if we were, in fact, making good progress.  He was the man, though; I had his back and he had mine, so there was no worries there.  By the time 6 weeks had passed, they’d let me re-architect anything I wanted; a far cry from my first week when they were like, “Why is this idiot suggesting we re-write a $2 million dollar website from scratch!? lol, n00b.”.  The code my team and I wrote was supposed to last for 6 months; it lasted for over 2 years.

My point here is that I knew the right thing to do, and found a way to do it.  It took building trust, hard work, and persistence.  I also didn’t do it in one fell swoop.  It was done in iterations; iterations that showed progress, earned trust, and were (mostly) architecturally sound.

The key here is balance between action, and playing the politics game to ensure you’re “allowed” to do what you plan to do.  Sometimes you should just do it.

Create a War Room

The best way to solve really bad software problems is to get all parties together, all day, every day.  With close knit communication and teamwork, you’ll kick ass.  You don’t do this in cubes, nor in meeting rooms part of the day.  You do this in close proximity, at comfortable desks, with no distractions beyond each other.  This is called a war room, and is the ultimate way to get a lot done quickly.  Typically a war room is associated with management/leadership, but in this case, it’s the room in which you and your team wage war, and win.

Using a war room, you guarantee every resource is available.  You don’t have to run into an elevator to go to another floor just to talk to your fellow developer/designer; you simply turn around and ask them a question.  If there is a problem, everyone immediately knows if it’s their issue or not to address.  If it’s not, they can more easily contribute ideas to perhaps invalidate it.  “Dude, I’m getting confused on the order of these search results; are they backwards?  Should we just sort in the Factory?”  The server side dev can say, “I’ll send it to you with a sort field as an Integer, and you can sort on that; no need to muddy up your client side code when it’s our responsibility to give you the data you need anyway”.  No meeting, no Outlook schedules, just raw productivity and agile communication at work.  Developer hit a wall with a skin implementation?  The designer is right there to help quickly get the developer back on track.  All the while the team lead and/or manager can help keep the team headed in the right direction, keeping ’em fed & hydrated, and making the hard calls.

…and ensuring no distractions come in the room.

Do Your Research on the Company

Understanding what the company does, what their market is, and how they make their money will do wonders in your communication with managers on up.  If you understand this, it’ll be easier for you to effectively communicate with them, and understand what they are talking about having only been working with the company for 4 hours in your first meeting.  It also makes you look like you care.

Do Your Research on the Players & Your Team Members

Search for those you are working with on Google, Facebook, LinkedIn, and Twitter.  Learn about their history and their online interactions.  You want to learn about that person to help strike up conversations (careful how you broach this; some people forget they put their life online and get taken aback when you suddenly know all about it).  Learning where people come from helps you understand what makes them tick.  Understanding what makes the people you work with tick helps you communicate with them better, understand their capabilities, and allows you to more easily get what you want from them.

Take People Apart, Find and Press Buttons

In addition to the above, take people apart you work with.  Take them to lunch, ask them to talk about themselves (people love when others ask them to talk about themselves).  Learn what makes them tick.  Everyone is covered with buttons (if you’re married, you know EXACTLY what I’m talking about).  Press them, see what they do.  Using real-time feedback, you’ll get a sense on how you can make others do what you want, when you want.

Keep Your Friends Close, Keep Your Enemies Closer

If there is a Director, Manager, or team that has the potential to thwart your efforts, spend less time with your firm & co-workers, and more time with them.  Become their friends, understand what they are working on, learn their agenda.  If they are crucial to determining whether your plans can succeed or not, it’s imperative you learn their motives, and ensure they align with yours… even if just long enough to ensure you can succeed.  Also, be wary of empty promises; they can be playing the same game with you.  Once you’re back is turned, and you start down a development path, you could suddenly get asked wtf you are doing by management since the other team who you thought had deemed your actions ok, suddenly weren’t when they learned the details.  This happened to me on 2 occasions on the same project and cost me 4 total days of lost team productivity, loss of client trust, and added more friction to meetings.

If that doesn’t work, get more guns; aka, more friends with those in power who can overrule that other team.  Remember, you’ll accomplish more, short and longer term, if you create connections vs. bombing every mofo in your path.

Beware of Hollow Allegiances

In addition to the empty promises mentioned above, beware of hollow allegiances.  If you have a meeting with another team/department you need on board, and they agree with what you say, and claim they’ll support you, it means jack.  Action & incentive have meaning; that is the true currency of politics, not words.  You need to ensure that the potential loss a team/department could have is something they can back up when push comes to shove.  Most aren’t willing to risk their job/salary/position when it really comes down to it (unless you’ve made friends and know they will).  Again, only fight battles you know you can win; the allegiances are just to reduce losses, and add creditability and momentum.  If a battle can only be won with an allegiance, tread very carefully.  You don’t want to be dependent on a non-trustworthy 3rd party.  Make sure you control your destiny, not someone else.  See “Who Makes Who Jump” above.

Depend on Yourself, Not Leaders

While you may garner support of those in power, ultimately you are the one who needs to deliver.  Don’t depend, nor take for granted, their power for long; i.e. don’t abuse it.  You need to ensure your actions in actually executing what you say you’ll do, and have it actually work as intended, occurs before those in power get pressured.  They also might write checks they can’t cash; i.e. make promises to deliver you permission they later find out they can’t do.  You need to account for these situations and make Plan B’s.  Better you have a Plan B than those in power who switch to survival mode and leave you out to get slaughtered.

Take Calculated Risks

He who dares, wins.  Take calculated risks. That is quite different from being rash.  Sometimes, you need to be bold.  You have no guarantees something will succeed, but you need to do it anyway to attempt to move ahead.  Even the act of forging ahead can sometimes inspire others… or make them think you’re crazy.

Sometimes large code bases are so large, and the problems so immense, you don’t have “4 days to attempt a re-work of the Factory layer”.  Other times, you know that’s the only thing that’ll prove that your team isn’t at fault and the server team is giving you bad data at strange times.  Once you do that, and get good logging in place, you can prove that 80% of the problems with the application are coming from the back-end, and thus, it’s the back-end team’s problem even though they’ve been claiming for 3 weeks they are sound.  If you succeed, it’s a crushing blow to their credibility, and will give your team more power and time to shore up defenses for another attack.

The risks are high; the weakest link in any client side Flash/Flex application is the back-end data.  Since it doesn’t have strong-typing until you parse it into a strongly-typed object, and is interpreted into the system, it can pollute the entire thing.  Changing anything with regards to a data model affects every single part of the application.  However, if you win, you gain the beach head you need to start winning the war on the code base, and earning greater trust of your client.  It’s a huge risk.  You could instead just stick to checking in minor fixes, and being pulled into a 1 hour meeting every day about how you and your team suck at fixing the data issues in an already pile of dung code base that you’re entire skill set is suddenly beholden too, and (unfairly) judged against.

What do you do?  Gee, that’s a hard decision… not.

You have nothing to lose; screw it, you could get your team to produce value on Thursday and Friday, while you spend those 2 days + your Saturday and Sunday “fixing it”.  If you fail, you lose 2 days+ 1 day of shoddy code in an already shoddy code app.

…but if you win?  The tide will turn.  Just do it.

Create a brand new component set just so a website can work?  Ballsy move, but it worked for me.

Create an entire website in 5 days with 2 guys because your 9 man team failed to create one with the client in 3 months admist the most insane politics I’ve ever seen in my life?  Desperate move, but it worked for my team and I.

There comes a point where you’re already screwed going down the current path, and only bold action will get you and your team out of the predicament they are in.  At those points, you have rise up, grit your teeth, and charge into the fray, even when those you trust say you’re nuts.  They either help you, or they are in your way.  From Aragorn charging alone towards the orc hoards to inspire his men in Return of the King, to the US Army Rangers fighting their way up Pointe du Hoc in Normandy, France.  It may suck at the time, but only action and grit will get you out alive.  If you keep your mind on visualizing success, and then working towards making that success a reality, you’ll win.  It works for professional athletes, it can work for you.

Get Things Done

Action has more weight than words, at least in the eyes of the client who’s paying you bling.  You can always win arguments when you’ve provided more value than those who are criticizing your position.  If you’ve checked in code, it works, and has fixed issues, you can use those successes as a bargaining chip.  While the client has already technically paid for it, you can use that as “trust currency” to bargain for more elbow room.  In my opinion, the more politics, the less your ability to get things done.  They are inversely proportional, and the less time you spend dealing with politics, the more time you can spend doing the right thing: programming your way out of the situation.

Earn credits through good programming.  Spend those credits to get out of politics so you can get more programming done and make more credits.

Conclusions

You need to play the politics game to ensure you don’t have to play the politics game.  The more time you spend playing politics, the less time you spend coding.  While playing politics ensures you and your team has time to code, that’s still less time you yourself are spending time coding, doing architecture, and leading your team.  It’s a challenging balance.

You don’t have to be a jerk, an alpha, or a loud mouth braggart from the future to get what you want.  You can be polite, yet assertive, friendly, yet firm.  Making friends, establishing alliances, and building trust are all positive things you can do.  Instead of identifying targets, identify allies.  You want to earn trust with these allies so they’ll back up you when someone challenges you.  Remember, you don’t just start out alone, you start out with no credibility.  If someone inside the company vouches for you and what you’re saying, suddenly you have a lot of weight.  No one cares that you’re a hired “expert”, unless all the members of the existing programming team start heartedly nodding their heads in agreement when you talk in meetings.

As an outside consultant (not a W2 employee of the company you are working for), while you may be perceived as an outsider with no vested interest in the success of the project, this gives you a lot of freedom to say and do things an employee cannot do.  Stay positive and control your emotions.  Work towards making strategic allegiances, assuage the clients fears by already working solutions, and be bold.  Also, watch your back.  Good luck.

One Reply to “Consulting Chronicles #2: Fixing a Pile of Rubbish – Part 3”

  1. We recently had an “consultant” come in an basicaly do the opposite of your 17 bullet points. Oh, except for half of one: “identify problems, and sell tailored, already completed solutions”.
    He was adept at identifying problems, then shifting the blame to us employees, then sucking up to management to keep his contract juiced by suggesting utterly inappropriate solutions. It was the anti-ethics of consulting. Unfortunately, this guys behavior undermined any future work by good consultants. Our team leads decided to pull everything in house after we pulled out the pitchforks and torches.
    As someone who was in consulting role for years and years, and will probably be in one again, I completely agree with your assessment of the human realities of doing this kind of work.
    I would suggest that consultants need to recognize theie limitations, as well. If all you have is a hammer (Cairngorm), every problem looks like a nail (using a framework will solve everything!), and a consultant can stir up some real ill will by making poorly informed suggestions and ignoring the history of a project.
    Thanks for the post, Jesse.

Comments are closed.