Robert Sfeir, Head of Delivery, Global at    Huge, Inc.

Robert Sfeir, Head of Delivery, Global at Huge, Inc.

Process. It feels like the answer to so many project woes and a threat to culture and creativity. So how do you go into an existing team with an existing flow and social dynamics and “fix” things? What’s the process process?

To start, you observe. That’s what Robert Sfeir, Group Director, Delivery—Global at Huge, explains as he shares the story of aligning the efforts of a 1,500-person digital agency. Too often people approach process change looking for patterns they know instead of watching to find small tweaks that could make things better. Once a few successes are enjoyed, the team starts to trust that improvements can be made. That’s the spark that gets real change underway.



Tune in for insights, and join Robert at this year’s Digital PM Summit to learn how to supercharge your team. (But hurry, we’re nearly sold out!)

Carl Smith: Hey everybody and welcome back to The Bureau Briefing. Today, we have got the Senior Director of Engineering at Huge, Mr. Robert Sfeir. Robert, how are you doing?

Robert Sfeir: Doing all right. How about you?

Carl Smith: I'm good, and I asked you how you're doing sincerely, because you manage process at a 1500-person agency. I can't even imagine 1500 people, even if it wasn't an agency. For everybody listening, can you tell them a little bit about your background and how you got into the role you're in today?

Robert Sfeir: Yeah. I got into it by accident, I think. I started in engineering, software engineering, and through the years as I changed jobs and took on more and more responsibility, I met Agile, and through that, I started discovering how much more efficient we can be working. It started piquing my interest and I thought, "Well, if I can use it for all these different things, with software, I wonder what else we can use it for?"

Through the growth in my career, I ended up in consulting. I worked with ThoughtWorks where I was exposed to a lot of different companies, fairly large companies, that had very unique problems. And I gained more and more interest in how I can solve some of these problems. Then moved to LeadingAgile where there was a little bit more structure around solving those problems, and I got to geek out a little bit under process part of things there, and learn and make up my own ideas of how I might approach some of this problem solving, some of these delivery issues that a lot of companies hit.

And then I got hired by Huge. When I started here, turns out that things were okay but we had a few projects that were not performing as well as we would like, and I started using the learnings that I had over the years, and started solving these problems one by one. I just take it by slice, and it's a real passion of mine. I love seeing people do better. I love being able to introduce so much effectiveness into a process that people get time to breathe, people get time to think, projects don't even cost as much as they used to, because of it. That's pretty much where the background is.

Carl Smith: You come in, you see the way that things are currently working, and then do you cherry pick certain things that you can see quick wins on? Or, are you looking more holistically?

Robert Sfeir: Yeah, so it's two pronged. One of the first things that I do is I actually take up a mind map and I start taking those of all the things that I'm noticing. I'm not going to jump into a project right away. I always like to assume that nothing is wrong, leave everything the same, and just watch it.

You can't start somewhere and assume that things are broken just because they don't fit the kind of pattern that you're used to seeing. You really need to understand what's happening, as part of the holistic view of the office.

Once I've got a mind map in place, I really get an idea of where things need help, and I also by then know which projects need help first. To your point, I always look for the lowest hanging fruit, simply because when you introduce new ways of doing things, or we try to fix something, the faster success you have, the more attention you're going to get from people.

Carl Smith: Right. This fascinates me because obviously there are a lot of different ... Well, we could say heated conversations that arise around project and process methodologies, right?

Robert Sfeir: Mm-hmm (affirmative).

Carl Smith: So I mean, there is the capital A, right? If you say-

Robert Sfeir: Are we not allowed to say the word, or?

Carl Smith: If you're going to designate, sometimes Agile has a capital A, and sometimes it doesn't. I think that kind of drives home the point. It's fascinating to me, when you're talking about it, because for me, it always feels like the best process is going to work around the individuals who are there, because everybody's got strengths and weaknesses. So you do see flexibility in the way that process is applied?

Robert Sfeir: Yeah, absolutely. One of the first rules that I apply, in fact, it's a rule that comes from Kanban. Kanban is going to be like water, right? You're going to try to get around obstacles, you're not going to try to move an obstacle. You can't deal with all the obstacles that are going to be in your way. You have to respect the boundaries as well. If you come in saying, "All right, so I'm going to work on this little piece here. Oh, I hit the first obstacle, great. Now I'm going to move you as well."

Now you're juggling too many things, now you're making too many people upset. The discussions, like you said, get really heavy, and intense, and often they get ... How can I say? Territorial I think might be the good word for it.

Carl Smith: For sure.

