Interview with Bruce Brien, Chief Strategy Officer at Hive9

Transcript

Ledge: Bruce, it’s really cool to have you on. Thanks for joining us today.

Bruce: Ledge, really appreciate the opportunity. Glad to be here.

Ledge: So, would you mind giving just a two or three minute background story of yourself and your work, just so we can jump off, the audience can get to know you a little bit?

Bruce: Sure. Absolutely. Ledge, I’ve been in the tech space since about 1987. I actually had a programming job while I was a senior in college. That far back. So my career spans all those decades in between, including a stint in the U.S. Air Force as an accounting and finance systems officer, some time with Accenture on a number of defense and tax projects from a consulting standpoint.

From there, spent a good amount of time in the ERP startup space with Minx software and Pivotpoint – both as a product manager and head of the pre-sales solution architect function at those companies.

Did that until the mid-to-late nineties, and then went up to the enterprise level with J.D. Edwards and Numetrics and earned my supply chain chops and began to work global strategic accounts from a pre-sales and total value management perspective.

With a couple of partners out of J.D. Edwards I founded my own company, Stratascope, back in 2001. Ran that for about 11 years until we sold… That was a market intelligence software company. We did a lot of work with Hewlett Packard, Microsoft, SAP, Oracle. A lot of big names in the space. Ended up selling that IP to the SAVO Group, sales company back in 2011.

From there I ran the Client Success practice at Bulldog Solutions, a B2B demand gen agency out of Texas. Spent the last five years as the Chief Technology Officer for SiriusDecisions up through this past summer leading up to their recent purchase by Forrester.

I have since joined Hive9 as Chief Strategy Officer. Interesting tidbit about Hive9 is that, while working for Bulldog where Darin Hicks, our current CEO, was then the CEO at Bulldog, right before I left to go to SiriusDecisions I handed him a 50-page design document and said, “You know, you guys really ought to go build this.” That design document is actually the genesis of Hive 9.

So, even though I’ve just joined them in the last six months, I’ve been kind of a friend of the company throughout their history, and I’m really excited to take something that was my own idea to market and help grow this company.

It’s been an exciting run.

Ledge: That’s a great story. Gosh, you’ve worn a lot of hats there. I like to ask – I don’t have as much tenure as you – so, core lessons. You’re out there. You’ve worn most of the functional hats and you’ve seen a lot of stuff since you got started.

Just reactions on career development for people maybe who are halfway there. What do you think is valuable?

Bruce: I think spending time with the customer. My gosh. It’s the most valuable thing you can imagine.

When I first got started with the startup here, companies, I was a pre-sales consultant and nobody was using me. I was 25 years old, I can’t imagine why! I started putting up notices around the office regarding my availability and my preparedness to do the demonstrations.

That self-promotion started to get me in front of clients and then, when we started to win the deals I was demonstrating on, my calendar started to get booked up really heavily. I got to talk to incredible senior people in the ERP space all throughout the Northeast in the high tech manufacturing space. That was really, really probably the most valuable thing early in my career, was to have interviewed people at almost 500 companies in a five-year span.

That cross-industry knowledge and working for a startup where ERP packages, as you know, even back in the day had 25 modules to them. Well, at a big company like an SAP, you’d have the guy come in to do the finance demo, somebody else come in to do the cost accounting, somebody else come in to do the manufacturing. I had the opportunity at a startup to do the whole thing. That led to me really coming to understand the full end-to-end business processes of most organizations. That foundationally put me in a really good position for the rest of my career.

So, I think early on the more time you can spend with a customer, the more time you can spend really holistically learning how businesses work, the more value you can bring to the table.

Ledge: Absolutely. We hear that all the time, that the biggest thing now is that engineers, like it or not, are being thrust into that customer-facing role. You build it, you support it. Or, operations standpoint. Or, even third tier support. But you’re going to touch the customer. At the same time there’s this coalescing product and engineering function, where more and more of that lives under the same place.

I think it’s absolutely critical and, if you listen to the podcast, you’re going to hear every one of the tech leaders that I talk to just talk about, it’s not about the technology it’s about the people skills and the soft skills. Which is a little scary sometimes, if that’s not the area that you come from, but I think you’re absolutely right there.

How about some thoughts around how to best deal with customers when you are first sitting in that developer seat?

Bruce: I think the most important thing you can do is listen and ask questions. No one expects you to get it right just because you had one meeting with them and they explained what they were looking for. Number one, it’s hard for them to articulate what they’re looking for. You’ve got to ask questions from 90 different angles to really triangulate on, this is what they’re looking for.

Then, as soon as you think you’ve got what they’re looking for, you’ve got to straw-man something together and bring it right back to them and get feedback on, if we do it this way, if we provide you with this type of process flow, this type of user experience, is that going to meet your needs? Punch holes in it. Give them high fidelity markups after that. Really iterate with the client and really come to understand their pain and their point of view on what they’re looking for.

One of the pitfalls to avoid is, very often the client will come to you with what they perceive is the solution to the problem. Now, in most cases they don’t have any design background, any developer experience, or anything that puts them in a position to be able to do this design for you. You’ve got to listen and find the need within the solution and solve for the need. Very often you can bring a more elegant, more efficient, more effective solution to the table if you can read through what they’re telling you to get to the need.

