Tag Archives: small teams

6 secrets for successful small teams

Managing small engineering teams is fun. You’re close to the technology, close to team that’s writing code, and solving problems hands-on. Don’t get me wrong: it’s satisfying, rewarding, and impactful to manage large teams, but there’s nothing like being in the details and seeing a product come together. You lead a small team, by being an example that folks can follow; in contrast, you manage a large team. It’s different.

Here’s six things I’ve learnt along the way about leading small teams. This post was inspired by Greg Brockman’s 6 secrets for building a super team — Greg explained how to hire a small super team, and this is my sequel on how to make it world class.

1. Lead by Example

I’ve seen newly-minted leaders of small teams fail. One of the common reasons is they stop doing what they’re good at: being technical. And when they stop, engineers stop following them. Engineers want their leaders to be driving engineering, working on the hardest problems, and setting an example.

Great leaders of small teams are at least 50% technical, they spend more than half of their time writing code, creating designs, proposing architectures, doing code reviews, solving technical problems, or otherwise getting deep in the details. They know everything that’s going on in their team — they’ve got the right people working on the right problems, they’re driving the people at the right pace, they’ve holding people accountable for doing everything the right way, and they know the teams’ designs and code like they know their own. In the other 50% or less of their time, they’re passionate and focused on process, people, teams, and leadership — they have just the right amount of process to keep the team on track and happy, they’re managing their dependencies, and they’re spending time growing their people and team.

2. Set clear, simple goals, with clear, measurable metrics

You won’t be successful if you don’t know what success is. It’s surprising how many teams build a product without a way of measuring whether they’ve been successful, deciding when they need to be successful, or even without knowing where they’re headed. You should always start with goals and metrics.

Let’s suppose you’re leading the home page team at a major web company. You’re charged with leading a team of seven engineers, who together build all of the components on the page, and deliver everything from the platform pieces through to the pixels. You know who your competitors are, and you’ve got some great ideas on how to build a better home page than they’ve got. You’ve thought about this — you know that owning the home page means you’re the front door to the store, it’s your job to get the customers inside so that they can use all the products and features that the other teams have built.

I’m a fan of having two or three clear goals and objective ways of measuring them. You might decide that success is having the acknowledged leading home page on the web. How might you measure that? Here’s two or three ideas: first, you have lower abandonment than your competitors (lowest percentage of visitors who don’t click anything); second, you win a head-to-head taste test against your competitors at least 2/3rds of the time; and, third, your page is faster to load that your competitor’s. These are all criteria you can measure on a daily or weekly basis, and you can track them and share with the team.

If you want to create drive, fever, and passion in your team, consider setting a Bold Hairy Audacious Goal (BHAG) date. Decide that you’re going to have the best homepage by January 1. Put a graph up on the wall with the months on the x-axis and your objective, measurable success criteria on the y-axis. Every week, update the points for you and your competitors. Huddle the team around the graph, and work together to make success happen. You’ll be surprised how effective this can be in firing up your team, and getting creative ideas into the product.

3. Balance the portfolio

Small successful teams spread their bets. They have many small projects going on, and a couple of large ones. Importantly, the vast majority of the projects are impactful — they’re projects that are pushing the team towards their measurable goals. Good teams avoid doing work that doesn’t matter.

Why are small projects important? Well, first, they mitigate the risk if a large project gets delayed or doesn’t hit paydirt. Second, they give the team a real rhythm: every week there’s something new going out that moves the needle, and the team stays fired up and on track to their goals. Doing only large projects can be a death march — and it’s hard to keep teams fired up on one of those.

4. Meet the team

You have to know your team to be a successful leader. You need to understand the people who work for you, and customize your style to get the most from them. Some folks will need more advice, others will need to be pushed, some will rebel if you push, and some just need to know the goals and be given plenty of space. There’ll always be some conflict brewing, and everyone will have something on their mind that they want you to know — and the only way to find it out is to meet them regularly, really get to know them, build trust, and help them be successful.

I recommend a weekly 1:1 that’s at least 30 minutes, and not focused on the day-to-day. Ask questions in a 1:1, and leave plenty of white space in the conversation for the person you’re meeting to talk to you. Listen to what they say, and ask more questions that explore what they’re saying. Most importantly, be open and honest — say what you think, and it’ll likely work both ways. Conversation is key to being a successful leader.

5. Keep it simple

When the team’s small, you don’t need onerous process, too many meetings, or too much email. I’d recommend a daily stand-up meeting as the basic tool to stay in touch: go around in a circle, and ask each person to say what they did yesterday, what they’re planning on doing today, and anything that’s blocking them from succeeding. Buy some hour glass timers, and make sure everyone stays under two minutes. Don’t allow point-to-point conversation, the meeting is strictly for broadcasting information (the 1:1 or 2:1 conversations can happen after the meeting). Tell the team you will buy them coffee and food if the meeting goes over 20 minutes, and work hard to keep it under 15. Keeping it tight on time and high on information content will ensure you get good attendance and participation.

