40 years of engineering leadership evolution
There’s no field known for evolving as rapidly as technology. But what about the human side of software—how has engineering management evolved alongside its products?
Mickey Mantle has been building software and doing engineering management—writing about it, speaking about it, and managing engineers himself—for over 40 years. After starting off in the early days of computer graphics at the University of Utah and 3D computer graphics pioneer Evans and Sutherland, he worked at companies like Pixar, Broderbund Software, and Gracenote. Like many folks, he started off as an individual contributor and evolved into an engineering manager.
“There are a lot of things that have changed in our industry over the last 40 years—and a lot of things that haven’t,” he says.
Now as the CEO of his own company, Wanderful, Inc., he continues to develop software delivering apps for iOS, Android, Mac, and Windows. He also co-authored Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams with Ron Lichty, and also frequently gives talks and workshops on how to best manage programmers.
We got Mantle’s first-person take on the evolution of engineering leadership roles, from managers to VPEs and CTOs, and how those roles interact with their teams today.
What’s changed for management
One of the more drastic evolutions in engineering management is how organizational structures have changed in the last decade. Very flat organizations have emerged and have brought a new approach to designing workflow and management systems. But don’t let these flat organizations fool you: There’s always some level of hierarchy (implicit—if not explicit), even in the companies that purport to flatten out or remove it.
And Mantle doesn’t always think the end result of these changes is beneficial. “I’m rather dismayed, quite frankly, by the recent prevalence of flat organizations,” he says.
Which is not to say that flat organizations don’t work—they can work great for certain companies and structures. It’s when companies grow and they keep the model because “it worked for us when we started.” Or because other successful companies use it. Or for any reason at all, besides this actually benefits our company right now.
“What gets short shrift are things like professional development, making sure that people are actually happy and productive, and helping folks get their job done.”
“In these flat organizations, you end up with a tech lead responsible for major portions of a project and directing others,” Mantle says. “What gets short shrift are things like professional development, making sure that people are actually happy and productive, and helping folks get their job done.”
Mantle sees more company cultures where managing people really isn’t valued as much as strictly getting results from them. He advises avoiding the adoption of new organizational structures just because they’re effective for others. New isn’t always better.
That said, new sometimes is better. For example, you can’t talk about the evolution of our industry without talking about one of the most significant transformations in how we run engineering teams: Agile methodology.
“What Agile has done is empower teams,” Mantle says. “That’s great. It’s forced focus. It’s forced flexibility.”
We heard from Mantle’s co-author, Ron Lichty, on how Agile changes the role of engineering managers, who often gives presentations on the topic: If we are Agile, why do we need a manager? “There are a lot of things, often unseen and under-appreciated, that a good software manager does to allow Agile teams to work even better. Agile makes it so that managers can step away from projects and focus more on the people,” Mantle says.
Lichty gives plenty of insights into the answers to that question. Mantle elaborated on a few points for us.
“You need a culture that values management and supports your process,” he says. “But it isn’t always that way. If it were, there probably wouldn’t be as many flat organizations there are.”
One of the great things Mantle sees about Agile (done properly) is that managers aren’t directly involved in the projects. “Now, managers should be connected with the various teams and projects enough to know what’s going on, but they shouldn’t be actively participating in the team’s stand-ups,” he says. “They may occasionally sit in on the daily stand-ups and listen, but they’re not participating.”
“You need a culture that values management and supports your process,” he says. “But it isn’t always that way.”
That’s because true Agile managers have time to do things they never would have time for if they were directly responsible for projects. Things like recruiting new talent (even when there’s not an opening), advancing their team’s professional development, protecting their team, and advocating for them.
A successful manager’s role, in other words, has become less about delivering products and more about supporting and challenging the team to deliver their best work. “There’s a lot of work to be done on the technical side as well,” Mantle says, “but it’s hard to find time if you’re actually just managing projects.”
What’s changed for VPEs and CTOs
We’ve had software engineering managers as long as we’ve had software engineering teams. But there are the higher levels in the hierarchy, and in Mantle’s years, he’s watched these roles emerge from next to nothing.
“In many of the most legendary technology companies in the seventies and eighties, there was never a CTO,” he says. “These companies made great computers, chips, and software, but they never had a CTO. There may have been a VPE, but the role of CTO actually emerged more broadly in the early nineties.”
“Good CTOs are removed from managing projects and deliverables. They’re looking over the horizon. What’s out there, and what’s coming our way?”
He attributes that emergence to an increase in complexity of software and hardware technology. “There is a barrel full of things I didn’t have to worry about as a CTO in the 90s,” he says. “Cybersecurity, IOT, Open Source, and the explosion of languages/tools/frameworks for example. And in particular, DevOps – DevOps is throwing a whole wrench into how software engineering, even with all its flexibility, has to operate.”
Considering that the role has emerged and evolved over twenty or so years, it makes sense that the CTO role gets to handle much of the big-picture concerns around these issues. “Good CTOs are removed from managing projects and deliverables,” Mantle explains. “They’re looking over the horizon. What’s out there, and what’s coming our way? They must ensure that standards are established, which the VP of Engineering has to agree on.”
The CTO and the VPE are an interesting duality, particularly because, as Mantle says, a lot of people think they’re a CTO and they’re really not—they’re doing the job of a VPE. With the development of the CTO as a very technology-driven role, the VPE position has been able to evolve to a more people-centric role.
And the line drawn between these roles is not firm. There’s a shared understanding of the division of labor when things are operating smoothly.
“Often one side is more people, and the other is more technical,” Mantle says. “Typically a CTO can get by having fewer people skills, as long as the people reporting to her (if any) will, in fact, report to her.”
One shared responsibility is the technology offense and defense that’s an important part of every CTO’s and VPE’s job. Technology offense, Mantle explains, is about going out and finding the technologies that would benefit a company or team to use, making sure they’re using them well, and providing the resources needed to enable their use.
Technology defense, on the other hand, is making sure your company or team isn’t off exploring a bunch of technology they’ll never use. “That will only get you in trouble,” he says. “I’ve got so many war stories about finding out way too late what people have been spending their time on.
“Often one side is more people, and the other is more technical. There’s a shared understanding of the division of labor.”
To a degree, CTOs are handling the technology offense/defense for the entire organization. VPEs work in more direct contact with engineering managers, implementing standards and making sure that all their teams are working together on the right things.
What’s stayed the same
The thing that hasn’t changed in all these years, and across each of these roles, is as simple as it gets: These roles are really about managing and leading people.
“You’re not just managing technology,” Mantle says. “You’re managing people. You will have responsibilities for other things, but your primary focus should be the people.”
Mantle offers one of his favorite rules of thumb, which really drives this point home:
“In the end, all business operations can be reduced to three words: people, product and profits. Unless you’ve got a good team, you can’t do much with the other two.”
— Lee Iacocca, former Chairman of Chrysler
Mantle is reluctant to say that programmers are a different breed because everybody will say that about their own ecosystem… but, he actually thinks that they are. He’s managed mechanical engineers and hardware engineers in his career too, and he says the discipline that those practices require is different than the discipline necessary in software, where you can implement changes right up to the last minute.
A lot of great programmers don’t have formal degrees or professional training to teach them the discipline that other engineering types acquire in their professional development. And this is a prime example of how all leaders in the software engineering hierarchy can focus on the people over the product. Because you can always demonstrate and develop the traits that will make your team more successful.
“You’re not just managing technology. You’re managing people.”
“First of all, be a professional yourself,” Mantle says. “Exude professionalism and expect it of your team. Encourage them and coach them. Management is leadership, coaching, and organizational skills. One of the key things that I think a good manager has to do is help guide their people’s professional careers.”
In that process, you can steer your engineers toward what it means to be a professional — in this case, develop discipline and what it means to have it. But regardless of the degree of professionalism you’re working with, you’ll never change the fact that you’re working with humans.
We can’t predict what new roles and org structures will emerge in software engineering in the next decade, let alone the next forty years. But whatever new organizational models emerge and whatever technologies you implement, the aspect of managerial evolution that I can foresee decades into the future is that management is all about leading people. That will never change.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.