Robert Sfeir: You want to be really careful about where you're stepping in trying to deal with the area that you are actually responsible for, and that you have actual influence over. In my case, with engineering, the first area was to look at projects that had a backlog, that had information in it, and everyone thought that things were hunky-dory, but then when we started digging in, we found that it wasn't.

So the first thing that we did, we said, "Okay, how are we working in engineering? How do we fix that? What are the things we need to improve?" Once you start doing that, then you start putting pressure on the size of the whole system. That's when you can start exploring what's going on.

Carl Smith: And at Huge, you go in there and you do that, and is it a project that you get running smoothly first and then you start to apply what you've learned there to other areas of the company?

Robert Sfeir: Absolutely. It was definitely a project that we started fixing, and then another project and another project. Once you get the projects running in a smooth way, and you're putting out all these fires that exist, you then take a step back and you say, "Okay, what else do we need to do? What is going on in general?" You start taking a look at SOWs, you start taking a look at incoming RFPs and how we want to respond to that.

You start taking a look at how creatives are working, how is information flowing from creatives to technology? What kind of direction are we giving the client when we start a project? Am I getting the client involved? Do they know how we want to work? All these layers, you have to start digging 'em up.

Carl Smith: Oh man, this sounds like a lot of work.

Robert Sfeir: It is. It's a lot of fun.

Carl Smith: When you do this, what are some of the common issues that you see teams struggling with the most?

Robert Sfeir: Communication. Being able to just get up and talk to each other, and stop saying, "Well, this is broken" and then just staring at their screen and keep going. I think that the second common issue is some teams have a hard time being honest with themselves and they say, "This is not working" or, "We're going to be late and we can't deliver on time," for example. I think it's a tough thing to have to stand up and say, "This is broken," so you can get some help.

Clearly you have to establish a trust model so that people can feel safe, they can feel they can say something to you and tell you that it's broken, so that you're not finding out that these fires are happening way too late.

Carl Smith: Part of that communication problem I found, and this is specifically around process, is we all seem to have slightly different understandings of what terms mean.

Robert Sfeir: Yeah, so that's actually an excellent point. That reminds me one of the first things that I did when I started here and I wanted to start establishing the foundation for how we want to work, is I remember putting a slidedeck together to add the list of all the ceremonies and all the roles and responsibilities and saying, "This is what these ceremonies are and here's what they're not, and here are the roles, and here's who does what."

Automatically when you establish that, people say, "Oh, I have a little more job clarity. I understand what's going on, and now when I'm in this ceremony, whatever it is, then I understand what the purpose of the ceremony is." When you give 'em that, and something doesn't go the right way, then they start saying, "Hey, that's not what we agreed we would be doing. Why are we not doing that?"

Now you're starting to open up the discussion, you're opening up the doors to being able to communicate in a way that makes more sense.

Carl Smith: So when you do this, is the client part of the process change? Do they get brought in and engaged?

Robert Sfeir: That's funny. Today, when we start a project, we have a project kickoff. We absolutely sit down with the client and we say, "This is how we work. Here's why. Here's what it means to you. Here's the control you have. Here are your reports that you should be expecting, this is how we organize our work," everything. They understand the whole thing [inaudible 00:09:13]. 

They might not have experienced it before, but at least they have a basic foundation for why we work that way. That enables us to have a relationship where if we have to say, "Look, too much scope, we need to cut, here's why," they're already engaged with us. They already know it's coming, they already know how to deal with it.

But if I were to go back to when I started here, and in fact, that happens with every place that I've taken over a project to try to help them out, typically the client or the team is unaware of what's broken. When things start getting fixed, when we start looking at this process to fix things, I absolutely include the client. In this case here, when I started, we were running scrum teams, and we were doing point estimation. 

I taught the client what point estimation means. "It's just a budget, and here's how much budget you have, and therefore if we need to work with the sprint planning, or we need to work with the scope, this is your budget, and here's what you get to trade." The client understood well, that if they had 50 points, and there's a story they didn't like, or they wanted to add another story that was 10 ... Not 10 points. It would be like 8 points or 13 points. They would say, "Okay, I would like to put this eight point story in and you can take this other eight point story out. I don't care about that one as much."

It's so valuable to the team because now you're talking in terms of complexity. They're understanding that this is really complex and they say, "Well, because this is so complex, I really don't care about it so much, so deprioritize it, because this other thing is more important." It's great to have that kind of control.

Carl Smith: Absolutely. So, when you start talking points, this to me is always one of the challenges for a lot of companies, because they get confused around the idea of story points, right?

Robert Sfeir: Mm-hmm (affirmative).

