Photo by Ross Findon on Unsplash
Has there ever been a time at work when things were moving in a direction you didn’t agree with or you felt could have been done in a better way?
Maybe you thought your company is too big or that it has been done this way for so long, how could you possibly make an impact?
You might work at a company with 10, a couple of hundred or a few thousand employees.
And your company might be a startup or a few years old or a couple of decades.
You might work on one or a dozen or 20 products or services.
At IBM, we work on around 20,000 products and services and our company employs around 400,000 people all over the world.
This is a story about a few people, who envisioned a better way to work and led a change effort that has transformed the way that IBM does business.
Our story begins in the year 2012, the year that Ginni Rometty became CEO. Ginni believes that the client experience should be our highest priority in everything we do. That same year, Phil Gilbert was appointed GM of the newly formed IBM Design organization. IBM Design’s mission is to reinvent everything IBM does and from the standpoint of our clients, build products and services for the people who use them.
This was the beginning of IBM’s transformation into a design-led company.
Restless Reinvention
This isn’t the first time that IBM has reinvented itself. After all, today we build software — but in 1911 we built machines for business. Over the past 100+ years, IBM has continually reinvented itself and we often use the term “restless reinvention” to describe IBM.
Arguably, the most critical component of IBM’s design transformation effort is the large scale hiring effort which aimed to hire thousands of formally trained designers. Increasing the ratio of designers to engineers at IBM was the goal of this effort. In 2014, Phil and his team also recognized that there is often a cultural and realistic divide between design and engineering so they expanded the hiring scope to include front-end developers. Modern front-end developers have the technical expertise of a developer and expertise in delivering a delightful user experience. (Since IBM loves acronyms, we often refer to front-end developers as FEDs.) These FEDs were hired to help to bridge the divide between design and engineering.
Designers hired at the time were on-boarded with a 3-month design camp experience. Design camp (as you might imagine) was designed for designers. Designers learned IBM Design Thinking, practiced user research, and were taught to design products and services with the user’s needs in mind. The FEDs that were hired experienced the same design camp and then were deployed out to product teams across the globe. (We have since reinvented the onboarding experience for FEDs hired through Design. Read how I used Design Thinking to help prototype a new experience for the FEDs.)
Back in 2014, Brian Han was one of the FEDs that was hired in that first wave. He and other FEDs went through the same design camp as the designers. He wrote some blog posts about his design camp experience and describes how he was mostly doing user research and user interface design and very little coding. Nonetheless, he hoped that once he was deployed to his product team, he would be able to contribute code and make an impact on the client experience.
What he found back in 2014, however, is that his managers didn’t really know what to do with him. He was often still doing user research and when he asked to code, he was tasked with building out prototypes. Since engineers viewed these FEDs as designers, they did not welcome them into the codebase. Keeping them out was particularly easy to do since the code was all locked up in a code repository with controlled access. As a result, these prototypes were rebuilt entirely in the production code.
At the time, rather than bridging the divide between design and engineering, the result was that the divide was even bigger, because the FEDs hired through the design organization lacked the credibility of a “full stack” developer respected in IBM’s engineering culture.
Back in 2014, had Brian and the other FEDs been granted access, they would have had to know Java and Dojo in order to contribute to the code. And if they did manage to make changes to the code, they would have had to request the code be merged by an integration engineer and in order to do that, they would have had to use a powerful yet complex repository solution which is very unfamiliar to most modern front-end developers.
These struggles led to a sense of overwhelming frustration and a feeling of lack of support from the IBM Design organization that hired them. Most of the front-end developers hired during this time were frustrated to the point that they were ready to leave IBM. A group of them decided to organize some meet-ups so they could discuss their challenges, figure out what to do, and ways to elevate their practice of development. They also decided to take their concerns to Phil and that is when he asked Damon Deaner, a member of his leadership team, to work on the problem.
At the same time, Sam Richard and Kevin Suttle, senior front-end developers who had industry experience, began to create a vision for making it easier to practice front-end development at IBM. They had experience with modern tools, techniques and best practices being used by leaders in the industry, especially around social coding, and they wanted to bring those to IBM. Their goal was not only to make their lives better but to improve IBM’s overall process, increase efficiency, and help to make IBM a leader in modern development.
One of the first things they pushed for was to be able to use GitHub to manage their code. They recognized the power of its simplicity and the benefits of social coding that it facilitates. They also knew that the talent IBM was hoping to attract use GitHub. So they pushed for its use, creating repositories on GitHub public, and eventually IBM CIO’s office adopted GitHub Enterprise, granting all IBMers access, through a program called Project Whitewater
Grass Root Efforts
In 2015, the FED@IBM Program was created by leveraging some grass root efforts. One of the key components centers on community. One of the first things that happened was that Damon leveraged the efforts of Jessica Tremblay and Una Kravets, who had organized those meet ups in Austin to share knowledge, to sponsor and create a global program called FEDucation. FEDucation is a virtual meet up which any IBMer can join in live or listen to recordings of the sessions. During the more than 100 FEDucation sessions held to date, members of the IBM community and external guest speakers talk about things like Vue, React, coding standards, APIs, ES6, web animation, continuous delivery, and workflow.
Another key component of the FED@IBM Program has been enablement. One of the programs we call Coding 101 was started by some developers who wanted to teach the non-developers on their team HTML and CSS so that they could work out their ideas in code and collaborate more efficiently. Another enablement experience created by FED@IBM was an intensive in-person up-skilling program called Hackademy. In Hackademy, developers listened to two days of conference-style talks on topics ranging from performance to accessibility to architecture to task runners to social coding and responsive design. Then they were broken into groups and asked to use the concepts they heard about to build a front-end application which solves a user’s need. We conducted a dozen Hackademy events around the globe with over 500 participants.
The FED@IBM Community has experienced rapid growth since beginning in 2015. What stated with a few hundred people has now grown to over 3000 members. Since I took over leadership of the program in 2016, we have begun to scale out the program. In my next post, I will talk about how we are scaling out our programming and sustaining our efforts. The FED@IBM Program is also being looked at by other communities of other disciplines (like user research and content design) who are learning from its success to create similar programs and communities.
Ripple of Change
As a direct result of Sam and Kevin’s efforts, we have seen an impact on how IBM does business by the introduction and scaling out of the tools they brought into IBM.
Every IBMer now has access to GitHub Enterprise as a result of Sam and Kevin pushing its use. Teams use it to collaborate, organize as well as share code. We see developers, designers, and project managers all using GitHub to support their workflow which supports a whole team approach to software development.
[I]t’s not simply the FED community at IBM that has benefited … engineering as a whole has prospered at IBM. — Phil Gilbert
Also now available to all IBMers is Slack, which was first introduced by Sam and Kevin in September 2014. In Listen to the Wild Ducks: How IBM adopted Slack — by Bill Higgins, you can learn more about the story of how they created the first Slack team which was a key factor in facilitating collaboration and conversation when creating the FED@IBM mission and community. Slack is now widely used across IBM.
If you think you can’t make changes at work, take a look at the resources below and read John Kotter’s Leading Change, which is a guide to business transformation. If a few people can change the way a 100 year old company with 20,000 products and 400,000 people works, transformation at any company is possible.
Now, I am not saying that we have completely transformed and solved all of the challenges at IBM — we are still working through many of them. But maybe after reading this, you will be inspired to lead some changes that result in impact at your company.
Resources:
Leading Change — John P. Kotter
The Field Guide to Understanding ‘Human Error’ — Sidney Dekker
What is #IBMHackademy — by Sam Richard
Listen to the Wild Ducks: How IBM adopted Slack — by Bill Higgins
IBM’s Design-Centered Strategy to Set Free the Squares