5 things I have learnt working as a Consultant Software Architect

 

I have been working as a Software Engineer for several years, however I have been a full time consultant only for the last one year and a half. I have a background of different experiences: working for small and big companies, in different countries, getting a PhD. The previous things I have done have helped me immensely on this new adventure, however there are things which are specific to working as a consultant.

Also, over time people started calling me a Software Architect. Now, I am not strong on nomenclature and titles, however it is true that my role has changed. While code is still my main focus I spend more time looking at the bigger picture, considering how software affects a whole organization.

Lately I have been thinking on the specificity of being a consultant and a software architect. In this post I try to distill what I have learnt so far.

I. The customer make the difference

The customers you choose to work with have a large influence on the quality of your life. Working as an independent consultant you acquire the possibility to choose who you want to work with (unless you are struggling). I think it is important to use that possibility and choose very carefully your clients. Working with the right clients can be a joy: you can have open discussions, work together on finding solutions, get feedback and the necessary support for the changes you are working on. When working with the right clients you continuously see things moving forward, this helps motivating you and keep a good pace. On the contrary, less positive, less involved clients make really hard to push to achieve the goals set for the projects. Consulting is a demanding job, and all this pressure, when it is not balanced by results, and the consequent loss of enthusiasm can easily end up taking a toll on the quality of your life.

II. Relevant projects

Working on relevant projects makes a lot of difference. When you work on a project that can really make the difference for a company the resources are found, people find the time to meet you, the decision makers encourage the organization to support the change. It is so much easier. For this reason I prefer to work with companies of medium size, because of the possibility of having a big impact on the people working there. In large companies you could have the same situation when working on a project which is really relevant for a specific department, maybe something that can really affect the careers of the decision makers involved. Sure, working on relevant project also means having to endure more pressure, but most of the time this is the positive kind of pressure, the one that motivates you to push harder.

III. Receptive environment

I really enjoyed the times I worked with American companies because I found them more open to change. In an environment which welcome changes you are allowed to try things, to experiment, to drop what it does not work and continuously improve the processes. I had the chance to work with very different companies so when I can I try to bring in new realities the things I have seen working in other contexts. There are companies that are very receptive: maybe some solutions have to be adapted for their context but they are willing to try. Others instead are used to a certain way of working and are reluctant to consider changes. This does not mean that results cannot be obtained but in this case I feel I can be less useful and certainly I feel these environments as more limiting. Continuous improvement is a joy but it requires all the participants to be humble and receptive. It is very difficult to find or build such environments but they provide such a better experience and so much better results that it is worth looking hard for those.

IV. Humbleness

We all have convictions, things we believe in and which proved valuable in some contexts. We need to be able to re-evaluate them each time we are in a new context. We have to stay humble and ready to learn. Your client, the guy paying you, has much to teach you about his context. You have to learn, and be ready to be proved wrong. Your job is to add to what he knows what you have learnt elsewhere, combining all together to create a better situation for you client. Being too confident of being right make you blind to things you should learn. It does not let you improve, and you need to improve all the time to keep delivering value.

V. Ego

It is never about your ego. In some cases you will have discussions that do not lead to the conclusions you support. In some other cases you will find someone against you for different reasons, maybe because the changes you are proposing endanger his position. As a Consultant you invest a lot of energy in your projects, you believe in them and as a consequence you can become very sensible to what you perceive as attacks to your ideas and in some cases to yourself. You have just to remember that these attacks are not personal. In some cases they are motivated by someone genuinely believing his ideas  are better for the company. You have to listen extremely carefully to those. In other cases there could be other motivations and these attacks could be, after all, not in the best interest of the company. It is your duty to fight those while keeping the environment as nice and productive as possible. If this not possible to support a nice environment you should consider leaving, because it is not about you, it is about the best interest of the client and if there are not the right conditions to do your work, you should leave even if this not your fault. Because it is not about you, it is about the outcome.

Conclusions

I think in consulting you need to refine your human interaction skills and your professionalism. Sure, you need to know your technical stuff, this is a given, but it is simply not enough. From time to time I like to stop and thinking on what I should work next.

And you? What do you think is important for a consultant?

You may also be interested into:

Download the guide with 68 resources on Creating Programming Languages

68resources

Receive the guide to your inbox to read it on all your devices when you have time

Powered by ConvertKit
3 replies
  1. Federico Tomassetti
    Federico Tomassetti says:

    My experience with managing developers is very limited. I sometimes help in organizing work, but I think that every developer should be able to organize his/her own work. Someone has to be willing to spend time on planning, so that developers can self-manage themselves in the frame of that plan, but that is it for me.
    When I will have more experience on this subject I will write a new post 🙂

  2. Alex Fruzenshtein
    Alex Fruzenshtein says:

    100% agree that developers can be self-manage 🙂

    I asked the question because I’m going to switch my current position to architect. So question of team management is very interesting for me now 🙂

    Any way big thanks for the answer.

    I’ll add you to bloggers which I read 🙂

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply