Is There a Disconnect Between Knowledge Workers and Business Leaders?

The past two weeks I’ve read a number of articles about the End of Agile and subsequent rebuttals. Yesterday I read an excellent article asking “Whatever Happened to Six Sigma?” Both of these articles are fascinating. The rebuttals to the first are incredibly enlightening. I don’t think these are the last of these sorts of articles. I expect to read “The End of Lean” down the road as well.

I think there are a few reasons, one of them is common between Six Sigma and Agile. Snake Oil Salespeople. Basically, what has happened with all methodologies (except for PMI’s Waterfall approach – which I’ll get to) there reaches a point in time where it becomes impossible to determine the quality of credentials for a given certification. At that point, the certification is valueless even if the training, like you dear reader received, was actually the top of the top. Because there’s no actual way to determine if the quality is any good or not.

I experienced this first hand while I was teaching Lean Six Sigma at AMD. I had some fantastic mentors when I was working there, that lived and breathed Six Sigma for their entire careers. They knew this stuff inside and out. Which made me gain a much deeper appreciation for the methodology. However, there was another small company in Austin that also taught Six Sigma to their employees, Dell. Whenever we hired people from Dell with a certification in Six Sigma, a Green Belt or even a Black Belt, we essentially had to retrain them. Many of them, did not truly internalize what they were taught, or the material was less rigorous. This was likely a trade off the Six Sigma training team had to make to ensure their team remained relevant to Dell.

However, whenever you cannot trust the training from an organization like Dell, it makes it a lot more difficult to trust training for any other organization. You just don’t know the standards. Agile’s currently experiencing the exact same issue. There’s been a huge influx of organizations giving certifications. Not all of them have the same level of quality.

I think as a reaction to this, the software development industry has created DevOps and DevSecOps. Which doesn’t have a certification process, but a general set of ideas, such as Trunk development, rigorous testing, continuous integration, and on the extreme continuous deployment.

I think all this goes back to a basic premise though. Knowledge workers, like engineers and software developers look at problems very differently than business leaders. I first experienced this while I was in college. I was studying Industrial Engineering (which pulls in elements from Six Sigma, Lean, Network Theory, Simulation, Human Factors, etc…) while a good friend was studying Business. We had a few conversations about how businesses should be run and it was very obvious to me, that we were talking about two completely different views of how a firm should be run.

I was arguing against (in 2003) off-shoring, because it decreased the efficiency of engineering and collaboration between manufacturing and engineering. Both Agile and Lean argue against off-shoring due to these reasons. Given the change in the approach, the salary savings, overall, didn’t make the effort worth it, because of the reasons I listed. My friend thought lowering cost was the right thing to do.

This isn’t just an anecdotal thing though. If you read books about Agile, Theory of Constraints, or Innovation, they all make the same arguments. The ideas taught in business school are causing business leaders to make bad ideas. Theory of Constraints was popularized in the book The Goal by Eliyahu Goldratt and came out in 1984. The ideas he espoused in that book were considered counter intuitive. If you read the Phoenix Project by Gene Kim which came out in 2013, which is written to model The Goal, you’ll find the characters running into, literally, the exact same type of thinking by managers and other team members. To me, this means there are other cultural organizations that are pushing back against the approaches technical leaders find work best and what our business leaders find work best for their goals.

The two most obvious cases for this are Accounting (which The Goal sets up as something of an antagonist) and Executives. Accounting has the weight of Law on its side, which is problematic, because Accounting organizations has their own reason for maintaining a status quo. They have their own certification process to become a CPA. From the executives standpoint, in many cases these folks are presented as having an MBA and excellent business training.

Despite that, they are still making poor business decisions for the technical team, poor decisions about how to structure their organization, and poor decisions about how to run projects. Most projects are run using a Waterfall approach, because that is the defacto approach we’re all taught throughout school. We manage to dates and push to get things done. The Project Management Institute has managed to corner the market on this approach, because most people can “do waterfall” without needing a certification. You learn through osmosis, by doing. The certification certainly elevates some PMs in some organizations. However, I don’t really think that having a PMP matters to most hiring managers.

So, where does this leave us? It leaves us with Knowledge Workers using ideas like Six Sigma, Lean, DevOps, Agile, and more to dress up their structured problem solving approaches to add structure and credibility. They need structure to compete with the Date Managed Waterfall approach. They need credibility of a methodology to put their approach on the same level as a PMP certification. In the case of Six Sigma, I’d argue its biggest success was internalizing the cost saving analysis. This helped translated the output in terms of money, which executives understand.

Every other approach tries to create an alternative measure. Elimination of Waste or “Working Software is the Measure of Progress” are nice alternatives to reducing costs or meeting due dates.

