Ted O'Grady

In order to build a great team you have to believe in your people. It is as simple, and as difficult as that.

Pick the right people

Everybody hires the top 5%. How can everyone hire the top 5%?

I pick my teams by looking for smart individuals who are passionate about what they do and enjoy learning. An open mind and willingness to learn and work with others is crucial. You do not hire a great team as a leader, you build one.

I have not found the magical programming question, personality test, coding test, or Aha problem, that will tell me that this person has the potential to be great. Sometimes I choose wrong. In order to maintain a great team, I must be prepared to correct those mistakes.

Passion and a willingness to learn ensure my teams will grow and enjoy hard challenges in their field. If you get the mix right the team will start learning from one another and pushing each other to build better software faster and then you'll have your high performance team. I love to work with people with passion and intelligence who can listen, argue and learn. Interestingly, these are the attributes that make having a team fun.

Leadership

What is your role as leader?

I have found that leadership in the field of computer science is tricky. Many view leadership and "chief architect" as being the same. Delegating coding to programmers who implement your vision. This model has not worked for me. The details of building something are much more difficult than I have ever been able to write down on a simple piece of paper, and usually I miss the subtleties of what people are saying, because at the beginning (middle and end) of a project I do not have perfect understanding of my users domain. My job as leader is to ensure my team has the tools it needs and the knowledge it needs. My job is to take away distractions that prevent my developers from solving the problem. My job is to ensure innovation is happening on the project. My job is to ensure learning is happening on the project. My job is to ensure the people on the team are heard. My job as a leader is to make sure the job my people are doing is important and communicate that importance to them. My job is to listen to my teams concerns and help them act on those concerns.

 

Management

My job as management is to track progress and report current status to the customer. I like to help them make trade offs and help them understand what they are asking for. A big part of customer management is in explaining the details. I find, that in the field of computer science, we underestimate the cost of the details.

My job as management is to watch budget. I need to to communicate overruns and actual costs. If we want to limit the budget of the project then we need to work carefully to manage features you need. If we want to ensure a set number of features, we need to carefully watch the budget (and projected costs) as well as prioritizing carefully.

Communicating is key. You need to find simple tools that communicate status quickly and accurately to the customer so that they understand.

If we want to ensure functionality is complete, we need to manage feature creep. Not everything we think of can be essential. We need to find ways to break up the problem and get it into production sooner. We need to watch the money so that it does not become an obstacle to the success of the project.

We need to keep the customer happy. It is a difficult line to walk, because software projects are expensive, hard to estimate, and hard to build. The very act of building software reveals the real requirements of the software. This is difficult for customers who are not used to the process of requirements discovery -> building -> more requirements discovery -> building -> ...

Innovation

Developers on my teams have always had great ideas. They like to think.

Thinking is the cornerstone of good development. Typing speed is not the bottleneck to development speed. It all has to do with how quickly you can think. Unfortunately there are no good techniques for making people think faster. Getting more people thinking, not just doing, is the key to making development go faster. Innovation depends on mistakes. If you are not making mistakes, you are not innovating, you are doing. Mistakes imply risk and risk comes with great returns, but requires a management structure that is risk tolerant. Teaching an organization to be risk tolerant, showing the benefits of making mistakes and the insight and learning that results is one of the key ingredients to building a great team.

 

Reading

Here are some books that taught me about innovation in management:

Becoming a Technical Leader - Gerald M. Weinberg - a book about Motivation, Organization and Innovation (MOI) and the different types of leadership.

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency - Tom Demarco - a book that has a bunch of Aha moments for existing managers if you want to create a great environment to build products.

How to Talk So Kids Will Listen & Listen So Kids Will Talk - Faber & Mazlish - a book about communication, the importance of clarity, respect and sincerity. Also good for raising kids.

High Performance Teams

Getting this all right does not guarantee a high performance team. Read about my attempts to create them on my high performance team page.