Transforming From Doing Agile to Being Agile
How Palantir has spent the last year developing an Agile mindset to become more effective as an organization.
Over the last year I’ve been looking at how Palantir might be structured to deliver more value to both our external and internal audiences. We’ve always been committed to continuous improvement, but after years of trying patches for the same old cracks, it was time to take a more comprehensive look at Palantir, our strategy, structure, processes, and practices.
Upon setting out, I established three principles to guide the effort, which I initially thought we could complete in 6 months (that was over a year ago now).
- Understand (and then solve for) the root problem.
- Design something that works for now AND scales.
- “Adapt what is useful, reject what is useless, and add what is specifically your own.” (courtesy of the ever-awesome Bruce Lee)
Fortunately, this effort was not entirely on my shoulders. In addition to the existing Palantir team, George and I were guided in this effort by a long-time colleague and instructor from Northwestern’s MS in Learning and Organization change (MSLOC) program, Maggie Lewis, who joined Palantir in September 2018, and her fellow MSLOC instructor and consultant Margaret Sullivan.
Understanding the Root Problem
Combining data we collected from existing and former clients, feedback from team members and organizational design research, we identified three root areas of focus if we wanted to become a more effective organization:
- Defining our service offerings so that each could be more effectively communicated, sold, and delivered in line with client expectations.
- Aligning on a shared vision for and delivery of value within our projects.
- Creating a structure (organizationally and within projects) with clear roles, responsibilities, and decision-making rights.
With those root issues uncovered, we used the star model to guide our organizational redesign efforts as well as four strategic questions that, once answered, would address the persistent issues we’d uncovered:
- How do we deliver repeatable value to our clients?
- How can we be a human-centered company not designed for/dependent on any specific person/people?
- How do we better support our team?
- How does Palantir become an agile organization? As we progressed, it became clear that becoming a more agile organization was the key.
Adopting an Agile Mindset
Palantir has used an Agile methodology on our projects since 2008. However, in analyzing our process more deeply, it became clear that while we use Agile practices and Agile tools, we had not yet internalized the Agile values and collectively had not yet developed an Agile mindset. This was a breakthrough insight as it not only provided a clear path forward, but it (along with Cynefin, a framework for decision making) provided perspective on why previous improvement efforts had been short-lived or ineffective.
Becoming a more agile organization means putting cross-functional project teams at the center of what we do. The core of our work at Palantir is and always has been our projects: whether external, like our client work, or internal, like our discipline teams and open source work. It’s what we collectively focus on most -- it’s where we spend most of our time and have the most impact.
As we reoriented toward our project teams, the priorities to help move us forward became clear:
- Optimize for focus and flow so that teams and team members can do their best work. Team members should be able to be "focused" with fewer projects competing for their attention and working more often “in flow."
- Connection, support, learning, and development are an integrated part of project team work, not supplemental and apart from it.
- Chapters are the place for organized learning around discipline skills (such as Engineering, UX, Project Management, etc.) and for discussion of the roles, activities, and artifacts they take on.
- Each person has a P.O.D. (Professional and Organizational Development) team that provides facilitation and coaching in performance, growth, and development:
- a project P.O.D. member, most often someone in a Project Advocate role providing insight into learning opportunities within your projects
- a chapter P.O.D. member, most often the Chapter Lead with the perspective of opportunities with skills growth.
- and a company P.O.D. member, to help facilitate alignment between personal career goals and the company’s opportunities.
- Deepen the connection between the organization and projects and accelerate how project innovation impacts us organizationally.
- The P.O.D. structure provides multiple regular touchpoints for feedback, support, and growth.
- Emphasize stable, small teams of +/- 8 people (project teams, chapters) to support connection, collaboration, and learning.
- Fewer large group meetings, although the All Company meetings and the Annual Retreat remain.
- Management roles are focused on facilitation, collaboration, and coaching with direct visibility into and engagement in day-to-day project operations.
- Articulate the structure within which individuals and teams work.
- Playbooks provide the default structure of how we do it here so that teams can customize their approach, not build from scratch every time.
- Establish an equitable compensation structure with defined salary levels that provide equal pay for equal responsibilities and level all salaries.
- Create a career grid that demonstrates what opportunities exist both for advancement within a chapter and laterally at Palantir.
- Support the career grid with a role-based structure that articulates the skills and expectations for each level so that individuals and P.O.D.s are orienting learning and growth conversations around a standard for promotions and opportunities.
None of these efforts are (or will be) perfect immediately. Many have taken longer than we expected to roll out. Others are still in progress. However, because we’re taking an agile approach, we’re able to work iteratively our way through this ambitious roadmap for improvement by breaking it down into manageable chunks, conducting experiments to validate our assumptions, and incorporating what we learn as we go.