Host Voice: Please welcome Eric Katencamp, Director of Information Technology for Publix Supermarkets.
Erik Katenkamp, IT Director, Publix Super Markets: Good morning.
So you probably think it's a little bit unlikely to hear from a supermarket guy at something like this,
but I wanted to start off by telling you a little about myself. I actually started off here.
My career started here at Kennedy Space Center about 19 years ago, believe it or not.
And I worked in a group called rtsoe2.
I don't know if that means anything anymore to anybody.
But it was the industrial and safety -- industrial and payload safety
processing group and it was a great experience.
But I did move on after a couple of years. And went to Publix, where I've now been for 17 years.
And I've worked in a lot of different parts of the company,
but I currently run part of the information technology department.
And you may wonder what kind of innovation we do there,
but there's actually a lot more than you might expect.
And I spoke here about a year ago at a systems engineering graduation
ceremony and talked about some of the innovative things we're doing.
And a lot of the things that I've been able to do as an engineer moving into the
supermarket industry is bring a lot of the higher mathematics and technology to how we replenish product,
how we forecast sales demand, how we decide what products go on what shelves,
what -- what shelf to put them on, what mix of products to put in each store,
how we get product from California to Florida and how we move product
from our warehouses to our stores, et cetera, et cetera.
So there's a lot of optimization logic and things that we've employed.
And as computing power has gotten more powerful, we're able to crunch tens
and hundreds of millions of calculations so that we can get product to the
right place at the right time in the right quantities.
So I actually was going to take a little bit of a different slant today
and talk more from an organizational standpoint how we do collaboration.
And I understand that collaboration was a big part of The theme today, as well.
And I called this the collaboration myth.
I'm going to talk some from my own experience of what has worked and what hasn't worked.
I'm going to tell a story about where our information systems department
was and where it is now from an organizational standpoint.
We've made changes to be more effective.
So real quick on Publix.
I'm sure most everybody has been to Publix.
We have 150 stores in five states across the southeastern United States.
We have about 28 warehouses and ten manufacturing plants.
It's a complex operation, about 40,000 items in each store.
So orchestrating that whole supply chain and network is not a straightforward process by any stretch,
and we believe we're on the leading edge of being able to, like I said,
get product in the right place at the right time.
The myth that I wanted to talk about that I've seen and experienced is that
if you put a bunch of really smart people Together and give them an objective,
you're going to get great results and they're going to succeed.
That is not a given, and I think everybody would probably agree with that.
I see organizational structures get set up in a way that assumes that this is true.
And I want to go back to when I joined the information systems group there at
Publix how we were structured and the type of issues we had and how we solved it.
So when I got there, we had a fairly traditional matrix-type project structure.
I'm sure most people in here are familiar with that kind of organizational structure, where you have
functional groups of like-skilled people with a manager that typically has that skill, too.
And those folks in those functional departments are allocated out to projects.
And I just show the projects along the side to depict it. You had functional groups going up and down.
In our case it was process analysis and system requirements and design and data base and architecture, and I
know here at NASA those would be different things. Then we have various projects.
So these folks would be allocated out to the projects, and a project manager would lead the work, whether it
was an innovative type, innovation-type solution, delivery of a particular project or solution,
and what we found is that this was highly ineffective. It was very slow.
And I'll just talk about a number of the specific issues that we encountered.
And I know this is conventional wisdom, kind of an engineering mindsets, right, that I compartmentalized the
like resources and allocate them out to projects to deliver results.
But some of the key issue we saw in this environment included, first of all, the managers of these
functional groups often times are not engaged in the projects.
They might have 20 or 25 people, and they naturally gravitate toward being what I call a resource manager.
Something I have no liking or desire to be.
Someone that just kind of manages people and pushes paper around and so on.
We found they were not deeply engaged with the customer, the end result of
whatever project their folks were allocated to.
As a result, they weren't really contributing to the ultimate delivery
of the solutions that Were being worked on.
Another issue is you have a natural problem here where you have people that have kind of divided loyalty or
you have people who report up to one manager but have some temporary allegiance to the project manager,
the person leading the particular effort they're assigned to.
And again, that happens a lot, but in my experience, preventing that to the degree possible is optimal.
The other problem we would have here is a lot of conflict arise.
So you can have competing objectives in the structure where you have a particular manager,
particular person from one of the functions that has a strong opinion about something
that should happen on the project that may contradict someone else on the project and possibly contradict
what the overall project manager has as their mission.
The problem is oftentimes that project manager role has very little authority.
So resolving these types of Conflicts oftentimes has to go way up high in the organization and is painfully slow.
Meetings, prep for meetings, sometimes getting on schedules a month out.
And the decision making process is incredibly slow in this environment.
And so we came to a point where we were just overly frustrated with our inability to get
work done and make decisions toward the things we were trying to achieve.
So I'm going to talk a little about what we did about this.
So in -- this is actually I have found in talking to other companies,
it's actually quite rare in an IT organization today.
And what we do is we went from this matrix structure to more of what we call a line of
business structure where teams were defined as more permanent structures.
So we took these managers, basically got rid of the project manager role altogether and got rid of the
functional manager role altogether, and we defined roles called line of business managers.
What's neat about this role is it's an individual who has overall accountability to a particular
business area or customer, but they also directly manage the resources -- pay,
performance reviews, career planning, and so on.
And it allows that person to balance supply and demand and to be totally accountable to the customer and
have the authority and the autonomy to make the decisions that need to be made quickly,
and that person also lives with the results, balancing short term and long term.
For example, immediate project delivery versus helping people grow and go to conferences and learn and so on.
Trying to balance that short term and long term,
that individual owns both of those as opposed to the previous structure.
It was conflict between the resource manager trying to grow their people and the project,
trying to deliver and actually get results.
So what we have found is that this structure is extremely fast. It's extremely effective.
We have grouped within these line of business teams cross-functional people that have all the skills needed to,
in our case, deliver information technology solutions.
And there's a manager in place that can make the decisions and Drive the results.
So the projects go more up and down.
The projects are not executed by pools of people from different structures.
They all report to the same manager. If we get a new initiative or business area to support, we create
another permanent structure with a manager, a "permanent" in quotes,
nothing's permanent in this world, but a manager who has people reporting up to
them directly so they can be accountable to the customer and own the resources.
So I was actually going to talk about an analogy of how we run our stores,
but I was thinking more it there's a continuum of types of work here.
And you might be saying to yourself, that sounds fine for an operational execution environment,
but in a project or innovation type environment, it doesn't make sense.
And I was thinking about kind of this continuum of work types with one extreme being kind of wartime
military where there's no room for consensus building, there's no room for negotiation and so on.
It's a straight chain of command, command and control structure that's required to make decisions for obvious reasons.
All the way to the other extreme which would be more like a think tank where folks are there contributing,
it's more loose decision making, rapid decision making isn't as critical, and so on.
But I would argue that what I've seen is that orb structures gravitate more toward the think tank side,
to far to the think tank side and less toward the good, old-fashioned command and control structure.
It's like somewhere about 15 years ago the idea of chain of command
and command and control structure became like a bad word.
Like what was talked about with self-directed work teams and stuff like that,
not traditional command and control structures.
My experience has been that good, old-fashioned line of command structures work best.
Now what's critical in this role, in this structure is that line of business manager.
You have to find people that have very good mix of skills to run a
cross-functional organization and be accountable to a customer and so on.
The first thing is they've got to have technical skills which means they've gone deep,
that's what we call it. They've gone deep once into something and
really understand technology and the complexity of technology.
They obviously have business skills, project management skills,
and leadership management and people skills.
And I'll admit it's tough to find people that have that complete package.
And we actually use kind of a pie chart where we classify everybody and say -- you know,
one person has two pieces of pie, another has three pieces of pie.
We want a lot of managers that have all four pieces of that pie that
can actually run teams from end to end.
The other thing I'll add is facilitation skills.
We obviously are dealing with professionals.
So this command and control-type structure has to be there for decision making and expediency,
but the reality is with professionals, folks have to be heard.
So it's important that the manager also has the capability to get input from everybody and facilitate discussions.
But at the end of the day has to make decisions and do it in a rapid manner.
And I'm going to close with this concept called work.
I'll tell you just a little about our president at Publix.
The president of Publix of a multibillion dollar organization has a high school education.
He's one of the most brilliant people I know. He often talks about this concept of work.
He has this book actually sitting in his lobby.
And he often talks -- it's a "national geographic" book, has pictures of all types of work like this.
I'm not exactly sure what types of work those folks are doing.
The concept is whether someone is sweeping a floor in a store or building an optimization algorithm,
at the end of the day everybody's trying to produce output, everybody's trying to do work.
And I've seen organizational structures get too focused on thinking, conceptualizing, and so on.
At the end of the day, we all have to have output. We all have to have work that needs to be done.
I would just suggest as I've had to do myself, next time a big project or
endeavor comes up and you're figuring out how to structure it,
at least consider building an actual structure with a command and control environment
where there's a manager ultimately accountable and the team directs to them directly
as opposed to a matrix environment where folks are there,
the project manager doesn't have a lot of authority, and you're spending weeks and months trying to resolve conflict.
And I know there are lots of models in between, but the challenge I would offer and something
I've had to do is just to -- the thing about structuring work the good
old-fashioned way where somebody's in charge as opposed to loose structures
that in my experience have been significantly less effective.
Thank you very much. [ applause ]