5 Steps to Reposition your IT Role from Plumber to Solution Architect

One of Sylvie’s team members came into her office recently, having just left a meeting with one of their business’ partners. They told Sylvie that this partner needed some new functionality built, and how they proposed to build it.

“That’s fine.” She said. “But why? What are they trying to achieve?”

They didn’t know.

“Have another meeting.” Sylvie advised. “Find out what they’re really trying to solve, and we can collaborate with them in figuring out a solution – which may be a business process tweak rather than a technical fix. Don’t stop asking questions until you have the reason for this particular request.”

To make sure this team member understood her call to action she gave a directive they had heard before:

“Be the architect, not the plumber.” – Sylvie Mwila-Jonath

A plumber builds out functionalities after the house is already built. An architect helps define the vision, and informs key decisions along the way that will allow the house to thrive with a remodel, or addition. Sylvie explains that sometimes you have to push to be brought into key conversations in the design stage. After a while, you’ll build enough credibility that you’ll start getting invited.

Recently I had the opportunity to sit down with Sylvie Mwila-Jonath, Head of IT at Torani. Here’s some of the lessons she shared with me, on how to think about and reposition your IT role in your company.

 

5 Steps to Move from IT Plumber to Solution Architect

1. Establish Trust

“Invest in having coffee with people.” It’s tempting to get heads down in the technical work, but Sylvie reminds us that it is the people coming together that make or break the success of a project. She makes an effort to get to know people across the organization on a personal level. She also makes sure to get to know the people who will ultimately be end users of a new implementation.  “Don’t underestimate the input of team members who will get directly impacted by the changes.”

Another key piece of trust is establishing credibility with your role as a technology  leader. “Your first 30-60 days on a new job are also critical,” Sylvie explains. “Always try to address the low-hanging fruit to immediately give some relief.”

2. Articulate the Shared Vision

Sylvie is clear that change can be hard, for any size business. So it’s critical that the executive leaders talk about their vision for the future, and place whatever technology project in the context of those goals for the future. “That way, when roadblocks come, everybody will hold hands and face the challenge together.  I help plant the seeds with our executive leadership – but ultimately they are the ones championing the change and promoting adoption across the company.”

3. Keep Asking the Why Questions

Moving into an architect role is as much about asking questions than providing solutions. Sylvie will often say to her team members, “I may be able to give you that, but it won’t solve your problem.”

Many times people are so used to working a certain way, they can’t even imagine  other possibilities. “The worst thing we can do is to implement new software or build automation around a broken business process.” Sylvie encourages us to keep asking why and involve team members in brainstorming. “You’d be surprised how sometimes just having someone talk out loud can change the story as we are talking about it.”

4. Resist the Need to Always Have the Answers

Most inexperienced technology leaders I meet feel like they need to always have the “right” answer, and feel embarrassed when they don’t know something. “Being the go-to person with all the right answers sets the wrong expectation, and sets you up as the plumber,” says Sylvie. “Someday you won’t have the answer, and what then? Besides – who wants to talk to and get advice from a know it all?”

Instead, Sylvie establishes a collaborative approach to finding the answers. “Let’s figure this out together” establishes both the business leaders and her IT Team as bringing value and knowledge to the conversation. And no surprise, colleagues are more likely to consult her for advice.

5. Move from Owning Functions to Owning Business Processes

Sylvie told a story how, early in her days of leading the company’s technology alignment sessions, they would have business leaders pitch projects, and then as a leadership they would collectively prioritize the focus and work of the projects for the next quarter, or year. “This worked to make sure we weren’t overcommitting,” Sylvie said, “But it meant that those who were better at pitching and presenting often got their projects picked, instead of tackling the biggest pain points for the organization.”

Then she and the executive team did something drastic with the introduction of the process ownership concept. Instead of having each individual department talk about their projects and needs, they started looking at processes holistically at the enterprise level to identify areas with the most pains and their interdependencies.– for example – tracking the process from the receiving of raw material all the way to the shipping of finished product.

Assigning an owner to the entire process began to help streamline the flow with clear roles definition and key metrics, Sylvie said. “We’ve since been able to prioritize more strategically the projects with the greatest business impact.”

 

Sylvie Mwila-Jonath is Head of IT at Torani, a beloved flavor business that was responsible for a rush of Huckleberry in my lemonade, while recently watching moose at a hotel in Grand Teton National Park.

You can see a live demo of some of the dramatic ways Sylvie has transformed Torani’s business using Salesforce and then hear me interview Sylvie on her lessons learned on Thursday, September 27 at 5:00 pm at the Salesforce Small Business Keynote. (Not going to Dreamforce? Check out Dreamforce.com starting Tuesday September 25th for live streaming.)