My hour glass timers. A large one tracks meeting time (20 minutes), and the two smaller ones are for individual speakers (2 minutes each) — one for the current speaker, and one for the next speaker.

When it comes to tracking a project, I recommend simple (and so do most of the people I work with). If it’s six to eight people, you can track projects with sticky notes, a whiteboard, and a camera for recording key information. I’ve also used a simple spreadsheet, where engineers can record the list of tasks that they’re working on and the time they will take, and the sheet automatically burns down the time remaining and computes completion dates. All the engineer has to do is keep the list of tasks in the sheet accurate, and the time estimates up to date, and the rest takes care of itself. In either case, simple is the key — very low overhead for the engineers, and pretty simple for the leader.

6. Keep it small

What I’ve shared applies to teams of 4 to 8 people that work for one leader. Beyond that, the team isn’t small anymore — you’ll find it nearly impossible to be more than 50% technical, and still get in the 1:1s and run an effective team. I’ve met a few people who can do it, but they’re usually super experienced or have super experienced teams.

We’ve all heard the stories of small startups with a few employees doing amazing things (think instagram or pinterest). It’s often because they’re lead by technologists, who’ve set crisp goals, spread their bets, kept it simple, and know their teams well. If you get your small team leadership right, your small team can change the world — and small teams do regularly change the world. Good luck.


Managing small teams: the tools you should use

Bobby Kostadinov recently asked me the following question on twitter:

And I was curious enough to go ask my team at eBay, where we use yammer to have fun conversations like this one.

The net of it is the team prefers simple approaches over complicated ones:

  • Many folks prefer using sticky notes, a whiteboard, and a camera for capturing them
  • A few folks like a spreadsheet, probably one with a few macros that create burn down charts and statistics
  • Using tools such as Jira, Trello, and Github Issues is becoming popular in the team

My personal experience with very small teams has been with sticky notes, whiteboards, and simple spreadsheets. When I began my career in 1990, I used a whiteboard on my first team and a polaroid camera to capture it. Many years later, I used a simple spreadsheet, and sticky notes late in the project to close down bugs and those final few features. If I had my time again on a small project, I’d probably do exactly the same thing.

The people on my team are wiser than me — they’ve got current experience with small teams — and here’s a compilation of what they said.

The most popular method: a whiteboard, a camera, and sticky (aka PostIt) notes

Ravi started the conversation about a simple approach and says that “for a small team – especially if they are working on a new project – [the] best I have seen so far is a whiteboard with cards or sticky notes. Put tasks as sticky notes or write in a card, move it along the white board from start to finish. Annotate the sticky with blockers, etc. if required”. Ibrahim has worked at two other major Internet companies prior to eBay, and says “Wow. Sticky notes people. It’s the most ‘obvious’ answer to all this. Sticky notes, whiteboard, and a camera (to capture) is all you need”.

Mitch, who’s probably been around as long as me, has the same experience and agrees, except when a team is remote. In that case, it’s time to switch to tools: “hypermail, jira (or similar, integrated system)”. Farah is of a similar mind and agrees “… sticky notes with daily huddles work very well. But being remote I have a strong preference for documenting everything. Taking pictures of the whiteboard after every huddle and putting the images on a wiki might work.”

Use a Tool

Sri’s one of our Vice Presidents, and has a long and distinguished career at eBay from individual contributor all the way up. He has “seen most open source initiatives use Jira. The rich portfolio of plugins make it a great tool for both the teams and for the project owner. Nice thing about Jira is that the companion wiki (confluence, the one we run) can surface it neatly inline as well through simple macros.”

There were many votes for Github Issues, including from Utkarsh who says that you should use it if you “are based off github. Simple and just works.”

Another popular emerging tool is Trello, which quite a few folks recommended. Other tools mentioned were Pivotal Tracker, newcomer Asana, and redmine.

Use a Spreadsheet

Jon D, who’s a veteran too, says that he’d stick with a spreadsheet. “For such a small team, especially if co-located, simple is good. A spreadsheet (Excel) or MS Project (using only basic features) are sufficient”. He was supported by several folks, who pointed out that there are good spreadsheets you can download and use, and that Google Docs is a nice way to collaborate across the team.

Other ideas

A few other ideas were mentioned, including using email (Google’s Gmail has excellent search capabilities), groups on Yammer, a Wiki, and (urrggghhh!) Sharepoint.

Hope this helps you Bobby, and a few others out there! Looking forward to starting a conversation on this one…