Carl Smith: I've notoriously compared them to Chuck E. Cheese tokens in the past. Because I put in 20 bucks, I got this number of tokens, I'm still playing Star Wars, and yet I'm out of money, and I have no idea what happened. How do you make sure that the client stays in touch with budget as it relates to points?

Robert Sfeir: How deep a rabbit hole are we going to go into?

Carl Smith: It could be pretty deep, but I also know that I don't want to take your whole afternoon. I'm just curious, because you are probably the most experienced process person I've talked to in the agency setting, and so I just really, this is for my own benefit, hopefully everybody else will keep listening, but how do you keep them aware?

Robert Sfeir: First of all, a couple of things. One, when we use points, they were always aware of how much we did from sprint to sprint, and that was never hidden away from them. It was complete transparency. Then if the consistency of the points from sprint to sprint wasn't quite there, so one sprint we would have 28 points, the other sprint we would have 38 points. 

The client needed to understand that it wasn't on a per sprint basis that you needed to calculate. You needed to look back 6-8 sprints if you had them, and get the mean number and figure out what your variance is, and plan for that. The second thing is, you always look at your backlog and you try to get a high level view of your backlog to understand the complexity that exists in your backlog, so that you can say, "Well, based on the speed we're going at, based on the complexity we have on that backlog, we may or may not reach the goal that we have within the budget we have."

That said, I find that points often can get in the way. I think folks tend to use it to measure a team instead of measuring the value we're delivering, trying to use it to sometimes even try to game the system, to try to get even more or less work out of it. I'm not a big fan of it. I think there are definitely times when I do still use it, and I think it's needed, but we've moved away from points.

What I do now with Kanban is I measure throughput, and I measure the number of cards I'm able to push week to week. Now, some people will say, "Well, with the number of cards, then they must all be around the same size." No, they don't have to be. They could be 1 pointers, can be 5 pointers, 8 pointers, 13, doesn't matter. They just need to get done and on average use a tool that basically tells you what the mean number of cards that you can push through the system, as throughput, throughout the week. Then you have an understanding of what your average is going to be.

If a team is on average pushing five cards a week, and I have 50 cards in the backlog, then I know that I've got 10 weeks to go. It's as simple as that. The clients can choose the features they want to push in and out the exact same way. Now, there's still the issue of, "Well, what is the complexity that exists in the backlog?" That's where I might ask my technical architect, or my technical director, to go in and just give a high level estimate of what they think these stories are in point, so we can look at what kind of complexity exists, so that we're not front loading too many big stories, or front loading too many small stories, and getting a false sense of throughput.

Carl Smith: Now, was this the way that Huge was working when you came in, or was this all part of the evolution?

Robert Sfeir: No, not at all. This is all part of the evolution, yeah. Go ahead.

Carl Smith: Where were they when you first came in? What was the process like? Because for a lot of the shops listening, obviously they're smaller than 1500. They're anywhere from 10 to 50 people so I'm just curious how Huge was working when you got there.

Robert Sfeir: Again, I'll keep speaking for Atlanta, because that's where my experience is now, although I'm working with a great colleague of mine up in Brooklyn who's starting to move the teams in that direction as well. In Atlanta, the way that the teams are working is that we had either standard scrum teams, everybody went in and did point estimate on everything, so we definitely did the estimation by teams, so one, two, three, shoot. And then you give a number of points, and then you have a discussion about it, and everything.

We had that process in place. However, what was happening is let's say we would plan for 30 points for the sprint, but we only get done 20. Then we would plan 30 points for the next sprint, and then bring in on top of it the other 10 we missed. So you just keep incurring debt, and that's typically a pattern that I've seen over and over in a lot of companies. They don't understand that if you plan 30, and you can only do 20 points, your next sprint, plan for 20 points, and oh by the way, because you missed 10, you only get to add 10 points. You see what I'm saying?

Carl Smith: Yeah.

Robert Sfeir: The concept is hard for people to understand that you've got to work within your budget, and until you stabilize that budget, then you don't get to just moving stories forward and add the same amount of work. All you're doing is shooting yourself in the foot and getting more and more delayed, and pretending like you're planning. You're really not planning. You're just going as fast as you can, hoping you deliver.

Carl Smith: And hoping nobody notices this big ball of debt that's following you.

Robert Sfeir: That's exactly right.

Carl Smith: I have to say, I'm super excited you're going to join us in Bend, Oregon, for Process Camp, which is going to be in August. You're our special guest. 

Robert Sfeir: I'm so [crosstalk 00:16:45], by the way. It's awesome. I look so forward to it.

