Working for consultancy companies

Recently I was approached by the guys from the Graduate Developer Community (GDC) where they asked me for an interview about life in a consultancy company. Their idea, that came out from an email I sent to the London Java Community (LJC) ages ago about different career paths, was to interview professionals that followed different career paths and publish these interviews on a website called GDC Careers so that graduates and people starting in our industry could have an idea about what is available out there in terms of jobs and career paths.

The interview was originally published on the GDC Careers but I'll also be publishing it here in full. I hope it helps any professional that would like to know more about life on consultancy companies.

NOTE: Throughout my career I've worked for three consultancy companies and this is just my general view of all of them. Each project is a different project and different consultants, working for the same consultancy company but in different projects, can have a completely different view of their employers.

Sandro Mancuso has been working as a software developer since 1996 but started writing code for pure enjoyment way before that. Although he has worked for software houses and startups, he spent the majority of his career working for international consultancy companies where he had the opportunity to work on a great variety of projects and across many different industries. He has a BSc in Computer Science and a MSc in Distributed Objects. He is a Co-founder of the London Software Craftsmanship Community (LSCC).

Title – What is your job title?

Senior Consultant.

What is your role about?

My role is to work with clients, helping them to identify what they really need, advise them, provide options, and help them to achieve whatever they want to achieve in the most efficient way.

OK, I know. That was not very specific or helpful. This is because the role of a consultant can vary quite a lot. Different consultants may choose different career paths. Some follow a more business oriented career, advising clients on strategy, marketing, investment, finance, etc. Some follow a more process oriented career, emphasising project management, Agile Coaching, training, business analysis, requirements, etc. Others prefer a more technical career path, working more often as developers, technical architects and team leaders, mentoring, etc. In my case, I took the more technical path so normally I do what I like doing, that is writing code, regardless of my position in the project. Although I was a hands-on developer on all my assignments, many of them had elements of mentoring. Some times I also got involved in customised training courses for clients, like TDD, Agile, etc.

I work mainly in Agile Java projects. Technologies vary quite a lot since every now and again we are working for different clients, different industries and completely different systems. Sometimes clients already have something in place and the technology stack is already defined. In this case, we often use whatever they are using to start with but we always try to make suggestions if we see that other technologies or frameworks should be used instead. Some other projects, mainly greenfield ones, we generally have freedom to choose the technology stack we judge is the best for the problem. 

What are the best/most positive parts of the job/industry?

In my view, the best thing about being a consultant is the amount of technologies and business domains that you are exposed to during your career. Because of the frequency that we change projects, we end up being exposed to a lot of interesting problems quite early in our careers, giving us a great understanding of many different software projects.

Networking is definitely another very positive aspect of being a consultant. As we move from project to project, client to client, we end up meeting a lot of people, in different organisations, what can be very useful as you progress in your career. The more people you work with or for, the more options you will have in the future.

Another important point is that, as a consultant, you need to be sellable. This may sound a bit negative, but if fact, what it means is that you need to be at the top of your game, knowing the latest technologies, methodologies and trends. The more you know, the easier it will be for a consultancy to place you in a project (sell you to a client). As the consultancy companies recognise that, in general they have different mechanisms (training, conferences, internal talks, events, etc) that you can take advantage of to improve your skills.

Because your peers are also moving from project to project and using different technologies in each project, it is amazing what you can learn from them. The variety of information shared among consultants about projects, businesses, methodologies, technologies, etc, is absolutely priceless. There is always someone doing something different somewhere.

What are the negative parts to the job/industry?

The main complain that consultants have is that in general you don’t have much saying on where you are going to be sent to. Once you decide you want to work for a consultancy company, you need to be aware that travelling is always a possibility. A few lucky consultants get to stay for a long time on projects close to their homes but in general this is not the case. If travelling or long commute is not an option for you, you really need to think hard before becoming a consultant. For those living in big cities, like London for example, in general this is not a big problem since the majority of the clients will be there anyway.

According to your level of seniority, years in the company and history of projects you delivered, you can refuse to go to some projects, in case you don’t like the project (less often) or if the commute is bad (more often). However, this is a card that needs to be played very wisely since you don’t get to play it more than once in a short period of time.

In some projects, you may be seen as an outsider by a few permanent employees. Some feel threatened by the presence of a “consultant”, since you may be “exposing” problems in the current process and software. It’s part of our job to deal with that and do whatever we can to be seen as another team member, a person that shares the same goals, and not an outsider.

