Ten Reasons To Embrace Storytelling As A Business Tool

From Paul Smith's book, Lead With A Story, here are the 10 reasons for embracing storytelling as a business tool:

1. Storytelling is simple
2. Storytelling is timeless
3. Stories are demographic-proof
4. Stories are contagious
5. Stories are easier to remember
6. Stories inspire
7. Stories appeal to all types of learners
8. Stories fit better where most of the learning happens in the workplace
9. Stories put the listener in a mental learning mode
10. Telling stories shows respect for the audience

Smith goes on to say that:

• you don't need a degree in English to tell a story
• stories can spread like wildfire
• lessons from a story are remembered more accurately, and for far longer, than learning derived from facts
• stories spark curiosity and interest rather than the urge to evaluate or criticize
• stories get your message across, without arrogantly telling listeners what to think or do

Leadership And Life Quotes From Leading With Grit

In addition to Laurie Sudbrink's, Leading With GRIT, being a great book for leaders, it's packed with powerful leadership and life quotes. Here are some of my favorites:

• Wanting to be someone else is a waste of the person you are - Kurt Cobain
• The respect you show to others (or lack thereof) is an immediate reflection on your self respect - Alex Elle
• You never really understand a person until you consider things from his point of view - Harper Lee
• People only see what they are prepared to see - Ralph Waldo Emerson
• We make a living by what we get, we make a life by what we give - Winston Churchill
• If it doesn't challenge you, it won't change you - Fred Devito
• The secret of change is to focus all your energy, not on fighting the old but on building the new - Socrates
• The biggest communication problem is we do not listen to understand. We listen to rely - Anonymous
• Attention is the rarest and purest form of generosity - Simon Weil
• Good leaders inspire people to have confidence in their leader. Great leaders inspire people to have confidence in themselves - Eleanor Roosevelt
• The only thing worse than training employees and losing them is to not train them and keep them - Zig Ziglar
• You can't change what you refuse to confront - Gina Senarighi

How To Create A Heart Culture With Your Employees

If you want to create a heart culture and a people-first culture at your workplace, read the book, Advisory Leadership, by Greg Friedman. 

Although the book is authored by an award-winning financial advisor and primarily written for professionals in the financial services industry, this book is a must read for any leader who wants to create a nurturing heart culture that hinges on the human-centric values the next generation of employees hold in high regard.

And, what exactly is heart culture? Friedman says, "At its core, heart culture symbolizes how a company values more than just an employee's output. It's not about the work, but rather, the people who do the work."

He further explains that leaders can no longer afford to ignore the shift toward a people-first culture and its direct influence on a healthy, effective work environment.

Friedman teaches that there are seven steps, based on human virtues we all strive to achieve, that are key to unlocking the power of a people-first culture:

1. Patience. Slowing down the hiring process to help you better choose the right candidate for any role, every time.
2. Honesty and Integrity. Leading by example and encouraging open and honest communication.
3. Compassion. Acknowledging people for their individual contributions and getting to know them beyond their roles.
4. Respect. Empowering employees to make decisions and guiding them in their personal goals for professional achievement.
5. Persistence and Consistency. Aligning your management team with your company's goals and reiterating your values through various communication channels.
6. Encouragement. Promoting and rewarding team collaboration instead of competition.
7. Courage. Looking inward before taking those crucial first steps toward change.

Greg Friedman, Ms, CFP

You'll also learn from the book the most common culture killers, which are:

• Focusing too much on a hierarchical organization.
• Complacency.
• Not guiding the troops.
• Holding on to toxic employees.

I really like this book, because it:

• Provides "real-world" and practical everyday steps you can take.
• Gives you specific techniques and tactics.
• Capsulizes "Tips to Remember" for you at the end of each chapter.
• Is incredibly easy to read and absorb.

Friedman is founder and president of Junxure, a practice improvement firm, and Private Ocean, a West Coast wealth management firm.

Five Tips For Writing Company Policies

