I'll never forget M.
M was my mentor, and we didn't get along. I chose him as a mentor because we didn't get along. I needed someone who had different perspectives than I did.
Anyway, one of our early meetings, I talked about people at work I admired. I said I idolized a guy we'll call Brad.
Brad was a guy I'd worked with many times. He was part of senior leadership, and he still found time to write code, on the evenings and weekends if necessary. At the time, his architecture team was embroiled in doing the scut work of rolling-out "Agile Development" to a hardware-development organization. (Another really long post for another day....)
M took a dim view of my man-crush on Brad. M was a Principle Engineer (there's another name for it there, but let's just call it 'Principle') and he took a dim view of people that "still write wrote code" at that level.
"Do you really think Brad should be writing so much code?" he asked.
"Umm.....yes." This was not the answer he expected.
I was slightly dumbstruck.
I'm writing today in defense of that "Umm, yes!"
I'm not so naive that I didn't get M's point.
He was thinking opportunity cost. Brad was paid about 5 to 20 times what developers in our offshore developer offices were every year. From a total cost perspective, it made more sense to have him lead 20, 40, or 100 developers and optimize their stuff and the overall systems architecture, versus him mashing a keyboard 8 hours a day pounding out embedded C code.
I get that. It makes sense, logically, but there are several fallacies there I'd like to discuss.
Fallacy #1: Outsourcing
Outsourcing and optimizing expense may just put you out of business.
Starting in the 1990's companies began to view their IT departments and programmers as a cost centers, and so they sought to outsource to consulting firms like IBM Global Services, or they spun up their own development centers worldwide and outsource.
A former employer of mine did the latter from 1998 onwards. Charitably, results were mixed.
One site got expensive and "insubordinate" (not that I blame them!), and another had to sustain 40% turnover year to year and a median developer age of 21. Combine that with a headquarters 12 time zones away, and results were predictable.
On the face of it, outsourcing makes perfect sense. It's better to have 100 developers instead of 10, or pay 1/10th the price for the same code widget. Profits go up, expense goes down...business school 101.
It doesn't always work that way. "Making outsourcing work" with a Business Analyst / Remote Dev team model is possible, with enough detailed specs.
However, for doing something new, this adds months or years to your product cycles and eventually you'll lose. Your competitor with colocated development teams will destroy you.
Fallacy #2: "Growing Beyond Coding"
We've all met that guy. We've even interviewed him occasionally: "Oh, yeah, I'm certainly good enough at the tech stuff, but what I really want to do is get into Management and Architecture, the place where the real decisions are made."
That statement always made me want to vomit.
IMO, anyone you want anywhere near your product won't have that attitude. We get into this business because we love solving problems, and we generally like the thrill of making computers do our bidding in the most efficient and AWESOMESAUCE way possible.
Almost twenty years in, I don't think you grow out of that.
Another (unofficial) mentor of mine, A, once told me, "You know who the real architects are? They're folks like B, and J....guys who make 100 decisions a day about how to do stuff in the system. They're the people implementing things, real technical leaders. That's real architecture."
If you can't tell, I agree with A very much.
The New Model (Developer) Army
So, if we're going to let Brad code, how will that work? He can't do the work of 100 people!
Wait, maybe he can. Much like Cromwell's New Model Army was much superior to Charles's royal cavaliers, a colocated team of senior engineers can do incredible work in small numbers.
What's really changed since the Architect > Business Analyst > Programmer model arose in the 1960's is the tooling. We now have high-level programming languages, IDEs, and test/integration tools that allow one developer to do the work of 20 from 1990 and perhaps 5 from 2000 when I started. It's entirely practical for a two-pizza-box team to deliver significant function, and that's the model most startups follow today. [Edit: Also, my current employer]
In sum, don't look at your 'Brad' developers and take them away from the code. They need it, and you need them to stay in it. Consider how you might rearrange things so they're still influencers across the organization and they're still making daily commits.
I believe you'll like the results.
Top comments (0)