Career Path

What is the standard career path/qualifications?

This varies quite a lot since consultancies may offer different type of services and they will need people that are more specialised in some areas than in others. Services offered may include software development, project management, training, coaching, business advice (strategy, finance, investment, etc), auditing, etc. Some consultancies tend to work more on the “consulting” side of things and tend to engage with clients at a more senior level (CEOs, CTOs, Directors, etc). Other consultancies are more focused on software delivery and tend to engage with clients at lower levels (directors, project managers, head of departments, etc). And, of course, some consultancies do a bit of both.

I’ll just talk about consultancies that focus more on software delivery since that’s my background.

My title is Senior Consultant but this is a reasonably vague title. Many consultancies, internally, distinguish their consultants by grades. Each grade has different ranges of salaries and responsibilities and we take on responsibilities on projects, in general, according to our grade.

For people aspiring a more technical career, in the entry levels you are expected to have a good knowledge of a programming language (in our case Java or .Net), most common frameworks, good understanding of Object-Oriented Programming and you would be working as a team member (developer). As you move up through the grades, you may take roles where you will be leading teams, be the technical architect, enterprise architect, Agile coach, etc. At the higher grades, besides all the technical knowledge you will also have some extra responsibilities like writing technical proposals, pre-sales, project inceptions, project management, manage clients expectation, etc. However, some consultants manage to reach the higher grades and remain totally hands on. That’s the path I’m following.

To be successful as a consultant, you need to be a well-rounded professional. Just knowing a programming language well is far from being enough to be a good consultant. You are expected to have knowledge in many different areas since you never know in which project you will end up and which position in the project you will have. And regardless what the project is, you need to be ready. Of course that we all know that is simply impossible to know everything that is out there but at least you need to show that you have the motivation and drive to learn whatever is thrown at you.

Besides the technical skills, another thing that is very important for a good consultant is soft skills, due to the amount of iteration with clients. I’m still working to improve mine. :)

What are the prospects?

Over the years, after many different projects, a consultant will have a good understanding of different types of software projects, technologies and also will have met a lot of people working for many different companies. This gives the consultant a good variety of options for the future. 

In your experience are you aware of any differences your role has between industries/sectors?

In terms of clients we work for, yes, there are huge differences. Working for clients where software is not their core business (a big supermarket chain, a media company, etc) is totally different from working for clients where software is their core business or is an extremely important part of it (software products, internet companies, telcos, etc). There’s also the investment banks, financial companies, government, gambling, etc. Each client will demand a different type of service and a different type of expertise. Some clients will ask a consultancy to help creating the process, roles and responsibilities, requirements, definite the technology stack, etc. Full freedom. Other clients, which have a more mature software capability, may ask a consultancy to provide help with a very specific problem. Sometimes they just need some good developers for a limited period of time. They may want someone in there to coach and mentor their own developers. That means, the role can vary quite a lot, depending on the client.

Reflection and The Future

What was it like coming into the industry?

Before joining my first consultancy company, I had worked for two small software houses and I didn’t know much about it. Job was announced in one of the main Brazilian newspapers. 800+ developers applied and just 34 were hired after a month long selection process, 4 phases, including a two week training and group dynamics. My two previous companies combined had in total 10 people. This consultancy company had more than one thousand employees just in Sao Paulo. Many thousands around the world. I was completely lost and a bit scared by the size of the projects. Before I was writing software for local shops and businesses and there I was working in projects for multinational companies and governments. Complete shock. New technologies, new people, massive projects, multiple teams involved, clients speaking different languages, etc. After a few months, I was quite comfortable there and knew that I had made the right choice. I guess that I was very lucky there, firstly because I was assigned to work on a very technical and capable team and secondly because for two and a half years I had the best mentor (my boss) that I could ever have asked for.

However, joining a modern and more agile consultancy company today is totally different, much easier and less traumatic, even when working on big projects for big clients. In general you will be working in smaller teams (even on long term projects) and following agile methodologies. The technologies used are accessible to every one. When I started, back in the 90ies, we couldn’t just go to a website, download certain technologies and install on our PCs. Many of the technologies were proprietary. There’s absolutely nothing to fear about joining a consultancy company today and the world is a much better place now.

Do you have any thoughts on the future of your role/industry?

