• Share
  • Share

The five jobs you have
as a solution owner

Our solution owners are simultaneously your BAs, PMs, scrum masters, developers, and everything in between. They’re your go-to leaders for both employees and clients, able to answer any question and manage any task.

Andy Whitehouse | July 24, 2017

Your most important job as a solution owner (SO) will vary depending on the day, hour, project, and person standing in front of you. But, every SO needs to possess a multilingual proficiency in project management, development, QA, UX, DevOps, consulting, and whatever other field he or she happens to be working in that week. Those core skills tend to manifest in five key roles.

The translator

Translator was the first metaphor I latched onto when trying to describe what I do all day. I’d say, “You sit between the business team and the development team and make sure each group knows what the other is saying.” The reality, I’ve found, is less quaint.

No one is born speaking Businessese. If Businessese is the primary language you’re employing on a project, it’s because your job on that project is to represent the point of view and interests of the business rather than, say, DevOps. Since language shapes our world view, that business perspective tends to be self-enforcing. The more I talk about project goals in terms of what they’ll mean for the business, the more I begin to think using a business perspective. The more I think and talk from a business perspective, the less invested I’ll be when someone wants to discuss the project’s DevOps strategy.

The SO’s job is to interrupt this thought loop by translating everything into a new, shared language—a language that borrows from Businessese, Developese, and whatever other languages everyone else speaks; one that simplifies and re-contextualizes those borrowed bits into something that everyone can consume with equal ease.

The diplomat

Projects are made of people, and people all have their own thoughts, beliefs, preferences, and priorities. It’s impossible to manage a project without managing the people involved. Enter: diplomacy.

Your second job as an SO is to remind everyone that their opinion is important and valid (because unfortunately for the simplicity of the project, everyone’s opinion will be important and valid), but that one person’s might not be as important or valid as someone else’s in that moment. Your job is to encourage empathy; to remind your team that you’re all in this together and express that someone else getting what they want in the short term is good for everyone in the long term. Ideally, none of these things should be a lie.

Sometimes getting everyone on the same page is as easy as reminding a frustrated developer, “Yes, of course QA is preoccupied with TestRail.” That’s their job. Sometimes it’s as messy as getting a dozen person–strong committee of product owners in the same room for the first time in their careers and, over the course of eight hours, getting them to document why a project—even the parts that don’t affect their individual departments—is worth their time.

A diplomat, of course, negotiates things in such a way to demonstrate that she really does have everyone’s best interests at heart.

The air traffic controller

Even when things are running smoothly and everyone’s priorities are dovetailing nicely, there will be approximately 2000 things all happening at the exact same time. As an SO, your third job will be air traffic control.

Sitting with a development team has always reminded me of The West Wing. Not just because the banter sounds like it was written by Aaron Sorkin, but because someone is always asking, “What’s next?” Someone’s finished will all her stories, but has two days left in the sprint. What should she work on? Someone else has an eight-point story on the board he can’t touch until another eight-point story is through QA. What should he do? Someone else still has found four bugs in one story, but they’re all minor. Are we passing the story? And we’re still merging to 1.4.1, right?

For the record, the answers are: she should help QA get the first eight-point story through; he should help QA get the first eight-point story through and wrap my knuckles if I ever try to assign 16 points worth of dependencies in the same sprint again; only if the bugs aren’t embarrassing; and no, roll back and merge to 1.5. Hey everyone, we’re merging to 1.5 now!

The therapist

In all that organized chaos, someone is going to get his or her feelings hurt. Someone’s hard work will be over-shadowed. Someone will get sick of picking up someone else’s slack. Someone will fumble a demo. Someone else will get put on the spot in a meeting. Nine times out of ten, it won’t be the event that causes problems but the emotional fall-out.

In your official capacity as team therapist, you will buy coffees, listen to rants, and say both, “I imagine that makes you feel…” and “What I hear you saying is…” with deep sincerity. You’ll suggest action items and different ways of looking at the situation. You will assure people it’s not personal and go full armchair psychiatrist on the client. You will plan three team meals for the same week. Mostly, you will say “I understand.”

The parent

As important and necessary as everything else is, often the best thing you can do for your team is to step back and let them get on with it, secure in the knowledge that you will always, always have their backs.

I can’t build an API, write an automation framework, set up an Azure instance, or figure out a clean way of showing a user that a room is booked. But, I can give the people who can do these things the tools to get it done, and then get out of their way.

When you’re watching someone transmogrify badly expressed technical requirements into a beautiful UX that makes the mundane interesting, or wade hip-deep into a framework that was unheard of a week ago to build something that’s going to make for an interesting demo by the end of sprint one, it’s not hard to be truly, outspokenly, impressed by the people around you.

And for the days when everything’s going wrong, the project seems off the rails, and the client seems out of her mind, I can at least ensure that anyone who wants to mess with my team must get through me first.

I don’t have kids, but I’m told the operating premise is similar.

Andy Whitehouse

Andy Whitehouse is a solution owner for Slalom, where she helps clients develop and implement custom IT solutions. Prior to consulting, Andy spent ten years before the mast in publishing. She lives in Cambridge, MA.

            

Start a conversation

What’s on your mind? Let’s explore the possibilities.