re: engineering management
notes on software development, leading teams and changing the way we work

Big Company Teams vs Small Company Teams

There are many common memes in the startup world. Always hire the best. Small teams are better than large teams. Fire problem employees quickly. Release early, release often. And so on…

Funny thing is, a lot of the people spouting these things have only worked in small companies and startups. A subset of them foolishly think that the same rules should apply for large companies. Maybe they should, but the real world has an obnoxious way of challenging your assumptions. It just laughs in your face. Allow me to introduce Stewart’s Second Law of Leading Teams (we’ll cover the First Law a little bit later):

Understand That You Don’t Always Get To Pick Your Team

First Draft Picks

When I first started in management, I was still in a senior development role. I read a lot of books and blog posts on management, specifically for software teams. Guys like Steve McConnell, Jim McCarthy and Tom DeMarco formed a lot of my early thinking. At the time, I was primarily developing for Windows so by the time I had to make my first hire I focused almost exclusively on technical skills. I followed a lot of the basic rules of interviewing and placed a lot of emphasis on the whiteboard coding sessions. This approach was sufficient and mostly successful (or so I thought).

My next position was also a senior dev role, but pretty soon thereafter I was placed into the official position of Technical Director. I had been involved in making a couple of hires prior to that, but now growing the team was my responsibility. At this time, the dotcom boom was just beginning and I was working for the interactive division of an ad agency. It was the stereotypical environment of that period: open space work layout with developers working in the same space with designers, producers and account managers. It was great place to work and I felt a need to help keep it that way. I wanted the people I hired to fit in and keep the cool vibe going. Without realizing it, I had started to focus on culture fit.

After two years at the ad agency, I had the opportunity to build a team from the ground up at another interactive firm. During the time off I had before starting the new job, I sketched out my ideal team structure. Given my penchant for subversion I drafted out a structure of small cabals, cross-functional teams of frontend and backend developers and information architects. I also added separate quality assurance and systems engineering teams. Although our technology stack was mostly Java on Linux/Solaris, I added a Microsoft cabal as well due to the needs of some of our clients. My primary goal was to have each cabal be less than 7 people and have them work on no more than 3 projects.

During that period, companies were hiring like mad. I had to hire quickly, so I seeded the new team with people that I had worked with previously and who wanted to work with me again. I also interviewed people and brought a few more people on based on both culture fit and technical skills. Over time, I realized I made a couple of bad hires, but I moved quickly to address those problems. All in all, my approach to team building had led to generally positive results:

  1. Assess technical and communication skills
  2. Look for self-starters
  3. Identify culture fit
  4. If you make a bad hire or have inherited a team member that is not a good fit, get rid of them. Quickly!

Over the course of my next couple of employers, my basic strategy continued to be successful in building teams. I was even starting to believe I was good at building teams. Of course, I hadn’t really been challenged yet.

What Do You Mean I Can’t Hire A Team?!?

Seven years ago, I started working for my current employer. I was taking over a team from a manager who was moving back to India. The team was about 14 people split between San Jose, CA and Seattle, WA. I was moving from NY and chose to work out of the Seattle office; San Jose was too clinical for me. Over the next three months, I applied a light touch in running the team while I was feeling them out. I learned who the really strong developers were, who thought they were stronger than they were and those who really needed to be doing something else. So, I set out to figure out the approved process for making the changes I wanted to make. That’s when I had my first encounter with the vaunted requisition, or req. Or, to be more precise, my lack of an encounter because I didn’t have one.

When I talked to my manager about the team and what I wanted to do, he just smiled with that Oh, silly boy! Let me school you as to how this works.“ look on his face. You see, large companies deal with hiring via reqs. In order to fill a position, you need to have an open req. How you get a req is usually a mystery, bordering on Cajun bayou voodoo. I still don’t really know how to get one. If someone quits on you, you might get a replacement req, but don’t count on it! If you let someone go, well…you’re taking a huge gamble there, partner! And, fill that req quick…they disappear as fast as they appear.

Speaking of letting people go, holy crap! For all the management training you’re forced to take about team building, you would think that your Human Resources department would understand the impact of having bad employees on the team for an extended period of time. Contractors are one thing and it was relatively easy for me to get rid of a couple of really bad ones. But, try and let a fulltime employee go. Although the general law of the land is at-will employment, pretty much every company has a performace plan process for “off-ramping” problem employees. On average, this process can take anywhere from 3-6 months!

For those of us who know the damage that low-performing or problem employees can cause to the morale and effectiveness of the rest of the team, what do you do? The usual approaches tend to be:

  1. “Manage” them out
  2. Wait for a reorg and let “nature” handle things
  3. Give them side projects to get them off the critical path

