Agile Zone is brought to you in partnership with:

Jesse Warden is a Flex Architect & Partner at Web App Solution, a growing company specializing in Flex/Java/BlazeDS/LiveCycle/AIR development. Jesse is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Consulting Chronicles #5: Getting In, and Out, of the Industry

06.13.2011
| 759 views |
  • submit to reddit

Today, I’ll talk about how to get into consulting, what the skills and expectations are, and what can cause you to get out.

What is Consulting?

Consulting in the Flash/Flex world usually consists of 3 tasks that may be related:

  1. Offer your architecture expertise.
  2. Offer your code mechanic expertise.
  3. Augment an existing team.

For #1, companies either want you to architect a project, give professional feedback on a suggested/signed off architecture done by another firm (usually to give a stakeholder corroborated evidence), or are having scalability problems and want your advice.

For #2, things aren’t going well and they want you to fix it. No, not re-write it, fix it.

For #3, they want you to augment an existing team. Some firms do this because the pay + finder fee is good money. Other firms do not because you can sometimes be put into situations where you’re setup to fail since you may be smart enough to fix it, but you’re not in charge, thus you cannot do so.

#3 is how I got into consulting, staff augmenting an existing team. While the #1′s were fun, they were few and far between; usually big companies would rather pay lots of money to fix things vs. pay what it costs to do it right. This isn’t cynical, this is fact.

Why Get Into Consulting?

The reason is often simple: more money. More money than full-time/salaried/W2 work. More money than freelance/contracting.

Other reasons include working with really smart developers, learning about how Enterprise companies build & sell software,  learning about how to work in and manage large software teams… TONS of opportunities to just learn on a variety of subjects. Sometimes people haven’t worked on extremely large codebaseses. It’s fun to take all the theory and see what it actually does in the real world, with real people.

Me personally, I like travelling, meeting new people, and seeing how different companies work.

Getting Into Consulting

You have a few options listed in order of ease.

  1. Find a firm, become an employee.
  2. Find a firm, become a sub-contractor.
  3. Become an independent contractor.

If you find an existing firm, especially when your country isn’t in a recession, this is the easiest way. Whether large like Deloitte and Accenture, to smaller firms (more focused on Flash/Flex) like Roundarch and Universal Mind. Regardless of skill level, while you’ll be sold to the client as a “consultant”, but larger firms will ensure a senior is on the project unless you’re merely staff augmentation. Joining as an employee usually is easier because you’re cheaper tax wise/cost wise to the firm, and you’re more versatile to them. Meaning, since you’re on payroll, they can pay the same rate to fix a huge client’s code base as well as working on your firms intranet when in between clients.

If you’re the freelance type, or typically like getting a variety of clients (and often potentially making more money), becoming a sub-contractor is another option. This is how smaller firms get off the ground, and is common place even in larger firms. While you usually cannot do mundane work, this is often easier for smaller firms tax wise, thus it’s an option as well. If the firm has no current clients, you won’t get any work though. A W2 will get paid for the 2 week downtime, you won’t. Hustling during consulting engagements is usually harder than hustling during contracting ones.

If you have enough contacts or typically do only Enterprise type software (LiveCycle, BlazeDS, Java/Spring/Hibernate), then going the independent route is also an option. Basically, start your own company, and start working directly with clients. This is the hardest, even if you do Enterprise software, because most larger clients only work with “companies”. Just because you have a company legally filed on paper doesn’t mean you’re a “company”. Often they’ll want multiple developers on a whim, liability insurance, and multiple large clients on your track record/portfolio. I’m personally still learning the sales for this, but it seems networking tends to help a lot/the most.

My advice, seek out people you know from the community at Roundarch, Universal Mind, or Cynergy, and make sure you’re known to be available, even if they don’t currently have any openings.

Skills

Being a consultant involves a lot of things a normal software developer doesn’t do. Even if you’re a salaried/W2 employee, these are still required:

  1. leadership
  2. large scale architecture
  3. travel on-site to client’s location
  4. expense reporting
  5. meeting clients and their stakeholders
  6. offering professional, 3rd party opinions
  7. dressing nice
  8. attending meetings for a company you don’t work for
  9. interviewing/hiring members for your team and/or the company’s on the company’s behalf

