TL;DR Being a Software Architect is not a Super Senior Developer role, in fact its both leadership & management (these two are not the same) role that should act in parallel (& independently!) to other management dimensions (e.g. product, engineering or project). Based on my personal experience, the proper equilibrium between different dimensions of accountability & leadership (including Architecture) has a tremendous impact on achieving a long term success in Software Engineering-powered business. Sadly, it's Architecture that can be ruled out of the equation most easily & subtly - frequently in a way that renders Architect(s) powerless & frustrated due to inability to do their work.

I keep repeating that I hate the words "Architect" & "architecture" (in context of software engineering) - they are so over-loaded & over-used, that their original, intended meaning is almost completely lost & depreciated. But it doesn't mean that in times when every 2nd developer adds "Architect" to her/his role description there's no place for "shepards" who tend to whole systems, platforms, how do they grow & develop, meeting ever-changing market conditions and expectations & such.

However, whether such an Architect succeeds in her/his mission or not, depends not only on her/him (skills, experience, grit, communication, etc.). Modern software development organizations are multi-dimensional, cross-competence, dynamic environments where responsibilities, dependencies & subordination paths are put in very different "mosaics". In such varying environments it's such "transversal" roles like Architect that are the most prone to effects of organizational "sins". And frankly - it doesn't take much to turn a life of an Architect into a miserable path paved with thorns of sheer frustration.

Oligarchy in power

In simplest possible words - your software development unit is most likely managed / governed / led by the mixture (sometimes very imbalanced) of the following dimensions (names vary, it's the meaning that matters):

• product management - managing the service / product you're building (its road-map, perspectives; part taken in value stream) from business perspective; should decide on WHAT (kind of business need) to address next, but not HOW
• engineering management - managing the working environment for people, overall delivery process, aiding people's career development, resolving human-related issues; in general - full focus on building a high performing engineering unit
• project management - managing the one-shot endeavor aimed to create a particular effect within the organization, quite possible with a dedicated team composition (built / fine-tuned for this task); grand focus on the expected OUTCOME of the project, meeting its assumptions (e.g. goal(s), deadline(s), etc.)
• architecture - managing the technical aspect of products / services (from the perspective of all architecture "-ilities") - WHAT exactly is being / should be built, WHERE does particular new "thingie" belong, HOW to incorporate it into technical architecture road-map (regardless of its detail level); additionally covers technical aspects of the delivery process -> what to bake into it to have the greatest feasible positive effect on the work products

So it's no wonder that there's nothing unusual in having few bosses these days, each of them responsible for different "area" of your "work life". Each of them decisive in different topics, each of them requires different kind of feedback information. Needless to say - sometimes they are in a sort of equilibrium (based on mutual co-operation & good understanding of responsibilities), but sometimes it's just 1 (or 2) dimension dominating with other ones either non-existent or completely marginalized (e.g. meaningful, effective product management very rarely co-exists with project management: it's either one or the other).

And the interesting thing is that it's the "architecture dimension" that gets pushed aside / "sacrificed" the most easily & eagerly. There's actually a valid justification for that:

• product management is usually the one backed up with money (sponsoring stakeholders) & money is power ...
• project management is also backed up with money & formally put in charge of dedicated team (as their line management for the duration of the project)
• engineering management is formally put in charge of people (as their line management)

What about Architects?

Now we're finally getting to the "frustration" part :)

According to myself, there are certain conditions that have to be met for an Architect to make an actual & real impact within the organisation, how it produces stuff (& what are the qualities of this stuff ...): the most crucial of them can be phrased like that:

1. Either the product is purely technical (e.g. B2B platform with a technology as a system selling differentiator), so Architect in fact IS also a Product Owner
2. ... or there's a healthy balance between "dimensions of power" (e.g. in case of powerful POs - deep understanding of tech excellence role in delivering a successful product) - a balance built on actual transparency, continuous re-alignment and flawless communication (this is hard to get w/o very high standards of org culture)
3. ... or at least a clear agreement regarding the baseline & boundaries (e.g. 20% of each sprint capacity is the for "Technical Product Owner" - aka Architect)

Sadly this is not what's happening in many of the cases. Here are some of situations I've encountered or even experienced myself (from 1st person perspective) in the past:

• architecture subjugated by software engineering - not necessarily the worst thing ever, but if the engineering unit has its own issues, there's limited co-operation across the teams (for whatever reasons), commitments are to be met (e.g. regarding the deadlines) than the technical product (its quality, vision coherence, etc.) is the 1st one to suffer; to have such a scenario to work well, there has to be a very strong & capable engineering manager with a proper support of mid-level technical leaders

• everyone (including business & Product Management) thinks in solutions (not problems) - clearly one of the most chaotic types of work environments one could imagine: there are ideas, there is energy, there is will, but there's no single drop of a proper focus; instead of trying to orchestrate people's creative power to build the most proper, beneficial solutions, Architect gets stuck in navigating across (semi-)random thoughts, half-baked documents and already committed "faits accomplis" ... It's possible to get this under control, but not against the clear acquiescence of someone else in charge

• org is formal & specification-based - in other words, such organization's way to deal with multi-dimensional management is via processes & procedures; Architect is given a proper mandate, but her/his influence is being harnessed by the formal flow of specifications, processes, templates, standards, patterns ... Organization itself is pushing an Architect towards shiny, freshly made ivory tower, far from the actual work (and any options for continuous feedback). Practically speaking, inertia of such setup renders the Architect completely powerless.

• org has much more fundamental problems - it's extremely detrimental to do something (even of the things that normally bring you enormous satisfaction), if you're already certain that all this effort will be wasted / ignored / misused because of some of some other problems the organization can't notice / solve (that are beyond Architect's area of influence). What do I mean? Consider the sail boat - one could spend months on fine-tuning its rigging, enhancing it with the most durable hi-tech sails, reducing its weight by eliminating any unnecessary ballast (or replacing with a carbon fiber equivalent), but ... what's the point if anchors are stuck at the bottom of the bottom of the port channel? Or captain has no clue what he's doing & doesn't bother to listen to anyone? Or the exit from the port is blocked by hostile fleet?

One could argue that this is one of very special roles that ought not to rely on given mandate or formal hierarchies but proven skill, developed capital of trust and field-level technical leadership. And this one would be absolutely & undeniably right. Being an Architect is all about elbowing, reaching to anyone willing to listen, imposing your opinions even upon people who are not your subordinates, evangelising & preaching, motivating & cheer-leading, teaching & learning, taking responsibility & making space for others to take some as well ... But ... there's a significant difference between doing something despite the lack of (formal) support in the organization and struggling against the active force(s) that (either consciously or not) limits your oxygen supply ...

Pic: © talitha - Fotolia.com