Keep these five tips in mind when you craft your next company policy:

1. Keep the policy short and simple.
2. Get rid of two old policies for every new policy you implement.
3. Make sure that your organization's policy and procedures are written to serve your employees and customers--not just your organization.
4. Don't write a policy in reaction to a single incident. The problem may never arise again.
5. Don't write a policy longer than one-page, no matter how large your organization may be.

Thanks to author Bob Nelson for these great tips from his book, 1001 Ways To Energize Employees.

Integration Does. Not. Scale.

In times past, there was a difference between the front office of a business – designed to make a good impression – and the back office – a utilitarian place where most of the routine work got done. The first (and for a long time the predominant) use of computers in business centered around automating back office processes, so of course, IT was relegated to the back office. 

As businesses grew, various back office functions developed their own computer systems – one for purchasing, one for payroll, one for manufacturing, and so on. The manufacturing system in vogue when I was in a factory was called MRP – Material Requirements Planning. As time went on, MRP systems were expanded to the supply chain, and then to the rest of the business, where they acquired the name ERP – Enterprise Resource Planning.

Over time it became obvious that the disparate systems for each function were handling the same data in different ways, making it difficult to coordinate across functions. So IT departments worked to create a single data repository, which quite often resided in the ERP system. The ERP suite of tools expanded to include most back office processes, including customer relationship management, order processing, human resources, and financial management. 

The good news was that now all the enterprise data could be found in the single database managed by the ERP system. The bad news was that the ERP system became complex and slow. Even worse, enterprise processes had to either conform to “best practices” supported by the ERP suite or the ERP system had to be customized to support unique processes. In either case, these changes took a long time.

ERP Systems Meet Digital Organizations  

As enterprise IT focused on implementing ERP suites and developing an authoritative system of record, the Internet became a platform for a whole new category of software, spawning new business models that did not fit into the traditional processes managed by ERP systems. Here are a few examples:

1. Many software offerings that used to be sold as products are now being sold “as a service”. However, ERP systems were designed to manage the manufacture and distribution of physical products; they don’t generally manage subscription services.
2. Some companies (Google for example) give away their services and sell advertising. Other companies (such as EBay and Airbnb) create platforms that unite consumers with suppliers, often disrupting traditional industries. In a platform business, the most critical processes focus on driving network effects by facilitating interactions between buyers and sellers. Although ERP systems can manage both suppliers and customers, they usually do not focus on the interactions between them.
3. The Internet of Things (IoT) brings real time data into many processes, changing the way they are best executed. For example, predictive maintenance of heavy equipment can be scheduled based on sensor data, resulting in better outcomes for customers and thus for the enterprise. ERP suites are intended to support standard practices; they struggle to support processes that change dynamically in response to digital input.
4. Capitalizing on the availability of data generated by products, companies are moving to selling business outcomes rather than individual products (GE is an example). When you are selling engine thrust or lighting costs, rather than engines or lightbulbs, processes need to be focused on the customer context. ERP systems generally focus on internal processes.
5. ERP systems are supposed to provide a single, integrated record of important enterprise data, but that data rarely includes dynamic product performance data, information about consumer characteristics and preferences, or other information that has come to be called “Big Data”. This kind of information is becoming an extremely valuable resource, but there isn’t room in ERP databases to store and manage the massive amount of interesting data that is available.

In summary, digitization is bringing the back office much closer to the front office, providing the data for dynamic decision-making, and substituting short feedback loops and data-driven interactions for “best practices.” Since enterprise ERP suites were not built for speed or rapidly changing processes, they are increasingly being supplemented with other systems that manage critical enterprise processes.

Postmodern ERP

In the last few years, in the wake of the success of Salesforce.com, many cloud-based software services have become available. Some target the entire enterprise (NetSuite for example), but many are focused on particular areas (e.g. human resources) or particular industries (e.g. construction). These services are finding an eager audience – even in companies that have existing ERP systems. Today, about 30% of the spend for IT systems is coming from business units outside of IT [1]. If they cannot get the software they need from their IT departments, business leaders are likely to purchase cloud-based services instead.

