7 things I learned in 3 years as a Thoughtworks consultant

My name is Geison Goes. I'm 35 years old, a tetraplegic and a Senior Consultant at Thoughtworks. I currently work as a technical leader on a team that helps deliver one of the largest video and OTT content delivery platforms in Brazil.

Having worked as a Software Engineer for 10 years, the experience of translating technical expertise as a consultant has been very enriching and I would like to share my key learnings with you.

1. Translate technical terms into business language

To be an effective consultant, you need to build strong relationships with people outside the development team who will often be part of the client team. These people could be Product Managers or executives from Marketing or Sales. Due to the nature of these roles, it’s important to remember that the terms you use in development may not always resonate with a more business-minded audience.

As a consultant, you should find ways to communicate in ways that non-technical people understand. Taking the time to look up common business terms and using visual templates, whiteboards and metaphors can help simplify technical concepts and their implications. Likewise, encouraging your technical teammates to embrace these business terms can build empathy within the client group.

2. The group will always be more important than the individual

"If you want to go fast, go alone. If you want to go far, go together" - an African proverb

Let's imagine you are the technical leader of a team and need to decide what technologies will be used for the project. Even if you’re well versed in a particular technology, the best option is to work with technologies that the majority of your team is comfortable with. It’s important to keep in mind that delivery isn’t the only place you can make an impact: developing others and increasing team performance—and perhaps even your account—are all areas to make a positive influence. 

As a leader, you are in a unique position to strengthen your team by helping each individual perform better. Talk to each teammate to understand their past, interests and goals in order to help them reach their potential. Connect colleagues with development opportunities. This means allowing teammates to take risks so that they can learn and grow, but also contribute to the team. Encourage knowledge sharing within the group and find ways to help facilitate connection.

3. Asking the right questions > always having the answers

Let's imagine that in a client meeting, you’re asked to develop a mobile app that calculates the dollar quotation. Based on your extensive experience in mobile development, you offer a solution that will serve both iOS and Android platforms and leverage the user's location to perform the right quotation for their specific country. 

The customer is impressed, but asks about an estimated timeframe to complete the project. You estimate it will take roughly six months, which worries the customer. As tension begins to build, your colleague starts to ask questions: 

Colleague: Will there be users for this system outside of Brazil? 
Customer: No.
Colleague: So if we remove user location functionality to expedite delivery time, would that be better?
Customer: Yes.
Colleague: And are you able to determine the percentage of iOS v. Android users based on customer profiles?
Customer: Yes, around 70% use Android.
Colleague: Ok, so would it make sense to make a quicker first delivery just for Android?
Customer: Absolutely.

By making the app for Android only and removing user localization functionality, delivery time was cut in half, making the customer happy and creating the foundation for a lasting partnership. 

Can you see how important it is to ask the right questions?

4. Feedback is important but should never be personal

We all have blind spots: things we do that are ineffective but can’t see unless someone points them out. That is why feedback is so important. Seeking, receiving and giving feedback are all essential for professional growth, but we must be careful not to take feedback personally.

For example, when asking for feedback, avoid the example below:

"Did you like the presentation I did?"

Try switching to:

"How can I make the presentation I gave yesterday more effective?"

See how in the second example we take the focus off the person and shift it to the presentation?

The same can be done when giving feedback, rate the example below:

"You have little or even no strategic thinking."

So rough! But if we change to:

"I’m having a little difficulty understanding your plan. Can we take a moment so I can present my understanding and ensure we’re aligned?"

Isn’t that much better? In the end, we should always seek to improve without hurting others.

5. Responding to change is more important than having a plan

Since change is inevitable in a software project, it’s no longer possible to follow a traditional management approach that focuses on tracking scope, time and cost constraints. A more suitable approach could be leveraging agile management, which focuses on receiving and assimilating changes in the best way, aware that they will indeed happen. In order to develop software in an agile way, it’s important to adopt a new process which allows the team to easily assimilate changes.

For example, “evolutionary architecture” is a technique for designing software architecture with the principle of supporting incremental changes in various dimensions. This technique is best explained in the book Building Evolutionary Architectures written by Neal Ford, Rebecca Parsons and Pat Kua. 

Other techniques such as “extreme programming,” “continuous deployment” and “continuous delivery”—which deal with software development, packaging and distribution practices, respectively—are also essential to having the infrastructure and processes needed to make change possible.

6. Be critical without criticizing

Criticizing a customer's product or service is like going to a dinner party and telling the host that their food tastes terrible. This analogy illustrates how we should act as consultants. We must remember that we are in our client’s “home” and therefore we must respect their wishes, listen to and understand their problems and adapt our ways of solving problems to suit their needs. Always work on solutions together.

7. Work ethic is essential for building trust

Jason Fried, one of the Rework book authors, has a concise and clear description of what it means to have a professional work ethic:

"Ethics at work is showing up, being on time, being reliable, doing what you say you are going to do, being trustworthy, dedicating a fair workday, respecting work, respecting the client, respecting the organization, respecting colleagues, not wasting time, not making work difficult for others, not creating unnecessary work for others, not being a bottleneck, not faking work. Ethics of work is being a fundamentally good person that others can count on and enjoy work."

Be careful when you say, "Do as I say, not as I do." No matter what you say, people will remember more how you acted. Having a strong work ethic is working consistently and ensuring that your actions reflect your words. Acting incongruously destroys trust. Saying "no" or "not now" is better than promising to do something and not handing it over.

If you always do what you promise, truly care about helping people and live your teachings you will have people's trust.

In conclusion

It's important to point out that these were things I learned in the context of a software consultancy in Brazil through the lens of a disabled person and yet with a lot of experience in the market.

If my advice was helpful or if you’d like to share your own professional insights, leave a comment below. I would love to hear from you.