Category: Insights

Hello,

Working with a high performance team is good for everyone, not only for the business. So this is something we should try to achieve. In fact, the people suffer if they are not managed properly to get must of each one.

I decide to write this post trying to help explaining how I achieve this. And that is totally possible if all people AND company are keen to it.

So let’s check my 6 steps do build a high performance team:

1 – Get the right crew

Pretty obvious and usually is something we are always trying to get.

But sometimes, we already have the right people but the problem is that we don’t know how to work with them. So, before think the people is not who you need, these actions can help to get the most of each one:

• Make sure you know very well the soft and hard skills
• Understand what motivates each one
• Try to assign tasks aligned with people expectation
• Gives equal opportunities to everyone: to talk, to ask, to decide, to act
• Try to organize the team and the project to get the most according to the skills and abilities of each one

2 – Build the team

Although the team is composed of by several persons, the team must have uniqueness in many ways.

That means all crew must be totally aligned. Walking to the same direction, looking for the same goals. This actions could help you to “build the team”:

• Share a clear vision of the project
• Present the project challenges and risks
• Make sure everyone understand what are they working for (at the company/business level)
• Care about the harmony among the members
• Create connections between the people (a Mentor/Pair system is very good for this)

3 – Care about the people

People work better if they are happy and comfortable.

No, we can’t solve all people problems, but if our company and us care about this and do actions to demonstrate it, this will reflect on people’s work.

The “job” and “go to work” should not be “one more problem” to anyone.

Others important aspects to care about: people confidence, technical preparation, expectations alignment, trust, freedom and autonomy.

This will provide smooth and enjoyable working hours to the team.

4 – Measure team’s performance

Of course, we need to know how our performance improvements are going.

Some metrics could be useful to measure the performance, detect problems and take actions.

Delivery Metric

Lead Time is the best metric to evaluate the team’s performance. Lead Time represents the time used from feature request to feature implementation in production.

The Lead Time can help to identity blocking situations, technical gaps, communication and process problems and, of course, team’s maturity level.

Quality Metric

Technical Debit could perfectly help us to evaluate the delivery technical quality. Make technical debit visible and analyse the backlog.

QA’s results and metrics can help to evaluate the delivery product quality.

5 – Keep the house organized

Bad organization causes waste of time, stress and disagreements.

We need to keep all cleaned and organized: tools, information, tasks, meetings, procedures…

• Use a good project management tool, like Jira
• Keep information centralized, organized and available for everyone
• Know and apply best practices of the tool and user stories
• Have a clear and well defined roles and responsibilities
• Control and avoid interruptions toward the team members
• Promote the knowledge sharing and transfer among the people

6 – Define short circles and milestones

The team must feel their job is important.

Even if we don’t use any Agile methodology, or even in a long term project, is important do define short life circles with start and end.

This will give the a periodic “mission accomplished” feeling. (Scrum Sprints are a perfect way to do this)

Although we have sprints or short circles. Some relevant/important milestones are crucial to the team healthy. For instance: releases, partial deliveries, third party integrations, new product releases, a specific numbers of users achieved, a specific sales amount achieved, a big technical improvement.

Define those milestones, get there as a team and celebrate. On each achieved milestone the team will get stronger.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”

Melvin E. Conway 1967

As many other cases, although was a long time ago, the law today is still valid.

Basically: organization structure equals system design.

Real life example

An organization based on the division of specialized departments like Front-end, Back-end, DBA, Infrastructure and so on probably will design and deliver systems the same way.

That means each department will work on their area and deliver they “part” of the system.

Work like that requires a lot of control, follow-up and synchronization. And creates a strong dependency between these departments.

About companies

Nowadays many companies want to migrate to microservices and many times they think that is just about break they systems into “small” services.

But before touching the code is necessary important changes on company’s mindset and organization to achieve independent teams with Ownership and Responsibility.

If the company is not keen to change (or adapt) won’t work with microservices and won’t get the real benefits from microservices. Maybe will have a lot of “small services” but not microservices in the essence. (see Microservices Manifesto)

To get there, the company needs (to get started):

• Dissolve those specialized isolated teams/departments
• Build cross-functional teams
• Eliminate bureaucracy
• Define the strategy to adopt (ci/cd, testing, accessibility, observability, scalability…)

About me and you

Most of engineers want to work with microservices. And also is getting prepared to work with it.

So how the Conway’s law affect us?

If we expect to be happy working with microservices but our company is not really doing the necessary changes, at the end we will be just working with a lot of “small services” on the worst possible scenario.

If you are looking for a job to work with microservices, try do know about the company during the interviews and find out if the company is really ready or getting ready to work with microservices. Some specific questions could help:

• How the teams are organized/divided?
  • Traditional divisions by “technology” (front, back, database…) — Is Bad
  • Division by business area, or by service(s) — Is Good

• What is the teams average size? (of course depending on the company size)
  • Large teams — Is Bad
  • Small teams — Is Good

• Who or which team is usually responsible for the deployment?
  • Another specific team or person deploy — Is Bad
  • The team deploys and scale its own service — Is Good

• How many teams work in one single service?
  • Multiple teams can change or work on a single service — Is Bad
  • A single service is maintained only by one team — Is Good

• If a team detects the need to change something in their service – like the database type for instance – can the team do it? or who should the team talk to?
  • The team doesn’t have autonomy and has to ask another team do the change — Is Bad
  • The team is autonomous; decide and execute change on its own service — Is Good

Conclusion

Conway’s law alerts us that if we are interested in work with some methodology, technology or pattern, maybe won’t be possible if the company’s structure/organization is not compatible.

Agile / Scrum and Microservices are a good example of cases that are only possible if the company changes its mindset and organization.