It could be that my brain just thinks this way, but I’m baffled that people don’t intuitively create information architecture. For me this takes many forms like mind maps, application architectures, swim lanes, flow charts, whiteboard drawings, paper sketches, among other things. What could be more basic then drawing a bunch of boxes, connecting the lines, dot in the servers, show the user flow, and end up with a diagram for what you need to build. Or showing the step-by-step of a process and connecting the relationships between these steps.
For applications I create detailed architecture drawings that document the connections and information flow, but even if you are diagramming the relationships between non-technical parts of your business you are creating information architecture. The act of drawing this forces you to think hard about how your business, application, process, or whatever works. The resulting document becomes a valuable tool to communicate this thinking to others within your organization – technical or not.
For example, I recently did an assessment of a development effort that had lots of moving parts. But to document in a spreadsheet or deck that there was a lot of variability didn’t do it justice. It was hard to visualize. So I created a flow chart of the process, connecting applications to products, to development teams, to hosting environments, to downstream processes, to revenue, etc., etc… This gave a visual high-level view of all the parts, and graphically defined the variability in the system in a way that a PowerPoint bullet list couldn’t do. And as a result, discussion and decisions begin from a whole new level.
Base Assumption 1: Mind the Power Center
I’m a fan of iterative development. There are schools of thought that say “all you need are user stories”, or in extreme programming a desire to have as little documentation as possible and ideally none. But think about what this does. If your engineers are not collecting requirements from the business, then they have the control, and your power center is off balance. And to be fair, this is an overreaction from business who stifled development with the bureaucracy of over documenting and over analyzing.
Base Assumption 2: The Need for Product Management
This is why I believe Product Management needs to reside as its own department, in-between the others. It needs to have the discomfort of accountability to all departments, combined with the authority to enforce a disciplined documentation process. It needs the strategic capacity to identify ways of achieving the organizational goals with an insight for designing appropriate tactical solutions.
Base Assumption 3: Information Architecture is a Required Competency
A big part of effective Product Management is information architecture. Even if you are in a non-technical industry, diagramming process flows is an example of how IA can be an invaluable tool. I’m not saying you don’t need the PowerPoint decks, CBAs, business cases, and all the other tools. BUT information architecture seems to be left out, or mitigated to something done by technologists or ‘technical product managers.’ If you are not developing this skill within your product management team, you are missing a huge opportunity.
Assuming you buy into the resulting value of information architecture, here are areas where I think people miss:
Discipline 1: Make the Time
In my estimation people are in a rush to deliver something, anything. Make the time to do it right. Delivering something mediocre is just that. Every hour you invest creating good information architecture saves you days of time fixing what you built wrong.
Discipline 2: Quality
Make it kick butt. When I work on an application I want to dominate the world. I want it to be so great that the competition will just give up from witness to its fantastic awesomeness. But you don’t get this without doing a quality job, with quality discovery, and quality information architecture.
Discipline 3: Understanding
You don’t build a rocket without a rocket scientist, and you don’t build whatever you’re going to build without subject matter experts (SMEs). I don’t care how much you know about application development, YOU WILL FAIL if your process doesn’t incorporate the non-technical experts, the business savvy leaders, and the everyone else your business depends on. THEY know the day to day, not you. So take the time to sit down and understand what they do. Along the way, develop the working relationships you will undoubtedly need as new questions come up. And of course, put all you learn into your information architecture.
Discipline 4: Patience
Go through as many revs of your document as it takes. I’m losing my hair and there is a reason why – I won’t give up until it is right. Every turn of your diagram is one less time you have to correct your code. I guarantee this is a cheaper way to discover your mistakes, so do the work.
Discipline 5: Replicate Yourself
It is impossible for you to see everything across your project. And depending on the size of your project, you may need ‘specialists’ who focus on pieces and parts as you look to the whole. But either way, get others involved, and have co-ownership of the information architecture. Regardless of who is drawing the IA, make sure you both talk through the details before you build anything.
Discipline 6: Review, Review, Review
Once you have your document, go back to the SMEs and ensure that it makes sense to them. This will likely require some revisions, but that is a good thing – see Discipline 4.
Discipline 7: Focus on Core Objectives
You have to have a clear definition of your organization’s objectives, how your project supports that, and be disciplined enough to keep the focus. If you don’t have this, none of the rest matters.
Discipline 8: The Big One – Eliminate Yourself
Assume you will be fired tomorrow, so today is your last day of work. But, sort of like saying goodbye to a friend, you want to give it the best journey possible. Similarly, work your butt off today, and give your project what it needs to succeed. Document what you know, make sure others do, so if you get sucked into a black hole the project has what it needs to move forward on a swift successful trajectory. And how do you do this? By creating phenomenal information architecture!
I look at productivity and reward programs with a cynical eye. This isn't to say that reward isn't important, it is just the way it's done. For example, a paper "you did great" award that someone is going to tack to their cube is demeaning, especially when executives are rewarded in far more grandiose ways. Creating a truly inspired team requires a leader to turn this on it's head.
Rather than "Leadership" I like to think of "Servantship". I suppose this is essentially servant leadership, but I fear that concept has been mentally packaged up and hung on a mental hook in the back storage room of many leader's mind.
When leading teams I view my role as having two unequal parts.
Team Leadership
The first, but smaller part is to:
- collect information from the team
- direct discussion about the important topics
- pull the right decisions out of the team
- make sure the direction that gets set is informed by the team and in alignment with the business
Leading with the team, rather than TO the team, is so much more effective, hands down, period. The reality is that when your team is aligned to the goals of the organization (OG), and the project execution (PE) is designed to directly impact these goals (PG), by association the goals of the project directly support those of the organization (PE + PG → OG).
Of course, making this successful assumes you get great people on your team. I think that hiring strategy is something that you are continuously learning how to do well. Jason Fried, CEO of 37 Signals has some good ideas about writing a job description that have worked out well for colleagues of mine, and is something I'll be testing out.
Support Support Support!
By FAR, this is so much more important than leading. Sort of like location in real estate, amazing leadership is all about supporting the team. Disagree? Then you probably aren't someone I want to work for, and my guess is that your team isn't happy about it either.
What keeps me up at night is when there is something I can do to keep my team moving. I'll work to the early hours of the morning or over the weekends if it means that I can keep my team moving.
One of my first bosses had this quality. I was in college working for a remodel construction company. We were contracted to rebuild a parapet wall along the top of a mall that had been damaged in an earthquake. It was over 120 degrees on that roof, and our crew was working with another sub-contracted team. While the other team's leader sat down in the cool air conditioning, our boss cam up with cold drinks then helped us move and place 3/4" plywood sheets. He was a great leader, and this wasn't abnormal for him. But the stark contrast between his behavior and the leader of the other team really stood out.
I think about that often. It's one of my favorite business memories. And as I lead teams I think about what I can do for the team. It might not be cold drinks and moving plywood, but as a metaphor, in whatever I do I'd like my team to feel that I am a part of the team and there to do whatever it takes to support them.
The Downhill Roll
Working in start-up companies has given me a short cycle time with employment, and the opportunity to work for a wide range of leaders. The other thing it's given me is visibility to the top. Even where I've had a boss between the CEO and myself, it is easy to see that the company culture is set by the CEO. Even a great boss can not completely shield a team from a toxic environment (although to the extent possible I think this is part of the 'support' role).
In "Good to Great" Jim Collins does a great job of delineating the difference between Level 4 and Level 5 leaders. Of course nobody is an exact match for one or the other, but as I think back, the better leaders tended to be more like the Level 5, and vice versa. I recommend picking up the book if you haven't read it - or my preference, the audio book and listen while you drive & fly.
>>
Level One: A capable individual who makes productive contributions through talent, knowledge, skills and good work habits.
Level Two: Also a team member, he contributes his individual capabilities to the achievement of the group objectives and works effectively with others in group settings.
Level Three: A competent manager. He knows how to organize people and resources towards the effective and efficient pursuit of predetermined objectives.
Level Four: Goes one step further and becomes an effective leader, he catalyses commitment to and a vigorous pursuit of a clear and compelling vision, stimulating higher performance standards.
Level Five: The person who knows how to build enduring greatness through paradoxical blend of personal humility and professional will.
<<
Rolling the Right Stuff Downhill
I had a leader tell me once that he was impressed with my passion, and told me to never lose it. When I'm doing what I do best, getting paid fairly, and aligned to the goals of the organization, having passion for what I do isn't a problem.
But it begins with leadership. If what I'm working on isn't making an impact to the organizational goals, and helping build a great company, there is nothing to be passionate about. The role of leadership is to create a culture with the right people, doing the right stuff, aligned to the right direction.
This brings me back to hiring, support, and Moneyball.
1. Hire people with potential. People who are hungry, anxious to do great work. People who, when you interview them can't stop talking about how they love to do whatever it is that you are looking for - even to the extent that what they do is their hobby that they get paid for. Go rent the movie Moneyball.
2. Align your project to the goals of the organization (this makes the work meaningful).
3. Get your team involved in planning & decisions. With them engaged in the process, the group inherits a strong sense of ownership, and will be extremely driven to deliver.
4. Give credit where credit is due - which is always the team. I like to participate in the great work, but I'm acutely aware that without the great people on the team, the results wouldn't be what they are.
5. Support the team however you can. If there is a problem, fix it.
6. You are accountable. If there is a failure, you probably didn't align the team with the right goals, so it is yours to take.
Want to eliminate passion in your workforce? Detach them from the organizational goals, limit their visibility, and implement a bunch of silly rewards programs.
Want a highly productive team? Roll the right stuff downhill. Besides, inspiration rolls easier and faster than commiseration and complacency. Not to mention that it is more fun and delivers better results. Which makes me wonder why there are so many lackluster leaders - I just don't get it.
I'm sure you've put together a few Power Point decks and modeled data in Excel. Both are great tools. But are you taking advantage of information architecture (IA) to make strategic decisions?
When using IA for strategic purposes it may end of looking more like a mind map. Although mind maps tend to stem from a common "seed" idea and branch out. I'm a fan of making lists of related things, and using connecting lines to demonstrate cross dependency. The more related lists you get, the more inter-related cross dependencies and touch points.
One thing that will become apparent very quickly is if you have a high degree of variability in your diagram, characterized by multiple intertwined many-to-many relationships. Note that many-to-many relationships aren't bad per se. If you have a clearly defined process that minimizes the impact of these relationships it may demonstrate the mature capability of your system. On the other hand, when variability and cross dependency are the rule, what you are seeing is an undisciplined approach that introduces significant risk into your business.
But here in lies the value proposition of strategic IA, especially considering that many people are visual learners, but can't visualize from a bullet list on a Power Point or connect the dots between numbers on a spreadsheet and the underlying processes that create that number.
The trick is finding people who can create the IA documentation. It takes more than just knowing how to draw this type of documentation. You need to have an understanding of business, operations, clients, technology, or whatever the relevant pieces are that drive your business >> or more to the point >> someone who is capable of learning these pieces, and represent that as they draft the IA.
See my post "Legacy to SaaS Transition? Mind the Gap!" and my thoughts on the role of product management. I believe that this type of IA documentation will naturally result from the discovery process. And in my opinion this type of documentation is an essential part of Product Management, because it enables better strategic design within the organization by maximizing the discovery time invested with a comprehensive output that is visual and easy to quickly understand. I'm tempted to post examples of the strategic IA work I've done, but as you can imagine all of my work contains confidential intellectual property.
Finally, for this to be effective senior leadership needs to embrace this as a learning mechanism. It isn't that Power Point decks and Excel models and CBAs aren't just as relevant. But the IA diagrams create the context for all of this to come together. Without being able to "see" what you are currently doing, and "see" what the impact of the proposal will be, conceptualizing the reduction of risk, or the expansion of capability, or the impact to clients and operations, etc., is difficult. At the very least it can give some perspective about why a significant investment is worth it, or why a problem is worth fixing, and so on.
With Software as a Service (SaaS) coming to maturity in the last several years, and the market valuation of companies embracing SaaS/Cloud/Web technologies, there is an exodus in all sorts of industries with businesses migrating from legacy infrastructure. And for good reason, SaaS offers all sorts of benefits.
But I've noticed a gap that if left unchecked can become a significant area of risk.
Empirical Understanding
On one hand you have people with empirical understanding. These people know what the business does in a hands on way - empirically. They know the process step-by-step, into the details, and "WHY" the business does "WHAT."
Pain:
- Slow and lacks automation
- Runs on old technology or hand done / paper processes
- Uses a "throw people at it" approach
- High cost
- An empirically based understanding
- A depth of understanding into the details
- The foundation that allows the business to get the service "right"
- Products, services, and support that are based on this knowledge
Technical Capability
On the other hand, businesses either develop in-house talent or retain outsource vendors who have strong technical capability. These teams build better ways to do what the business does, replacing slow or manual processes with automation, and extending areas of control to clients.
Pain:
- Requires significant upfront investment
- Requires time to build
- Requires the right people to develop
- Requires the business embrace a new way of doing business
Benefits:
- Current technology with lower cost of ownership
- Transitions human cost to clients
- Gives clients the control they want
- Can create a cross business platform
Risk In The Middle
The gap between these groups is almost a "generational" gap, where the empirical "legacy" generation is eventually eclipsed by the new technical "SaaS" generation. But so what? What is the big deal?
Think first about the complexity of your businesses. Your operations people fulfill your products or services, they don't build or understand technology.
Technology is capable of providing tools that solve complex problems. Technologists build tools, they don't fulfill your products or services.
If you do not form a plan to bridge these two groups, you will effectively build a "generation gap" into your business.
Solving this at first brush may seem easy, but consider the following:
Empirical Knowledge:
- Does your leadership have a deep empirical understanding of your products or services?
- Do you have mechanisms in place that help facilitate this understanding with leadership?
- Do you utilize these mechanisms to help communicate this understanding to your technologists?
- If the answer to any of these is "no", are you planning to implement learning mechanisms?
Technical Knowledge:
- Does your leadership have a deep understanding of how your technology is built?
- Do you have mechanisms in place that help facilitate this understanding with leadership?
- Do you utilize these mechanisms to help communicate this understanding to your operations people?
- If the answer to any of these is "no", are you planning to implement learning mechanisms?
The Role of Product Management
Senior leadership is always incredibly busy. So the first thing I would say is that if your business is considering or beginning a migration from a legacy platform to SaaS, an investment of time from leadership is critical. That said, the goal should be to maximize the time spent by leadership. But the same is true of your operations and technology development groups.
Product management should take a leadership role in facilitating the information share and learning. Moreover, the design of this approach should work for leadership, ops, and development.
This isn't to say that product management should become a training team. You may also need create such a team, but product management should be blazing the trail.
Why product management? If you are going to evolve into a SaaS based company, you need to evolve your product management competency to support this. You will need product managers who come from both sides. Technical PMs need to take the time to thoroughly understand the business, and business PMs the technology. How else can you possibly manage SaaS based products?
What you end up with is a small group that sees both sides of the fence. This should be reflected in the product requirement documents, application architectures, functional specifications, executive summaries, business cases, and the myriad of documents that come out of product management.
From there I'm a big fan of web-based video. This may be where you incorporate a training team who can take direction from product management on the "who & what" to film. Video is a great format, is inexpensive, and becomes a powerful tool. You can easily do interviews, screen capture, and film the white boarding of concepts, to name a few things. It is a "do it once, reuse it many times across multiple locations" format. And when you shoot internal-only video, production value takes a back seat to the value of training, and the speed of the impact. Moreover, it is a SaaS based tool, and if you are transitioning to a SaaS platform it is a great way to embrace the concept to build internal competency about the concepts.
Take Away
Obviously there are a lot of ways to skin the cat. But if you are transitioning your business to SaaS, don't just hope that somehow your business will learn the new technology, or that the respective groups will educate each other. To be successful you MUST design a disciplined plan that:
- has product management blaze the trail
- uses tools and/or groups that can educate
- creates content that trains SaaS to operations, and in-house competency to development
- and both sides to leadership
Now Zoom Out
Reconsider that many businesses in many industries are going through a similar migration. And the marketplace is demanding the same Web/Cloud/App based user experience with their business applications that they have with their personal applications. And if it hasn't happened yet, it is likely that your competitors will soon be considering SaaS/Cloud/Web/Apps to support their clients.
Now consider your approach to a SaaS migration. Businesses who win don't just do whatever it is, they do it better. So don't just rush at SaaS. Slow down, migrate better, set the stage for better ongoing execution, and win.
When I was a kid I needed to learn how to swim. But I wanted nothing to do with swim lessons. They finally duped me into being the "teacher's helper". And soon enough, I learned how to swim.
I've always been slightly embarrassed about this swim lesson story. But lately I've been thinking a lot about project execution and alignment to the corporate strategy. It occurred to me that throughout my life there have been many times similar to the swim lesson event, although not always as contrived. Nonetheless, for me to participate at all I needed to be tightly integrated into the leadership of whatever it was.
This isn't to say that I have to be the one in control - just involved. In fact, I've noticed that for me to get really excited about a project, I need to have a team of great people around me. I know that I don't know everything. And I might be a good point for some projects, and not for others - but I'm happy either way as long as my contributions are focused on the success of the overall project.
In large organizations it is easy for all of the strategy to be trapped at the top of a vertical org chart. And you could argue that because of their background, experience, education, and so on, their purpose is to be the strategic component of an organization. You could also argue that because of their level of responsibility, they are too busy to spend much time down in the trenches.
I believe there are ways to overcome these things. In fact, Jim Collins in his research for "Good to Great" found that the majority of GTG companies had CEOs that came from within the company, and the comparison companies far more often had CEOs that came in from the outside. The immediate correlation is that if you have swept the shop floor, driven the fork lift, done the grunt work, and worked your way up, THEN you understand how the business works. You have a deep understanding that someone coming in from the outside can't have.
At least, they can't have it without going through a discovery process. Having worked in many different companies, industries, and departments; and having developed applications that have modules serving many departmental workflows simultaneously; I've learned the skill of learning how things work through a discovery process.
The first thing you need to do is make time. The second thing you need to do is take notes, make lists, draw flow charts, and whatever it takes to capture and document the way things work. And finally, you need to amalgamate all of this into a cohesive document as if you are going to present it - even if it is just for yourself.
This effort gives you deep understanding. It gives you working relationships. It identifies opportunities for improvement, competitive advantages, and connects the dots. Without all of this it is difficult, if not impossible to have a clear understanding of the right strategic direction. But this effort can result in a perspective similar to that of a leader that spent years rising up within the organization.
Now consider the working relationships piece of that. When you've spent time with the people doing the work, they get to know you, are able to contribute to your approach, and feel like they are involved in the process.
In a large organization this almost becomes more important. Cultivating this understanding throughout your leadership is critical. And more than just reaching down within their own departments, it is essential to do cross-departmental discovery. Follow the process from beginning to end, point of sale to fulfillment, infrastructure development to client support.
The depth and breath of your leadership's understanding, the better your ability to make good strategic decisions will be. AND the organization will benefit from the foundation of the working relationships. Leaders will understand who does what, and the people on the teams will be more aligned to the strategic direction.
Conversely, when strategy is all at the top gaining alignment down the ranks is difficult if not impossible. If leadership doesn't understand the organization, people don't know how to align. If people don't have rapport with the leaders, they aren't motivated to align.
Finally, if people are motivated to align to your strategy, they will be more productive. On one hand, you eliminate most of the "out of alignment" work that would have been done with "in alignment" work. You also boost the overall enthusiasm the workforce has for achieving the goals of the strategic direction. When people are focused on the right things, and passionate about doing these things, it becomes a great recipe for productivity.
Obviously there are many other components to creating a high performing organization. But if you don't take the time to get the deep understanding and build rapport then you won't foster alignment or motivation, and subsequently high productivity.
I'm not a gambler, but I like to play in Vegas. I don't play because I'm looking to hit it big and retire to a life of comfortable irrelevance. For me, the allure is an empirical touch point for luck, combined with the short cycle time, and tangible feelings of winning or losing. Next time you are in Vegas, you have to play - even if it is just a little.
>> I put $20.00 into a penny slot, 1 cent per line, 9 lines, 9 cents per bet
I think most people think about luck as something good or bad that pops up out of the blue. You do nothing and there it is.
I'm going through "Great by Choice" (Jim Collins & Morten T. Hansen - go buy it) for the first time, and there is this great concept, paraphrasing roughly "It isn't whether you will have luck or not, but what you do with the luck you get."
At one point, I was put in charge of a small project. It was a proof of concept at a particular level. But there was opportunity to be had.
>> The penny machine stats hitting, I double the bets, 2 cents per line, 9 lines, 18 cents per bet
Over the course of the next year I worked hard. The project grew. I had a phenomenal team of people working with me. We were getting recognition for our work, and it felt great.
>> The machine is ticking along, I'm up, and go to 5 cents per line, 9 lines, 45 cents per bet
Then, as I was preparing to launch into an new wave of development that will expand the application into a fully fledged platform, the business shuffles the projects and sends the development work to another part of the company.
>> The machine loses steam and I'm down, way down.
But there is a silver lining here. I was smart about the way that I developed the code, and how I had built my team. I was lined up to reuse that code for other purposes and had a smart team with solid working relationships that were locked and loaded.
>> The machine is up and down, but the bottom isn't falling out
As I headed into the next project the stage was set for a quick ramp-up and an accelerated deliverable schedule.
>> The machine was climbing again
Even in cases where the worst happens and it all falls away, you have to always be thinking about how what you are doing now prepares you for the best AND worst case scenarios. This is your job as a leader, so when it all hits the fan if you don't have a plan B the finger of responsibility only points at you!
>> I'm part of a players club, and earn points for all the money I "invest" into the machine.
I've lost my job more times because the company I worked for went out of business - but that is the high risk nature of the start up world. But things happen in large companies as well, because you are battling other strong wills, leaders who are overwhelmed and under informed, and have to work with people who don't always have the background they need to make the best decisions. It's life.
>> When the machine is out, at least I've earned some points that will help me get good offers on discount hotel rooms for my next stay. See, it REALLY is "investing" after all!
Several times I've worked on projects where aging mainframes or early web architecture is either causing maintenance pain, or forcing a rebuild all together.
In the case of main frame systems it doesn't just look bad, you see hardware that reminds you of the "fax machine beat down" scene from the movie Office Space. And until developing with multiple application layers reached maturity, many apps were build with the business logic in the HTML files making updates difficult and timely.
Given these technical limitations, business leaders have had to deal with high costs, long time lines, and nominal value returns. And just because a better methods exists, it doesn't mean that all development is equal or good. So it is understandable that business leaders are wary of new development projects, since they may be high cost and result in the same frustrating situation.
To make matters worse, most business leaders don't have a technical background, and have to rely on the consultation of tech leaders who themselves are not always up-to-date on the latest technology trends. Not that I'm an expert per se, but I do surround myself with people who are - and based on successful experiences in application deployments I've developed an approach SaaS platform design.
This shouldn't be a unique approach, as it is built on best practices. But because of that, I feel like it should be a well tested solution infused with standards that transcend my (or anyone's) individual experience. So I'll call it "my approach" since I'm presenting it here, and because I've personally implemented it with development teams.
My approach to platform design allows your data to be maintained, independent of technology. It allows your applications to be developed and maintained without the limitations of the hardware or UI. It allows your UI to be flexible, and adapt to design trends, new device environments, and better client side technologies. And finally, it makes your hardware cost an ongoing maintenance cost, with the benefit of the best hardware available, and the avoidance of high cost total system replacements.
Learning from the past, the things that have since been fixed are hardware and the user interface (UI). So the question is, how do you break this limitation as you design forward?
The key is to modularize your application. At a high level your application development looks something like this:
A) Client Interface
B) Business Logic
C) Data
D) Hardware
Within each layer there are modular components.
In the Client Interface for example, you'll have CSS, JavaScript, other include files, and so on. And these may be further broken down by application area, component, or conditional need. The obvious advantage here is that you can make updates to one location and have it populate throughout - a one to many time saving solution. Another advantage is that you can create programatic conditionals that affect display, such as co-branded or white label skins.
When you work with highly scalable providers like RackSpace, who have almost magical ability to spin up / down environments you are experiencing hardware flexibility. This ability stems from technologies like RAID servers (redundant array of independent disks). I've been lucky enough to be in hosting facilities and witness RAID servers be pulled from the back of a live site, a replacement inserted, and the replication process begin.
In between these two layers you have your business logic and data.
Most of your development effort should be focused on the development and maintenance of your business logic. And over time, the accumulating client data creates value. But by removing dependency on the UI at the top and the hardware at the foundation, these layers can "float" between, or allow updates to these to upgrade with the progression of hardware and UI development trends.
Adding better security and load balancing to this scenario is now possible, and gives you an architecture that looks something this:
-Firewall [[security layer 1]]
- Load Balancing
A) Client Interface >> design trends >>
- Web Services
- Firewall [[security layer 2]]
B) Business Logic ((development & maintenance))
- Web Services
- Firewall [[security layer 3]]
C) Data <
D) Hardware >> hardware improvements >>
This increase in security is critical, especially for any application that maintains / touches the personal or financial data of its clients.
The load balancing enables application scaling, but it can also allow for transitioning to a disaster recovery environment if necessary.
With these things in place, the technology developed is not only easier and more cost effective to maintain, but has a much longer shelf life. Making the decision to transition to such a platform may be difficult, but from a cost/benefit perspective, the long term benefits should outweigh the up front hurdles and deliver a break even in a reasonable time horizon - even with conservative projections. There are several ways this is realized.
1. Lower technology maintenance costs:
By eliminating the struggle to maintain a rigidly entwined application, UI, and hardware, your technology costs should be reduced or redirected to things that provide higher ROI.
2. Current/better hardware:
By keeping your hardware current it's a given that you make regular updates to the appliances, meaning regular investment. But you avoid the pain of maintaining old hardware, and you distribute the update cost over time rather than getting hit with a huge balloon cost when you are forced to get current.
3. Better technology development costs:
You can focus almost all of your engineering effort directly into the logic of your applications. This should give you better applications over time (assuming you are disciplined in your development and maintenance approach) which translates to better ROI.
4. Increased retention & growth:
Because your applications will be better, they should provide better service to your clients. Of course this assumes you are disciplined in your client engagement approach. But if you do this well, you will increase client retention and growth.
5. Easy, cost effective scaling:
With a larger client base you will need to scale your environment. But because you have removed your hardware dependency, you can scale your physical environments to meet demand, paid for out of revenue. And if your business is seasonal you can scale up/down as needed to manage costs (this assumes you are leasing overflow environments).
6. Momentum:
With all of these things working together, you will develop momentum. Upgrading servers - no big deal, just replicate and go. Upgrading the UI - no big deal, just design and deploy. Adding new features - easy.
7. Competitive advantage:
We are at an inflection point. The dot-com bubble innovated a new way of doing business. The last 10 years adoption of web technology has been adopted and proven in large industry segments. However, the early adopter behavior of this technology, especially by non-web businesses, has not been designed to "move with the development of technology". Therefore, if you update to a flexible format, you can be more nimble than your competition, and your platform becomes a catalyst for great marketplace performance.
Replace yourself - this mindset assumes no long term position
No long term position means you are focused on the organization's success, not your own
Not focusing on your own success means you aren't in it for the money (not that unfair pay is ok or salary is irrelevant, but it isn't the point)
This means that your efforts, your ego, is invested entirely into the organization
All of this maximizes the value you can offer to the organization
Here Is Where It Flips
With the organization benefiting from your maximum potential, it stands the best chance at being successful
If it is successful, this success translates back to the people who made it successful
While employed by the organization, this may mean things like bonuses, promotions, raises, recognition, and greater opportunities
When looking for another job, it qualifies your abilities by pointing to a wildly successful project
Even if you aren't looking for a job, if the project is publically successful, you may be recruited away to greater opportunities
Here Is Where It Flips Again
But none of this is possible if you are hedging your bets
Because if you are hedging your bets, you are trying to prolong your tenure within an organization
If you are trying to prolong your tenure, your actions will be in favor of self preservation and will tend to lack any profound contributions
Your approach at best will be lucky
More likely it will be one of "don't rock the boat"
And at its worst, you approach will become one that binds the organization with problems you've intentionally created to maximize your stay as you solve these problems
Why Business Leaders Miss the Point
In my opinion, most people go into business for things like money, power, and pride
If a person is working for money, power, or pride, their motivations are focused on these, not the organization
If a person isn't focused on the organization, then they aren't working to replace themselves
And if they aren't working to replace themselves, then they aren't delivering the greatest value
Because most people go into business for money, power, or pride, it is completely unintuitive to them WHY you would focus on the organization rather than yourself
Look to Behavior, Not the Rhetoric
Regardless of what your colleagues or leadership say, you can see this to be true by their actions, not their words
Great leaders focus obsessively on a balance between the right growth and the right costs
Mediocre leaders focus obsessively on exponential growth while simultaneously pursuing aggressive cost cutting
Great leaders establish a core guiding principle, informed by the business, understood by everyone in the business, and designed to lead the behavior of the business
Mediocre leaders design eloquent corporate propaganda, created by the select few at the top, published to the rest of the organization as a fantastic new philosophy that should be commemorated
Great leaders understand that the creation of greatness is a valuable discipline regardless of the business type, objectives, or current position
Mediocre leaders focus on the valuation of a business and the maximization of that valuation in an attempt to acquire bonuses, recognition, or liquidation events
Great leaders take the time to get to know all levels of the business, understanding that this gives them the information to lead, and the rapport to support their team and the team to support them
Mediocre leaders are too busy, don't regularly engage the team, don't get the information they need to lead, and either fool themselves into thinking they have the team's support or don't care
Great leaders appreciate the team and regularly give credit, because without this team the success of the organization, and as we’ve discovered the success of the leaders themselves will suffer
Mediocre leaders are detached, take personal credit for achievements, boast about bonuses, create organizational tiers where the higher ranks are eligible for rewards, and in doing so create a culture of commiseration and complacency which erodes organizational performance and therefore the success of the leaders themselves
There are other examples, but I think you get the point
The Counterintuitive Path to Greatness
So the path to greatness turns out to be counterintuitive
Focusing on the organization over you maximizes the benefit to the organization AND to you
The question to ask yourself is, "are my actions working to replace myself?"
It seems counterproductive at first glance, but in practice is the best possible approach
Because if your actions are designed to replace yourself, the rest will fall into alignment
What I Mean by "Replacing Yourself"
Good parents raise their kids, then allow them to become adults. At some point continuing to engage a parent <> child relationship OVER a peer to peer relationship becomes enabling
Similarly, if a business person isn't expecting their project to persist at some point WITHOUT them, the leader <> project relationship works much like the enabling metaphor
On day 1 you should say to yourself, "what happens if I don't come in to work tomorrow?" It's likely you will be needed on day 2, and probably on day 3, and day 10, and day 80....
What are the things you need to do so that some day, you can step back from the project and let it fly itself?
I like to begin with a great team and through specifications
As things roll out, and large blocks are transitioned to the maintenance team, development picks off the critical path items
As operations takes over fulfillment and the application goes live, as a Product Manager, I should be supporting the product with client feedback, design improvements, performance analysis, and other ongoing business based product leadership
But at this point, at least for my role, the product should be in a position where it is well organized, supported by great people, and my personal contribution is just one piece of the puzzle - and I can be replaced
And that is the moment I push hard to reach from day 1
I've worked in many industries, but in each of them there has been a need to develop Web based technology in one capacity or another. Even where the core purpose of the business has nothing to do with the Web, creating marketing, e-Commerce, client support, and sales support is a need.
Suppose you were to walk into an architectural office. You would expect to see people drafting building plans that detail everything from the floor plan, to the foundation, to plumbing and electrical, and so on. In fact, you would expect a great number of drawings should be required in order to build a building properly. And as you might expect, there is a whole discipline around the development of these documents.
Think for a moment about what your business creates. Here is a fun project for you. Ask around and see if you have documentation that thoroughly details the core of what you create. If you are in a Bio-Med organization I'm sure there are all sorts of documents, from chemical recipes, to device schematics, to case studies and trials, to patent applications, etc., etc...
But the creation of all this documentation takes discipline. It takes a type of person who is skilled at pulling vague ideas and concepts out of other experts, knowing enough about it themselves to be able to understand the ideas, and the ability to put it into a document that captures all of the essential details.
Not surprisingly, the businesses I've worked in have not had this dicipline. It isn't surprising, because I would speculate that adding this type of person to their team was the part of the reason they hired me.
Think of this discipline as a trial run. If you create a document that can be reviewed by subject matter experts and stakeholders, you can identify issues and find compromises BEFORE you invest in development. On this alone, the costs associated with the discipline - both in salary and in time - repay themselves.
I've worked in organizations where projects run by my colleagues flounder as they struggle with one release after another, not meeting the business requirements, or missing the feature expectations, or learning of issues late in the game. And I wonder why they didn't begin with a good set of plans. It is a classic and all too familiar lack of discipline.
Working in software - especially in Web/SaaS applications - Agile development is a new buzz word. I'm a fan of the SCRUM methodology myself, and have used it or variations of it on many projects, serving simultaneously as Product Manager and Scrum Master.
Part of the Agile process is the creation of User Stories. I really like user stories, because the methodically walk through the most important use cases for an application. And in the project management of Agile, these User Stories are written down - usually in an PjM application and get associated to an Iteration in the Iteration Planning Meeting.
Taking this one step further, another branch of thought in Agile is Extreme Programing. In my experience you create almost no documentation, leaving it up to the engineer uses their creative and intellegent mind to create the necessary code.
I've worked in companies founded by technologists, and the strategic direction was dictated by engineering. I've worked in companies where senior marketing executives were brought in, and the control came from their department.
I bring these methodologies and departmental scenarios up, because it really highlights the need for what I call a "Power Center" within the organization. In my opinion the best way to create a power center is to:
1. Make Product Management its own department
2. Make Product Management accountable to all of the other departments (it serves them)
3. Give Product Management the responsibility for delivering
4. Give Product Management the authority to execute
5. Require Product Management to define requirements in a format that is accessible to all departments
Several things happen when you do this...
Steps 1 & 2 put Product Management in a submissive role, where it is required as a key function to collect and document the requirements of these departments. Regardless of the departments you have in your organization, Product Management becomes the information hub between them. Connecting the needs of these departments results in a natural effort to negotiate inter-departmental synergies and compromises.
Step 3 forces Product Management to set priorities. When priorities favor one department over another this time, the exchange can be in trade the other way next time. Not that everyone will always get their way, but you have a servant department that becomes a common intermediary between areas of the organization.
Step 4 gives Product Management the autonomous ability to drive decisions and execution. But this is held in check by Step 3. So you don't create a department that acts as a dictator, but you also don't create a department that bends in the breeze. It is a check and balance system that ensures accountability.
Step 5 is the Rosetta Stone, the blue prints, the patent definitions, the magic. I've invested many years developing my particular style of information architecture and wire frames. These work amazingly well for software development. I can put them in front of a marketing person, a software developer, a graphic designer, and a sales person in a round table meeting and we can all talk about what it is, how it impacts our departments, and pen up collaborative solutions. Before I have a team write a line of code, I've turned a few revisions of my document and ended up with something I know will work, while maintaining the ability to adapt over time.
Possibly more important than any other part of my job, maintaining this discipline around product specifications is the most important. I will never be an expert in all things, but the documents created by myself and my team are informed by the gamut of experts. Therefore, the resulting specifications represent the group mind with the:
- Interdepartmental needs
- Interdepartmental prioritization
- Interdepartmental compromises
- Interdepartmental synergies
My motto is "the more people are involved, the better my specs will be." Of course you have to know how to get the right people involved, prevent getting too many cooks in the kitchen, and filter out noise related to in-fighting. But I've noticed that when you develop great specs, based on great group input, you deliver great results that benefit the whole team. When this happens, you build motivation to participate in your process. You help erode the internal conflicts. You help build overall momentum. And you help accelerate your organization on a path to building greatness - regardless of what business you are in.
Luck
In "Great by Choice" Jim Collins and Morten T. Hansen write that it isn't whether you will have good or bad luck, but what you do with the luck you get.
After graduating with a philosophy degree I immediately realized that I might not be properly positioned to kick off my career. Fortunately I had a friend who worked in high tech who told me to go work for a start up. At the time it was a boom economy, I should be able to get hired doing something, and could take on responsibilities from there as I figured out what I wanted to do. It turns out, this was perfect advice.
I began working at my first start up soon after. I thought to myself, "great, I'll put in 5 or 6 years and when I have some experience under my belt I'll see what is next." Well laid plans. About a year later, with the economy in a nose dive the business went under - no IPO, no liquidation event, no expensive sports car.
Then I got hired at another start up. And a year later.... I've worked for many start ups, each a fantastic learning lab for business. I wore all kinds of hats, developed a deep base of skills, learned valuable lessons from senior leaders who came to work in these start ups, made lots of great colleagues and friends, and experienced in short cycle times what works and what doesn't. I look at this as a 5 or 6 year hands on MBA course - if only the school of hard knocks had a degree system. But as Robert M. Pirsig points out in "Zen and The Art of Motorcycle Maintenance", the degree and grading system is a flawed institution - not that it isn't valuable, but the quality of practical experience I invested into myself was so much greater that I am all the better for it.
I think many people may have looked at this and all the bad luck and say "What a waste!" But I can't imagine having a more fortunate early career. When I work with people now who put in years at their first company (remember my 5 year plan above), I notice key distinctions in my approach to business that I wouldn't have without my years in the start up world.
Inspiration
My work is business. My hobby is business. If business was a breakfast cereal, I wouldn't just eat it for breakfast, I'd have boxes in my pantry, coupons in my wallet, and track when it goes on sale. I LOVE what I do. I am passionate about it, and I'm not afraid to wear that on my sleeve.
When I work at more established businesses, I feel that my job is to be an evangelist for cultural change. You CAN NOT understand how to be a great business if you DO NOT understand the following:
"If your people are not inspired, you will not, CAN NOT build a great business."
Posters on the wall that state the corporate mission - offensive. If your corporate mission isn't basic enough to be understood by everyone in your organization, then you have failed.
A focus on headcount reduction, rather than a focus on growth - incorrect focus. Almost like subconscious predestination, you will do what you focus on. And your team will feel it. Working with people who are worried for their jobs breeds commiseration, complacency, and inefficiency.
Have fun - even if you aren't a start up. I remember having razor scooters for getting around the office, putting golf meetings around the office, and pick-up ping pong brainstorming sessions. You don't have to go invest in a foosball table, but you should call time out and think about your corporate culture.
Build the right culture. While we are talking about it, things like "years worked" awards, high fives, employee of the month, and other generic rah-rah crap that HR departments love to implement is a colossal swing and miss. Start with things like giving credit to teams who deliver, recognizing people with a "thank you," noticing hard work with an email.
At the same time, recognize that your team is more important than you are. When you hit milestones, make sure organizational leaders hear about the people who made it happen - even to the extent that you DO NOT mention your own contributions.
Development of Culture With Your Team
I recently had a leader tell me to never lose my passion for what I do. I don't expect that I will, but in the context of business I think I'm an edge case (my boss recently told me I need to "learn how to be more of a slacker"). HOWEVER, most people that I work with have the ability to get revved up about the project as the momentum builds, and the barometer for expressing excitement for achievement is set by the leader.
Step 1: Get The Right People
People who are smart, passionate, and a fit for your culture.
Step 2: Create The Culture
Define a culture that is excited about achieving your core concept.
Step 3: Enable Success
Build buffers, contingency plans, redundancies, and adaptability into your projects.
Certainly there is more to running a business than this. But if you have these qualities you will be prepared to deal with luck - good and bad - and you will have a culture that is inspired to work hard toward achieving your core concept in both good and bad times.
When I began my career I worked in the fast paced world of Silicon Valley high tech start ups. These were extraordinary days where small groups of highly skilled and motivated people were building the future. I think from the outside in, most people might recall the "dot com" boom, some of the many of the failed "sites", and the subsequent investment vacuum as the market bottom went into a free fall. Nonetheless, this era of tech boom laid the foundation for the smart phones and world of apps that are common place today. It was the touch point where networked computing power and the general consumer market were brought together by the growing penetration of in-home personal computers.
At a personal level there were things about this environment that benefited me beyond measure. As my career has progressed I've realized in retrospect that many of the things about the inherent way that I execute is A) tied to this period of personal "career incubation", B) is distinct from those who have gone through traditional methods of career growth, and C) continues to provide an order of magnitude accelerator to what I'm able to deliver.
The People
Depending on how you define it, I've worked for between 5 and 10 different start ups. Regardless, in each case I've worked with senior leaders who either had the guts to leave a cushy corner office and shoot for the moon, or were crazy enough to double time their work week to simultaneously bridge a day job and a start up. These were my professors in a hands on school of brutal hard knocks. And almost like having gone into battle forms a bond between soldiers, I still share a friendship with these incredible people.
>> Upshots:
When you create a team you can't just look at the acronyms on a resume, or the years of experience. You want to build a culture to your group. It has to be positive, requires mutual respect, and collaboration that includes the whole team.
IF you have high performing people, and the right culture, everything else will fall into place. The more experienced will educate the rising stars. The newer thinking will come up with unique ideas to traditional challenges. Leadership understands and appreciates the contribution of the team, and gives credit where credit is due.
Hard Work
I never knew how hard I could work until I started at my first start up. Recently I pushing to hit a deadline and was putting in hours that reminded me of the start up days. So to test I began clocking my hours, which were totaling up to between 85 and 92 hours per week.
I am not a sprinter. Genius ides don't just come to me. I think I'm generally a pretty normal guy. But it doesn't matter. Making meaningful impact sometimes comes down to some old fashioned elbow grease. When you make meaningful impact, people notice.
>> Upshots:
Thought leadership within an organization comes from demonstrative examples. In "Good to Great" Jim Collins explains that change is created by turning factual potential into factual results.
I suspect that most people don't put in the time. So, if you have a group that knows WHEN this can add value, and is capable of delivering the extended hours of high-value focus, you have a strong competitive advantage. Note that "when" is a relevant quality to understand - just working your team long hours to maximize work hours is NOT the same thing.
Expert Leaders or The Seat Of Their Pants?
I used to think leaders knew what they were doing. As I've led projects I've come to realize how much I depend on the team members. Sometimes I feel like I'm flying by the seat of my pants, but that wouldn't quite be right. The trick is to think objectively about the people you bring into the group. What are they GREAT at doing? As Jim Collins writes, "are they genetically encoded to do what they do?" But this quality doesn't just apply to project leaders, it is a filter you should apply to EVERYONE in the group.
For level 4 leaders, the need for control is great. These leaders micro-manage, check the minute details before a release, and lead with a stick. They don't get it.
>> Upshots:
Great leaders understand the value of the group mind. You can't know everything, and you don't want to try. Getting high performing people with the right culture creates your ideal leadership environment. Here the people in your group can report on the details, and you can focus on bringing it all together into a cohesive direction.
Know Your Business, Know Your SMEs
I've worked in many industries, each of which needed technical web-based solutions. While I live to build web applications and platforms, I have to go through a discovery process to learn the business each time. I think that often is the case that technologists shrug their shoulders and say "yep, I can build that," but fail to get a deep understanding and a deep base of subject matter experts (SMEs) who can help.
If you want to create market value. If you want to make your business wildly profitable. Then you need to understand how to build greatness. Without context for what greatness means for your business in your industry, the development of technology is irrelevant.
I sit down with SMEs to understand what they do. Follow the process, and the data. I like to do this in short 30 minute 1 on 1 meetings where the SME works - at their desk. I'll also do quick "fly by" in-person stops where I can ask questions. I am appreciative of the information I get, and always try to give credit at each milestone deliverable to the network of SMEs who helped deliver the result. It builds rapport with a wide network of SMEs in a quick amount of time. It creates a working relationship that I can leverage moving forward. And it ensures that WHAT I build is based on a strong base of WHO knows it the most.
>> Upshots:
You might say that this is a practical example of the "who first then what" concept. And I'd agree. But I rarely see people use this approach in favor of consensus building meetings, external experts, and scheduled meetings that create time delay. If you can be nimble, in-person yet low touch, and with a quick turnaround cycle time, you will have a significant advantage.
Use Video
People are busy. People are geographically distributed. And yet, people need to know. When you deliver a milestone, create a 5 minute video about the delivery. I can be viewed when people have time, from wherever they are in the world. Invest in a video camera, a screen recording application, and some basic video editing software. Does this sound outside your comfort zone? Then find someone who can help.
Using These Tools to Affect Organizational Change
When I was working in start ups with 35 people, affecting change was easier. But even in a larger organization you can affect change. And sometimes the best place to steer is not from the helm of the ship.
- Get the right people to work on your team
- Learn to work hard, and when to work really hard
- Develop a group mind approach to your team leadership
- Form a tight working relationship the SMEs that provide input to your project
- Use video to demonstrate deliveries, successes, and to give credit
From my perspective, I want to do work that helps the companies I work for be the most successful in the market - even to the point that I want to decimate the competition. To that end, having the ability to directly influence the most senior leadership is an important quality I place on my value of my work.
Of course, senior leaders are busy. They have backgrounds and philosophies of their own. And they have demonstrated themselves to be effective leaders. Which means that I can talk all I want, but I'm just a voice in the crowd.
I believe a better way to make an argument is by demonstrating the potential. You can't always go from potential to results in a prototype, mock up, or video demo. But the visual appeal, the "tangible" nature of these things is far greater than a power point deck or a conference call. It doesn't get as lost in the fray.
You still need the power point decks, business case, market research, and all the other stuff that makes the argument for your project. But moving the core presentation to the demonstration of a real thing makes an impact.
Moreover, these are the kind of things that build an infectious buzz. As you demo, set up meetings with managers, then directors, then their VPs, and so on. Create water cooler chatter around the organization that resonates.
Infuse your demos with your (see Jim Collins) big harry audacious goals (BHAGs). And as the name implies, you will likely not achieve these out of the gate but it builds in the excitement. It is the vision of the greatness that awaits on the other side.
At some point, if you are successful in marketing your project internally, someone will mention it to you. Or you will get a "I've heard about this" from someone you are presenting to for the first time.
None of this makes the decision, but it does build awareness with senior leadership. And if you have genuinely and objectively built your case. And you have refined it with constructive input as you've gone. And you have confidence that the project will return factual, measurable results. Then you have successfully influenced those who are at the helm, who relied on all of your hard work.
And thus, sometimes the best place to steer is not from the helm.
Today I was thinking about attrition. I've worked in many companies where the reduction of attrition is identified as a priority. There are many things that business leaders do to help elevate the Net Promoter Score (NPS), from client visits, to client panels, and even hosting spectacular events where clients can be schmoozed.
None of these things feels wrong per se, but (at least in my experience) I've seen this as one arm of the business trying to build up what the other arm is tearing down. This internal turmoil seems to be unrecognized, and is a direct result of a misaligned business.
You may have heard the cliche' "there are those who build/support it, and those who sell it, and everyone else is just overhead." I understand what this is getting at, but of course this doesn't quite hit the mark of truth. Nonetheless, I bring this up because I think there is a clear division between the building/supporting of a product/service, and the selling of that product/service.
Ultimately this division bubbles up to the priorities of the respective departments. When you work in an aligned organization, you experience similar behaviors between the departments. To keep it simple I like to zero in on what I call the "language" of the department.
If departments are aligned, it makes sense that they are tied to a common goal. They do different things (perform tactically different), but the alignment is tied to the overall goal (strategy). So you will here things like "we need X so that we can deliver [Goal]".
If departments are not aligned you hear more self serving language that has little to do with the overall success of the organization. "We are overwhelmed with X [stop]." "I don't care about the downstream implications, I just need to get to Y [stop]."
To solve this, company leaders focus on team building exercises. So you end up with a bunch of people in a room (or on a conference call) with whiteboards (live meetings), sticky notes (chat), etc., and the defacto external expert who will whip the synergy back into place. I am always simultaneously frustrated and grinning inside at these events because it is just a matter of time before we all do the "list the 5 things we can do better" exercise and someone will put "we need better communication." Fantastic! I'll tell you right now, that totally misses the point.
What leaders FAIL to realize is that while things like "better communication" ARE needed, the context for that communication has not been set. The context needs to be a clear core concept for the business. It can't be more than a sentence, it must be something *everyone* in the company can understand (down to the interns), AND must be something *everyone* could tell you off the cuff (I don't want to say memorize - but "live by" might be better). For more on this, and how to create a core concept, go read "Good To Great" by Jim Collins, and study the Hedgehog Concept, the Three Circles, The Council, The Brutal Facts, etc....
How Does This All Relate To Attrition?
In theory, sales closes deals, operations supports the sale by delivering the product / service.
In a misaligned business, sales closes deals that are not in line with the core concept of the business. Not that ALL sales are out of alignment, but it is a shotgun approach, and not a fault of the sales team. The driver for the Sales Team is to meet their quota/target. Without a higher guiding concept everything is fair game. There is nothing to inform what a good/bad client is. EVEN when this is defined, "we are going after call centers" or "we want to sell to businesses with 50 to 100 employees" or "we want clients with X in annual revenue", it is a loose definition out of context to the core concept of the business, and really more of a way of backing into answering "how can we hit our quota/target."
In a misaligned business, operations supports the sales. As the hodge podge of clients roll in, service absorbs the brunt and cranks out fulfillment. But again, this is NOT the fault of sales. HOWEVER, it is VIEWED as the fault of sales by operations. Now we have inherently built in a point of contention to our process.
Because management has not clearly defined a core concept, they likely do not have a clear understanding of what it takes to support the business either. Note in Jim Collins research that typically Good To Great companies have leaders that came from *within* the business, and that the comparison companies tried "saviors from the out side" far more often. The upshot here is that operations probably is running on inadequate tools to facilitate the product/service. To overcome this, they need to add people, process, and long hours. This IS the FAILURE of leadership, and is viewed as this by operations. And again, we have inherently built in another point of contention.
Within this mix, operations says to themselves "we have a chaotic environment we can not control, but we can organize a plan to cope." There are a few things going on here. First, you can tell by the nomenclature that there is not a plan to excel or be great, simply a plan to get by. This is a natural symptom of, second, not having a sense that you can make a meaningful impact to the overall business. But operations has a financial need to keep their jobs so they, third, give just enough to satisfy the need.
There is nothing about this scenario so far that builds momentum, or drives a business toward becoming great. This decay will be felt in the quality of the product/service, and indeed in the business itself. Eventually, clients will begin to attrit.
Now Begins the Degenerative Spiral of Attrition
The very name "Net Promoter Score" says it all. Business must value clients who promote their product / service. Moreover, it is built in that this is a sliding scale with a score on that spectrum.
One method of "we want a pat on the back" validation businesses will take is to ask their clients "would you refer people you know?" But have you ever answered a questionnaire like this? It is easy to lie. In fact, using a slice of game theory here, I *expect* that people lie. This is the business version of "do these pants make me look fat?" I have a vision in my mind of the Geico insurance commercial where "honest Abe" Lincoln is asked that by his wife, and disaster ensues. We are socially programmed to keep things copasetic. "If you don't have anything nice to say, don't say them at all."
Of course my argument here is contrary to statistics that show complaints being reported far more than complements. Even so, I think there are two levels of communication here. When my gut makes me realize that I need to make a replacement, I want to make that transition as smooth as possible. I'll start by identifying alternatives, get the details, scope the impact of the transition, and weigh that against the long term benefits. My assumption here is that if there is something fundamentally flawed with an employee, supplier, etc., and it is beyond my control to fix that, any amount of good faith effort is really wasted. I'm better off finding an alternative.
Following this thinking, I believe growth and attrition rates are a better indicators of the NPS than a survey. And I'm sure many companies factor this into their NPS equation.
As this impacts attrition, you can see the natural consequence of the misaligned business being a rising attrition rate. As clients "fall off the back", they contribute negatively to your NPS, which circles back to sales, and hinders growth. Your market opportunity decreases with some multiplier, because business know other businesses and will either refer other to your competition, deter them away from you, but usually a combination of both.
The longer this scenario plays out, the greater that multiplier becomes, and the greater the impact it will have on your business.
Industry Impacts
I've noticed that in mature industries, ownership of the market is roughly static for seemingly long periods of time. I think this leads business leaders in the industry to become complacent about growth and attrition, because their revenue and profits will generally be the same as they have always been.
I would argue that these industries maintain this balance, because the mix of forces surrounding them are also at balance.
But the acceleration of technology is out there. And businesses are learning, adapting, and finding a way. Look at what VoIP has done to telecommunications (with Skype who needs international calling plans?). Streaming media has done to video rental (Netflix eviscerated Blockbuster). Online retail has done to shopping (wonder where your local Boarders Books is --> Amazon.com).
Looking back to the degenerative spiral of attrition, in a balanced mature industry clients may have cycled from one to another, then back again over some period of years. But now there are hungry technically savvy companies who want to build market share. And the waterfall of attrition coming off the back of these legacy companies is ripe feeding ground. No doubt there will be a battle for market share, but time and again technology seems to win. At least for now....
At some point the forces will balance out, the technology companies will become the incumbents. And once again the characteristics of alignment and misalignment will play out. And once again, disruptions in an industry (technical or otherwise) will cause a reassessment in market ownership. Great companies focus on alignment over time to a core concept, with tools (technology) that enable market superiority. The others fail at the highest level to implement the internal precepts needed, and thus set course to ride the degenerative spiral of attrition.
