Q&A: What’s a purple unicorn, and why you need one
October 29, 2014
Sharon Lynch is a Managing Director of solution ownership and quality engineering with Slalom’s national delivery team. She explains what her team does and why the solution owner is the “purple unicorn” of the consulting business.
First, give me a couple of examples of how your folks are going in and helping a company.
(On any project) there’s a bunch of highly skilled people that do things really, really well. Delivery leadership’s role is to pull all that together. We are there to support everything that Slalom does, and in particular, everything that national delivery does. Without proper leadership, how can you expect to deliver what the client needs you to do?
So we just organize all that for them. It’s really simple. We rely on all the people with the skill sets to actually do the work, and we just help organize the work and make sure that the client understands what they’re asking of us, and that we’re going to give it back to them when they need it.
It sounds like a lot of it is the communication and the organization part of any project that we’re doing. Is that right?
Yeah. And I’ll say it’s also the hard discussions around scope and feasibility.
So, you wouldn’t expect (most people on the team) to have a discussion with the client and say, “Listen, what you’re asking for is infeasible, impossible, and will cost X dollars.”
That’s up to delivery leadership. That’s up to a technical program manager to help wrap their brains around, “What you just asked has never been asked before” or, “What you just asked is way different than what we had talked about, so let’s talk about that.”
What’s the most rewarding part of working in this delivery leadership space?
I would say we get to see everything. We get to see the request from the client. We get to see their passion behind whatever we’ve asked them to deliver. We get to see their frustration around the timeline. We get to see amazing teams come together and do the work. And we get the satisfaction of organizing that work for them so that they can deliver.
We’re there from the beginning, and we get to see the client’s face when we deliver to them.
You recently created this new position within your team called solution owner, and this sounds like a new thing in your field.
When we go to clients, we say, “This is how we set our projects. You have a technical program manager that’s going to work with you on budget, resources, overall big picture, number of releases.
“And we’re (also) going to give you a solution owner. They are your person. They’re working with you to own the end-to-end solution, understand everything, and really be your advocate and listener when they’re talking to the development team.”
Are you already using these solution owners in the field?
The discipline has always been there, but the term was born with a client in Chicago.
We were building a very strategic product to enable the launch of the Affordable Care Act. There was a defined go-live date. Very big budget. Multiple work streams.
And they were like “Whoa. There’s going to be so many complex requirements coming in, there’s no way that a typical business analyst, or even a technical analyst, can do this job.”
And they sat together, did a diagram on a board and said, “OK, what we need is someone to own this. Own the solution.”
So the term was born. They used that methodology at that client for two years, (and) this was one of the only companies that was successful to go live on that date to support the Affordable Care Act. I mean, it was an incredible result. And that engineering team, they worked very hard, but their conclusion was that it was because of the solution ownership role.
Yeah. And that client is still our client, and we’re still doing a lot of work with them, and the role is alive and well.
It seems like a really hard role to fill, because you have to be able to communicate with the engineers but also present to the executives, who tend to not be technically savvy.
We call them “purple unicorns.” They don’t exist. And what we do is we have a list of qualities that we’re looking for, and we usually get about 75 percent of them.
The one thing that we do not waver on is they have to have the technical background in some form.
And why is that?
If they do not (have a technical background), they will not be able to have the discussion. They will not be able to filter because they don’t understand how the technology works, how code works, how solutions work. They have to be able to filter as they’re listening to the client.
Tell me what you’re hearing from the clients. Are they relieved to have this person that can kind of be their - as you say, their person on these projects?
Normally these clients won’t let these people go. (They’ll say,) “The whole development team can go, but I want this person to stay.”