Ledge: I can tell you from a sales perspective, I’m sure you know this, that the more you do that in that empathetic and active listening kind of way, when you show them the thing that you actually made, they’re going to say, “Yeah. That’s exactly what I wanted. That’s what I meant.” You can make them think that it’s sort of their idea. That you didn’t change it. Didn’t try to force it down their throat your way of doing it.

That level of shared understanding really builds that relationship rapport from the ground up.

Bruce: Absolutely. They’re looking for you to come to the table and, having actually understood their needs, putting together something that openly expresses how it addresses those needs.

It doesn’t have to be all bells and whistles. It can be very clean, very straightforward, gets the job done. A lot of times they’ll appreciate that.

People. This is really tough one for a lot of developers, and that is that your customer does not want you to keep coming to them with options. You are the expert. They don’t want to answer question after question around choices. They’re happy to answer question after question around needs, but they want you to lead them. They want you to come with a recommendation. So don’t be afraid to say, “I think we should do it this way, and here’s why,” but tie it back to their needs so that you really are addressing it.

A lot of people, I find, they want to just keep coming back with more questions or, “I’ve got you seven options for a user interface. You pick which one you want to do.” They don’t know how to make that choice. You’ve got to really help people and lead them through some of these choices.

Ledge: That is a fantastic point. I can echo that too. Some of the advice that we often have to give to our freelancers with their clients is, it’s rarely more valuable to have many choices. In fact, come with an A and a B and a pros and cons list, and you’re going to do a lot better than if you have all the possible things.

You’re right. There’s analysis paralysis and this fear of… You really perpetuate this idea that, “Jeez, I don’t speak this tech thing and this guy or gal doesn’t understand me.” It’s better to come from a binary standpoint to make their life easier.

That’s the value you can help bring because they’re going to assume you already filtered out the bottom eight solutions; here are the top two and here’s some pros and cons on what you should use. Totally agree with that feedback and it’s good to hear that that endures through the sales engineering seat and the customer seat that you’ve been in.

Bruce: That’s an interesting point you bring about too, though. There’s additional risk in bringing five or six options to the table, in that your heart is only in at most the first two to begin with and the lack of heart in the other three or four can really show through across the whole group. It clouds what you brought to the table in terms of your primary solution that you’re focused on.

It’s really hard for anybody to fall in love with six iterations of their own take at a problem. I think that can really hurt you if you bring in too many to the table.

Ledge: So, you’ve seen a lot of organizations. You’ve been part of and led engineering organizations, software organizations. I wonder, from the hiring side, what have you seen to be really successful to bring in and retain the best people?

Bruce: I’m a big proponent of small, highly skilled teams. I would rather have two full stack developers than a team of seven of eight specialists. I’d much rather give two guys the reins. Have one guy primarily focus on business rules through UX, and the other guy overlap on business rules down through the database and DevOps layer. Have those two guys really knock out an incredible amount of work. They develop a bond together. They develop a working relationship.

I just think that the amount of code you can get out of small teams outweighs all of the communication headaches and so forth of going down the road of a larger split-apart team. I know it’s the world of specialization, but two full stacks can get a ton of work done.

Ledge: It makes me think of… Are you a proponent of the Mythical Man-Month type of thinking; that more people, more problems?

Bruce: Absolutely, especially at the communication front. There’s so much that has to go on in terms of communication. The more you can build a stable team that is going to stay together, small group, they will outperform, from a productivity standpoint, bigger groups every day of the week.

Ledge: You’ve also worn the project manager hat, you said. I imagine that had involvement with quite a larger group of stakeholders.

As the organization grows, the number of stakeholders grows. You might be able to hold your dev team to small headcount, but how do you deal with the scaling nature of multiple stakeholders and business folks that are trying to put input into the product? How do you control that in a scalable way?

Bruce: Well, my product manager time is a bit dated so we’re actually going back to the mid-nineties – early nineties in fact – on that. So, we’re not talking agile at this point. We’re not talking a full blown UX function. We’re not even in the graphical interface at that point.

Really, it was a big old-fashioned six month waterfall where most of my work was done in the six months prior through the six months of development. That’s when I’m meeting with clients, developing massive functional and technical specifications, that are going to be delivered to a development team that then takes it through the next… It’s old-fashioned code development at that point.

Ledge: Sure.

Ledge: That still exists. There’s still plenty of people trying to do that out there. To be fair, I think we’ve swung the pendulum so far in the agile direction that there are times when you might go back to some of those practices and say, did we throw the baby out with the bathwater?

Yet, I’m sure now every organization you come in contact with is going to be agile from a product development perspective. I’m just curious, having had a lot of experience in both, do you seen any areas that maybe agile doesn’t always fit the bill?

Bruce: Most people don’t know what the hell they’re doing with agile. That’s one of the problems with it. I’ve talked to offshore guys who are looking at six-week sprints. There’s no team on the planet that is good enough to support a six-week sprint. Nobody is that good at coding.

