Going lean within an enterprise: a few things to remember
The first project I took on at Pivotal Labs was with an enterprise client. If you’ve ever worked at or with an enterprise, you’ll know that any time you want to try something innovative, you’ll often be met with “But we’ve always done it this way and we’re fine”. Well, the client team that came to work with us was a small group of intrapreneurs who were tired of hearing that. They were determined to change the way their organization approached building software and were very excited to work with us. This project was a stealth project within their company in order to avoid political roadblocks.
As is expected, helping an enterprise go lean is not without its bumps. These are a few takeaways from my experience that may be helpful for consultants and enterprises to remember as they try to go lean.
Do whatever it takes to talk to users
The importance of talking to users vs. building a product in a vacuum cannot be emphasized enough. Because our project was operated in secret, the clients were reluctant to reach out to their customers, which meant we had to get really creative and careful with our recruiting. (At one point, we even considered going to a nearby mall to physically recruit people to interview.) Fortunately, we found some workarounds that our clients were okay with. Once we ran a few interviews, it was clear to them how valuable user research is, as it gave us a clear starting point on the user problems we should be solving first.
Once the clients returned to their home office, they ran into some political concerns that prevented them from talking to users on-site, so they did whatever they could to talk to people: meeting them off-site in coffee shops, meeting them during off-hours, slowly involving more and more people until they got enough buy-in to start incorporating research into their regular design process. Doing whatever it takes to get good quality user insights is worth the fight.
Make sure your organizational environment supports your team
After our clients unveiled the MVP we built to their stakeholders, a lot of change happened within their organization. Our progress wowed them so much that they ended up promoting many of the client team’s members so that they could teach our process to the rest of the org. They also made sudden structural changes to support a more collaborative environment.
While this was really great news, it meant two things:
- The original client team was spending less time on the project since they got promoted
- While the organizational structure changed, individual responsibilities did not change as much, which meant that people were still getting distracted by meetings, old responsibilities, etc. and not making as much progress.
You can’t change culture overnight. But if you’re going to change your org structure, make sure that each team still has the roles and support it needs, and that the overall structure and responsibilities facilitate progress.
Raise IT issues as early as possible
Due to the secrecy of the project, we didn’t end up deploying to a production environment early on, a risk that kept building up until the end of the project. This meant that there were both technical and product risks: from a technical standpoint, more code = more risk when trying to deploy to a new environment; and from a product standpoint, having an app that had never been put in the hands of end users (outside of user testing, of course) meant we had no metrics or trends to indicate how this app would perform in the real world over time.
Often times in enterprises, requesting something from IT can be hard: you usually need to get approval from several people within the org, IT is handling tons requests from across the company, and it can be hard to get your request prioritized or find the right person to talk to. The whole process can be very slow. Whether it’s deploying to production or some other IT issue, be sure to raise these to the right people early and often.
By the project’s end, not being in production was recognized as the team’s biggest risk, which got the right conversations moving. But in retrospect, raising this as a high risk item as soon as possible could have gotten the ball rolling much earlier.
Rules are there are no rules: use guidelines and adapt them to your organization
The methodologies we practice at Pivotal Labs are meant as tools — or countermeasures, depending on how you want to look at it — to encourage
the desired behavior of getting to a more generative culture. While effective, they are just a means to an end, and should be adapted to each situation as needed to reach that end. It’s less about the what, and more about the why.
When our clients returned home, sticking to these methodologies was a way to keep them from falling off the wagon, which is great. However, blindly following practices without thinking about how they might impact your current situation can lead to doing things that don’t work. At times, they may have done too much user research. At other times, in an attempt to avoid prescriptiveness, product management may have overcompensated and not provided enough product direction where they should have.
Every organization is different: the methods that work at one might need to look different at another to achieve the same outcome. It’s important to first understand the underlying reason behind each practice; then take it as a guideline and adapt it to fit your own organization. Do what works!
“It’s less about the what, and more about the why.”
It’s important to remember that this enterprise still made huge strides in the way they approach building software. We showed them what a balanced team should look like and gave them the tools to get there. They have started the right conversations with the right people, are in a better position to effect change, and have found a more iterative and collaborative way of working with each other. It’s not yet perfect, but it’s a great work in progress.
This client is not so different from other enterprise clients we’ve worked with. Many, like this one, have taken back several of our practices and continue to weave them into their organization: pair programming, research-driven design, an iterative approach to development, and an overall more collaborative spirit. It’s not impossible for an enterprise to go lean; you just have to start small, iterate, and do what works.
