My Top 3 learnings from 5 Years at ThoughtWorks

June 6, 2020

In April I had my 5 year anniversary at ThoughtWorks and I think it is now the right time to reflect on what my key learnings are from last years.

A short context: I was on five projects, always working in a cross-functional team. First as a Quality Analyst, later as Business Analyst. Most of my project were in retail, but some also in finance. In addition, there was always a coaching part for Product Owners or other roles - sometimes smaller, sometimes bigger.

I noticed that almost all my learnings can be summarized to three essential one, which I want to share with you.

Team Spirit is everything

Although I knew beforehand how important good team dynamics are for a successful project, it was made very clear to me again within the last year on my last project. The team - both the people and the room itself - should be a place where you feel welcomed. The term “safe space” is often used in this context. I think we even had a “brave space” in which we encouraged each other to experiment, supported each other in solving problems and pushing ideas forward. And in which making mistakes is completely okay, which in turn makes it possible to learn and try again. How did we manage this as a team? Basically, everything is based on trust, which in turn is based on vulnerability. It must be okay not to know things and to ask questions several times - nobody is perfect. I think our random 1:1s was one practical approach to building trust. Every day the names of 2 team members were drawn to talk to each other about a topic of their choice just to get to know each other better.

End-2-End responsibility enables fast innovation

I have experienced that innovations fall by the wayside through a cut between backend and frontend - especially if one of the teams involved is not 100% working on just this one product. In summary, the backend team was heavily dependent on the frontend team. The development progressed slowly because different roadmaps had to be coordinated and priorities could not be clearly defined. For example, the frontend team had to work on many different and equally important topics and had to balance different stakeholders. This whole situation can quickly lead to demotivation and frustration on the team’s side. Questions about the sense and purpose of the project keep coming up, but also the product development stops. All this can be avoided if a team has end-2-end responsibility and can develop its product independently or with smaller dependencies.

Humans don’t like change

Another topic we were involved in was the transformation of a monolith into microservices. This can get messy pretty fast and the biggest obstacles are often not technical, but human. Employees often have a hard time during a transformation. It doesn’t matter if it is organisational or like in our technical. The way the employees work changes because the workflows are re-defined, data is no longer accessed from one single central system and a new skill set is often needed. The most important issue behind this is often fear. Fear of change, fear of losing responsibility, fear of missing skills, fear of… What if change is inevitable and it’s the best for the company? To start with the employees should be taken on the journey from the very beginning. Their fears and concerns have to be heard and taken seriously. Then, as much as possible, the employees should be involved in the solution making. This adds a sense of ownership, accountability and care for the project’s success. Most transformation processes fail because the human factor is left out. Of course it is more strenuous, the whole transformation process may take longer, but it is worth it.

Twitter