Information Architecture has been a very interesting service for Xentity to provide. With the various changes in information products, data science, and information technologies all building upon each other it’s hard not to remain continuously engaged, amazed, and curious. There is something great about seeing your designs go live with tangible solutions. On the downside, when there are “glitches”, things tend to go downhill and the architects get blamed for it all.
Nonetheless, having information architecture in your portfolio of accomplishments will make you very proud of what you envisioned. This is true whether it is a concept, design, or solution for what you tried to build and implement. Point being, an information architect naturally wants to see their design go live and move onto the next design. It’s not like an “operations” position where they become a master of efficiency in their trade. Or “development”, where you become an expert in a set of core technologies. Or, a “requirements gatherer” or “project manager” who enjoys the battle of herding cats.
Information architects want to either keeping doing similar architectures or evolve into the next. And as a company that provides architecture as a service, Xentity understand this better than anyone. So we want to take this opportunity to expand on several major subjects regarding architecture. This helps you figure out whether you as an organization want to employ or not.
What Is Next? The Driving Question For Information Architects
When a technical leader or hiring manager envisions what is needed for instituting information architecture services at their company, there are a few things to consider. For example: “what will the architect be doing after the next two projects?” Per the introduction, the drivers are very clear for information architects. Particularly, in a career where the big question is: “what is next?”.
- Will they be churning out more architectures in same patterns, or growing the company, and thus their architecture skills will need to grow with it?
- What will the role description look like after the first two projects – more technical prowess or more leadership and management growth?
- What level of architecture services/work is needed against the size, maturity, and complexity of the organization?
- After the first two projects, what are the key results needed to measure a skillset that is both needed to have proven history and portfolio of work as well as handle future concepts against the description?
- How do you interview and commit for a role – do you assess portfolio for leadership potential or resume qualifications and in-basket technical exercises for the technical depth or both?
- How do you measure creativity against portfolio trusting it is comparable while not asking too much hypotheticals as architects are built to design for the “what if” and they will beat you every time.
- Do you know after the first two projects that you will have the challenge the architect will be seeking or that they can handle?
- Will it slow down and become a more technical hands-on position or will it speed up and the responsibility will grow, and can they grow with it.
- Meaning, what will the level of work look like – not just variable (fast/slow) or stable, but will the role description change or be static or limiting?
- Will you need them to take on any task that comes their way or be a strong expert in a specific architecture stack, but those tasks may have gaps in time?
These are the challenges of hiring a full-time information architect. They will be driven by “what is next?” which you may not know. Also your likelihood for expected retention rapidly diminishes before you start.
Retention And Sizing
Below we’ve provided advice concerning information architecture staffing, followed by solutions on various staffing models for architects.
It’s A Buyers Market For Good Information Architects
Good information architects have grown their skills in leadership, change analysis, obtaining results, and team-building. Good information architects adapt to the subject matter and technical skills required. That way, they can handle the rapid change in technology stacks and patterns. These aspects become like “the Matrix”. Information architects see through the next technical vendor and industry wave of architecture stacks. In this way they grow their value through increasing ROI on services. Also, in outlining more valuable or efficient concepts of operation.
Finally, in collaboratively designing blueprints or transition roadmaps into change management plans. Information architect positions will pay more. Furthermore, the architects themselves have a lifespan of at most 3 years until they get bored. Now, if you are hiring for a specific technology architect then advertise for that and lead with that. The hope is that the technology stack has a reasonable lifespan. Also, the architect knows their role will be consistent and repeatable on that technology stack as it grows.
Average Information Architects Will Plateau
If you hired a technical or IT architect, they will be more of an analyst or lead architect. Likely, they will do it well. If your company is growing, changing, and employing new technical stacks, new services and products, and new or growing business models, your information architect will not grow with it if they were hired as a technical specialist. The role in these circumstances change from requiring just systems analysis or root cause analysis. The circumstances transition into business change, policy, or political analysis. The role will now be required as the service or product grows in relevance and importance to the organization. The IT or solution architect may struggle with hanging onto old patterns they know, sticking with the custom portfolio. Or worse yet, not keeping up with business management just-in-time training.
The hardest part is they are learning non-intuitive soft skills that go against the more IT introverted hard skill professional profile. They also need to keep up with keep up with the technical architecture changes induced by Moore’s and Metcalfe’s Law. Typically, this means too much learning, and an external or new hire is required. In shorter terms, you wouldn’t hire a cook and ask them to farm just because both work with food. This is why technical architects overengineer as they move up – they do what they know as they move up. Vice versa as well.
A Required Position For The Next Two Projects, Then What?
Let’s say we bring the information architect on for specific architecture skill sets. Maybe there is an MVC stack flavor of the past few years or maybe that is enterprise architecture analysis. And lets say we hire the architect and he fits perfectly as a model architect. As the first two projects wind-down, the problem is time has passed, Moore’s Law has changed, and the portfolio requirements have adjusted. However, the skill sets chosen may now become legacy. It happens that fast.
Then, the architects adrenaline wears off from seeing the conquest of going live. They begin to realize the next architecture project will likely not fit. They tend to either know the end is near or hijack and get “proactive” as business is perceived to delay. As business looks at their next architecture need, data architecture, or process re-engineering, governance or in a new subject matter expertise, they consider if that technical specialist architect can morph.
The Answer Is Technical Or Application Architects Do Not Tend To Morph Or Grow With The Organization
Then business considers a new architect, while retaining the old one. Now you have architect bloating, dual roles, and the ROI on architecture is at risk of eroding. This is the Achilles heel of architecture, which all comes back to the staffing model. Point being, hiring for the first two projects will yield an average architect. They will hit value stagnation and either reduce into Senior Engineer role. It may be of value, but it is definitely a compensation plateau. Or they will realize their diminished value and either underperform or encourage them to move on which is just not a good way to acquire talent.
Hiring a rock star externally out of the gate will work. Keep in mind though, they will expect compensation above the organization curve and above inflation. And they will keep up with the salary norms, even if they are comfortable with well-balanced life. They know they can move around to the next conquest.
The Position is required Long-term As CIO Trusted Advisory, But Near Term, Need Hands-On Technical Architecture
Let’s say you start out with finding a seasoned trusted advisor instead. One with experience in corporate culture, subject and domain matters. They would also be familiar with patterns in enterprise, process, data, performance, service, technology, and security architectures as well as works well with the various change management domains. They fit perfectly.
However, starting out, you have a project that needs more than a guiding touch. But it needs to get their hands dirty in new MongoDB and NoSQL mapreduce code analysis. The seasoned veteran has not kept up with actually coding as they have been on higher order tasks, as they should. This gap between the role description long-term need, and short-term fiasco creates a perception of lower value of the individual. This happens even though they were not hired to fill in these unique architecture technical deficiencies.
Typically what happens here, is the junior technical staff will begrudgingly fill in the gap. They will then wonder what the “old guy” is doing to earn such a salary. Consequently, they will take longer to team build. Technical architect will team build great with the team, but struggle with the antithetical upper levels, especially in handling the drivers, political sensitivity, and explaining the benefits of the architecture, and design in simple speak.
Some Major Challenges
Essentially we have pointed out some major challenges to hiring the architect as a full-time employee model?
- How can you keep good talent? How can you retain the investment and knowledge?
- Are you going to want the role to expand?
- How can you get both the architect who grows with the company and solving low-hanging fruit tactical hands-on issues?
- Do you have enough work to keep the architect adding value based on what you are compensating for full-time employment?
- How can the architect keep up with rapidly changing technical patterns as well as growing in leadership, management, enterprise context, and corporate subject matter?
- How can you keep up with changing expertise while balancing the amount of change introduced to stay innovative, relevant, and moving towards stakeholder and stockholder end goals in a timely manner?
Simply put, the full-time employee for an architect position that is likely to grow with company or product does not work. That is too much change to ask of the architect. They must lead change, train others in change, grow in 3-4 professional domains, all while showing interest in a company asking a lot from them, fully knowing the rest of the market is buying back risk and innovation in this skill as well. Or they may be able to do it when the service footprint is small, or in project mode, but as soon as operations picks up, moves from a project to projects to program, to regional to division, on the fast ride of national or worldwide services, that is when the peter principle kicks in.
Point Being, Consider Other Models Based On Where You Are Buying Your Risk
- If you only need for next two projects, consider contract-based employee
- Or, if your organization is on roller coaster of growth and portfolio change, contract out consulting firms
- Also, if your organization has the raw talent, but need some temporary leadership, contract our consulting firm leaders to grow team
- Furthermore, you want long-term, but can’t define needs bring on consulting firm to bring in various architecture skillsets
Setup these external support (contract, independent consultants) to address 6 major things:
- Make them earn your trust – set up a starter or bridge task – You need to connect with the individuals before you commit long-term. Give them initial tasks. Worst case, if you change your mind and want to go back to employee, you have flexibility now. Thereafter, award good work with next tasks, but appropriately longer.
- Be clear on what may change – Don’t map out the roadmap for them – make them earn their purpose, but at same time, let them know what roles may be needed in future, so they have a sense of what type of architecture you may need. You wouldn’t hire a cook, then after six months after, ask if they could farm as well?
- Define outputs – Try to avoid long-term time & materials. Maybe initially, but thereafter, be project or outcome milestone based to assure the honeymoon delivery value continues
- Setup Lead Key Personnel – Make sure you get a team lead or lead point of contact you have written into contract/task order to escalate, report, and get status from to manage change, risk, issues, and quality. Though you typically do not get personal services contracts, unless it is just independent, you can ask for certain commitment level from A-team before they staff with a B-team – that is what you are paying for.
- Contract Terms should be simple and clear – Clear outputs and due date from award, clear understanding of their assumptions for resources, access, team, and dependencies from you, clear either fixed price or not-to-exceed amounts, and clear indirect cost understanding (travel, other)
- Know Executive expectations – If you know the executive is getting impatient, has high expectations, putting that on a new full-time employee may be hard. At same time, if you want to take time, build the culture, and internal skill set, building short-order tasks to consultants will possible create adversarial relationships between employees and their bosses to show-off.
If anything we’ve been talking about has piqued your interest, please take some time to review “What are Various Architecture Staffing Models” that Xentity can support. We can help you figure out what kind of architecture staffing you want to employ, if at all.