I think that while there is a need for software development, consultancies and consultants will always have a place. However, the time where consultants were the only or the best specialists in the market are over. Due to the internet, open source projects, social networking, user groups, conferences, shared videos, podcasts, etc, any one, anywhere in the world, has access to the latest technology at the minute it is released. Consultants now, more than ever, need to be at the top of their game. Consultancy companies will need to do their best to get the best professionals in the market in order to survive. They will need, more than ever, to show to clients that they have the best people to work on their projects.

What advice would you give someone entering your industry?

The following advices are valid for any developer starting his or her career, regardless if he wants to be a consultant, the industry or career path he will choose:

- Firstly and most importantly, enjoy and be proud of what you do. Software development is a very cool profession. During your career, there will be many people out there that will be using and benefiting from stuff you created. And this is definitely really cool.

- If you think you studied hard during university, think again. You haven’t even started studying hard yet. Software development IS NOT a 9 to 5 profession. Be prepared to study hard, outside working hours, for the rest of your life.

- Always aim for jobs where you are going to learn more and not earn more. Preferably a place where you could have a good mentor. Be patient because money will come. If you are good and keep learning, you will have a very decent life throughout your career. If you just aim for the money instead of learning, you may get a good money now and be unemployable and out of the market in a few years time.

- Put a lot of effort on learning the fundamentals of software development instead of just learning the latest framework. If you have a good foundation, you will be able to learn any new technology much faster.

- Contribute to open source projects, learn from their code base and take the opportunity to communicate with other contributors.

- Always have a pet project (you may be excused if you are actively contributing to an open source project). Pet projects are great for you to try different technologies, techniques and methodologies. The cool thing about a pet project is that you have the power to do whatever you want, whenever you want, making it quite fun to work on. You don’t need to finish a pet project, in fact, you never will.

- Join you local user groups. The amount of stuff you learn and people you meet is just priceless.

Have you come across anything or anyone that has helped you move forward in the industry?

Definitely the mentor I had early on in my career. He was an exceptional developer and like a father for all of us in the team. He could hit us as hard as he wanted but no one else was allowed to do it. He shielded his team (us) from all the external heat and pressure. Quality was non-negotiable. He was a true believer that “how it’s done is as important as having it done“, phrase that I use as my blog’s subtitle. He believed in the apprenticeship model, although we’ve never used the term. It was there and then that I learned the true values of what today is called software craftsmanship. I worked for him and on that team for two and a half years and by far it was, if not the best, one of the best teams that I've been part of. My mentor gave me everything I needed to become the professional I am today.

Twitter: @sandromancuso
blog: http://craftedsw.blogspot.com
LSCC: http://www.londonswcraft.com

Fighting the Pirate

