I have a goal. I’d like to see a new term gain popularity in the field of leadership development. The term is Solutions Architect and here’s why I think we need it:
The Problem:
Despite the fact that I have worked in leadership development for more then 15 years, I often struggle to describe what I do. Consultant seems to vague. Trainer is far too limited.
A few years ago I was talking with some friends about the work I do. I explained that I like to work with clients at the very start of the project to discover their needs, tease out and describe the end goals they have in mind, understand their culture, and then create a solution that will get them to their goal. Many of us who work in the field learned the ADDIE model: Assess, Design, Develop, Implement, and Evaluate. Personally I like to work on projects that run the whole way through from Assess through Evaluate. My particular skill set and interests make my sweet spot Assess & Design. The problem is that somehow in our field we’ve ended up using “Designer” to describe the Development phase!
In fact, colleagues often contact me when they are looking to hire (permanent or contract) “Designers.” When I ask them to describe the roles and responsibilities they have in mind the responses vary widely. Designer sometimes means “We need someone who can understand client needs and conceptualize broad, multiphase and multimedia solutions.” Sometimes it means “We need someone who can write workbooks and instructor guides.” Of course, some people can perform all of the responsibility along this spectrum, but I believe that they are two very different roles that require very different skill sets, knowledge, and expertise.
The Solution:
I have a good friend who likes to create workbooks and leaders’ guides. I am amazed at, impressed by, and grateful for her skills and contributions. I prefer to do the front end conceptual work. We end up being called the same thing. We were talking about this one evening and my friend’s husband, who happens to be a software engineer, joined in the conversation. He lit right up and said, “Well, you (Wendy) and really the architect and Jody (his wife) is the developer. He went on to explain that Solutions Architect is a term used in software engineering. It made complete intuitive sense! When I got home that evening, I googled the term and happened across this job description:
The Solutions Architect is a problem solver and is responsible for the overall execution and organization of the development effort on large-scale technology engagements. The Solutions Architect has the ultimate responsibility of making technologies work together and, as a result, is a key role that contributes heavily towards the success of the project. They are responsible for transforming the requirements into architecture and design documents that can be used by the rest of the team to actually create the solution. The Solutions Architect is also responsible for the guidance of development as well as obtaining buy-in and acceptance of the solution architecture. They must be able to understand and predict from afar how all the pieces will fit together and identify potential issues and risks early on to develop mitigation strategies and contingency plans. The successful candidate will have advanced communication and negotiation skills, as well as an innate ability to simplify complex technology concepts and to plan, prioritize and seamlessly integrate all moving parts to deploy successful solutions.Replace a few words and you have a perfectly accurate description of what so many of us do! In the months since this conversation, I’ve started to talk to others in our field about the term. Occasionally I come across folks who are already using it. More often, I describe it and others say, “That’s perfect. I totally get it! Can I use that too?” It turns out that there have been a lot of us looking for a way to describe what we do.
Why Does It Matter?
I’m not usually someone who obsesses over details. So why have I been thinking about this for months? Why am I using up my time to write about it and your time to read about it? Because I think it matters. I think we need to be sure that we describe the role we need people to play accurately. I think that if we don’t have the right terms we end up:
- hiring the wrong people
- causing frustration and conflict due to role confusion
- negatively impacting performance and engagement when people are in the wrong roles
- missing steps that are required for robust, workable, effective solutions
- failing to serve our internal and external clients
In fact, I came across a blog post about the problems that come up when people confuse software development and software programming (You need Developers, not Programmers). The author points out that we need to know the difference between people who perform tasks of coding (programmers) and people who are looking at the broader solution and whether it meets the client’s needs (in this case developers).
In the world of leadership development I think we would benefit by having more clear, consistent, and commonly used terms to describe our roles. I think Solutions Architect is a good start.
22nd February 2012 Wednesday 




Comments
No comments yet.
Leave a Comment