When joining Pivotal Labs, a software development consultancy, and attempting to explain what I do to others, I quickly realized how the terminology “consultancy” very much misrepresented what we do. Having previously worked for 3 years at a business management consulting firm, I could empathize with traditional associations most have of consulting and consultants.
I started this initially to help me explain the key differences and similarities to friends, particularly former consulting colleagues, but it is useful for anyone interested working for or with Pivotal Labs!
How are we different?
On a high-level, our Pivotal Labs’ services are anchored in the belief that we are the last software consultancy that you need to hire. Sounds a little strange right?
Many clients come to us with a largely outsourced engineering team, siloed IT and business organizations, no embedded design practice, and a waterfall approach to product design and development, where most of the decisions are made by senior management far in advance of execution. As Pivotal Labs, we want software engineering to become the value-engine of the organization. We want the end-to-end product development process to be a core competency of your organization, driven by empowered, autonomous and self-organizing agile teams and guided by principles of user-centric design, lean startup methodologies, and lean engineering practices.
Our mission is to “Transform the way the world builds software” and we can only feel proud of achieving this mission if clients are enabled to continue evolving these core competencies within their own organization.
A little more specifically, here is what sets us apart…
Lean/UCD/XP vs. agile/waterfall
Pivotal Labs practices principles of lean startup, user-centered design, and XP agile software development. Therefore, we do not start a project with a fixed scope or solution. Our initial goal is to minimize product and development risk upfront. Projects come to us in many shapes and sizes. Sometimes we define and build brand new products. Other times we help our clients evolve or improve an existing product. We always seek to identify, test and validate our assumptions throughout the product development process. We typically begin by exploring the problem space through user and stakeholder interviews and market research, to validate and narrow down the problem space for the first release. We ideate and prototype our ideas for that first release, test those prototypes with real users and start development when we have a higher level of confidence in the initial set of features. We then continue to learn and iterate with user feedback throughout the development process to derisk the product and execution.
Time-based resourcing vs. fixed cost / time / scope
The ability to follow this lean agile approach is inherent in how we structure our client contracts. Pivotal Labs functions on a time-based resourcing. The client only pays for the number of people and hours that we spend working on the project (project team members log every hour they spend on the project on a weekly basis to calculate burndown). We follow 40 hour work weeks, Monday to Friday 9am — 6pm with an hour lunch break. Our working hours are not a perk to attract talent; they come from a belief that sustainable pace drives high quality software on a predictable cadence, and supports pair programming. Given the size of our clients (medium to large) we want to teach them how to go fast, forever. The software quality compromises you make at early hours of the morning before a deadline does not enable this. It is important for us to model this behavior that we are trying to instill in our clients.
We do not commit to a fixed initial scope. We optimize for learning — as the team learns more from our client, business value, user research, and technical complexity, we can be flexible and reflect changes in our priorities without being tied to a promised scope. This is to ensure we are always working towards delivering the highest business and user value in the most effective way possible, as we continue learning. Agile means the ability to reach to change — our contracts reflect the ability for us to do so.
Execution vs. recommendations
Pivotal Labs is ultimately held accountable for helping our clients build digital products that provide value to the user. Pivotal employees choose to work at Pivotal because we feel like we have the opportunity to practice what we preach — we build software that we have identified as valuable to the user and business. We are happiest when we are producing tangible outputs! Admittedly, this comparison relates mostly to traditional management consulting and less of other development agencies 🙂
Enablement vs. handoff
Our mission at Pivotal is to “transform the way the world builds software.” Therefore, a primary goal for us at the outset of the client engagement, is to empower the teams of that organization to adopt lean startup, user-centered design and agile principles and to be able to practice them in their organization without us. This is probably what sets us most apart.
We are a teaching company and we pair with our client developers, product managers, and designers EVERY DAY. This means we are all considered the same team that work together daily. My goal as a Product Manager is to make myself obsolete by the end of the project, and that my client PM can fulfill the role successfully on an ongoing basis. Since designers and engineers also pair on all design and development, we do not need to spend time on handoff. All developers have experience with and a shared understanding of the entire code base.
Immersion into Pivotal Labs vs. client site
As part of our goal to enable, we set the expectations that our daily working clients co-locate in our Pivotal Labs office every day and share our routines. We have a particular culture and routine at Pivotal Labs that has evolved to support our lean and agile development practice (check out “A Day in the Life of a Product Manager”). For example we have a daily free breakfast and office-wide standup, 9am-6pm working schedule, 1-hour-long lunch breaks with optional activities & free lunch, open working spaces, after-hour meetups, etc.
It sets the expectations that the client will learn and adapt to our way of working and it provides the white space for our clients to understand how things can be done differently. We then work on enabling the client on bringing principles and practices that works for them to bring back to their organization. As employees of Pivotal, it also allows us to maintain and contribute to a consistent, sustainable culture across projects.
How are we the same?
It is ultimately a client services business.
At the end of the day, consultants are still beholden to the desires and constraints of the client. The best we can do is help clients validate / invalidate assumptions that drive these desires and find solutions to address the constraints. As external folks, it is important to quickly identify what lies within / outside of our ability to impact or consulting can quickly become frustrating. Success is ultimately determined by the perceived value of the client. Since it is a client service business after all 🙂
One can move on.
Every project is to some extent ephemeral. In a few months, I’ll be working with a new team members, new clients, and new set of opportunities and challenges. I can choose to make the most of the time I have with the client and can equally look forward to shifting gears if a project isn’t the right fit.
There are phenomenal learning opportunities.
I have learnt tremendously from my time at consultancies. I’ve gotten to see some of the world’s largest, most influential companies from the inside-out, learn what drives our economies and fails them, and be a part of solutions that will shape the future of industries.
Every project brings something new: new co-workers with varied domain knowledge, new clients, new problems, new industries and markets, new users, new technologies.
Pivotal and other consultancies can provide tested principles and frameworks for how to approach problem solving that empowers you to build a path forward no matter how hard and opaque the problem seems.
And the “soft consulting skills” — the ability to empathize and understand your stakeholder’s context and and then have the storytelling skills to communicate clarity and align towards a common goal — are invaluable when working with anyone, anywhere.
If you have any questions, feel free to reach out!
Pivotal Labs: a very different type of consultancy was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