Six years ago I took the decision of investing my efforts into the creation of a software application. It was a complex project that potentially required thousands of hours of work. I had to make it financially viable. No sponsor was in sight, so the only solution was to make a commercial program and sell it. I was extremely lucky, because the facilities to sell it were readily available and convenient too.
The difference between a normal application and a commercial one is that the latter must be copy-protected in some way.
I had complete freedom about how which technology to choose to protect the program. It was clear to me, and still it is, that no money had to be spent for the protection. First, I was not sure that the product could sell enough to invest part of the money into its protection. Second, it's a non-sense to spend money to protect software by piracy. I think that those who steal a copy of a program are inherently thieves. They can't be convinced to buy a regular copy. Stopping the theft does not increase the volume of sales, therefore it is not the case of investing money for the protection.
On the other hand, I had discovered since a long time that:
- writing a program is easy;
- selling it is hard;
- convincing people to use it, after buying, is even harder.
Have you read all the books you have bought? Are you still using all the programs you have bought? We are subsidizing the software industry with this kind of unhappy purchases. I want my share of this cash flow and copy-protection is the way of keeping this little share intact.
I invented my own home-made protection, which was based on a simple but effective encryption. I don't know, however, who were the pirates and how they worked. I believed that a pirate was somebody interested into directly using the program. Nothing was farther from truth. After a couple of years I found the first pirated copy of my program. It had been cracked by someone who only wanted to demonstrate how smart he was (or how dumb I was), but had no idea about whose was the program and what it was for. There was no intent of stealing my money or saving their money. It merely was a kind of illegal hobby. The pirate thinks he is a gentleman, because he never cracks the latest version of a commercial program, but the version of yesteryear. Unfortunately, not all the customers need or asks for the latest version, so piracy is still a danger.
When I discovered the first successful crack, I was not terribly worried. First of all, beige worried could not have helped in any case. Second reason: the particular version they had cracked was probably the buggiest version I had ever released. Third reason: the program was still relatively unknown, up to the point that having illegal copies around was a cheap publicity.
Fast forward another two years and I was seriously worried. This time they had cracked one of the finest version I remembered having made, virtually flawless. Multiple copies of the cracked version had already been uploaded on Rapidshare and were relatively easy to find with Google. I realized had to fight and I fought. On the prevention side I studied how the crack had been executed. Then I implemented a different protection mechanism. All my future versions became more difficult to crack. But what about the copies around? I simply wrote a single email to Rapidshare. I explained that they were violating a copyright, but I didn't threaten anything. With my great surprise, all the files were removed within 24 hours. I accomplished two great results: all the copies had disappeared from the web and a lot of broken links had remained around. Anybody who was going to search for the crack, he was going for a frustrating experience.
Today things are quite different, because there are a lot of parasite sites that promise you, in change of a registration, to disclose the links for the download. No link is published, but probably no link exists in reality. I can't believe that somebody can risk a virus infection, a robbery of their bank account or simply a ton of porn spam, only for getting a dubious link to a cracked program, and not the most recent version of it. The parasite sites are the worst enemies of the pirates.
I had discovered the main weakness of my protection mechanism: the bottleneck design. This is an important and wise design in normal programming. Instead of disseminating the code with duplications, I concentrate the important instructions into a single routine, that is called several times by the rest of the program. If I want to change the mechanism, it is enough to change the internal code of the bottleneck routine, I don't need to care for the rest of the program. Alas, it was too easy for the pirate to find the bottleneck and modify it. Instead of verifying the key code, the cracked routine simply returned "yes" every time, even if no key was present at all.
At the same time, I had discovered the weakness of the pirate. He was not using the program, he had no time to verify if the program was functional (he doesn't even know what the program is about). He has too many applications to unprotect, because he is in competition with other pirates. It's not important, for them, to demonstrate they can unprotect a single program. Their goal is to unprotect as many programs as possible. Quantity does not mean quality and accuracy, this is a piece of information I can exploit.
I have found two solutions that can be combined together. First, I have duplicated the code that verifies the key. The pirate will find the first occurrence, he will bypass it and the program will be apparently unprotected. Five minutes later the second version of the code will be called. By that time, the pirate has already quit the program, so he will never know there is another verification. The second solution that I have found is to put some important action into my bottleneck. Apart from returning "yes", the routine must do something necessary for the rest of the program. If the pirates bypasses the routine, a hole will remain into the memory. Soon or later, the program will fall into it and crash.
Last month a friend of mine, who lives into another continent, discovered a new cracked copy of my program into a lab nearby his. My friend sent me the cracked copy. I launched it and waited. After five minutes, without doing anything, the program crashed by himself! At least in this last battle I have been the winner. The war will go on forever.

Frustrations and aspirations of a software craftsman

For a while I've been thinking about what makes me like or dislike a project. Having spent a very big part of my career working for consultancy companies, I was exposed to many different environments, industries, team sizes, processes and technologies. There were projects that I absolutely loved, some projects were OK and some were a real pain.
 
There were even a couple of times in my career where I questioned myself if the choice of being a software craftsman and keep walking the long road would be the best thing for my sanity.

What makes me dislike a project?

Well, there are many factors. Here are just a few but is far from being a complete list:

• Bureaucracy is something that can be really frustrating. That includes process for the sake of process, innumerable cycles of approvals, tortuous and long test and deployment cycles, pointless documentation, and all that anti-agile stuff. 
• Old technologies or the "wrong" technology for the job is always demotivating. We love new toys. There is nothing more annoying when the technology stack is imposed on the team. "You must use these tools from Oracle or IBM. But, hey, don't look like that. You have support if you need it."
• Lack of autonomy and credibility. "You are just the developers here. You don't make decisions. You do what you are told to do. There are much smarter people here to worry about the _real_ problems. And by the way, you don't have admin rights to your PC and you can't access a few websites either."
• Uninteresting domain. It's always difficult to find motivation to build a great software if you don't like what the software does or don't really believe in the business idea. 
• Demotivated people. How can we find motivation and have team spirit when your colleagues attitude is: "Oh, I just turn up to work, keep my head down and do what I'm told. If something goes wrong, it's not my fault." 
• Finger pointing and highly competitive environment, where no one plays as a team. This is an environment where everyone wants to be the boss, they are always looking for a scapegoat and the less work they do, the more they delegate, the better. If something goes wrong, it would never be their fault. If something goes well, they take all the credit. 
• Arrogant and unskilled people. Arrogance many times is used as a self-defence mechanism in order to hide the lack of skills a person may have. "I don't need to read any books. I think all these new technologies and methodologies are crap. I've been doing this for years. I know what it is best."
• Software factory concept. "We need to go faster. Let's throw more developers here. Which ones? Doesn't matter. Just hire some monkeys."
• Mortgage-Driven Development
• Project managers that think they are the most important member of the team
• Very deep hierarchy
• You can't help those who don't want to be helped.
• I really could go on forever here.... 

So what is really the problem here?

When I first mentally thought about all these items, I realised that almost all the things that make me dislike a project are related to people. Yes, people. One of the few exceptions are uninteresting domain and old technologies. So even if I make sure that I don't work on projects related to subjects I have no interest and that use the latest technologies, the people involved may make it very frustrating. Have you ever been on a project where you thought that the project had everything to be a great project but for some reason it was a pain?

After this analysis, things were not looking good, so I decided to look at all the projects I really enjoyed. It was when I realised that in some of them we didn't use the latest technologies and in a few of them I was not exactly passionate about the domain either. One or two were even quite bureaucratic. So, why did I enjoy them? What was in there that made me put them among the projects I liked the most? Once again, the answer was "people".

The good projects and what I always would like to find

My favourite projects had quite a few things in common but the most important ones were passion, craftsmanship, friendship and trust.

Passion

It's not because you like something that you are going to be good at it. However, to be really good at something, you must have a passion for it.

The best people for a job are the ones that love the job. This in the essential quality that drives people to be successful in whatever they decide to do. A passionate person will do whatever is in his or her power to keep acquiring skills and do the best they can. Passionate people bring innovation, they question what they are doing, they want to contribute, they want to get involved, they want to learn. They want to succeed. Passionate people CARE.

Craftsmanship

The only way to go fast is to go well - Uncle Bob Martin

In all my favourite projects, the focus on quality and the willingness to see users satisfied and using the system was always a big thing. The whole team was focused in delivering the best project we could, taking into consideration all the constraints we were under. It was clear to all of us that to be successful we had to be pragmatic. We also always believed that how it is done is as important as having it done.
Software craftsmen use the right tools for the job, are skilful, are pragmatic, care about the quality of their work, care about their reputation and want to delight every single one of their customers and users. Software craftsmen CARE.

Friendship

So far I've been talking about passionate people and care. However we know that people have different opinions and there are many ways to do the same thing. Now imagine a room full of very passionate people that don't really get along. In the best scenario, there will be some memorable arguments. In the worst, they will kill each other.

Friendship is the answer to that. The importance of social events for a team is enormous, even if it is just a few drinks once or twice a month. Like it or not, we spend more time with our colleagues than with our own family, so it is important that we have the friendliest environment possible. Having lunch together at least a few times per week is another thing that can help improve this friendship. Team members need some time together where they are not always just talking about work. Team members need time to know each other. 

Among friends people feel comfortable to speak their minds. Working with friends helps to improve the quality of the discussions and no one is worried to expose ignorance or give suggestions. Friends help each other, friends learn from each other, friends CARE for each other. 

Trust

Once people can demonstrate their commitment and passion, can demonstrate competence, willingness to learn and contribute and are able to deliver the best software possible, trust is easily established. With trust you gain autonomy and are free to decide what it is best for the project and to do your job well. With trust you can be more effective when delegating or sharing tasks. With trust we can remove all the bureaucracy that impedes that we do our job efficiently.   

Aspirations

I just wish I could find the things I described above in all projects. Companies should aim to hire passionate and skilful people. People that can contribute to their projects and organisation. People that are willing to share and learn.

Unfortunately not always we will find all that. In those cases, the only thing we can do is to try our best to change the environment around us. We can try motivate people and share our passion. We can be nice to everyone, respect our colleagues and promote an environment where everyone feels comfortable to ask for help, to help each other and share knowledge.

With great people we can overcome any obstacle and have an environment where every morning, when we wake up, we would think: "Yay! Today I'll have another great day at work."