Can Great Engineering Leads Negate the Need for Enterprise Architecture?
This post explores the challenges in determining whether the value delivered by Engineering Managers (EMs) and Lead Developers (LDs) during each sprint requires the supplementation of enterprise architects (EAs) who are focused well beyond the current sprint or the next. This subject applies to the development of software applications, SaaS products and managed service offerings.
The Spectrum Spanning EMs, LDs and EAs
EMs and LDs are typically accountable and responsible (respectively) for shaping and crafting, char-by-char, config-by-config, the stories and features that have been articulated and prioritized by product owners and product managers (respectively). If the development shop were an assembly line, these folks are akin to the Kanban steps that cut up raw material and assemble the pieces of the product, per particular design specifications. Our perspective on this would characterize the nature of developing-to-spec as responsive effort in the realm of working on the business.
At the opposite end of the spectrum, EAs are accountable for a particular portion of the development specifications. They shape the realm that connects what is being developed at the present moment to where the organization is going in the future. This means that they need to review the specs that are going into the assembly line regularly, and reshape them based on long-term strategy if and when needed. Our perspective on this would characterize the nature of reshaping specs as proactive effort, still in the realm of working on the business.
The Rub – Agile and Developing-to-Spec
Many agile proponents reading this might be thinking, “We don’t develop-to-spec in agile! We let engineers figure out the ‘how’, and everybody around them should just articulate the ‘what.'”
To some extent, this statement is true. Any textbook user story should describe exactly what the functionality is supposed to accomplish, along with reliable test criteria. All things being equal, a seasoned full-stack software developer can execute said story by creating a data apparatus, middle layer/set of API components to interoperate with, and a front end view/SPA for users to interact with.
But…here’s the rub: what do the specs look like if this story or feature is a dependency for a story-to-come in the future? By this I mean, the feature being developed cannot just be developed in a vacuum. While I know this statement sounds obvious, mistakes often originate beneath the surface in the abstract and complex world of software development, manifesting as technical and functional debt later on.
Imagine that we are developing a car. If the feature being developed is a steering wheel, then we all know that it needs to be placed behind the windshield in the front seat. We all know this because we have all driven (or at least ridden in) a car.
Now imagine that you are developing something that is highly complex, such as a payroll or wealth management system. This kind of complexity signals the need to supplement engineers with enterprise architects, because most often, the engineers building the product have not spent their careers mastering the business/functional space of your products. Because of this, I have come in as a consultant and seen many steering wheels mounted in the back seats of business applications.
Should My EA(s) Be My Best LD(s) and EM(s)?
No.
This is because your leading engineers typically focus their professional interests (and passions) on technology first. Their functional aspirations, no matter what, are most often secondary. Yes, over time they can learn a lot about your space, but often not to the extent that is required to be proactive about shaping specs to fit long-term organizational strategy.
The person(s) you want in your EA space are those who were compelled to limit (for the better) the depths of their technology career to focus on broadening the bigger picture of building a successful product organization in your space.
The perfect people for EA roles are those who can build a bridge between your executive think tank that can foresee your company’s future and your leading EMs/LDs. While product owners and product managers typically fill part of this, there is a space closer the metal (i.e. data structures, workflows, interoperability strategies comparing APIs vs. async, enterprise product management, strategic/digital transformations) where EAs need to step in when your product lives in a complex space.
These operatives should possess end-to-end detailed functional expertise on any human endeavor that your product facilitates, either from having been power-users of products like yours over their careers, or having been principals in startups similar to yours in a past life. They should also posses solid high-level technical knowledge about how software applications are constructed, and how they interoperate. That knowledge will go beyond merely informing your minor stories and features being delivered in the short-run, to connect them to your underlying enterprise structure and evolving capability deck that will keep you competitive in the long-run.
How Do I Find an EA?
Not on a typical job board.
Unfortunately, today’s candidates are coached up so hard on how to load their resumes with key words from your market space, it can be hard to determine whether they are truly at the EA level in your industry. Locating and vetting just the right one and getting them in for an interview could be very time consuming and laborious.
Here is an alternative: find a boutique or consulting firm who has done business in your market space for a decade or more. Often, they know someone who is looking for a position in that space. Better yet, they may be able to contract with you in a fractional capacity as an enterprise architect, technology officer or strategy executive, and help you strategize your next few years of evolution. Finding the right EA can be a game changer for your SaaS company.
Closing
Is your shop in need of enterprise architecture or strategic planning? D’Mention Systems has over two decades of combined hands-on experience in the following market sectors:
- Accounting, General Ledger and Finance
- Payroll, Time, HR and Wealth Management
- Enterprise Systems for Higher Education
- Enterprise Systems for Automotive Dealerships/F&I
If you are looking to recruit, vet or contract your next team member in the one of the sectors listed above, please reach out – we would love to help.
Mike Liskow is a business development consultant, writer, artist, entrepreneur and thought leader in the business development space for tech startups. D'Mention Systems was established in 2003 and provides business development consulting engagements for tech startups.