Carl Smith: Well, and for me, knowing the different types of shops and teams that are going to be represented, I think it's going to be an amazing opportunity, an amazing discussion, because we're going to have teams working in a variety of different methods right now, some of which are probably really good, and I just, every time we've done something like this, we've seen new ideas come out of it that still fit within the concepts that people had.

I'm curious, when you've worked ... Now, you were at ThoughtWorks, LeadingAgile, did you ever work with teams that were doing something that just felt kind of off, but for some reason it seemed to work?

Robert Sfeir: Oh, I think that happens all the time. I'm doing that right now with client teams. I can tell you, it feels off, but it works. I think the reason why it works is simply by people's sheer will to make it work. 

Carl Smith: They're pushing that boulder up the hill no matter what the hell happens.

Robert Sfeir: Absolutely. I mean, I think people are committed to doing their job. I think people really want to get work done. I think they want to own the work, see results, and get it out there, regardless of how much they're struggling. Unfortunately it gets sometimes to the point where they struggle so much they just give up, but most of the time, they're really just plowing forward, ignoring that big boulder that they have actually dragging behind them, and that's how it works.

And it's odd, and you look at it and you say, "This shouldn't be working, but it's working, but let me at least show you how to do it a little bit better at least." I'm not interested in changing the whole process from beginning to end. I really love to evaluate what's there and see what are the immediate changes we can make to make things easier? I think that's the key.

Carl Smith: I used to explain it to clients. When I was running my shop, we were really well known for process. We were not agile. I don't know what we were, but one on the things, we lost a client, prospect. They said, "Well, you just seem so process focused. We were worried that nothing could be creative." We started talking about it and what I realized was there's really two ways to look at process, right?

It can be a meat grinder that you force everything through, or it can be a bandage that you wrap around a problem. What you're describing to me, very much sounds like that bandage that you wrap around that part of the process, that can get fixed.

Robert Sfeir: So yes, definitely not the meat grinder. 

Carl Smith: That's not a pleasant, nobody likes that analogy.

Robert Sfeir: But it's interesting. I'm going to share with you that recently I've come to realize that our process here has become so efficient that we've lost a little bit of that creative magic that we used to do. So, now we're looking at that and saying, "Okay, hang on. We can't lose that. What is causing this? What do we need to change or remove, or simplify, in order to reintroduce this magic of the creative process?"

I think you can go, even with bandaging, you can go to a certain point where it becomes very structured, and you lose the looseness of it all.

Carl Smith: Yeah. I think you're absolutely right. It's really nice to hear you say that, because at the end of any project, it's not just the efficiency, it's the originality.

Robert Sfeir: That's right. On one hand, you want people to be efficient, you want them to have a good time, you don't want them to be burning the midnight oil doing things, but you can become so structured that you can tend to forget that there's a really important creative aspect to our business.

In fact, when I first started here, one of our creative directors sat me down. He said, "At Huge, we start with creative." At first I looked at him like he was nuts. But within a few months, I really understood what he meant, because people don't come to digital agencies for the technology part of it necessarily. They do now, but most of the time they come to see what we can do from a creative standpoint, in combination with technology to deliver. 

I like to think that I'm being really careful about where I'm stepping so that we don't break that creative aspect. 

Carl Smith: Robert, again, refreshing. We have friends in common, Dave Prior, Dave's amazing. I think he shares that same concept. They're are definitely people out there, not just on the process side, but also on the creative side, that just struggle to communicate with each other, because each is, to your point, they've got a little bit of their sandbox that they're moving through.

Robert Sfeir: Yeah. I find the creative types as brilliant as they are, to just absolutely loathe the word process, and it shouldn't mean anything insulting. It's really about, "Look, I just want to understand how you work so I know how to work with you." That's particularly the difficult part of the message that takes a little while to communicate.

Carl Smith: And it's definitely the glue that has to be there in order for it all to work.

Robert Sfeir: Yep, I agree.

Carl Smith: Well, thank you so much for being on The Briefing today. Again, educational for me, and it's got me just so pumped up and excited for Process Camp. I can't wait to get there and talk everything from ... I was going to say discovery all the way through to delivering, but to your point, it's way back in the beginning. It's business development. What are those expectations when people are first thinking about working with you and how do you follow through on those? It's getting [crosstalk 00:22:44] all the time.

Robert Sfeir: [crosstalk 00:22:44]. Always go to the root of the cause and where the stream starts, always.

Carl Smith: That's great. Well, thanks again for being with us, and I look forward to seeing you in Oregon.

Robert Sfeir: Same here. I look forward to all the learnings I'm about to learn from everyone that's going to be there, 'cause I'm sure it's going to be very interesting.

Carl Smith: Well, all the best, and everybody listening, we'll be back next week. We'll talk to you then.