Perspectives from 5 years leading teams

After ending a great and rewarding journey I decided to compile some of the perspectives (kind of a retrospective) from my last years leading software development teams. Some of them learned the hard way, others from intensive research that had the opportunity to put in practice. In the end, it was a great experience and I look forward to learn even more in the future.

Hire the right people for the job

Many would say the best, but I say the right ones, why? First because it’s hard (impossible to be more precise) to define the best (by what metrics? how do you measure? – “Every company says they want to hire the best. Anyone who tells you they know how to do that is either lying to you or to themselves.”), and second because building a great team is not about hiring the top person for each position, but instead, having a mix of high-value professionals with potential-value professionals that, with proper motivation, can achieve amazing results.

That also means knowing what you’re looking for in candidates (The Guerrilla Guide to Interviewing (version 3.0) is one of the most interesting guides that I’ve found), specially people that adds something more to the team.

In the Macintosh Division, we had a saying, “A players hire A players; B players hire C players” – meaning that great people hire great people. On the other hand, mediocre people hire candidates who are not as good as they are, so they can feel superior to them. (If you start down this slippery slope, you’ll soon end up with Z players; this is called The Bozo Explosion. It is followed by The Layoff.) — Guy Kawasaki.

Provide the right culture

It’s important to provide the right culture that enables teams to improve their skills and processes, specially with high-value professionals. Continuous improvement should be taken as something very important and that’s only possible if the team is part of the process.

Safety is required for learning and learning is a continuous path which requires (many times) failure. So it’s important to address failure in a proper way and enabling it (not by allowing the same mistakes over and over again but by allowing learning with it). Improving means being critic about how you work.

In the end, “technology is the product of the culture that builds it”.

Tools and Frameworks doesn’t replace thinking

Today there’s so many options to help you (tools, frameworks, processes, etc) but none of them replace thinking. Things like processes and frameworks should be a starting point to adapt to the team’s needs and not the other way around – every team works differently.

Thinking is also very important for productivity. Anyone knows how bad multitasking is and how easy is to feel overwhelmed with all the things to do, but picking the right tasks and focus on a single one at a time will decide your level of productivity (something harder than you might think). That also requires work and thinking before acting!

Design things to scale systems not teams

Small teams moves faster (see for example Amazon’s Two-Pizza rule for teams) so the big challenge when building large systems is to have small teams that can contribute independently. A good way to achieve this is to have a good system design that allows teams to contribute with their part without breaking other’s components. This requires coordination between teams but it’s easier to scale systems than teams.

Refactor! Avoid rewrites!

Joel Spolsky, in his famous blog, gives an excellent explanation about Netscape tales from a rewrite and I think everyone has, somehow, experienced a similar feeling in a past project.

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

This doesn’t mean that you have to accept technical debt, but the better way to deal with it is to refactor and ensuring small improvements towards a bigger goal. Choosing the rewrite path as a high risk of being unsuccessful and put’s pressure to the team and to the business. So it’s important to allow time for refactoring as a way of improving (this also applies for code reviews, pair-programming, etc).

Ensure your team is an investment, not a cost!

This is very important not only to the team but also to the company. And this defines your ability to build great teams instead of fixing problems all the time.

One of the most insidious problems in Vernon’s experience is when an IT department is considered a cost center and the business views software development as something negative, a drain on the organization that merely cost them money. Such a business doesn’t consider software a game changer, merely something they have to tolerate.
Letting business people spend days writing specifications into a collaboration tool is for Vernon a huge waste of time. Most of the developers don’t use these specifications because they don’t contain the information they need and just leads to poor collaboration. Instead business people and developers should have conversations and in much shorter time come up with a solid design backing the business needs.

Be patient! Your team’s success is your success.

When you’re leading teams you no longer have simple measurable outputs (like it used to be as a developer) and your work becomes somewhat invisible to others:

As a manager, almost all of your work is done behind the scenes. As a result, being a manager becomes this “out of sight, out of mind” thing where some people will perceive you as doing very little work. This is because when I talk to an employee about their communication style and issues they’re having interacting with others, I do it privately. It’s not as if I can send a status report e-mail to the team that says “I had a chat with Person about their communication issues, high fives everyone!” As a result, nobody other than the person I talked with directly knows that the interaction happened. Thus, to others, it might appear that I never addressed the issue.

So you must rely on your team’s work and ensure that they have all the proper conditions. Although the goals may be defined (largely) as a team you should manage individuals, not teams. And 1-on-1 meetings will play an important role on your weekly tasks.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s