The Star System
Staffing a Software Engineering Team
The “Star System”. Roone Arlidge was one of the pioneers of this system, not in software engineering, but in modern media. As Al Michaels states in his book, “You Can’t Make This Up,” Roone believed in hiring the best, paying them the most, treating them the best with the finest benefits, expense accounts, and travel, but he also expected from them the absolutely best in return. And this strategy worked spectacularly, so much so that Life magazine called Roone “one of the 100 most important Americans of the 20th Century.
I wholeheartedly agree with Roone. In the age of generative AI, organizations do not need these seemingly massive software engineering teams, most of which are hired in bulk based on salary bands, ranges, and geo-locations, decided on by people who have never built software. What is needed in a software engineering team is the best and most talented engineers of all kinds of experiences who can innovate, architect, design, and lace together the pieces and parts generated by AI.
Today, the trend is large software engineering teams with a blend of high-cost engineers in the developed world and low-cost ones in India, Manila, Eastern Europe, or another developing region of the world. This is usually enforced by Finance demanding a “blend” of salary costs because, obviously, they know all about how to build a successful engineering team, and yes, I’m dripping with sarcasm. Or perhaps you, as an engineering leader, get “advice” from HR that your company needs to lower overall engineering salaries for some reason, even though the budget for the product or project stays the same, or you have to have a specific ratio of offshore to onshore.
Ignore them and use the “Star System”.
So, what should you consider when assembling this software engineering team based on the “Star System”? Let’s work backward with what you should NOT consider, or better, flat ignore. First, ignore the location of the engineer; it doesn’t matter. I have an engineer who works for me today, and from day to day, I have no idea where he might be. And I don’t care if he is in a hot tub in Antarctica. He codes solutions overnight, in his sleep, and all of his work is stellar. You want talent; the location is irrelevant. Second, salary, who cares? Do you want the best or not? If you have a budget of $5 million USD and pay all of your developers $300k and end up with 16 software engineers instead of the 90 or so you can get using the older model, don’t worry. As long as you pick the best, most passionate engineers you can find, those 16 engineers will code circles around a team built on the traditional blended salary and location model. The experience level doesn’t matter. If you pick the right engineers, you will end up with some entry, some mid-career, and some late-career engineers, but the important thing is that they will be passionate, know they are well cared for, and, as a result, will code like the wind; their code will be beyond reproach, and they know they will be treated well if they overachieve.
I can hear the naysayers now; what about bonding, Agile (I’ll have another post on Agile, capital “A” at some point), team interaction face-to-face, blah blah blah? Well, naysayers, you are flat wrong. Interactions? Are you serious? Have you ever met a non-socially awkward 10X software developer? No, neither have I. I once saw an Agile scrum team stare at each other for the entire stand-up with only a few halting words and the soft sound of shuffling of feet. Sure, getting people together in the same room for kickoffs of major efforts and the like can be highly useful, but a bunch of really talented engineers not only do not need the social interaction that comes with putting time in the office, they hate it. Don’t waste your time.
When staffing this mythical team, be on the lookout for creativity. Great engineers who are also creative can be found, and they are worth whatever you pay them. I once had a young engineer just out of college who was a fantastic software engineer and an art history major. She was amazing, not just with her code but her ability to take a few requirements on a whiteboard and a sketch or two and build it; and drag others to help her make it. These are the people you should prize.
Flexibility is a rare trait that can bring great dividends to your team. Engineers, at least most of them, get stuck . . . and they like it that way. They like staying in the same area of code; it’s comfortable, and they feel like they are THE expert. These inflexible engineers are the engineers that, over time, cause development inertia. They don’t want anything to change; they will resist anything new. While you can turn inflexible engineers around if you are starting new, what you wish for is flexible engineers who love a challenge and don’t care if you will break their Agile sprint and have them do something completely different. Flexible engineers don’t mind learning new skills; when you ask them to code something in a new language, they leap at the opportunity, not run away.
Passion is indispensable. When recruiting engineering resources, it is the first thing I look for. Passion manifests in many ways, including a determination to finish and finish well, a hunger for the impossible, and a willingness to do whatever it takes. The best-skilled engineer lacking passion isn’t a good candidate. You need that passion in your organization.
The Star System is not an easy internal sell, and as a senior engineering leader or CTO, you will find that there will be a great deal of opposition from support services that think they know better how to staff and hire. But it is worth the effort as your team will be far more productive, and you will exceed your company or organization’s expectations.