All the standard stuff like team management, working with the company’s stakeholders, and tracking your hours are there too. You also don’t always do all the above mentioned; sometimes just one. It’s just those aren’t normal required in traditional freelancing (excluding #3 and #5). Let’s break down what these skills mean.

Leadership

Unless your role is for staff augmentation, leadership is the most important skill for a consultant. You need to be able to inspire confidence in strangers you’ve just met, inspire confidence in your chosen direction & decisions, and to keep people moving on the right path.

Some leadership skills can be taught. Some people are just born with the other aspects. If you don’t know how to do this, watch & learn from those that do. Examples include raising your Charisma score. Doing one or more of the following will help:

  • have good hygiene
  • have clean clothes that are ironed
  • dress to impress; this boosts your confidence as well. You want to look successful.
  • listen: people like good listeners
  • empathy: people like others who understand them. If you listen to their pains, and sound like you understand, you connect.
  • be knowledgeable: if you know what you’re talking about, you’ll exude confidence when you talk. You also won’t get offended if someone disagrees and will want to hear their point of view. If you don’t know, ask/listen vs. act like you know.
  • have a vision: assuming you know the companies problems, have a long term vision to fix everything. Communicating this to your colleague and your client’s employee’s is paramount.
  • communication: you need to be an effective communicator to articulate your vision to others, and get them to follow you. Be relaxed, look people in the eyes, be confident in your delivery, and be open to listen. Using slang/ebonics/l33t in normal conversation negatively affects people’s perception of you. Be professional when you speak.
  • egg shells: crush those sons of bitches. You do NOT walk on egg shells. You’re a consultant; grab drama by the neck, raise it high, and execute it. Then, move forward.
  • be positive: while Andrew Dice Clay and Rush Limbaugh have gotten popular for their negative spin on things, they don’t last. Positivity is the antithesis to Entropy; that lasts, especially in people’s perception of you.
  • control your emotions: software is hard. People in large groups do really dumb things, particularly large companies. Have patience, breathe, and keep your emotions in check.  Your self-control inspires confidence in your actions by others. People assume you have things under control if you’re relaxed and poised.
  • win: You have to WANT to win. You need ambition to reach your goals and vision. If you have that, you’ll have the motivation to do all of the above.

Large Scale Architecture

The most common need in the Flex world is architecting how the Flex talks to the BlazeDS/LiveCycle, and how that talks to the Java, and how that talks to the client’s stuff. Often, they’ll have an existing infrastructure in place and you’ll need to decide & describe how and where to integrate technology stacks to a client’s existing infrastructure and possibly already in progress project with the existing resources, which are often in a variety of teams.

You need to know this well enough that you can cater design, development, and deployment techniques to various client needs. You need to be able to effectively articulate these to the client, the team, and ensure the tasks meet the resources currently available; meaning the client can build, deploy, and support what you’re actually suggesting to do. That’s a lot of traditionally Project Management tasks.

If you don’t know how to architect large Enterprise sized projects, specifically Flex, learn. If the back-end/middle tier isn’t your thing, partner with those who know it. Unlike learning traditional software skills, you can’t really get away with practicing as a consultant. Based on my consulting gigs people can do this all the time if they’re a salaried employee of a large company. So, if you want to get on the fast track to learn, join a consulting firm and get mentored.

Travel On-site to Client

Unless it’s staff aug, most consulting involves travelling on-site to the client’s location(s) to meet the stakeholders and team. This means donning your business casual, booking airfare & hotel, and travelling both on the weekend and during the week. Being responsible by ensuring you have ample lay over time, don’t get the last flight out,  arriving to the airport early, and arriving at a client site early to ensure you’ve gotten enough sleep are assumed.

For those with needy significant others and/or young children, this is challenging to do, and will determine if you do higher level consulting or not. This has forcibly paused my career which I’ll defer to a later blog post.

To me, this was one of the draws I have to consulting. I like traveling to new places, meeting new people, and the lifestyle of being on the move. Being on the road is one thing that’s therapeutic to me.

If you don’t have a few thousand in the bank to cover the costs (flight, hotel, fuel, food), the firm you work for will have to front the money. Either way, you have to ensure this is tracked as reimbursed expenses for tax purposes (unless you’re salaried with the firm). The benefit of paying for these things yourself are tax write off opportunities as well as frequent flyer miles with certain airlines.

If you can use expedia.com, drive a car, and find your way around an airport, you’ll be fine. Sometimes you get to meet new people you sit next to on the plane. Yes, there are cool people in coach, but you want to strive to be in first class even if the company will only fund coach. Make sure you use your own miles program vs. the companies if you can. You aren’t paid for your travel time like lawyers, so it’s nice to have some way to offset costs; i.e. being able to work. Trying to type on your laptop in coach is torture vs. first class.

Expense Reporting

A lot of consultants, even if salaried, are required to document their time and expenses. This means documenting, usually in some web based time tracking program. Thus, you need to be aware of how much time you’re spending on tasks, what those tasks were, and how much more you think you’ll do. This can get tricky, too, when you end up in a staff aug position and basically end up running the project. Suddenly you’re holding the ball, and people are wondering why you’re billing time for meetings vs. coding… you can get into really uncomfortable, and extremely irritating and unfair situations. Examples include being the architect & mentoring company employed developers on the project, and when the UAT comes up at the end of an Agile SCRUM Sprint, you show zero User Story points completed, and people in charge question what value you’re providing.

If you document well, cya (cover yer arse), and have transparency with the client into what you’re spending your time on by talking to them early and often, you’ll do fine. While they often don’t plan for you to spend a lot of your time in meetings for doing architecture, as long as they’re aware that out of 4 months of billable hours, 2 months were spent helping the client align their processes to ensure they could support the app, ensure the user stories/features in the application were valid, and the design was actually capable of being built… then you’ll at least get paid.

Document your time, be aware of what you’re working on, and what you need to work on. Communicate what you’re doing for the client often.

Meeting the Client and Its Stakeholders

I like meeting new people. I like talking. I like meeting successful people and learning from them. Consulting with companies that desire your expertise teaches you a lot about software that supersedes the construction of it, but how it’s actually consumed and sold. This makes you question a lot of the commonly held beliefs by OOP Purists and other fads touted in the news. It’s awesome. You get to learn how to build software, how to fix it, how to align teams, how to prevent fire drills, why you’d even want to prevent a fire drill, how to compromise amongst silo’d departments, how it’s sold… the list goes on and on.

To get things done, and get bigger problems resolved (like using the wrong technology stack/methodologies/processes), you’ll have to meet & talk with the big wigs. If you aren’t comfortable talking with upper level management, having an MBA helps. If that isn’t your thing, find someone who is good at it, and learn. Sometimes these are either A) the only people that can move you forward and/or B) they’ll great at articulating why you’re so eff’d and just need to deal with it.

