“It is literally true that you can succeed best and quickest by helping others to succeed”, a quote by American writer Napoleon Hill and author of one of the 10 best-selling self-improvement books of all time, Think and Grow Rich. First published in 1937, the book covers a variety of philosophical business practices that - even almost 90 years after its initial publication - are still considered as one of the most important fundamentals for a person, team, or business to succeed. And yes, it can be argued that success isn’t guaranteed by simply following the most basic of guidelines; Books, people, and even the Internet (despite its vast amount of available information) are not always right - it is what you do with it to succeed.
The big question is: How would you describe or measure success? In this day and age, digital evolution has become such a big part of our daily lives, that the simplest of things, like shopping and streaming movies are now mostly done online. Meetings, remote work, and even big company events follow the same pattern. Transitioning to a digital age can or possibly should be considered a necessity, though not always as successful as one might hope. For smaller IT teams this type of change has definitely created its own set of difficulties - success isn’t always visible, but definitely measurable.
Our team currently consists of four smaller core teams: directors, designers, developers, and testers. Though each team has its own responsibilities, to succeed as a whole it is important to understand what each team does to define its own success and how their values play a role in this. Starting with our director team, it is needless to say that direct contact with the client is of high significance. Without a deeper understanding of what the client wants for its business, success cannot be achieved - it all starts with mutual respect and agreement. Similarly, the work that the director team is responsible for, has a direct effect on all the other teams. The designer cannot create a visual representation without an idea; The developer cannot build without specifications and designs; The tester cannot finish the project without the previous parts.
To ensure that the director’s work does not create any hiccups further down the line - and possibly hinder the success of the project - there are several protocols in place. Initially, the content of a new release is privately discussed between the director and designer, this to make sure what is doable within a specific timeframe. In case of a bigger release, a rough outline is shared with the design team. They create a prototype (often a variety of different designs) and share this with the other teams. Since each core team has a completely different perspective on how to use the design and whether or not it needs improvements, a prototype presentation session is held before the team takes it to the next step: sharing the prototype with the client.
The client may or may not like the design, or could even ask the designer to add changes so that it comes closer to what the company is aiming for. This also provides the director team with most of the information it needs for the technical specifications, whilst the design team focuses on the final design. Once a reviewable version of the specifications is available, each core team takes a look at the contents and provides feedback. For developers this could be related to changes to the existing code or technical matters, and for testers about testability or unusual cases in which the implementation could lead to issues. Since this whole process takes place prior to development, communication between each team is crucial.
Development and test are two equally different beasts. For example, our team consists of several developers and quality engineers to make sure the new version of the application gets exactly what was agreed on. This could be a set of small changes, or bigger additions like new screens, animations, or functionalities that would further improve the user-experience. On paper, the development team is located right in the middle, not only responsible for communication with both the director and designer team in case of further clarification or - if necessary - slight adjustments, but can also act as the direct point of contact for technical issues or questions from the quality assurance team. Once development has come to an end, the testers take over and start the final sprint towards release. Assuring a perfect and bug-free product is - in almost all cases - not possible, but through constant feedback and consultation it is a lot more likely that one team’s victory will be a step closer to measuring the success of the group. People are intrinsically purpose-oriented and believe-driven, ergo deciding where and how to start is equally important as understanding what each team believes in and what it does to reach the finish line.
To come to a close, I believe it is essential to understand the difficulties each team may struggle with. Difficulties create hurdles, and hurdles lower the speed at which you progress. Without progress you can not bring it to a successful conclusion. Though it is completely understandable that each core team is and should be in charge of its own success, not sharing any of it with the others only leads to confusion and possibly less motivation. For instance, animals follow a similar pattern. A perfect example would be wolves, where the pack is divided into smaller groups. Each smaller group has a purpose, with the one in front (the strongest) responsible for creating a path and protecting the weakest, and the one in the middle (the older ones) and the one in the back (the leader) for keeping the pack together. Trust and communication are key, as long as each individual group knows what to do to help the others succeed. “If everyone is moving forward together, then success takes care of itself.“
