As one! Building top performance teams is very difficult. Sometimes it’s actually a matter of luck. But is it possible to create a culture that improves the odds and lays the ground for great teams? Fellowship It’s mandatory that members have a good and friendly relationship. Pressure, deadlines and many problems will arise and how the team behaves will make all the difference. There will be the time when someone will make severe mistakes or cause slowdown. At that time, the team should act as one, be supportive when needed and do everything to get past obstacles. team On the other hand, after successfully overcoming the obstacles, problems need to be addressed. Sometimes the team is very friendly and there is no confrontation. The team members should be direct, expose all the facts and leave nothing unsaid. Feelings should be kept aside and team members must understand that teammates may not agree with some solution or may believe that something could be improved. That does not mean that people don’t like each other! Having a postmortem culture is handy to achieve this. Forces the team on learning how to communicate via facts and consider processes or guidelines to overcome future obstacles. Challenges What good does a tight team do if there is no use for it? There should be challenging tasks to perform. The team needs to put the skills and to the test, constantly. This will make the team evolve and become better. It will also foster the need to continuous learning and improvement. teamwork Starting projects or tasks that are challenging should always be motivating to the team. And completing those tasks with success yields a sense of achievement and should be celebrated. Continuous evolution is a core responsibility of the team. Team members should always be looking for better ways to solve existing problems. But it’s also a responsibility of management, because the business needs to evolve in such way that people feel the healthy pressure to always overcome themselves. Ownership The team should have ownership over what they do. And with ownership comes responsibility. Given a set of challenges or goals, the team should be autonomous to define the path to get there, and should be held responsible if things go wrong. The responsibility part is important because it forces the team to consider the future. If you are building something that you’ll have to support later, you’ll put more thought into it from the start and have more quality considerations. It also forces better communication. If the team has the ownership and responsibility of something that will not be done in time, for example if it’s getting behind to meet a deadline, that should be communicated as soon as possible and should be addressed. Impact What the team produces should have a clearly defined impact. Sometimes teams build great things that are not used or have no practical effect on the business. That is very frustrating for a highly skilled team. In the past I considered that providing the impact was not the team’s responsibility. However, there is always something that the team can do. — understanding why something is important to do greatly adds to the motivation of implementing it. Will it help our customers? What additional value will it bring? What is the goal? When receiving a task, the team can and should ask why the task is important — sometimes the teams have some refactoring to do, or want to improve processes or learn new things. These team tasks should be properly communicated and there should be consensus on what should be done first. New tasks versus housekeeping — how will we be able to measure the success and usage of something that we’re doing? We need this information to be able to iterate on the task and improve it. That’s the only way we can know that what is being done has impact. Demand success metrics The team should have knowledge of the business and have a vision for the product. It helps to have someone with a mindset. product engineering Vision It’s important to have a clear and inspiring picture of what’s ahead. The team should be focused on the short term. Of course they need to consider the impact and quality of what they are doing, in terms of future maintenance and evolution. But the team should be focused on a short period, like a sprint. Again, knowing the why is more important that knowing what. Ideally the vision is supported by data and not based on intuition. In my opinion there are two more thresholds of vision that are important. — this is usually the responsibility of the team leader. There should be a clear vision on what will be accomplished on the next 3 to 4 months. This forces the team leader to organise and communicate the next developments and that information may be precious for what the team is currently doing. Medium term vision — this is usually the responsibility of the direction of the company. There should be a vision on where the company is going on the next year. Maybe two years even. This could be more abstract and more in terms of objectives and goals. Long term vision In summary, the team should have its mind on the ball, the general manager needs to provide and tune up the strategy for the game, and the president should focus on what’s needed to win the championship. Another metaphor I like to use is the bridge building one. You may have a top team who knows how to build strong bridge parts. But what good will it do if you don’t build straight to the destination, but build in circles? Or if you build it at the wrong spot! At the end of the day, teams are not alone. They should work together with teams from all areas. This will be mandatory to achieve success. If teams are motivated, have a sense or purpose, are continuously improving, and know that their work has impact, that is a recipe for success. Do you agree with my ideas on the requirements for strong teams? What would you change or what would you add? Thanks for reading and you may reach me out at @donbonifacio

Ball

Twitter

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Requirements for strong engineering teams

Too Long; Didn't Read

Companies Mentioned

Pedro Pereira Santos

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Requirements for strong engineering teams

Too Long; Didn't Read

Companies Mentioned

Pedro Pereira Santos

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES