Teams: building, managing, leading, performing

Development, Leadership, Management, Planet PHP 24 Minutes

Years ago, after finishing my bachelor in computer science, while doing my specialization studies in teaching and, later on, while doing my masters in leadership and management, I had several subjects about psychology, management and leadership. Although I never excelled in human sciences, I always felt great interest in them and was a successful student at those subjects. The explicit concepts learned back then have since been fading away, leaving me with scattered implicit concepts, knowledge that I don’t really know where it came from any more, nor even if it has any validity.

Thus, I decided to refresh and update my knowledge, so I searched for some conference talks and articles about the subject, and decided to leave here my notes about what I’ve learned and re-learned, as well as a few opinions derived from my past team leading experiences.

Building and leading teams into performance is not an easy task, there are just way too many variables to be predictable. It’s after all, a human science. Nevertheless, there are many studies, theories, behaviour models, guidelines, questions and answers that can help us build and lead a team into performance.

Building

Hiring

Team building starts when hiring people. So what should be important when hiring people? Well, if we are, for example, hunting for a PHP developer I personally feel these should be the priorities:

  1. Team player
    • The new team member character and personality must fit with the current team members. If not we will disrupting or even destroying the current team. A team is, after all, much more than just a group of people. They must support each other, understand each other, trust each other. So their characters must fit together.
  2. Development knowledge
    • The new developer needs to have global development knowledge, meaning coding standards, clean code, SOLID principles, Design Patterns, Architecture Patterns, a bit of devops, etc. This knowledge is common to all programming languages, so, depending on the position we are hiring for, it might even be OK to hire a JAVA developer for a PHP development position if he has profound knowledge of these topics.
  3. Programming language knowledge
    • Obviously, if we are hiring a PHP developer, he should have knowledge of the language. The exact proficiency with the language depends on the position for which we are hiring (intern, junior, medior, senior, architect, …). Having some kind of certification in the concrete language gives us some assurances, but we shouldn’t trust it too much, checking an actual piece of code made by the developer, his repositories, articles and involvement in the dev community, are much more reliable indicators.
  4. Tooling
    • The exact personal work tools used by the (future) team members (OS, IDE, virtual environment, …) should not be a reason to veto a developer, on the contrary, diversity is indeed a plus just by itself and some tools used might even be a great plus. For example if the company software runs on Linux servers, then it might be a plus if the developer uses Linux. The same way, if the software users use mostly Windows clients, it might be a plus to have a developer using Windows.

Its also important to think about the different roles in a team:

  • Technical expert
    • The technical expert is an expert in the technicalities of the position he is hired for. So for example a technical expert within a software development team is a developer who has full knowledge about how to build new features in the product the team is building. Such a developer would, however, need to consult with a domain expert in order to understand exactly how a feature should work.
  • Domain expert
    • The domain expert is an expert in the product itself, how it works, how it should work, how the market needs it to work. So for example a domain expert within a software development team can be a QA tester, who must know how the software should work and can test if it works as expected. He would not, however, be able to build functionality into the product. It can also be a member of the support team, which supports the clients explaining them how they should use the software.
  • Dual expert
    • The dual experts are some the most important members in a team, as they have knowledge both about the technicalities and the domain. So in a development team, A dual expert is a developer who know exactly how to build functionality into the product and is also an expert on how the product should work. This developer has a huge advantage in the team, because he can match the required functionality with the technical requirements, on his own. This means there is no miscommunication risk, and no risk to end up with wrong or incomplete feature.

Start-up company context

In order to decide on the team composition, we should also consider the company stage. According to Khurram Virani and Jake Hirsch-Allen, if we are in the context of a start-up, it is crucial that we give high importance to:

  • Experience, otherwise technical debt will accumulate rapidly and, at some point, it will need to be paid, just like a financial debt;
  • Equity to the founding team, in order to create deep motivation, commitment, and avoid the loss of developers and the knowledge they possess;
  • Remote talent, meaning part of the company can work remotely. The technology to support this is accessible, and finding the right people for the company is indeed difficult enough without considering geographic restrictions;
  • Generalists rather than specialists, as they are cheaper in the end and we still don’t know if we will have the extraordinary success everyone wants.

Mature company context

In the context of a mature company, however, according to Robert C. Martin, there is this myth that all developers are the same, and ten developers do ten times the work of one developer, which is a completely wrong idea:

We are all humans, and the same way there are doctors and lawyers with different levels of experience, quality, proficiency, specialization, the same happens with developers. And like doctors and lawyers, the better you are, the more expensive you should be.

After that initial start-up stage, the team should be composed by a mix of experienced and inexperienced people, where the more experienced developers train and guide the less experienced ones, thus constantly creating more knowledgeable and experienced developers and teams. At this stage, the focus should be on hiring specialists, rather than generalists.

Tuckman’s model of team forming

Tuckman’s model tells us about how teams form, going through a few stages, with their specific support needs from the team leader:

tuckmans model
The Geek’s Guide to Leading Teams by Patrick Kua

When a team is put together, its obviously in the forming stage, where people start to get to know each other and are not yet comfortable with each other.

From there the team moves on to a storming stage, where people already know each other a bit and start to have disagreements and arguments. I personally think this is a stage of establishing statuses, hence with power struggles, where people try to prove their knowledge, empathy or legitimate power, just to name a few. Although stressful and unpleasant, it is a common and, many times, unconscious process.

During the norming stage, the team establishes the rules by which it will work, common grounds between the team members are reached and agreed upon.

The performing stage is when the team really excels and has high performance, high productivity. This is really where we want the team to be!

The storming and norming stages are the most crucial ones, and a team might fail to overcome them. This is in fact the stages where the team needs the more support from the team lead, in the form of conflict resolution and decision making. It is extremely important at these stages, to not be afraid of conflict. It is through openly approach conflict of ideas that the norming stage is established. Without being able to openly discuss clashing ideas, the desired norms and agreements can not be reached and a team can not establish global and stable work norms.

It is very relevant to also note that this whole team formation process will restart every time a new member enters the team, or even when there are position shifting within the team.

Team building

Team building is not something that happens overnight, with sporadic “team building” activities. Team building is a slow process, and should be based on small, common, every day social activities that drive the team to know each other at a more personal level. This will contribute to the the creation of a “safe to fail” professional environment, as well as ease communication within the team, because people will feel more confidant and comfortable sharing their thoughts, doubts and ideas.

Beware of the bad apple

Sometimes we have a colleague who can even be a really nice guy, but he is always complaining! Or, he is brilliant but he is also arrogant, demeaning to his colleagues and obviously unpleasant to work with.

This behaviours can have a really bad impact in the team morale, in the “safe to fail” atmosphere, communication and teamwork all together.

This issue can be approached in different ways. Its part of the team lead role to approach this in a positive way and try to somehow help this team member overcome this behaviours. Usually approaching this issue frontally and clearly with that team member should do the trick, as with most cases where conflict management is required. Nevertheless, this is not always the case, some people are not capable of introspect themselves and/or change their attitude. In a last case scenario, if a team member can not improve his attitude, then maybe this team is not the right place for that person.

Team is firstThe team must always be more important than the individual.

Managing

Managing vs Leading

At this point its important to focus and clarify what is the difference between managing and leading. These roles, although different, don’t necessarily have to be played by different people.

Managing Leading
Promoting change Designing change
Organising people Inspiring people
Consolidate and build Innovate and create
Plan and budget Strategy and vision
Effective action Meaningful action
How, who, when ? Why, what, what if ?
Reflect status quo Challenge status quo
Doing things right Doing the right things

Hierarchy

Implementing the correct organizational structure is critical to maximizing productivity, and establish a healthy and pleasant work environment. An organizational structure can be either vertical or horizontal, where each have their advantages and disadvantages. However, what must never happen is the absence of hierarchy.

A vertical hierarchy allows for great control on decisions and processes throughout the company. There is a clear knowledge of where the responsibility lays, who has the power to make decisions, and the career path for every employee. The decisions are made by the top layers with little of no contribution from the lower layers. However, because the decision makers are distant from the decision implementers, the decision makers are also distant from the information they need to base their decisions upon, so the decisions made have high risk of being inadequate. Adding to that, the decision implementers often feel uninvolved and therefore demotivated and uncommitted to the project. Also, the agility of adaptation to the market is very low, as information and decisions take too much time to flow within the corporation hierarchy layers.

A horizontal hierarchy, in the other hand, empowers and involves the lower ranks of the company. Objectives are laid out by the upper ranks and the lower ranks inform and may even fully decide on how to reach those objectives. The hierarchy levels are as few as possible, upper ranks are easily approachable, and there is no great need to tightly control how objectives will be reached: both the power and responsibility of decision is close to the lower ranks, where also the practical knowledge resides. Agility of adaptation if high, as both the information about the need for adaptation and the decision power to do it, are very close.

Nevertheless the clear advantages of having a “horizontal hierarchy”, it does not mean the same as having absent hierarchy. A clear hierarchy and strong leadership are always needed, be it a vertical or horizontal hierarchy. The biggest difference is, in fact, how decisions are made: contrary to a vertical hierarchy, a horizontal hierarchy involves and empowers of the lower ranks in decisions and processes. This involvement and empowerment must be sought out by the higher ranks, although always making clear of what is the hierarchy, as to avoid power fights and anarchy of team direction: the team must still behave as one, work with the same goal in mind and the same path to that goal. A strong leadership will make sure that all team members know their role and tasks in the team path to the goal, it will make sure that all team members stick to the plan, and that the team works and behaves as one.

Growing people

When making people grow, we must assign adequate tasks for them. An “adequate task” means that it can not be something the team member finds overly easy, nor overly difficult. The task must be just a bit above the current skills set of the team member, allowing him to learn something without overwhelming him.

In order to do this, we must know our team very well. We must know our team members individually, their skills, their strengths, their goals, their interests. The mix of those four quadrants will clearly identify the role that team member has or should have in the team, as well as to what type of tasks he should be guided to.

peoples drive dimensions
The Geek’s Guide to Leading Teams by Patrick Kua

In the four quadrants above, the only one we can really influence is the Skills. The remaining three are very personal dimensions, and although they can still be influenced, there isn’t really much we can do about them. Nevertheless, we must be aware of them so we can use each team member where he will be more motivated and productive.

When it comes to influencing the team members skills set, we can have several types of learning activities:

  • Team code reviews
    • The whole team gets together and discuss a piece of code in the application. Here its important that the code choice and the approach taken doesn’t make the code author become defensive;
  • Pair programming
    • Colleagues produce some code together, side by side;
  • Brown bag sessions
    • Colleagues lunch together and one of them talks about a subject;
  • Video/book club
    • Colleagues discuss a video talk or a book chapter and how it can apply to the current team context;
  • Technical retrospectives
    • A team talk about how a new or old part of the application works;
  • Spike showcases
    • Showcase the different things we have learned recently and spread the knowledge.

Leading

Why do we need a team leader?

When we work alone on a project, we have a clear goal, we have a plan and we know what is the path to get to that goal.

However, when we work in a team, even if everyone knows what is the end goal, if there is no coordination everyone will have their own plan to reach the end goal. Well, I think any sensible person can imagine that, if in a team of 5 people everyone follows their own independent plan, in the end, the result of those 5 plans will not match together, and a lot of time and effort will have been in vain.

Hence:

  • The team needs a common plan;
  • Every team member needs to know exactly what he is supposed to be doing at any given time;
  • Every team member needs to have his own clear goal within the project and team context;
  • There must be no blocking issues for any team member;
  • The team must work as one;
  • The work result of every team member must be in a similar fashion, which does not mean it must be identical: There must always be room for individual creativity and experimentation in a failure safe environment.

These are things that the team can not do on its own. There must be coordination, there must be a higher power to be responsible for the decisions made, and take action when the team can not.

This is the role of a team leader.

Power

Being a leader is, in fact, the capability to influence people. This capability, in turn, depends on having some kind of power over people, hence the relation between leadership and power.

Studies about power, identified five primary types/sources of power:

  1. Power from position, which has no value if the team does not acknowledge it
    1. Legitimate
      • Given by the assigned hierarchical position;
    2. Coercive
      • The power to punish;
    3. Reward
      • The power to reward;
  2. Power from personal traits, which is given by the team and not by corporation
    1. Expert
      • The power given by knowledge or information that others don’t have;
    2. Referent / relational
      • This is the most effective type of power, as it relies on respect and the desire of people to be somehow related to the leader. Commitment, integrity, humility and protection towards your followers are the most important traits in a model of leadership based on relational power.

When being leader, specially if leading several teams, we will need to delegate leadership upon others. When this delegating is related to a specific position, it should be done formally and publicly as to give legitimate power. However, it is not always the case that delegating leadership is related to a hierarchical position.

For example, if we are leading a development team and want one of the team members to have more influence over others in order to have the others follow his technical ideas and guidance, we can subtly and informally praise his technical skills before the other team members, with the intent of giving him power of expertise, making him a technical reference/leader within the team.

The dev lead must be an active developer

A development team is mostly a team of developers and, although not always the case, the dev lead must be an active developer, at least 30% of the time. This doesn’t necessarily mean it must be the best developer as the set of needed abilities is quite different. He must, however, be able to extract knowledge, commitment and performance from the team members.

Vision

The dev lead must have a vision for the project, both technically and business wise. In other words, the dev lead must have long term goals established, and the team must be informed about those goals, otherwise the team itself will not have a clear goal, therefore no commitment and no motivation. It will simply be drifting.

Share leadership

Sharing leadership is the way to empower the team, involving the team members in the decision making process. This is done by asking them for the information needed to make the decisions as well as advice on what the decisions should be. Such approach will provide the foundations for a very motivated and committed group of people.

Value people

Valuing people is yet another way make team members more engaged and motivated to the team goals and projects. People need to feel they are valuable for the team and that their work and efforts are appreciated.

Display authenticity

The leader should do all of the above because that is who he is, not as a mean or strategy to get what he wants. Emotionally intelligent people will easily see through a fake leader.

Engaging

According to Ken Wright, one of the most important things when managing people is engagement. Engaging people in the team and the project at hand can be quite difficult, but there are guidelines.

Engagement is actually the level of emotional commitment to the leader, and is critically important to the team performance. Studies say engaged people are 30% more productive than disengaged people, and it all seems to come down to the empathy with the leader.

Here are five keys to be an engaging and inspiring leader:

  1. Face challenges: Great leaders have the bravery to face challenges and deal with them in an honest way;
  2. Win trust: Employees are more productive if they work with people they trust;
  3. Be authentic: Don’t pretend to be someone you aren’t;
  4. Earn respect: Behave in an ethical way to earn respect from those around you and will help create a feeling of pride, loyalty and engagement;
  5. Stay curious: Knowledge and innovation can come from many places. Stay on the look out for knowledge and valuable people and incorporate these advantages into your business.

Supporting

A team lead must be able to know the team members, their goals and motivators, in order to provide them what they need to improve their motivation, attitude and performance.

The Maslow pyramid of needs can help understand what are the priorities for a person and how his personal life events influence his productivity and commitment to the team. For example, its common and understandable that a student who has a difficult family life has more difficulties to perform in his studies. In the same way, its important to understand that a team member who just moved to a new country, a new city or simply to a new house needs to stabilize, to feel safe, before he can be fully committed to his professional project.

Maslow's_hierarchy_of_needs.svgHelp your team members have a healthy and stable life, help them believe in themselves, care about them, develop them, inspire them and they will be focused, engaged and highly performant!

Level 5 leadership

In 2001, Jim Collins published a book about a leadership model he called “Level 5 leadership“, which became a reference in business and leadership. Although not criticism free, it brings up interesting concepts and ideas about the traits a team member should possess.

Level 5 leadership consists of the duality, some would consider to be paradoxical, of professional will and personal humility.

  • Professional will
    • Creates superb results, a clear catalyst in the transition from good to great;
    • Demonstrates an unwavering resolve to do whatever must be done to produce the best long-term results, no matter how difficult;
    • Sets the standard of building an enduring great company; will settle for nothing less;
    • Takes personal responsibility for poor results, never blaming other people, external factors, or bad luck.
  • Personal humility
    • Demonstrates a compelling modesty, shunning public adulation, never boastful;
    • Acts with quiet, calm determination; relies principally on inspired standards, not inspiring charisma, to motivate;
    • Channels ambition into the company, not the self; sets up successors for even greater success in the next generation;
    • Does not take credit for the success of the company, giving it to: other people, external factors, and good luck.

According to Jim Collins, each of 5 leadership levels reflects a specific set of leadership behaviours:

level type characteristics
5 Executive Builds enduring greatness through a paradoxical blend of personal humility and professional will.
4 Effective leader Catalyses commitment to and vigorous pursuit of a clear and compelling vision, stimulating higher performance standards.
3 Competent manager Organizes people and resources toward the effective and efficient pursuit of predetermined objectives.
2 Contributing team member Contributes individual capabilities to the achievement of group objectives and works effectively with others in a group setting.
1 Highly capable individual Makes productive contributions through talent, knowledge, skills, and good work habits.

Situational leadership model

Is it ok to direct people? Yes! But not always.

There are many leadership models out there (behavioural, transformational, servant, level 5, …) and they all can be helpful. However, the situational leadership model helps us identify what type of leadership is the more adequate to have with each of the team members, depending on what is his profile and his current task at hand.

The slide bellow shows the path of a team member, all the way from an intern to a highly skilled and motivated collaborator. As his knowledge and motivation shifts so should the leadership type, moving from a directing leadership style when the individual has low experience up to a complete delegating style when the individual is experienced and motivated.

situational leadership
The Geek’s Guide to Leading Teams by Patrick Kua

Performing

Consistency over cleverness

  • Cleverness is the need we have for using the latest coolest thing out there, and doing things the best way… The problem is that “the best way” for one person might not be for another one, and if we all try to do it “our best way” the team ends up doing things in very different ways, each dev going their own direction, and having numerous time wasting discussions of which is the “true best way”;
  • Consistency is about making a decision on how the team is going to do things, like coding standards and technology toolkit, and sticking to it. There are far more important discussions to be made, serious and difficult algorithmic and architectural problems to solve. We can not waste time, energy and effort trying to impose our own personal preferences.

Team culture

  • The team should strive for excellency, for quality, for making sure we have green builds as much time as possible and fixing issues quickly;
  • The team should not avoid conflict, the team members should be able to, instead of quietly refactor each others code to suit their views, have a normal and rational talk and decide on what will be the way things will be done;
  • The team should have a safe environment to fail. Team members should feel comfortable offering new ideas, trying new approaches and failing at them. This is how people learn and evolve, and as such, the team;
  • Team members must feel comfortable to ask for help. It makes no sense to have a developer stuck on something that a colleague could easily help him get out of;

Strength in personality diversity

We should focus on our strengths instead of our weaknesses. Not to say that we should not personally, or as a team, address our weaknesses in order to improve them, but a team lead must be aware of the strengths in each team member, and use those strengths to the team advantage by assigning specific task types to the most adequate team members.

To better match tasks to team members, according to their personality, we must understand what the task implies and demands from who ever is going to do it, and we must also be aware of personality types and how they can leverage an advantage.

There are studies made, that can help identify personality strengths and match them to specific types of jobs and tasks. Its also the type of personality characteristics we should search for in a CV, either by the candidate explicitly mentioning them or by reading through his past job descriptions.

Tom Rath identified several different personality strengths, some of them are, for example:

Strength Description
Achiever People that have a great deal of stamina and work hard. They take great satisfaction from being busy and productive.
Activator People that can make things happen by turning thoughts into action. They are often impatient.
Analytical People that search for reasons and causes. They have the ability to think about all the factors that might affect a situation.
Communication People that generally find it easy to put their thoughts into words. They are good conversationalists and presenters.
Input People that have a craving to know more. Often they like to collect and archive all kinds of information.
Strategic People that create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.
Woo People that love the challenge of meeting new people and winning them over. They derive satisfaction from breaking the ice and making a connection with another person.

Agile fluency

Aside from the Situational Leadership model, there is a another one that I consider highly relevant as it connects closely to the Agile methodology.

L. David Marquet tells us about a paradigm shift when it comes to leadership. This change is a reflection of what some other leadership models tell us as well. However, I liked his approach specially because he makes a very clear and pragmatical speech about why and how we should do it:

Stop giving instructions and start giving intent!

Then, your team members will need to discover the answer, will need to think, and the psychological ownership shifts to them. It’s about giving control to the team, but for this they need the technical competence (how do we do it?) and the organizational clarity (should we do it?). Its not easy to do, but this way you will have a team of thinking, active, passionate, creative, proactive people!

The main task of a leader is creating the environment for thinking!

According to Martin Fowler, this mindset change is one of the most important and yet difficult things to achieve in order to be able to reach a highly performant agile team.

Diana Larsen and James Shore wrote a valuable paper about agile and specifically about the levels of agile fluency / usage that they have observed in companies and teams.

Ajile fluency levels