I’ve had to use all of these approaches at one point or another and it was never easy. The issue wasn’t so much that I had identified someone that needed to go, it was the time it took to get them gone. All the while, the rest of the team got angry or resentful because they knew there was dead weight on the team. However, corporate policy gets in the way of taking decisive action.

Up until this point, I had been used to having my own budget so hiring and firing decisions ultimately rested with me. I had a set amount of money to use for the year, so if I blew it that was my problem. But, in the Big Company world, you’re lucky if you even know what your budget is. It’s more than likely that unless you are a Director or VP, you have no idea. Or, even if you do, you don’t have the authority to use it as you please. When it comes to hiring, someone much higher up the chain controls that and they do it via the req.

Internal transfers fall under the open req rule as well. No req, no transfer. And while it is generally frowned upon for managers to try and hold onto their employees or block a transfer, it does happen. A lot. Headcount, in the form of reqs, is one of the major coins of the realm and no one wants to lose anyone.

Except…when your management decides to reorg. This is the only time that I have seen reqs open up, but it’s still a mystery on how the distribution works. If you’re lucky, you’ll get a few reqs thrown your way to fill a gap that the execs think you have which is generally wrong but, you’d be stupid not to take the reqs! The other thing that happens in this process is by far the most damaging. They give you resources. Not reqs, but people from other teams in the organization.

Why is this damaging? They were given to you, that’s why. You had absolutely no say in whether or not you wanted the person. You probably had no opportunity to screen the person before they were put on your team. Your execs probably thought:

“Hey! We’re SuperMegaCorp. We only hire the best! The very fact that they work here means they’re good. Enjoy your new resources!”


Stewart’s First Law of Leading Teams

So, here you are with these new people on your team that you know next to nothing about because you had no hand in selecting them. It’s worse than having a brand new hire that’s an unknown quantity. In that case, at least you interviewed the person and had some sort of opinion that led you to hire them. But now, you have a complete mystery and the only thing you know is that they made it through the door previously.

What many organizations fail to realize, especially for software teams, is that people are not interchangeable! Yes, your new team member may be very smart but are they smart in the way that you need them to be? Are they a specialist in an area that is completely unrelated to the skills needed for your project? If so, you have a 50-50 chance that they’ll be able to acquire the skills you need and become productive. Actually, I’m lying. Your chances are much lower than that. Much, much lower.

In order for your new team members to be successful you, as the manager, need to have followed my First Law:

Identify Your Desired Team/Organizational Culture

This is one of the only rules I’ve found that works for both big companies and small companies alike. If you work at a big company, you’ve probably been inundated with a lot of talk about your company’s culture. But, most cultures have sub-cultures. That’s where you come in. Within the context of the larger organization, define the kind of team you’d ideally want to run. I always try to run my team like a poorly-funded startup. This helps to create a sense of urgency and efficiency in the way we do things.

The thing to remember is that your new team members are probably as unhappy and wary as you are. They don’t know what kind of manager you might be; Dilbert’s Pointy-Haired Boss, Bill Lumbergh or a lunatic micro-managing empire builder. They are as afraid of what you will do to them as you are afraid of what they will do to your team and/or project.

The Third Law

Teams are formed in a variety of ways. You may have the luxury of picking every single member of your team and can be as discriminating as you want. In other cases, you may just be inheriting a fully-formed team (or a group of people who report to you on the org chart…they may not actually be a team, yet). And, in other cases you have a hybrid situation; an existing team with the ability to supplement it with new hires. No matter which situation you find yourself in, Stewart’s Laws for Leading Teams have proven invaluable to me throughout my career:

  1. Identify Your Desired Team/Organizational Culture
  2. Understand That You Don’t Always Get To Pick Your Team
  3. Communicate, Defend and Curate the Team/Organizational Culture

Communicate to your team the basic principles of your culture. This has to go beyond just writing slides and holding a meeting. Your actions must reinforce the ideals. Make sure everyone understands what type of team you’re building and that they buy into the idea. If there is no buy-in, there won’t be a team, much less a team culture.

Defend your team’s culture against negative forces. There may be some misguided corporate initiatives/processes that conflicts with your team’s goals. Another team may be trying to convince you to do things their way. Or, you may have one of those problem employees that either refuses to adapt or just wants to be an agitator. You know what to do.

Curate the culture by ensuring that the environment you create and processes you select support the team goals. You can’t identify and communicate an agile, high-performance culture (which implies a high degree of trust and discipline) and then go around micro-managing your team.

By following these three laws, you stand a good chance of ending up with the team you want. The real difference between small companies and large ones is the amount of time it may take for you to get the team you want and how long you’ll be able to hold onto them. Assuming you’ve managed to assemble your All-Star Team, you must now diligently follow Stewart’s Fourth Law of Leading Teams:

Get Out Of Their Way And Let Them Be Awesome

Your job is to be the shit umbrella, not the shit funnel.