A software developer usually has two career paths to choose from. If the developer wants to eventually get into management, they will have to make a significant career shift.
The primary duty of a software engineering manager is to manage other people on the software team. They can no longer just think about the technical aspects of a software project. They have to think about things like budgets, working with other departments, dealing with personnel and many other nontechnical dependencies of a project.
It’s not for everyone. Many software engineers prefer to stay on the technical track. It’s not an easy decision to switch from being a pure technical software developer to a manager. Just because a software developer may excel at creating quality software, doesn’t guarantee they will be a successful software manager.
Being a successful manager requires many nontechnical skills you won’t learn by developing software … people skills, the ability to work well with others, communication skills, soft skills, and many other qualities that take a lifetime to master.
Furthermore, it’s not so easy to switch back from a manager back to a software engineer. Being a software engineer requires constant training and on the job experience writing code.
Technology moves so quickly that it’s absolutely crucial a software engineer continues learning new things. There are always new programming languages, programming frameworks, new development methodologies to learn. You simply can’t afford to stand still and be content with the technical knowledge you currently possess.
It’s amazing how quickly your technical skills can degrade over time if you’re not constantly developing or enhancing existing software. Imagine a software engineer who decides to try being a manager for a few years. They will likely not be able to do anything but manage. There simply won’t be time for a manager to write software. I’m not so sure it would be easy for a technical manager to switch back to pure software development.
And for some software developers, that’s exactly why they stay on the technical track. From junior developer, they progress to senior engineer and then … what’s at the top of the technical food chain?
It’s the title of Software Architect (there’s many other variations on the name like Solutions Architect, Enterprise Architect, but the core job responsibilities are mostly the same).
What Exactly Is a Software Architect?
A software architect isn’t much different in basic theory than a building or house architect. A building architect is responsible for designing the overall blueprint of a building … the foundation, the floor plans, where all the plumbing, electrical wiring and all the other requirements that need to go into a building.
When the architect is done finalizing the blueprint design, the actual construction crews can take the design blueprint plans and begin working on the actual construction of the building.
Software architects operate in much the same way as physical building architects. A software architect thinks about the overall design and architecture of a digital system.
What I mean by “digital system” doesn’t necessarily mean a single software application, though it certainly can be. Architects are often required to think about software at a much bigger scope.
For instance, enterprise architects can often be tasked with a project that spans multiple applications and systems. Often times, an enterprise architect is tasked to figure out how to get different and external systems to communicate successfully with each other.
Easier said than done.
Many organizations have written software and applications written over a great many years. That means the earliest applications were written in older programming languages and frameworks and newer applications written in different languages and libraries.
Sometimes the original applications and frameworks were written so long ago that there’s no one still at the company who knows how those original applications and systems worked … they just keep humming along with duct tape and prayer that they won’t catastrophically fail down the road.
Yet the enterprise architect is often tasked with figuring out how to integrate these ancient and legacy systems with newer applications and systems.
Not an easy task by any means.
And that’s just the technical challenge piece of the puzzle. There’a also figuring out how those ancient legacy systems worked from a business perspective. Try figuring that out when most if not all the original designers and business analysts no longer work at the company.
There’s also the challenging task of working with a myriad of people across the organization … business analysts, project managers, product owners, company executives, sales people, marketing people, pretty much every cross functional team that can exist in an organization.
Then there’s the technical challenge of figuring out how to build the NEW system to integrate all these different moving systems together.
It’s why software architects must have lots of proven experience and knowledge about an organization’s technical systems and business knowledge on how the organization makes money.
It’s not uncommon for organizations to require a minimum of five to ten years experience from an employee working within their own organization, to qualify for a software architect position.
It’s why you usually don’t see companies advertise for software architect positions to the public … they want a software engineer who has been with the organization for a significant number of years who knows how their business operates.
It’s the reason why technical architects are usually the end of the road for software engineers and their overall career path. It’s about as high as you can go on the technical track, if you don’t want to end up in management or the C-level executive track.
So What Exactly Do Software Architects Do?
Well not only do they have to think a lot about the initial design and architectural requirements for a new application or system integration, they have to work with the actual “ground soldiers” who are responsible for actually implementing all the architectural designs and plans the architect has come up with.
One of my previous employers would assign each software architect to a different software engineering team. For the duration of a particular project, the architect’s primary focus was to help the engineering team answer any architectural and design issues related to the project. They would help engineer’s and answer their technical questions and offer recommendations on how to implement something.
They were very useful for asking important business domain questions and review actual software code.
I found it extremely helpful to have a dedicated enterprise architect who worked directly with us software engineers. I could rely on his subject matter expertise on the business domain of our organization as well as his extensive technical experience he acquired over the lifetime of his professional technical career as a software engineer and architect.
Pairing up software engineers to senior architects is also a great way to groom future architects, much in the same way journeyman/apprentice carpenters, electricians, metallurgy craftsmen pair up with the senior and most experienced members of their particular tradecraft, so that one day those same junior level workers end up becoming the new senior-level master craft architects.
I’ve noticed a particular problem with the way some architects act and behave. They sometimes forget what it was like being a software engineer.
Some architects can obsess about architecture, design patterns, proper coding patterns and best practices to the point where what they recommend to the actual software engineers is it gets too abstract and disconnected to the actual implementation work involved in completing the project.
I sometimes hear this complaint amongst other software engineers who complain about architects in their “ivory tower of abstraction”.
It’s easy to fall into the lure of design patterns, new frameworks, new development methodologies that it’s easy to lose sight of the fact that the most important part about software developing is creating SHIPPABLE SOFTWARE.
Every software engineer and architect should never lose sight of this fact. We don’t get paid to write software just for the sake of writing software. The whole reason why companies hire software engineers and architects in the first place is because it helps the company either save money, time, or create new revenue streams.
I think one disturbing observance I’ve seen with some architecture teams is that they’ve stopped coding. They talk about theories, and design patterns and very high abstracted concepts, but I sometimes wonder if you actually plop them in front of a computer and ask them to write some code, if they would be able to remember how to do it.
This software architect gap is unacceptable. Every four-star general and admiral in our military didn’t start out at the top. They were all foot soldiers and sailors at the beginning of their career. In order to lead from the front, an officer needs to have come up through the lowest ranks.
Software architects are no different. They need to come up the technical ranks much in the same way.
And more importantly, they need to continue to write software and help other software engineers with their own software.
Do what I say, not what I do? Yeah, I don’t think so. Or else you’re going to have a bunch of irate code monkeys who’ll conclude maybe they won’t need the architects to get the job done.