The cloud reduces dependence on a company’s IT department, so it has become quite easy for various areas of the enterprise to independently adopt “best-of-breed” solutions specifically targeted at their needs, rather than use a single ERP suite across the enterprise. These best-of-breed systems are usually selected by line business leaders and hosted in the cloud. They tend to be faster to implement and more responsive to changing business situations than the enterprise ERP suite – partly because they are decoupled from the rest of the enterprise. Gartner calls the movement from a single ERP suite to a collection of ERP modules from multiple vendors “Postmodern ERP”[2]. 

Gartner warns that a multi-vendor ERP approach can lead to significant integration problems, and recommends that multiple vendors should not be used until the integration issues are sorted out. Of course, business leaders want to know why integration is important. IT departments typically respond that the ERP’s central database is the enterprise system-of-record; other ERP modules – financial reporting, for example – depend on this database for critical data. Without an integrated database, how will the rest of the enterprise be able to operate? How will the accounting department produce its required financial reports? 

Integration Does. Not. Scale

But hold on. There are plenty of very large companies that work remarkably well – and produce financial reports on time – without an integrated system-of-record. In fact, internet-scale companies have discovered that integration does not scale. If we go back to the year 2000, we find that Amazon.com had a traditional architecture – a big front end and a big back end – which got slower and slower as volume grew.  Eventually Amazon abandoned its integrated backend database in the early 2000’s, in favor of independent services that manage their own data and communicate with each other exclusively through clearly defined interfaces. 

If we have learned one thing from internet-scale players, it’s that true scale is not about integration, it is about federation. Amazon runs a massive order fulfillment business on a platform built out of small, independently deployable, horizontally scalable services. Each service is owned by a responsible team that decides what data the service will maintain and how that data will be exposed to other services. Netflix operates with the same architecture, as do many other internet-scale companies. In fact, adopting federated services is a proven approach for organizations that wish to scale to beyond their current limitations. 

Let’s revisit the enterprise where business units prefer to run best-of-breed ERP modules to handle the specific needs of their business. This enterprise has two choices: 

1. Integrate the various ERP modules and store their data in a single ERP database.
2. Coordinate independently-maintained enterprise data through API contracts. 

The problem with the first option is that integration creates dependencies across the enterprise. Each time a data definition in the central database is added or changed, every software module that uses the database must be updated to match the new schema. This makes the integrated database a massive dependency generator; the result is a monolithic code base where changes are slow and painful. 

Enterprises that want to move fast will select the second option. They will move to a federated architecture in which each module owns and maintains its own data, with data moving between modules via very well defined and stable interfaces. As radical as this approach may seem, internet-scale businesses have been living with services and local data stores for quite a while now, and they have found that managing interface contracts is no more difficult than managing a single, integrated database.

What Scales

Assume that every team responsible for a process can choose its own best-of-breed software module and is responsible for maintaining its own data in appropriately secure data stores. Then maintaining an authoritative source of data becomes an API problem, not a database problem. When the system-of-record for each process is contained within its own modules, new modules can be added for handling software-as-a-service, two-sided platforms, data from IoT sensors, customer outcomes or other new business model that may evolve. These modules will exchange a limited amount of data through well-defined API’s with the credit, order fulfillment, human resources, and financial modules. Internally, the new modules will collect, store, and act upon as much unstructured data and real time information as may be useful. More importantly, these modules can be updated at any time, independent of other modules in the system. In addition, they can be replicated horizontally as scale demands. 

It is the API contract, not the central database, that assures each part of the company looks at the same data in the same way. Make no mistake, these API contracts are extremely important and must be carefully vetted by each data provider with all of its consumers. API contracts take the place of database schema, and data providers must ensure that their data meets the standards of a valid system-of-record. However, changes to an API contract are handled differently than most database schema changes. Each change creates a new version of the API; both old and new versions remain valid while other software modules are gradually updated to use the new version. A wise API versioning strategy eliminates the tight coupling that makes database changes so slow and cumbersome. The reason why federation scales – while a central database approach does not scale – is because with a well-defined API’s strategy, individual modules are not dependent on other modules, so each module can be deployed independently and (usually) scaled horizontally. 

When you think of Enterprise ERP as a federation of independent modules communicating via API’s (rather than a database), the problems with multi-vendor ERP systems fade because the system-of-record is no longer a massive dependency-generator that requires lockstep deployments. With a federated approach, business leaders can move fast and experiment with different systems as they become available, and still synchronize critical enterprise data with the rest of the company. In addition, similar processes in different parts of the enterprise can use different applications to meet their unique needs without the significant tailoring expense encountered when a single ERP suite is imposed on the entire enterprise.

What about Standardization?

Won’t separate ERP modules lead to different processes in different parts of the enterprise? Yes, certainly. But the question is – under what circumstances are standard processes important? In the days of manual back office processes, there was lot of labor-intensive work: drafting, accounting, phone calls, people moving paperwork from one desk to another. Standardization in this kind of operating environment made sense and could lead to significant efficiencies. But in a digitized world, the important thing is not uniformity; it is rapid and continuous improvement in each business area. Different processes for different problems in different contexts can be a very good thing.

Jeff Bezos agrees; he believes that the only path to serious scale is to have a lot of independent agents making their own decisions about the best way to do things. This belief was a key factor in the birth of Amazon Web Services, a $10 billion business that keeps on growing. Amazon began its journey away from a big back end by creating small, cross-functional teams with end-to-end responsibility for a service. These teams designed their own processes to fit their particular environment. Amazon then developed a software architecture and data center infrastructure that allowed these teams to operate and deploy independently. The rest is history.

In Conclusion

It is time for enterprise processes become federated instead of integrated. This is not a new path – embedded software has used a similar architecture for decades. Today, almost every successful internet-scale business has adopted some type of federated approach because it is the only way to scale beyond the limitations of the enterprise. 

As digitization brings back-office teams closer to consumers and providers, they must join with their front-office colleagues and form teams that are fully capable of designing and improving a process or a line of business. These “full stack” teams should be responsible for managing their own practices, technology and data, meeting industry standards for their particular areas. They should communicate with other areas of the enterprise on demand through well-defined interfaces. 

The good news is that you can gradually migrate to a federation from almost any starting point, including an enterprise-wide ERP system. Even better, as IT moves from enforcing compliance with the company’s ERP system to brokering interface contracts and ensuring data security, it becomes a business enabler rather than a bottleneck. And best of all, responsible full stack teams that solve their own problems will create attractive jobs for talented engineers and give business units control over their own digital destiny. 

"It is the library of patterns that defines a good software architect"

I have recently read an interview with Ray Ozzie, Microsoft’s chief software architect where he spoke about his role as chief software architect and what makes a good software architect.

Over the last 10 years I have met a few CIOs who did not believe in the role of the software architect. More often than not those CIOs left to the senior developer or team leader in charge of the architecture. That is a very dangerous practice with many negative consequences to the organisation.

Ray Ozzie says that good software architects are the ones that have spent time building and debugging applications. He says that one can learn a lot by reverse-engineering applications. The more systems you develop and debug, the more you develop an understanding of good software architecture. “It is the library of patterns that defines a good software architect”.

Ray Ozzie’s view makes sense. A good architect should have plenty of experience in order to develop a comprehensive knowledge of the patterns required to build applications. A good software architect is the one that is always researching and learning about new technologies and how to apply them to solve real-life business problems. A good architect will not reinvent the wheel, there is probably a pattern out there for most issues in solutions architecture.

IT professionals - make it your business to know your business

Over the last few months I have been collecting the skills/experiences that feature more often in IT job adds. It has been quite an interesting little research that highlighted a few interesting points in relation to technology demands in the market.
The research was done during the 3 months leading into April and covered about 60 IT job adds. I was focusing mainly on IT management and business applications positions.

