By Brian Lucas
Wayne Bruch is a hyper productive, natural agilist who has found a way to improve both process and productivity by 10% a year for the last 5 years by focusing on the key 20% of the Pareto Principle. He is the IT Manager at Easton Hospital, 250 South 21st Street, Easton, PA 18042.
Lucas: Even though you are an IT Manager with experience as a consultant you never had any formal training or education in agile, have you?
Bruch: That’s correct.
Lucas: Tell us a bit about your responsibilities.
Bruch: Well, I work under a different model than most IT managers. I oversee the IT Department as the right hand of the director. At a high level, I am responsible for the following areas:
- Project management
- Infrastructure design
- Systems design
- Implementation oversight
- Managing IT’s resources
- Staff and equipment cost projections for the facility’s needs
- Maintaining vendor relationships
- Coordinating with IT staffs at other facilities
- Consulting with medical and administration employees on services and technology
- Process improvement
Lucas: You also work at a very detailed level, don’t you?
Bruch: At a very detailed level, I also am responsible for:
- Clinical systems analysis
- Maintenance of 30 applications
- Troubleshooting
- Expert knowledge of all applications
- 24 hour call support as the primary or secondary contact
- Hardware and network support
Lucas: How do you manage to keep all that discrete application knowledge and detail in your head?
Bruch: I maintain my knowledge of the applications by approaching them from the user’s perspective and understanding at a basic business level what they are trying to accomplish. I keep a model of this system flow in my head. I also have it documented – something I have tried to do for all basic processes. When a specific question arises, I know what the application is trying to accomplish, so I can either remember directly how the system does it or expeditiously rediscover how a particular detail was implemented. It really is an application of top/down[1] thinking where I work my way to the middle or whatever level is necessary to solve the problem.
Lucas: Do you know that you are describing a thought process that is very similar to the concept of high level functionality being described in epics which are then detailed in user stories?
Bruch: Yes, I am aware of that now, but I actually gained that articulation of those terms from my recent reading of your blog. Prior to that; it was something that I just did naturally because it made sense to do it that way.
Lucas: How do you control the various amounts and levels of work that you do and deal with?
Bruch: I encapsulate each request to stand on its own. That’s important! I would equate it to a user story. I move them through a process that is similar to what you refer to in your blog in transforming a user story, into acceptance criteria then test cases then an implementation. I always have the concept early on what is the definition of DONE for the issue. That’s critical!
Lucas: How do you set priorities and make estimates?
Bruch: Estimates are always difficult to make and subject to change. I always determine priority first, so I can focus in on the key items. If it concerns patient care or patient health related information it has the highest priority and must be addressed immediately and correctly.
Lucas: How do you ensure quality?
Bruch: In essence, I follow much of the philosophy that was documented in the Toyota Way[2]. I ensure I have all the facts as it pertains to the event by good communications with all the various users involved. Frequently a problem doesn’t originate in one department or one place. That is why it is important to reach out to everyone involved. I try to break a problem down quickly into its constituent parts and hypothesize each one and test the hypothesis. If any of my hypotheses are false then I reevaluate and create a new one. Each department has its own unique understanding of the process – registration is different from bed control which is different from nursing. I have to look at things from an overall process and goal and then resolve how each department implements it often by looking at the underlying system.
Lucas: How many separate items are you dealing with on an average day?
Bruch: There is on average around 20 items that require my direct attention, an intense day would be more than double that.
Lucas: That is quite a work load! How are you effectively able to communicate with so many different people in a single day?
Bruch: By conversing with them in the language and terms that they use every day and understand. It saves a significant amount of voice, email and text time. Plus it puts the user at ease since you are not introducing terms to them that they are unfamiliar with when they are in the middle of a problem.
Lucas: Good communications is one of the prime ingredients of agile. You seem to be taking it to another level and have implemented something that I have heard being referred to as “agile speak[3]” where people use a common and often precise language to communicate.
Bruch: It’s important to communicate well throughout the organization structure. I also always keep my management apprised of the status of items that could escalate to them. These are issues they would need to facilitate. That way, when an issue rises to that level, they are in a position to rapidly mobilize resources, because they already understand the problem.
Lucas: How do you manage to maintain progress on your strategic tasks while dealing with so many tactical issues?
Bruch: I always focus on the goals. It sounds like a cliché, but too many people often lose sight of the end goal. They get mired in minutia and form that doesn’t count. They waste most of their time and effort on triviality and processes that don’t add value. It’s very much an aspect of the Pareto Principle’s[4] 80/20 rule. I constantly keep a queue of work items; both electronically and in my head, which I verify the priority. I reorder this stack daily. This is very similar to the concept of product backlogs and stack ranking. I also distribute responsibility and work as much as possible and employ a team concept vigorously. However, the situation I have at the hospital does not allow for single focus dedication. I might have, at any one time, 10 people, each one working on more than one team at a time and each team dealing with more than one unit of work.
Lucas: That’s usually contra indicated in agile where focus and dedication bring on velocity. How are you managing to keep that all straight and maintain the efficiency of your team’s actions?
Bruch: It does get hectic, I would say very hectic; but I believe strongly in the concept of team empowerment. That’s the first key – good decision making at the lowest possible level is always the most expeditious way of resolving work. The second key – I call “T2 communications”[5]. It stands for terrific and tight communications. By terrific, I mean, immediate and complete; by tight I mean to the point and directed at the right person or persons. I implemented this, first by being the communications conduit myself. Then as the teams got used to what was being communicated; I began to ask an individual to relate what they just told me to specific people. I explained why those individuals needed to know that information. Gradually by cross pollinating my teams; they were able to share information with each other. I phased out of being the conduit. I also, as a part of this concept; do a lot of MBWA[6] with my cell phone glued to my ear. In fact, I do a lot of things with my cell phone glued to my ear. That can at times become overwhelming, but it’s a matter of balance. My focus during my MBWAs is always on maintaining quality first and ensuring a common understanding of priority. I also, where necessary, provide guidance. I always treat myself as a team of one when I am working as an individual. That sounds like a strange concept to some people, but it is really about expectations and treating yourself no different than others. I have always believed in leading by example and won’t ask someone to do something I am unwilling to do – provided I am technically able to do it.
Lucas: So by a scrupulous application of the Pareto Principle and teamwork, supported by terrific and tight communications, you have achieved a level of agility that has enabled you to implement a sustained continuous improvement program.
Bruch: Yes and thanks to your blog I am more aware of better articulations for the things I have been doing. They have helped me to coalesce my thinking and express it in better terms. I especially liked your post, “HCM, HIM and Agile are Perfect Together” which I would like to follow up with more research. “A Simple Definition of Kanban Leads to Agile Productivity” I thought was helpful in creating a simple spreadsheet that I now use to track my work in progress. I thought your post “Middle of the Road CIOs are Getting Hit by the Innovation Truck” was something every CIO and MIS manager needs to read. The comic screen bean image fleeing before the truck caught my eye. I also recently read, based on your recommendation, Stephen Denning’s book, “The Leader’s Guide to Radical Management. It was a fascinating read and I can see much of what it refers to a long term trends already gaining movement within industry.
Lucas: Your cell is giving off a custom notification tone; I guess it’s time for you to focus on the 20% again.
Bruch: Indeed.
[1] A top-down approach (also known as stepwise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. Top-down design was promoted in the 1970s by IBM researcher Harlan Mills and Niklaus Wirth. Top-down methods were favored in software engineering until the late 1980s, and object-oriented programming assisted in demonstrating the idea that both aspects of top-down and bottom-up programming could be utilized.
[2] The Toyota Way is a set of principles and behaviors that underlie the Toyota Motor Corporation’s managerial approach. Toyota first summed up its philosophy in 2001, calling it “The Toyota Way 2001.” The two focal points of the principles are continuous improvement and respect for people. The principles for a continuous improvement include establishing a long-term vision, working on challenges, continual innovation, and going to the source of the issue or problem. The principles relating to respect for people include ways of building respect and teamwork. In 2004, Dr. Jeffrey Liker, a University of Michigan professor of industrial engineering, published “The Toyota Way.”
[3] I will define this more at a later time since I have not found a good generally accepted definition for this yet.
[4] The Pareto principle (also known as the 80–20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. It was named it after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of the land in Italy was owned by 20% of the population.
[5] Pronounced T-Squared
[6] The term “management by walking around”, refers to a style of business management which involves managers wandering around, in an unstructured manner, through the workplace(s), at random, to check with employees, or equipment, about the status of ongoing work. The emphasis is on the word “wandering” as an impromptu movement within a workplace, rather than a plan where employees expect a visit from managers at more systematic, pre-approved or scheduled times. The expected benefit is that a manager, by random sampling of events or employee discussions, is more likely to facilitate the productivity and total quality management of the organization, as compared to remaining in a specific office area and waiting for employees, or the delivery of status reports, to arrive there, as events warrant in the workplace.
The origin of the term has been traced to executives at the company Hewlett-Packard, for management practices in the 1970s. The management consultants Tom Peters and Robert H. Waterman used the term in their 1982 book In Search of Excellence: lessons from America’s best-run companies.
Keeping Agile™ with Brian Lucas 
Thank you Brian and Wayne. Always interesting to learn from those who are doing instead of just talking about doing.
Thanks for the comment Jack! I agree with you thinking and talking without doing leads to a useless life!
The term “Natural Agilist” is perfect. It embodies all of the attributes of the industrial revolution, American ingenuity and entrepreneurial spirit that is driven by a competitive marketplace. It’s unfortunate that for a whole variety of reasons the natural agilists have been shackled at an alarming rate.
Thanks for your comment George. As an entrepreneur you are naturally (if I may over use that word) frustrated whenever regulation interferes with business adaptability. As you should be; after all it is your business’s life blood to move quickly into opportunity. Having said that, “The only shackles we wear are those of our own choice!” – The Book of Brian: Chapter 1. We live in a voting republic and are responsible for our government such as it is. It is up to all of us to vote change into the system we have that power. So few vote; and many less are truly educated as to the issues with their knowledge existing only in sound bites and their opinion implanted in their brain by media pundits. That must and will change in the future because it is incompatible with the basic need of society to advance.
AS A PROJECT MANAGER WHO HAS WORKED IN INFORMATION SYSTEMS FOR OVER 22 YEARS I WOULD LOVE TO WORK WITH OR FOR AN ENLIGHTENED PERSON LIKE WAYNE. THANKS FOR POSTING THIS BLOG.
Thank you for the reply Eric! I will pass your comment on to Wayne. It is high praise indeed, but I assure you in his case is well merited.
Wayne sounds like a super manager. I wish my boss was this smart and did this much work. I hope his hospital appreciates him.
Yes John, Mr. Bruch is one of those very smart, incredibly productive persons who do the work of an entire team every day.
Great interview! It amazes me how you can speak with so many with varied backgrounds and beak their successes down in to the innate ability to be Agile. Wayne seems to have an exceptional ability to keep track of a long list of projects and required actions. He also speaks about re-prioritizing that list on a daily basis. That is a very valuable attribute, and keeps in sync with the theme of Agile.
With each interview you do, I am able to focus in on what other Agile managers are doing, and I learn from their methodology. As with most Agile minded managers, I will continue to adjust my own methodology based on new knowledge. Your Blog certainly helps. Thank you, and keep up the good work!
Thanks Dave, Keeping Agile is about learning and teaching. We all have something to learn from one another and we all have something to teach another. From the comments that I have received on your interview, it has inspired and taught many to become more engaged in their work and career. You have such a positive attitude about being responsible for your own career that we should do another interview just on that subject. Thanks again for participating and sharing your wealth of knowledge and experience! -Brian
Great story! Very meaningful to hear a real life examply instead of a theory. I never focused on agile as being a fundamental way of thinking about everything. Your blog Brian, has really opened my eyes. Keep posting!
I have two more interviews Jack that I have done, but not yet posted. I just have to find the time. Thank you for being a regular reader. -Brian
Brian – Thank you for your response. I have actually read the post 4 times now and am getting something extra out of it with each reading. This series on interviews with natural agilists is definitely a winner. It is an approach to teaching by example that I can understand. Your blog is definitely turning my mind around about the importance of agile and the need for me to be more involved with my development teams. Thank you again for posting such solid and original material and not just reprinting or rewording what others have already said. – Jack
Brian – I read this interview again and all I can say is if Mr. Bruch is ever planning on leaving the hospital, I would love to have him work for me. The T squared communications concept is something I plan on implementing. Do you know if Mr. Bruch has any documentation on it or would be willing to write a post just on his communications concept? I realize that this is for the most part a compendium of best packages, but I like the way he simplified and packaged it. Please let me know, I would like to get started on this. -Jack
Jack – I am let Wayne know he can have a guess spot if he wishes. He would like to post, but it is a matter of time. I actually suggested that he create a backlog of material before he releases his first post, since it is hard to keep up. Thanks for your interest and support! -Brian
Jack, thank you for your interest in my interview and Brian’s informative blog as a whole. I’ve noticed your many replies and I’m very appreciative of your comments. I’d also like to thank Brian for this opportunity. A write-up for the T-squared communications concept is forthcoming. Stay tuned! – Wayne
I was forwarded this by our CIO as a good read. Since we are not a health care organization and Bruch is not a software development manager what is the message you are trying to give here about agile software development? I didn’t get your point…
Ben, I believe the message is agile methodologies can be applied anywhere to facilitate process improvement, problem resolution, fulfillment, optimization of communication and hierarchical structure. This isn’t something that has to be limited to software development.
Is Wayne involved at all with software development? What methodology does he follow is it Scrum? and what development tools do they use?
S, our business model at the hospital and that of the parent corporation allows all development to occur outside of the environment. For all intents and purposes, we are the end user. Packages are delivered and installed, and we are responsible for final QA, file building and training. We do work closely with the developer’s analysts during implementation prior to go-live. – Wayne
Hey Brian – I am a project manager and our CIO is a fan of your blog and likes Wayne’s T-squared communications idea. He has asked me to create something like this for our organization. Do you have anything else on this or could Wayne post some more details about his concept? It would help me out a lot. Thank you in advance!
Zoe – Wayne is writing a brief on T-Squared communications. It will be posted here as a separate article. -Brian
Brian can you tell me if Wayne is open for few questions concerning how he maintains his priority list and what process he uses to decide what takes priority. I am trying to implement a new and more responsive prioritization and I have been told to look at how Wayne does this. I assume he has some kind of formula for doing this. Any help you could give me would be appreciated the deadline I have for coming up with this is short. GH
Gene – I will pass your request and email on to Wayne. -Brian
Gene – I am planning a post on T-squared communications that Brian was kind enough to offer to post on his blog. I will cover in somewhat more depth priorities there. However, let me say that I use a Maslovian Ladder principle in priorities which remains fairly constant as far as categories of issues are concerned. This gives me the stability to handle what at times are very conflicting sets of priorities. For example, the first priority is to a patient’s care and health. That overrides all concerns regardless of what level the priority has been set at, even the C-level. A patient’s health is the main reason we exist. Immediately following that is the patient’s right to privacy of information. Below privacy is the efficiency of systems and operations for the hospital staff that we support. I have specifically not covered government regulations be they federal, state, etc. since those are considerations that are built into the systems themselves. This is what I would call the first tier of priorities.
The second tier of priorities deals with augmenting or facilitating information flow. These are concerns such as making data available in a particular form to a requesting hospital entity or outside medical or insurance entity that, with the patient’s approval, enables a patient to receive services, treatments, financing, or insurance. Every time that I receive a request or generate a priority of my own I pass it through this “ladder of needs” analysis and I always work this ladder from a top down fashion. This prevents for the most part any argument or confusion about how resources, particularly limited ones, are assigned to an issue. The tricky part is when you have two issues or priorities in the same category. Generally speaking, if it is a priority in the first tier I will have resources assigned to each and every one of those issues simultaneously, pulling them from lower priority activities.
The important thing to understand is that the ladder you create has a very high ethical connotation and is very strategic and stable. That’s something that you need to devise for yourself up front. Depending upon what business you’re in, you would have a different set of criteria. The most important thing is that you consider the ethics as being your overall guiding factor when creating your own ladder.
-Wayne
I have been a supervising nurse for 13 years and in my experience the computer department from various hospitals has always treated us in nursing as if we were stupid whenever we had a problem with the system. It was always something that we did that screwed up the computer. It sounds like things are different at the hospital where Mr. Bruch works and that he has a much better attitude.
Fran, this one goes back to the cliche’d golden rule. I wouldn’t like to be treated poorly when I call anyone for a service issue, either. There are times that the user is frustrated and feeling less than capable when he or she is unable to function. I understand that I become the “suggestion box” for all of IT’s perceived inadequacies just by being on the other end of the phone. This user frustration can be attributed, although by no means always, to a lack of understanding. That’s OK. You know more about nursing than I do. That’s why I’m not a nurse. I tell this to my staff with the expectation that it will put the user experience in perspective, and they tend to work in a calm and even-handed manner. -Wayne
Wayne,
Fran forwarded me your interview and your response to her comment. I am very impressed with both. I am surprised you commented so well and so rapidly. It appears that you are true to your words in the interview. I certainly wish that you were our computer systems director. As head of nursing for our hospital, I am forwarding your interview to our computer systems people. I hope they take the hint! Thanks for sharing your expertise and thank you Brian for starting this novel blog. I am going to read your other posts. Haley
I was sent this link by a friend. Wayne sounds like a super star. Wish he was my boss!
Wow Brian your blog is really going viral here, everyone is reading it, great interview with Wayne, what an enlightened manager.
Yes indeed he is Leigh! Special thanks goes out to Fran who first read Wayne’s interview, commented and forwarded the link to her friends. Obviously this is resonating with a number of people in your organizaiton.
Wayne – You sound like the perfect IT Manager. There is so much knowledge, care and concern for the patient and your users, like we nurses, that we are all very impressed with your interview. I say all since you have been the topic of our break chats ever since Fran started circulating the link to us. I could not find you on FaceBook do you use FaceBook or have your own website? Anyway we are looking to improve our communication between nursing and IT and I was wondering if you would care to share any of the details on how you make this happen at your hospital. I think it would be interesting if you wrote a post about your interview from your perspective. Like how long it took? Are you and Brian colleagues? Is this actual dialog? Did you get questions ahead of time? This was such a perfect interview and you both seem to have very good communication skills. Do you ever speak at hospital conferences like AHA or NPC? I think many of us would enjoy hearing you speak.
Bonnie – Thank you for your positive feedback. I appreciate the time that you and your colleagues have taken to read Brian’s blog, this interview and post comments. Comments such as yours are valuable not just to me, but to other readers, and are the life-blood of any blog. You add your thoughts and qualifications to the intellectual content of these posts, and create a value-add to the information within. A majority of readers, even if they follow a blog every day, will not comment. That’s why people like yourself and everyone that has posted end up speaking for a larger number of individuals who let the comments speak for them.
It is difficult for me to speak at public engagements due to the intensity of my schedule. However, Brian has offered me “Guest Posting” privileges on his blog and I will be creating a series of posts; the first of which will deal with how it came about that Brian interviewed me, what the interview experience was like, and how profoundly self-educating I found it to be. I think this would be a great way to share common experiences with a large audience, greater than speaking at an event.
-Wayne
After looking into a handful of the blog articles on your blog,
I truly appreciate your technique of writing a blog.
I book marked it to my bookmark website list and will be
checking back soon. Please visit my web site as well
and tell me how you feel.