Leading Software Engineering Teams At Scale
Todd Tidwell is an experienced software architect and engineering manager. We recently had a great chat about the differences between enterprise and startup software teams, and how to be a an effective engineering leader. What follows is a lightly edited transcript:
To get everyone up to speed, could you introduce yourself and tell us a little bit about your career?
Sure, I’m Todd Tidwell and I’ve been building software since before the original dot com boom.
Back in 1996, the internet was starting to take off and everybody knew there was something there, they just didn’t know what to do with it. I started with this small group at Sony Corporation of America. The whole purpose of that group was look at bleeding edge technologies, understand them, develop prototypes and then be ready when the rest of the organization was ready to use it.
We were doing XML before anybody had ever even heard the word. One of the first big projects I ever did for them was figure out if Java could be used as a CGI technology. At the time, you only really had two options for CGI: either write it in C and plug it directly into a web server or do it in PERL. We wanted to see if we could do Java and so I wrote what would be considered now a servlet container.
After that, I did consulting for companies like 3Com, Logitech, and Walmart and ended up being part of the original dot com explosion. I’ve worked for both big enterprise and startups for the last two decades.
What differences do you notice at a large enterprise, where software is one division, as opposed to a classic software ‘tech’ company? How does that look inside of engineering?
There is a big difference. If you’re not the classic software company—maybe you’re a construction company, an accounting firm, a bank, or even an electronics company—then software is a support role for everything else.
When you’re building software or other forms of engineering with bunch of geeks front and center, that’s your money.
Let’s take an enterprise example. Even at a title level, it’s a different ball game. A small bank is going to have a CFO, a Board of Directors, and a CEO or a Chairman. There’s going to be an Operations Officer. What you won’t find is a CTO. There is a need for technology but not at an executive level, so you’re really not going to find the need for a Chief Technical Officer.
When software directly starts to influence your ability to make money—and in this day and age, it’s becoming more pervasive—somebody creates a Senior VP of Information Systems who reports to the operations guy. Then sometimes, they’ll go a little further and they’ll create a CIO whose job is to deal with Information Systems but just calling it Information Systems is back-lining it to a support role.
Even so, the big difference is that engineering is always a cost center. It is always, from a management standpoint, a money drain. Why are we paying for these servers? Why do I need to have this software?
How does that dynamic influence the role of an Engineering leader?
A CTO in a company where software is the focus has more resources and a lot more sway in the direction of the company.
Imagine you’re the CIO of a bank. You walk into a strategy meeting and say, “I want to move our entire ecosystem to the cloud and I want to start offering services to our customers that take advantage of our new abilities to scale.” The decision makers are going to say, “What’s a cloud and how is that going to help our customers,” and you’re never going to explain it. You’re never going to get it over the goal line. Eventually everything boils down to, “If I move into the cloud, I can save you money.”
They’ll be good with that, and you’ll get to move into the cloud, but you will never get real input into the products that you’re building.
“A CTO at a company where software the focus has more resources and a lot more sway in the direction of the company.”
Now imagine you’re CTO of a software company. You walk into the room and say, “Hey, I’ve got an idea for a feature or even a secondary product that’s linked to the first one and I want to take ten engineers and point them at it. Here’s the idea… ” Everybody’s going to listen.
The CEO is going to listen, the COO is going to listen, the Board of Directors is going listen because they are a software company. It’s just the way it works and the bigger a company gets, the more that’s true.
Picture a small construction company of about 20 that hires someone to run IT and contracts everything else out. That IT guy might actually have a little influence on how they get to do time tracking, or how they run payroll. Turn that into a twenty thousand employee consulting company, the IT guy is going to have very little influence on how they deal with their people, how they run payroll. They’ll just do what they’re told.
How does that play out at the level of an engineer?
As an engineer, it’s always better to work for a CTO. And typically it’s going to be better to work with a company that’s doing software as it’s primary product.
It’s true even if you’re playing a backup role to that primary product. There may be some big fancy front-facing application that everybody is working on. Somebody still has to write the accounting system. Somebody still has to manage the accounting system. Somebody has to maintain the marketing website. Although you may be playing backup to that main product, it’s still going to be a better gig.
As far as scaling, what is your experience with adding head count to address a software problem?
Here’s the deal. We’ve all heard the phrase “nine women can’t give birth to a baby in a month.” I think it’s a paraphrase of Brooks’ Law, and it’s absolutely true. Some things are not divisible in a way that’s conducive to throwing bodies at the problem.
Reminds me of that NASA AMA on reddit…
You can obviously put more people on it, but at some point of any project, things boil down to a piece of work that only one person can work on. If you throw five developers at that project, they’re either going to be crowded around one desk all giving input and some poor sap having to type — or there’s going to be one on it and four sitting off playing Galaga in the corner.
The key is to break up work into pieces that one person can tackle.
How big can a team get before you need somebody dedicated to breaking up tasks for the rest of the team?
Five. At six, you need a person who chops stuff up for everyone else. It should be somebody that was an original member of the team. You want one person who does nothing but amplify other people.
Five seems to be a pretty good number because by the time you get to ten, you’ve got a lot of communication being lost. You’ll have two people working later hours than everybody else and they’re doing something different than the other eight on the team and that’s where it really starts to be a problem.
Somewhere around five, you need somebody watching out for the group. They’re in charge of who’s working on what and kind of the bigger picture, and this scales all the way up to about twenty.
At five or six, that team member is probably still contributing code. When you get up close to twenty, all they’re doing is managing the team.
Okay, what happens at twenty? You hire a couple more. Now you’re at twenty two, twenty five. What happens then?
You’ve got to think about moving those people to smaller teams. Any team over three, you’re immediately going to see natural leaders emerge. From the CTO’s perspective, a natural leader is immediately going to be the one that everybody’s going to go to for answers before they go to you.
You’ll start hearing a lot of , “Well, John said…”
If you’re hearing that from everybody on the team, then you need to have a talk with John because he’s already emerged as a type of leader, and you’re going to find two or three of those. There’s going to be somebody that everybody goes to for database stuff, another for UI, and so on. Immediately, you can start to pull those off into little groups.
How do you go about adding team leads into the chain of command? Is it a formal management layer, or more informal?
You can go either way. It’s all about culture at some point. Depending on the experience and age and even where people are from, you can figure out if they’ll respond better stronger, tighter, more defined structure, or if something more casual will be better.
That’s why I believe in the natural leader thing. When leaders emerge, these are people that someone has already decided they’re willing to take orders from.
“When leaders emerge, these are people that someone has already decided they’re willing to take orders from.”
You just go ahead and acknowledge it, but it doesn’t have to be super formal. The last couple jobs, everybody I’ve worked for and everybody that’s worked for me technically direct reports to the CTO above me. but they all know who’s in charge.
Flat organizations have been in and out of favor. Are you suggesting that even a flat organization needs some levels of hierarchy?
Absolutely. Somewhere over 25 or 30 people, you’ve got to really start thinking about it.
Flat organizations are a popular idea when a company is young, but what’s inevitably going to happen is that these little groups you’ve built, some of them are going to grow. Some of them are going to grow very fast. Some not too much. As those groups start to get as big as the original group, before you split it, you’ve got to think “how am I going to split that?” At some point, you’ve just got to say, “You know what? You’re in charge of all things UI and you’ve got twenty people.”
What do you think about companies that are trying to get rid of the management layer?
I think it’s a disaster waiting to happen.
Inevitably, there will be a team disagreement. Somebody will disagree vehemently and it will be because of experience or perspective or they’re smarter than everybody else in the room. But they won’t be able to communicate well to their fifteen other peers. They’re going to get overridden and that group is going to make a horrible mistake.
Whereas if there’s a hierarchy, they don’t have to convince fifteen different people, just one. A scenario of the one-on-one by the water cooler, and the whole disaster can be avoided without the pressure of the groupthink. That’s the difference.
“Hierarchy is important because somebody needs to make the tough calls, and only one person can own it.”
The other problem with that is when those fifteen people overrule that guy… Even when they realize they blew it, they’re not going to be willing to admit it. It’s human nature. They’re going to spend as much time denying and covering it up—more time doing that than it would take to fix it.
Hierarchy is important because somebody needs to make the tough calls, and only one person can own it. A group will never do it.
What are the most important things to focus on as an engineering manager?
The most important thing is you’ve got to take the time to understand and know the people that report to you. Not the people that report to the people that report to you. The people that report to you. You’ve got to understand their strengths and weaknesses, where they excel, what motivates them, how to inspire and encourage them, and how to help them when they get in a rut.
I hate the, “Everybody is a snowflake thing,” but when it comes to effectively managing people, you actually do need to treat everyone different. There isn’t a cookie cutter pattern. I can’t come in everyday and treat ten folks the exactly the same way. I’m not going to get the same results. Everybody has their strengths. Everybody has their weaknesses and you’ve got to manage around that. That’s job number one.
Job number two is to keep all the management, politics, and crap off their shoulders. You are their first line of defense. Those are the two most important things about managing anybody. Engineers or not. You are their first line of defense and its up to you to help clear the deck so they can do the best work of their careers.
Know an engineering leader that we should talk with, or want to suggest topic? Email us: email@example.com
Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.