I’ve been involved in software, offering consultancy, advising, and engaging in various projects for over 15 years now. I started my journey with a small agency and eventually transitioned to freelancing, taking on gigs for clients all around the world. Here, I’d like to summarize a few key lessons I’ve learned over the years.
Each gig is unique
Each gig is a different beast. It presents a unique opportunity to learn, grow, and, more importantly, to share. It is a bi-directional process. One important lesson for me is that you should not be afraid of sharing knowledge, experiences, tips, or ideas of any kind. While my services generally center around technology, I’ve found that product or even business-related contributions were always more welcome than I thought. Do not leave anything for yourself; treat your client as if it were your own company.
People first
Culture is about people, and people are key in an engineering team. You must listen, ask questions, think critically, analyze, while not taking ownership from the permanent team. Once you’ve understood the dynamics, you can offer your insights, suggest changes, and share your way of working to see how it fits into the process. But do it in a very respectful manner, as you are a guest in their house. Don’t pretend to be the main character; you are not.
Also, cultivate your soft skills, provide honest but constructive feedback and, once again, treat the team as if it were your own company, fostering a sense of ownership and dedication.
Communicate effectively
Apart from what has just been mentioned, I believe that having good communication skills and practices is key in this job. To me, it’s very important to communicate often and effectively. By communication, I don’t simply mean broadcasting information, but rather ensuring that the message and all its details reach every individual involved. For that, I rely a lot on documentation. I often support my communications with attachments such as an architectural proposal in the company’s internal repository, feedback in a Pull/Merge Request, a summary of notes from a recent meeting, or just some drawings on a virtual whiteboard—whatever it takes to make the message clear and easily understood, even asynchronously.
Get your hands dirty
As a consultant, it’s often easy to feel like a redundant asset, perhaps not entirely necessary, or just hard to fit in. Of course, while you’ve been hired for a purpose, the goals of the collaboration might still be unclear or were not communicated clearly. In such situations, staying too high-level and not getting involved in the internal ceremonies, such as getting into the code, doing peer-code reviews, or helping out with some nasty bug, might work against building trust from your peers, who are also your clients. I’ve been in many situations in which I unexpectedly joined a conversation, ended up pairing and doing “real engineering stuff,” and felt like everyone’s trust started to increase, which allowed me to work more confidently as well.
Tools are secondary
Nowadays there are almost infinite ways to approach building software products, with a myriad of tools and methodologies available. Often, we tend to base engineering decisions primarily on the choice of tools rather than focusing on more fundamental things. When I refer to ‘tools,’ I mean frameworks, stacks, programming languages, vendors, service providers, and so on. While being proficient with specific technologies can provide valuable insights (and it’s necessary for some gigs, of course), it’s equally important to prioritize identifying participant domains and their interactions, establishing the right communication architecture, and laying the necessary foundations for the project or piece of software in general.
I’ve learned that there are not many truly fundamental things in engineering which are sometimes overlooked. It’s also gratifying when you start to recognize these patterns, even when using different tools.
Nothing is written in stone
Every company I’ve collaborated with has had its own unique processes. It doesn’t matter if they are very well-funded or more relaxed, only a few aspects should be set in stone. From an outsider’s perspective, it’s easier to identify when something’s not working, but it’s often so deeply ingrained within the team’s culture that making a change looks like an impossible feat. As a consultant, you can introduce fresh ideas and perspectives based on past experiences and your own learning journey.
Know your strengths and weaknesses
I tend to become personally involved with products and teams I like to work with, which leads to a strong personal commitment that makes me stay present and honestly concerned about the product’s success. This is, in a way, both a strength and a weakness, and I’m still learning how to deal with it.
Another weakness I’d like to highlight is my tendency to delve too deeply into details, making it challenging for me to delegate tasks. And, when I do manage to delegate, I often try to anticipate and prepare as much as possible to facilitate a smooth transition, which is not always the most efficient approach.
Speaking about strenghts, I would say that raw experience is one facet that I try to exploit. After having had the opportunity to collaborate with several companies of different sizes during my career, I often experience the infamous “I’ve been there” feeling. When a familiar solution presents itself, I reflect on previous successes and failures, adapting the approach to meet current needs.
Also, I’m basically a tech guy who has a product-oriented mindset as well. I’ve been in the situation of taking a product from 0 to 1 many times and I know it’s easy to forget things when you are fundamentally a technical person. Do not forget that in the end, it’s all about making things work for the users. Don’t stay exclusively in the technical side of things and ask questions such as “will the users understand this?”, or “does it make sense from the user’s perspective?”, “wouldn’t it be more cost-effective if we do this instead of that”?
If you’ve been in a similar situation than me, I would love to hear your own experiences or lessons learned. Please, drop me a line at hola@davidanguita.name or use the comments section below.