Solution Designer Role

Today, I’d like to share some insights into the role of a Solutions Designer, a fascinating job that I believe is suitable for both tech-savvy and non-tech individuals. Here, non-tech refers to those who have a basic understanding of information systems but don’t necessarily work with code or interact with systems on a daily basis.

The work of a Solutions Designer primarily revolves around solving problems for Business Stakeholders by applying technology, processes, or management techniques. In the language of Enterprise Architects, this role involves guiding the transformation of a business from state A to state B to adapt to new conditions.

You don’t need to be highly proficient in technology (for instance, having a background as a developer) to excel in this role. In fact, being too specialized in a particular technology can sometimes lead to biased decisions because of over-focusing on that one technology. As someone who started as an engineer, I constantly remind myself of this challenge.

Your main responsibility is to understand the tools and processes needed to solve problems, with the belief that the process will guide you to the final outcome (Trust the Process). Most of your time (over 80%) will be spent on non-tech activities such as communicating and exchanging information with different departments, analyzing requirements, working with Risk, Security, and Governance teams, supporting stakeholders in decision-making, and lobbying, etc. During this phase, you might use various tools such as Divergence-Convergence design thinking, human-centric design, pattern trade-offs, gap analysis, numbers-don't-lie, second-order thinking, and more. It's crucial to work systematically, applying professional methodologies and processes to avoid having to "schmooze" or "win people over" ??. When a stakeholder asks why you made a certain decision (XYZ), you’ll have all the information about the processes that led to that decision, which you believe is best for the business based on criteria ABC. You need to be professional and document everything clearly (even if no one reads it ??).

The remaining 20% of your time will be dedicated to high-level design, focusing on connecting different systems and domains. At this stage, you’ll have the support of other experts in your team or from vendors, so you don’t need to know everything in detail. All the effort you put in during the first 80% will pay off at this point when the problem is well-defined, and the information is clear, allowing you to design a technology solution, moving from conceptual design to logical and physical design (this usually doesn’t take much time). The implementation phase will also go more smoothly since you’ve already worked with all relevant parties to "pave the way."

In terms of organizing your work, you won’t need to work at the Sprint level, so there’s no need to participate in Agile rituals like standups or sprint planning. Your work will mainly be at the Quarter, PI, and Annual Planning levels. Projects and Portfolios (groups of projects) will be the main structure for organizing your work. A Portfolio usually aligns with a roadmap or vision set by Stakeholders. Based on this vision or roadmap, you’ll design the Target Architecture (long term) and then perform Gap Analysis to break it down into Transition Architectures and smaller projects to be executed over one or several years. Occasionally, there may be projects arising from sudden business demands, for example, when generative AI suddenly becomes a hot topic, you’ll need to solve the specific challenges of that project.

Some challenges of this job include:

• Limited Power: You don’t directly control resources and authority. The only thing you have is Influence. However, depending on the project, you might negotiate with stakeholders for more Power to make your work easier.
• Since you don’t have direct control over resources (e.g., an independent implementation team), you’ll need to gain the consensus of all parties to get your Solution implemented. Sometimes, you’ll have to overlook the opinions of some people, which might make you unpopular ??. Using the RACI model, you’ll know who to persuade and who you can ignore.
• It’s easy to get discouraged because you won’t see immediate results. As a developer, you can see your code running right away, but in this role, you don’t have that satisfaction.

Some perks of this job include:

• Sometimes, you don’t have to be directly responsible for delivery -> less stress.
• You get to meet and connect with many people.
• Being detached from daily BAU tasks allows you to observe and learn more.

I hope this short post provides you with an overview of what it’s like to be a Solutions Designer.