Levels of Agile Fluency:

  1. One-Star Teams Create Business Value
    • The first stage – the “one star” stage–requires a team to learn to work together to focus on creating business value rather than merely finishing technical tasks. In return, the organization gains greater insight into the team’s work, and has more opportunities to influence that work in positive directions. This star reflects Agile fundamentals.
    • Teams on this level plan their work focusing on building added value, new features, improvements, bug-fixes. They work in a basic technical agile way, with clear tasks, reporting to management, and working collaboratively.
    • The biggest challenge is the shift in team culture: They must learn to plan in terms of business value and work as a team.
  2. Two-Star Teams Deliver on the Market’s Cadence
    • Achieving a second star requires a team to invest in learning a wide array of development skills. This star reflects Agile sustainability. The skills don’t come easily, and it’s often frustrating to go back to basics, especially for senior developers. But with time and adequate organizational support, the team gains the ability to create and ship low-defect software as frequently as the market will accept it, which gives the organization new opportunities for achieving return on their software development investment.
    • Adding to the ability to build added value, these teams can ship at will, fast and whenever the task is done.
    • A team in this stage uses techniques as continuous integration, test-driven development, pair programming, and collective ownership.
    • At this stage we have higher quality software, minimum technical debt and dramatically improved responsiveness to the market.
  3. Three-Star Teams Optimize Their Value
    • The third star represents the promise of Agile: a team that dances and turns in response to changing market conditions, and collectively takes responsibility for building the best product your investment can buy. Achieving this star means business experts must join the team as full-time contributors, and while this change to organizational structure takes time and effort, it pays off in the team’s improved ability to serve your business.
    • A three star team steps up to the point that the team has profound knowledge of the business and naturally uses its terminology.
    • The team is aware of the business market, can even predict it, and make educated business decisions.
    • It does require, however, a change in the company culture as people in the organization must learn to trust the team and its use of Agile in order to give it the power it needs to make business decisions.
  4. Four-Star Teams Contribute to Optimizing the System
    • The fourth star represents Agile’s future. Four-star teams collaborate with other teams to optimize the value produced by their whole organization. Reaching this level requires whole-system thinking and a willingness to experiment.
    • The team is fully aware of its work impact in other parts of the organization, and cross references and innovates with other teams.
    • It happens in organizations where trust is high, communication overhead is low, and business information is widely shared, mostly seen in single team start-ups.

Time for you!

Also very important for the process is that, the team lead actually takes time for himself, for his work, for unblocking others, planning and preparing. This time, although almost invisible to others, can in fact be exponential as it affects the whole team organization and focus.

Time for me! Planning!
The Geek’s Guide to Leading Teams by Patrick Kua

Conclusion

The most important element to have a high performing team is to have a great leader in front of the team.

Although many of this things might seem obvious and might come naturally to some, its not the case for most people. Few persons are an innate manager and/or leader, and not everyone has even the profile required to grow into a great manager and/or leader. Nevertheless, its important to note that people can learn to be great managers and/or leaders, as long as they have the base personal structure and are open for learning.

Many things postulated by the referenced models are repeated within several of them, meaning they are quite consensual. This helps in establishing what might be the most relevant traits of a leader.

The way I see it, being a great leader comes down to these few personal traits:

  • Show strong determination, so the team knows there is someone in charge, fearless, who believes in the project and in them;
  • Choose team members that can form a brilliant team, not just a group of brilliant people working on their own;
  • Create a collaborative atmosphere, creating a “safe to fail atmosphere” where people are not afraid to have a finger pointed at them when they fail. Protect them when they fail while doing their best, and immediately crush any behaviour that threatens the “safe to fail atmosphere”. Completely abolish words like “I”, “me”, “you” and related: replace them all by “we”, even when it doesn’t make grammatical sense. This will decrease even more any personal interpretations and strengthen the idea of team;
  • Be humble and protect the team, praising the team when they perform well, building up confidence in themselves. A leader must never boast or take personal credit for individual or team good performances. The team is key: The team should take responsibility for all success, and the leader should take responsibility for all failure;
  • Involve the team in decision making process, giving them ownership, which translates into strong commitment and motivation;
  • Be approachable at all times so team members can come up directly and quickly and easily solve blocking issues;
  • Cut down time and energy waste, by making accessory decisions (like coding standards) as soon as possible.

Of course, even though I feel leadership is the key factor in having a high performant team, because it is the root of most other factors, we must not forget all other aspects related to the team like choosing the right people, team building activities, team learning activities, understanding the stage of the team and individual team members and adjust our support accordingly.

Suggested reading:

Sources:

Published by hgraca

Published

3 thoughts on “Teams: building, managing, leading, performing”

  1. Pingback: Библиотека программиста — @alexeyfedko
  2. Pingback: Dev curricula – Java Việt Nam

Leave a comment