One of the main findings is the ongoing need for IT professionals to bridge the gap between IT and the business. Professionals who can understand and speak business language, professionals who can translate "IT talk" into something that makes business sense.

The following chart summarizes the skills that featured more prominently in my research.



It is no surprise to me that the two skills in high demand are leadership & management and bridging the gap between IT and the business. These are interrelated as quite often leadership relates to leading the business during a transformational phase which certainly involves bridging the gap between IT and the business.

On a side note, I hate the term "IT and the business". IT is an integral part of the business and IT professionals  should not use this language. I always work with my teams to ensure that this term is not utilized and to ensure they position themselves as an integral part of the business. Maybe I will right a post on this topic sometime in the near future.

Following are a few of my thoughts on how to bridge the gap between IT and the business. I have put all of these ideas in practice and have seen very positive results.

Business education

I got the shock of my life when I first saw my schedule as a 1st year computer science student. There were no IT subjects, I was so frustrated. All I wanted to do was to write code, instead I had to spend all of my first year, and subsequent years, with a significant focus on business, language and critical thinking subjects.

Little did I know that the focus on those subjects was going to be so critical for my career. I still remember the struggle we all went through with accounting, and get that, literature. Yes I had literature as a subject in computer science. I count myself fortunate for having that sort of foundation. The only subject we had in the first year remotely close to writing code was logic. I still remember what the teacher said in the first day, she said "This is not about computers, it is all about the business". I have kept this mantra all throughout my career.

Business education has to be a key educational component for all IT professionals, particularly if you are in the business applications area. Software exists to serve a business purpose, it is imperative for you to know  what that purpose is and exactly how your application addresses it. Furthermore having business related education will equip you not only with the expertise but also the terminology you need to be familiar with in order to communicate with business peers.

Know your business

Business applications are at the core of every business. In order to be a successful applications professional you need to know the ins and outs of your business. It is not good enough to know the industry you are in, you need to know exactly how your business makes money and what is involved in the process.

Let me give you an example, the performing arts industry. There are many different moving parts in a performing arts business. Good music, programs, artists and artistic management. However, how does the company make its money? It is not through artistic management alone, or even great programs, the company makes its money through the marketing of the performances which leads to ticket sales. There are many parts that make the whole and it is important to consider and support all parts of the business, however without ticket sales the company wouldn't survive at all. IT professionals must know and understand deeply how the business generates revenue in order to support and enable its operations.

You need to know exactly how your business makes money and all the supporting technology infrastructure and applications that support and enable its operations.

Make it your business to know your business as well as those who are running the front line business functions.

IT professionals, make it your business to know your business

Be a business professional with a lot of IT expertise

In the last few years IT strategies have gone towards business partnership whereby IT business partners work very closely with other business functions in order to drive technology strategy and implementation.

IT Business Partners must be so close to the business unit they are working with that to an external observer the IT business partner is seen as a member of that business unit.

A few years ago when I was leading the business solutions team of a fast growing organization. I worked so closely with the Marketing team that I was named an honorary member of that business unit. I did speak their language and understood their function, objectives and KPIs thoroughly. I knew the strategy was working because they considered me an integral part of their team and over time the business partner I appointed to marketing did quite well and we were able to achieve great things together.

A successful IT professional must be a business professional first, who can advise the organization on the technology opportunities that can support it to achieve its objectives. You must be a business professional first.

Taking this approach can even lead to IT professionals taking roles outside of IT. For almost one year now I have setup a business function within the Commercial area of my organization. It has been so far a fantastic opportunity despite the many challenges. This assignment will make me a far better IT professional.

Wrapping it all up

IT professionals, make it your business to know your business. The IT function must be seen and operate as a business partner to the rest of the organization delivering value that drives the business forward. In order to be a successful IT professionals you must know your business as well as you know your technology.