Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
September 21, 2021
This post is adapted from A Seat at the Table: IT Leadership in the Age of Agility.
Accompanying our transition to an Agile IT world, and subtler in its implications, has been the rise of community as a way of practicing IT. This change is due in large part to the rise of open source, but can also be traced to the demographics and inclinations of today’s emerging workforce, as well as to the interdependence of participants in a DevOps model.
A successful business can harness this community aspect of today’s IT work environment, nurture it in their own organizations, and use it as a principle for building the capabilities of what I have called the people asset. Many of the challenges I have described in A Seat at the Table—challenges of governance, oversight, requirements, quality, Enterprise Architecture—can be addressed by borrowing ideas from the community model.
I am going to take the risk of over-generalizing to paint a picture of today’s emerging workforce. These characteristics reinforce the changes I describe in A Seat at the Table, making them almost inevitable.
As new people enter your organization, your way of working is going to change—and it will change to be more of a community-based, adaptive organism, a gift economy where individuals are respected and honored for their contributions to the community.
Your new IT workforce will respect co-workers who have impressive technical skills, and will have little respect for people who don’t. Skill is demonstrated through hands-on “shipping” of product. Management for the sake of management is not respected. On the other hand, a manager who can make solid technical decisions, contribute to technical discussions, or even sit down and code is likely to command admiration. Leaders emerge informally based on who has the best technical skills, and great technical performers are motivated by the chance to work with other great performers.
The IT workforce wants to ship code. They expect to make an impact. They will be frustrated by obstacles placed in their way. Some companies that use a DevOps approach make it a practice that new employees deploy code to production on their first day of work. This both helps the employee overcome the fear of deployment and gets the employee used to the idea that they can ship code without barriers. As in the open source economy, success and motivation are based on outcomes.
The hierarchy must be flattened. Layers of management get in the way of goals. The employee wants the shortest possible path to shipping code without needing layers of approval. Management should be close enough to the action that they can demonstrate understanding—witnessing employees’ contributions and removing impediments. Employees expect to be able to argue and have their voices heard, even in a meeting with more senior managers.
It used to be natural for ops specialists to do ops, developers to do development, and testers to do testing. Now, crossover skills are increasingly important. On a delivery team, employees will help each other across roles in the interest of shipping code. If there is a backlog in exploratory testing, people who normally do development will help test. Software engineers will oversee their code in production and help make changes to the infrastructure if necessary to improve performance. Security skills are de rigeur.
We speak of T-shaped people, people who have broad skill sets, with depth in a particular area. In the open source world, one is not funneled into a particular specialty—if you can contribute in one area, then it doesn’t matter that your “job description” is in a different area.
Learning and experimentation are taken for granted. In the old days, COBOL programming was one specialty and FORTRAN programming was a different specialty. Today, it is assumed that a software engineer can learn new platforms and will be given the opportunity to do so. Someone who programs in Ruby should be able to learn Python quickly. They should also be able to switch between different continuous integration tools, different build tools, different deployment tools, and different types of deployment containers. In the open source world, you can join more than one project, and the projects can be of very different types.
The workplace must be fair. Arbitrariness provokes negative reactions. If someone needs to be on-call to solve problems (“wear a pager”), then everyone should share in that responsibility. Moral outrage is easy to provoke. Teams are expected to help each other, so incentive structures that encourage teams to focus only on their own deliveries will be frowned upon. Companies should be transparent. In the open source world, norms are enforced by the community.
The software engineer role is increasing in importance. Tests and infrastructure are now both represented in code; with SDN, soon even the network will be. Infrastructure can now be tested, like code; it can be placed in version control. Newly important roles include those of the data scientist: the expert in working with data, with a mastery of statistical inference techniques, machine learning algorithms, and data obtaining and cleaning; the site reliability engineer (SREs), with expertise in maximizing performance in a web-centric environment, and the user experience (UX) researcher and designer.
Finally, as Martha Heller says in The CIO Paradox, “most IT people are technologists; they need to work with technology, to touch technology, to walk and talk technology—at least some of the time.” They are in your IT organization because they enjoy technology; they are proud to be technologists. It is time to shake off the last traces of the attitude that this is something to be ashamed of or that they need to be controlled, learn to speak the language of the business, or start wearing jackets and ties.
A CIO who sits at the table will have created a community in which smart, motivated employees can be creative.
We are moving toward a world in which IT empowers—a world in which instead of passively waiting for requests from the business, IT reaches out and creates platforms that can be used to move the business forward. One way IT can accomplish this is by putting flexible tools in the hands of business users—business intelligence tools, data analysis tools, collaboration tools, and support for mobility and remote work, for example. To go a step further, IT can just as well put development toolkits and platforms, support for self-provisioned cloud environments, test tools and automated test suites—tools that were formerly reserved for people reporting into the IT department— into the hands of the broader community outside of IT.
IT can open its code within the IT department, across the company, and ultimately across the open source community. The non-IT folks can contribute too. If they know how to program, great—they can contribute to the codebase, especially in areas that affect them or that they are passionate about. If they know how to do graphic design, then they can contribute design work. They can contribute documentation, do testing, or suggest solutions. Just as in the open source community, people can make suggestions to improve the code, and others can respond to those suggestions. IT can act as the shepherd, the community organizer, and the main contributor to this community.
It is in this context that I say this: support shadow IT! It is a way to overcome the business-IT-contractor relationship. It is a way to motivate employees and to stimulate innovation. Finally, it is a way for IT leaders to break out of the contractor-control model, bring in the best ideas from the IT world, and contribute to the company’s framework for execution rather than trying to own it.
Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.
Awesome thank you for sharing the amazing article.
Reply
Your email address will not be published.
First Name Last Name
Δ
You've been there before: standing in front of your team, announcing a major technological…
If you haven’t already read Unbundling the Enterprise: APIs, Optionality, and the Science of…
Organizations face critical decisions when selecting cloud service providers (CSPs). A recent paper titled…
We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…
