Open way and open source: enabling transparency and accelerating the enterprise

Here’s a parable, and possibly an interesting exercise for your own organization:

A new CEO comes to a troubled company. On her first day, the CEO tells her new secretary to have all company executives write down the company’s vision on a sticky note to be presented during a meeting in the morning. The secretary, puzzled, asks, “Why do you need that? They’re all C-level executives and senior vice presidents. They obviously all know what our company vision is.”

Nevertheless, the CEO insists, so the secretary visits each C-level executive and SVP and delivers the assignment along with an invitation to a meeting with the CEO the next morning. The next day, the executives and SVPs arrive at the meeting. The CEO asks them to put their sticky notes on the wall. Surprisingly, no two sticky notes match.

This story demonstrates how easy it is for people to misunderstand a common message. I cite this story when I want to explain why transparency matters when you work on a project, and how that’s critical to making any project successful.

I have worked on multiple projects throughout my career. All of them have been IT projects, but they’ve ranged from DevOps, back-end engineering, front-end design, and cloud architecting. Although they have been different teams, common themes emerge when it comes to some of the problems they are trying to solve. From the process perspective, one of the most common themes is how to make the process more agile, fluid, and stable. Another way to describe this is that almost every company suffers from a lack of transparency by way of siloed tasks.

I believe this is where the open way of doing things can help. And open source, which represents a codebase that can be contributed to by anyone, can also become the key component to enable transparency and to accelerate the project.

Open way #1: fixing a siloed team by sharing

What’s “obvious” to one person is often not obvious at all to another. If your university math professor writes a bunch of equations on the blackboard and says, “the proof is trivial,” you’d probably drop the class for fear of failing. When you work on a project, sharing as much as possible, with few assumptions about what is “obvious,” you help others succeed. And when one person succeeds, the team succeeds.

Almost every project starts with a Proof-of-Concept (PoC), usually followed by a Minimum Viable Product (MVP). Everything starts very simply, but projects grow as the team finds value in the product or service and a need to scale out. As a project grows, the team needs to assign responsibility for different groups of people. This is the right way of growing, and the separation of responsibilities is 100% necessary. However, as groups start working on discrete functions, they can lose sight of the project vision as a whole. This misalignment, as with the executives in the parable, goes undetected because the teams aren’t transparent, instead diligently pursuing the idea they believe represents everyone’s vision.

The solution to this is that each individual needs to be as proactive as possible when it comes to sharing their knowledge and work with the rest of the team. This can be done by sharing documentation, periodic presentations, and mentorship. Agile methods can definitely help, but no Agile or other software development lifecycle or business process can fix the siloed problem if people do not want to share. By realizing that helping others can help everyone, a successful team is born. Enabling transparency in an open way is critical to every project.

Open way #2: fixing your team’s problems by contributing to open source

Open source projects, or enterprise projects based on open source, have an interesting concept called upstream. Upstream is any entity that provides your project with resources required for successful production. For example, Red Hat has a cloud product called OpenShift, which is mainly targeted to enterprises. But OpenShift has an upstream called OKD (The Origin Community distribution of Kubernetes) , and this is the place where anyone can participate and contribute. The significant thing about open source is that literally everyone benefits when it’s improved, and by contributing back upstream, you cut through all silos by pushing changes directly back to the common source. Upstream contribution can serve as a common virtual meeting ground for your project, helping different teams collaborate by contributing to the same superior code base. By identifying upstreams and the communities around them, you can do everyone using the project (including your own team) a favor, and of course, you’re likely to benefit when others do the same.

You don’t necessarily have to become a programmer to contribute to the open source project. Say you work with a product and discover a potential bug or an area for improvement. The first step should be to reach out to the dedicated support team, but the problem might be related to the product itself. In such a case, identify the upstream project, and check whether you can file an issue there. Filing issues as high in the supply chain as possible ensures visibility and benefits for all teams downstream.

For example, I’ve been involved with a Red Hat product called CodeReady Workspaces. The upstream for this is Eclipse Che. Here’s an example of an issue I reported.

Some issues like this may have an easy workaround solution that your team can apply right away. But some problems might be related to the core functionality that can be fixed in the next GA release version. When you report a problem like this, the problem becomes transparent. And when the solution is available for the problem, the solution becomes transparent as well. This process continues to establish the pattern of best practices by identifying what works and what does not work, then solving what does not work, and everyone gets the benefit from this process. If this is not the true open source way, what is?

As you can see, the open way can boost the enterprise’s success by enabling transparency in both your team and the community. I get to find out about this by working through a professional career, but I am confident that this is applicable in many areas.

Can you think of any other open way that can contribute to the enterprise’s success? Feel free to share your thoughts with us.