Having really to come to grips with what agile is about. Seeing people delay a sprint and really not understand how to run both a daily scrum and a sprint schedule, and how to adhere to it, and how to understand, how to deal with scope creep and how to split items and move them into a subsequent sprint to capture the scope creep and that kind of stuff.

There are so many people out there that are simply trying to do fast waterfall that you’ve got to really make sure, before you try to tackle agile, that you’ve got an actual project manager, PMO, that is a scrum master and has been certified in it. You’ve got to make sure that the developers frame and understand how a sprint actually works, or you’re going to run into all kinds of problems.

So, yeah, agile is not something you can just say, “We’re going to switch to agile from waterfall. Let’s go do it.”

Ledge: Great point. You see this particularly on the enterprise. It’s easy to say all those words. It’s not easy to do in practice. The elegance of agile is that it’s easy to say. That doesn’t mean it’s easy to do – and particularly when you have your old habits.

I would say that, in addition to that, you need to have an organization and leadership outside the engineering function which fully supports agile, because all your business stakeholders way down on the left side of that product development line, they really need to understand that too. That, they’re going to experience things in a very different way.

Bruce: Absolutely. Not everything is going to work the way you expect it out of the gate because we’re going to make continuous improvements on it. That’s something on the stakeholder side, that they’ve become accustomed to a long wait period but a completely polished and wrapped up project. They’re going to be involved all along the way now, so they’re going to see some ugly stuff along the way that is absolutely going to get corrected by the timeframe they would have seen it but that can be difficult for them.

The other thing is to have a development manager come to you and say, “The two-week sprints are killing us, we’ve got to go to three-week.” Then turn around and tell them, “No. If the two-week sprint is killing you we’ve got to go to one-week.”

It’s that fundamental understanding of, if I can’t get the work done in two weeks it’s because the blocks of work are not well enough defined. They were too big. So we’ve got to shorten the sprint, shorten the scope, and get you to the point where you can get a week’s worth of work done in a week, on time, good quality, on schedule. Then we can talk about going back to two weeks.

But anybody doing a three-week sprint should only be doing it if it’s because they’re so good at one and two-week sprints that they can now handle.

Ledge: I love that. That’s great. I’m going to use that one.

So, I want to give you a chance before we have to wrap. Tell us about Hive9 and some of the product and the technology that you helped design there, and what you’re doing in the marketplace.

Bruce: Sure. I’m real excited about Hive9 because I love the business aspects of what Hive9 is all about.

As you know, there’s three or four thousand companies now in the martech stack space doing all kinds of crazy stuff. What we’ve found is that there’s very little oversight to all the things that are happening as marketing activities move through the tech stack.

So, what we’ve done is we’ve built an application that really looks at marketing planning, marketing financial management, and marketing performance management as a wrapper around all those execution functions. Things that the marketing cycle starts in Hive9, where you build the plan, you put in your goals and strategy, and then you feed it out to finance and get it funded from a budget perspective. Then, what we do is we connect after that to all your execution systems.

We start pulling in the performance data from a Salesforce.com, or an Adobe Analytics, or Eloqua, or Marketo – all those types of places – and pull all that actual data back in so that we can then monitor and analyze and get predictive around whether or not the plan is going to meet the goals that it’s set out to accomplish.

If it’s not going to meet those goals, it’s got to give me some prescriptive advice as to what I should do, what I should change in that plan to make that happen. Then have any of those changes immediately ripple down into the execution system. Shut off that campaign. Turn on this one. Give more funding to that paid media.

It’s really this management layer that’s been missing that surrounds all those other pieces of the martech stack that is going to help a CMO or a leadership team manage all of that program spend that they have – which is typically above 50% of the marketing budget.

Ledge: How big of an organization is the target customer for Hive9? It doesn’t sound like something that a startup could put in play.

Bruce: No. If you can manage your marketing tactics for the year on a hundred-line spreadsheet, you don’t need us. It is absolutely a complexity play. We are focused on organizations that are about a billion in revenue and up, and typically they’re dealing with complexity and it’s really frustrating for them.

I told you I was in London this week, working with a company right now that’s managing hundreds of millions of dollars worth of marketing spend across the world in 30 different countries, with 50 to 60 different marketing managers. All trying to work in independent spreadsheets and tie that stuff all back together on a monthly basis and getting reports from accounting that they have to manually input into their spreadsheets to try to reconcile everything.

That’s a real picture of a real story of one big company after another around the world. That’s the problem we’re trying to solve, and it’s exciting to be in that space and help these people that really, in a lot of cases, we’re doing a little bit of education on the frontend. A lot of people don’t know that there’s anything other than Excel that can help solve this kind of problem.

Ledge: Everybody loves this except Microsoft, I guess. Well, Bruce…

Bruce: We’re never going to supplant Excel.

Ledge: Right.

Bruce: Let’s take the stuff out of there that most people can’t handle.

Ledge: Absolutely. Well, it’s exciting. Best of luck on the current business trip and we look forward to keeping eyes on Hive9. I love what you guys are doing.

Bruce, thanks for sharing insights today.

Bruce: Thanks so much, Ledge. This was great. Thank you for having me on.