However, most share holders don’t care about that. They only care about what’s going to make them more money. Ethics and approach be damned. Until that is resolved. We’ll continue to have more fads or business fashions, as Knowledge Workers push back against Business Leaders.

The Innovation machine – This is a “how to” guide for Innovation management

As many of my blog readers know I’m an innovation reading junky. I’ve read many of the books on how to manage, from a individual’s perspective, creating an innovation or even at a high level how to run an innovation project. However, this if the first book that looks at things in a very systematic manner utilizing a lot of case studies. The Innovation Machine by Rolf-Christian Wentz is a fantastic introduction into a series of case studies of the most innovative companies in the world.

Books like the Innovator’s Dilemma are a lot more prescriptive in what a business should do or how a given business has been disrupted. Typically they focus on the smaller entrants that enter a market and beat the incumbents. The Innovation Machine on the other hand looks at the incumbents and analyzes what the organization did culturally to enable innovation. I believe books like Innovator’s Method and the Lean Startup address a different need: how to take an innovative idea to market. This book touches on those things, but looks at how the whole organization can enable those Lean startups within the organization and use it’s size to maximize the results.

The Innovation Machine also touches on the portfolio management aspect as well as some of the best ways to fund projects, staff projects (2 is best, a small room is next, anything else is doomed to fail), and finally how to integrate the project teams back into the larger business as a whole. No book that I’ve read has really discussed how to do this. All these topics are covered with clear case studies of some of the most innovative companies. He includes discussions of Google, Toyota, GE, P&G, SC Johnson, BMW, Microsoft, Whirlpool, and a litany of others. The stories are referenced as he details the concepts that were leveraged by the companies in his case study.

I believe that this book is a must read for a CEO or a leader that values innovation. Especially since he calls out the massive differences between managing Incremental Innovation and Disruptive Innovation – he gives very clear practical examples and methods for managing them separately. I believe these are powerful and will help me identify projects I work on more easily as disruptive or incremental.

I’m surrounded by @ssh*les!

Everywhere I look I see bad managers these days. Which is surprising considering that there are articles being published every day with headlines like “People don’t quit companies they quit bad managers” or “Bad Managers are the no 1 reason why people leave their job.” This is a problem specific to one company or one industry, but rather it’s across industries and sectors. I’ve worked in Semiconductor manufacturing, semiconductor design, and now health insurance all of them have had their share of bad managers. It’s not even just home grown managers that make poor decisions, it’s managers that are specifically hired to come in to effect change that don’t have the right skills to do the job that needs to be done.

It is whenever managers are put into a position where they do not have the information they need or the right skills to do the job that they become assholes. This is especially problematic in complex environments and this complexity isn’t linear from person to person, which is to say that a given person might find one level of complexity manageable, while another person may be unable to handle it. So for one manager that could be managing the line at a fast food restaurant, while another it might be managing a project that has 5 internal stakeholders and 5 government regulatory agencies as stakeholders.

In large organizations complexity is only going to increase. In this way complexity is like entropy, it only increases. We implement new policies and likely never eliminate historic policies. This is especially true with government regulations. We rarely sunset those provisions. The only way to manage this complexity is to plan. Like all plans, they are pretty much worthless after you build the plan, but going through the process is invaluable.

For instance, my preferred strategic planning approach is to pull in three types of data, Voice of the Customer, Voice of the Business, and Voice of the Team. Voice of the customer is what your customers are telling you about your existing services and offerings. They can tell you how much you’ve screwed up and where you’ve screwed up. They might not be able to help you identify the next iPhone, but they can tell you not to build the next Blackberry device. Voice of the business is typically the loudest voice at any organization. This is what the C-Suite is telling everyone to do, this is the competitive landscape and the regulatory environment that you operate within. Together these voices are powerful and loud. Finally, the voice of the team is almost always ignored, mostly because the team won’t speak up. This needs to be a true analysis of the capability of the team using Capability Analysis of Business Architects or doing a SWOT. Using these three voices to have a frank conversation, you can build a three to five year road map. Then you can build out your strategy to enable your team to meet your customer needs as well as your business requirements.

Managers become less of an asshole whenever they have clear management processes in place. Clear reasons why they are doing what they are doing. Employees aren’t the only ones that need processes. Managers and leaders need them too. They prevent churn and waste if they stick to them.

What should a manager manage?

Managers should not be managers of people, they must manage processes. Managers should be leaders of people not managers of people. Managing people by watching them closely is not typically a very effective method to ensure that work is completed. Micromanagement breeds mistrust between employee and manager. Through managing the quality of the processes the manager is able to increase the likelihood of success of their people.