Bottom line, you can get the REAL story behind why the way things are, and exactly where they are going by talking to project stakeholders vs. the variety of “this is my world at this company” responses you’ll get from interviewing employees who aren’t Director level or higher.

Offering Professional, 3rd Party Opinions

Often you’re firm will be hired for your realm of expertise. Other times, they already have the expertise, whether internal employees or another firm, and just want your opinion as a 3rd party who isn’t currently involved nor has stake in the current project. They actually care what you’re opinion is and pay for it. This helps them confirm what they already know with an “iron clad” assessment, or perhaps challenging strongly held beliefs in a certain section of the company.

Sometimes these validations, such as:

“Yes, this other consulting firm is billing out a bunch of n00bs to you for $150/hr, and yes, you’re internal employee DID in fact build something amazing in 1 week what the 2 n00bs couldn’t do in 3 months.”

…lead to consulting engagements. Sometimes confirming what the company already knows builds trust, and thus leads to a longer term engagement.

Other times you’re actually hired for a less valued position such as staff augmentation, but you’re experience/knowledge ARE in fact beneficial the project. Thus, you need to find a way to ensure those who need to know learn about what you know. If you sucked, you wouldn’t be hired for your high price, thus, ensure the client gets value from you via your professional opinions.

Dressing Nice

I’ve mentioned this countless times before. Clothes make the man. Women typically dress to impress other women; in this case, women need to dress to impress the client. Business casual is usually ok, although, the larger the account, the more formal you need to look. In my opinion, you CANNOT be overdressed for an engagement. If someone mentions on the side you don’t have to, they’re either threatened, or don’t understand the game.

Dress to impress. If you look impressive, you must be impressive. You’re thus apparently successful because you’re knowledgeable. This includes accessories such as the car you drive, the bag/briefcase you carry, and the business card you deploy.

Attending Meetings for a Company You Don’t Work For

Sometimes, especially if you end up being a shield for the rest of the team, or if you just want to learn about the lay of the land, the players, and all the drama, you’ll need to attend company meetings. These are often a waste of time, or things to be avoided at all costs. However, to management, THIS is their transparency to give to stakeholders at some companies. Providing attendance by your firm is often a requirement.

Either way, you’re involved in the project, and need to attend the meetings, and sometimes participate. Sometimes you even need to call/create meetings (OMG, the horror!). These are usually to get consensus from the team on an issue that you couldn’t do in SCRUM, or resolve drama, or to brainstorm on how to solve some challenging coding issue.

Interviewing/Hiring Members for Your Team and/or the Company’s on the Company’s Behalf