All work is a process. Even if there doesn’t appear to be a process if the work is to be fully completed there are a series of steps that must be completed. It doesn’t have to be a good process, a repeatable process, or particularly effective but if the work is completed it followed a process. Furthermore, if more multiple people do the same type of work without a clearly defined process it’s likely that there will inconsistent results to their work. A manager owns the overall output of all the work of their employees. If the work is consistently subpar or employees have a difficult time picking up the way to do the work that is expected of them, this is the responsibility of the manager to address. It doesn’t matter how amazing the employees are, they could have been consistently excelling in a previous, if the processes are terrible those employees will not succeed.

Not every type of work can effectively be managed through traditional software. For example, software and technology development in both these are “knowledge” activities that unlikely would benefit from a highly structured process. In these cases there are two things that help manage the process. First creating a regular process of checking in, managing what work the developers should be doing, and working to eliminate roadblocks – in software this is Agile software development. Second you create a standard process to feed in consistent data into the truly creative process and consistent outputs so that the consumers of the work are able to use the output of the creative process effectively in their work.

To manage the processes managers need to equip their employees and themselves with tools to do root cause analysis, conduct structured problem solving, and rigorous process improvement. Managers need to take ownership of the end to end process, the data their employees use to complete their work, and the quality of the results. It is important that this becomes the norm as it will switch blame from people, who generally want to do the right thing, to the process and how work is completed.

This is not to say that whenever people deviate from the agreed upon process that the manager shouldn’t address that or if people still fail to meet expectations while working in the process that they can’t be fired. However, leading employees to identify broken processes, supporting them in fixing them, and providing tools to do so becomes the role of the manager rather than micromanaging their employees.

Strategy and Business Management

As I mentioned in my Business and Silver Bullets article, there are a lot of different approaches to managing your business, or at least a portion of your business. None of these approaches are easy to implement and it seems that there’s a bit of a revolving door around what leadership approach is the best for a given business. Furthermore, it’s troubling to me that organizations are looking at initiatives like Lean and Six Sigma as only operational improvement opportunities. As I’m reading through how Business Architecture works, it’s obvious to me that many of the organizational deployments of LSS have failed in reaching their full potential. I saw it at Samsung, AMD, and I’m skeptical of the full reach I’m going to have at Regence. It’s not a failure of the individuals deploying it or of a given leader, it’s a failure of the full organization to accept that changes need to happen. Organizations need to integrate approaches like LSS into their core strategic planning process. Otherwise those methodologies will only impact a limited area and won’t appear to have a holistic approach to making changes to an organization.

From my experiences Lean and Six Sigma methodologies can indicate the need for organizational re-alignment. These require real change with serious effort to implement those changes. In many cases those are outside the scope of the project facilitator, the leader of the process improvement center of excellence, and likely the owner of the processes. It’s got to come from an executive sponsor. They have to be able to provide the organizational courage to make real changes to an organization. Through these tools it’s possible to identify redundancies and areas where organizations require massive change.

Why don’t organization implement these changes? Too many priorities is likely one problem. Another is that these changes are hard and unless they are well versed in Lean or organizational structures, they won’t understand why the changes are fundamental to continued success of an organization. They may not understand the changes because they weren’t involved in the redesign process intimately enough. Finally, it might also be that these changes are bottoms up recommendations and not top down.

I believe this is why Business Architecture eventually was a created as a discipline. I believe in organizations that are truly Lean that these types of roles are not needed. Simply because the bottoms up approach allows the leaders to focus on different things especially since a true Lean organization is always customer centric. In organizations that there is a great deal of legacy behavior and entrenched management fiefdoms, it might be a requirement to go through an organization like Business Architecture to give the true sense of ownership to the leaders. It makes the bottoms up recommendations that come from the BA team seem like it’s a top down approach that is sanctioned by all of leadership. It let’s people see that clearer tie between the different organizations in a way that a lot of Lean work doesn’t. It’s designed to be holistic not something grown into the whole over time.

This leads to a different method for developing strategy than what a lot of Lean practitioners utilize. Business Architecture focuses on the current capabilities and works to align the strategy from there. Lean starts with the 5 year vision and goals and figures out how to align existing projects and improvement efforts to enact those goal, through providing a metric for the person doing the work on the ground.

I think that these business management approaches are both valid, I’m really biased towards Lean, but I do believe that in many organizations Business Architecture is likely required. It leaves the control a bit more in the leadership rather than the Lean approach. I believe they both can impact strategy in an effective manner, but it’s likely that BA will be more tightly coupled from the start than many Lean initiatives.

Businesses and Silver Bullets

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.

Methodology, managers, and projects

When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.