Sometimes you’re brought onto a project, and realize you need help. The company looks to you to “build it” or “fix it”; if that means more developers/designers from your firm, so be it, they’ll find the budget. Getting resources can be challenging. At a smaller firm, you may have to have the resources yourself already ready to go. David Ortinau, one of my mentors on this, has helped me create a spreadsheet of people I’ve met over the years. On it, I list out people I’d hire (and who I won’t ever hire), what their speciality is, and what the last rate I got them for was. This is because they are often working for me. Even at my firm, my partners are uber-busy, so I can’t immediately assume they’re always available. Obviously they’re my first pick to work with.

If you’re with a larger firm, they can often help in 2 ways. First, they can provide you additional consultants if the client has the budget for it. Secondly, they can sometimes provide resources from other firms. This is more challenging because usually the other firm will want their cut of providing a resource. This means, either your firm makes less revenue from that resource, or justifies the lack of serious profit from your dire need…. or both.

Other times, the company is looking to maintain the solution/software you/you and their team has created. This means hiring employees that work for the client. They’re responsibilities include adding features to & maintaining that software. Often, you’re the most qualified to hire said employees. Interviewing potential coders is a challenge & learned set of skills in and of itself.

Getting Out of Consulting

A profession that provides a significant amount of money, a huge opportunity to learn, and networking opportunities with new people & companies seems like something you wouldn’t ever want to leave, right?

Wrong.

Consulting has a lot of overhead on the soul. This includes the following:

  • copious amounts of travel to be on-site wherever the client is. This is time away from your loved ones.
  • dealing with incompetence where said incompetence cannot be fired/laid off, yet continues to actively sabotage your project and/or client relationship.
  • dealing with politics that theoretically help the company’s stockholders, but ensure the software team is setup to fail
  • various implementations of Agile SCRUM that aren’t true to the tenets of SCRUM, and thus don’t see the benefit of it. A lot of times, this angers everyone involved in the team including the PM’s running it, and is just a gross feeling.
  • You potentially never “love the code” you’re working on.
  • The ultimate consulting goal of “leaving the company better than you found it” may potentially be unknowable in how to do so.
  • Entropy is scientific fact that all things eventually will return to chaos. You’re constantly fighting this in consulting/leading large teams regarding the code base; this can take an emotional, and spiritual, toll.
  • Sometimes, companies pay you lots of money to produce code that never sees the light of day.
  • Sometimes, companies pay you lots of money to code in an IDE you loathe on an OS you are unfamiliar with using a framework you hate implementing design patterns you disagree with amongst a team who doesn’t understand why you’re unhappy with the status quo.
  • If things go sour, you can sometimes not get paid, or take awhile to get paid.
  • Depending on the team, the complex processes involved on the surface appear to provide no value to the project and prevent developers from actually writing code since they’re in meetings or writing docs instead.

Add to that the paperwork around expenses & taxes, and it’s an enough to make anyone want a salaried job. A steady, consistent paycheck with easy taxes. Sometimes way less stress, too.

In most cases I’ve seen a change of scenery, a long vacation, or just a different project is enough to rejuvenate even the most burnt out consultants. Other times a dive back into the W2 world is a great vacation from consulting.

Just be aware there is a huge pay scale difference between consulting and non-Enterprise salaried positions. Just because you take a salaried, full-time position at a large company because they offer comparable money & benefits doesn’t mean you’ll actually be able to use your consulting skills. There is a lot of power in not working for a company directly. You can get away with telling them off for being incompetent, explaining how to get out of the mess, and they’ll thank you for it. You do that as an employee, you typically get a different reaction, one you don’t want.

Bottom line, this can make finding comparable employment & compensation challenging if you’re thinking of getting out. From a skill set perspective, usually only start-ups need someone of that caliber, and unless they have known backers, it’s hard for them to afford you unless they offer some serious equity.

Conclusions

Consulting is a profitable endeavor, usually involving your skills on larger projects for larger companies. You can work with various teams or simply offer your expertise, perhaps via training. It’s a great opportunity to learn, meet new people, and discover the business of software and the development processes various companies use. The money can’t be beat, either. The easiest way to get in is to find an existing firm such as Universal Mind or Deloitte and get hired.

The skills required are more demanding that normal freelance software development. Specifically, knowing how to architect extremely large applications, having good leadership skills, and the ability to communicate complex subjects succinctly are key. These skills can be learned and practiced.

Consulting is a demanding career choice and it’s ok to take a break from it. Being an expert in your field requires you to be constantly researching, learning, and being on top of your game.

Keep in mind, too, you can work for a consulting firm and “just code”. This isn’t consulting, though.

Published at DZone with permission of Jesse Warden, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: