Finding Hope, Allies, and Transformation in the Face of Skepticism
A 4-year transformation in digital strategy led by bottom-up and top-down efforts
A preface
This is a long one, but I hope you stay with me for the ride. 4 years can sometimes feel like forever or just a small blip. I’ve become a father, team leader, and much more in that time. But in an organization like ours, it’s just a tiny stitch in the broader canvas of the work. This article brings together a meta-story of how our work has evolved and where we’re at now.
Testing the Tides
When I joined the NYCDOE and met with dozens of people to learn about their work, they would politely ask me about mine and inevitably land on the same question: “do you think you can do it?” At the time, while I didn’t know which specific problems my team and I would be taking on, my vision was clear. My goal was to recruit and build up a cross-functional product team that could take on some of the most important challenges in the system through new products and services.
What I wanted to do differently was start with a deep understanding of what educators needed to be their best rather than what we thought they should be using.
The people I met with were encouraging but understandably skeptical. Some were open about how naive they thought I was being — worried I was in over my head. They had every reason to be wary: the kind of change I dreamed of was risky. It wasn’t how things were done.
They had every reason to be wary: the kind of change I dreamed of was risky. It wasn’t how things were done.
But I had a hunch that if I could find more people that were itching to bring new ways of problem solving to help improve the lives of the educators we could begin to see real change. It all began with a small experiment.
First Foot in the Door
We had our first win with a very simple app. Teachers and principals liked it because it made important content easily digestible in a user-friendly format. It humanized data and information that could sometimes feel judgmental.
As I shared here, we’ve made a number of pivots, expanded the audience, and significantly increased our reach since then, but in many ways it’s still built around the same hypothesis. Our earliest users and partners began to sense that something was different in how we approached creating solutions for them: we listened, showed a little, and listened some more.
The second major leap came when we began working with another office to build a new app using a more modern and standardized architecture. This shift from a cluster of independent applications to something more akin to a platform changed everything. It required tremendous coordination, compromise, and change management to bring together different team cultures, technologies, data, and management approaches.
Despite overcoming many of the collaboration challenges, hardly anyone used the new tool we built. We had made significant strides in creating norms around data and application architecture, project management, and a blending of cultures but the application itself wasn’t the right fit. We had something that our engineers and analysts were quite proud of but not what our users needed (yet).
While we didn’t find product/market fit on our first try, that wasn’t even our primary objective with this first project. I realize this isn’t typical Lean strategy. If you’re a start-up you absolutely need to get to P/M fit. But in an enterprise, change management is sometimes the bigger struggle. The changes we made internally and the infrastructure we built set the stage for a series of transformations that would soon come.
A Few Steps Back
Before we could capitalize on those lessons and build from our new assets, a new project came in that tested everything about the models, tools, processes, and values we were just beginning to hone.
The project had the makings of an extraordinary opportunity for our office: a way to bring together people from all of our teams to produce a set of products that could inform truly systemic changes. But there were major risks — the project was high profile, high stakes, and required a very quick turnaround.
Over the course of six months we tried to eat our cake and have it too. We tried to leverage some of the assets we had built (e.g. shared data, APIs, and coding standards) while piecing together a slimmer front end that better fit the skills of the people we had (e.g. R Markdown over VueJS). We tried to stay user-centered while balancing the needs and demands of the organization’s most senior leadership. We tried to work in an Agile way, but found ourselves working increasingly toward a single release whose goals and requirements were a moving target.
It was a trying time.
After creating two versions of the product we were making tangible progress both in the quality of the tool and the efficiency of our methods. We had developed new skills, built new pipelines for real-time data, formed new relationships, and begun to understand a new set of stakeholders’ needs. But the work wasn’t sustainable.
Without a more significant shift in how we were managing the needs and getting clearer goals about what we were working toward, we were caught in what felt like a hamster wheel.
A New Era
Before we get into how things changed, we need to zoom back a bit. In addition to the changes and advances that we made in our platform’s architecture, work processes, and methods, we also began tinkering with arguably the most complex challenge: how we approached product strategy, innovation, and governance.
To bring leadership into one place where they could tackle those three domains, we formed a Steering Committee that brought together leaders from multiple offices. They provided support, secured resources, offered content expertise, and helped us engage with other senior stakeholders. Several of us were reading and discussing Lean Enterprise and tried to shape the portfolio of our applications following the 3-Horizons framework — differentiating how we spent our energy on legacy products from new needs that we were trying to meet.
leaders must be able to make the tough call about what to focus on and what to hit pause on or stop.
Our pilot with the Steering Committee gave us a chance to learn the strengths and weaknesses of the model for empowering teams to do their best work. A few of the key takeaways were:
- Leadership needs to be clear and up front about non-negotiables in a project. When there are must-have priorities from senior leadership or external stakeholders, leadership must help frame why meeting those are important while giving space for the product team to own the “how.” Being clear about what these were and why they mattered helped increase the team’s buy-in without taking away their autonomy.
- Recognize that hierarchy is real (and take advantage of it). Most enterprises have hierarchies, and this is especially true in government agencies. Rather than ignoring it, a hierarchy can help leverage existing influence, shape decision making structures to break deadlocks, and open doors. Leaders can use their privilege and situational power to help un-stick things and escalate where needed.
- Leadership must be partially responsible for shaping the priorities of what to work on. Call it product strategy or something else, leaders must be able to make the tough call about what to focus on and what to hit pause on or stop. They absolutely should use insights and evidence in their decision-making, but product teams need guidance on which problems are most important for the organization’s strategy and assurance that their work will be backed up.
Things Fall Together
While one project struggled to find its feet amid a rapidly moving landscape, another was gaining traction. By tuning our governance model, strengthening our shared assets, and developing even better ways of working together, we were able to move on to the next project with focus, clarity, a strong team, and even stronger processes.
As these elements came together, they helped us realize a few key understandings that shape how we work now:
Empower teams, not individuals
Every member of a product team plays a critical role in creating the solution and needs space to use their judgement, expertise, and decision making authority. Doing this means the PM needs to be actively nurturing that culture and behavior, but it is also the responsibility of the leadership for beginning with that expectation and reinforcing it through words and actions.
Adapt new methods (but skip the jargon)
We found a way to meet the theory with our practice not by reading books alone, but by solving problems that were critical for us to move forward with.
For instance, we pursued improvements in our deployment pipeline through near-textbook Continuous Integration/Continuous Delivery because doing it manually was risky, time consuming, and blocking progress. We can deploy the latest version with the click of a button but hardly anyone throws around the CI/CD terminology. We tested new methods for testing hypotheses and developing prototypes pretty closely to standard Lean UX models but we don’t talk about canvases or ‘product/market fit’ because it doesn’t fit our culture.
We learned to frame goals and objectives in terms that leadership not only saw the value of but could throw their full support behind. This often meant skipping the tech-jargon and telling stories of the capabilities we were working toward.
Tell a new story
I remember sitting in a meeting with one of our senior leaders about a year and a half ago while demoing an app we had just built. As we talked through it, he paused, wrote down a few notes, looked up, and asked, “I just want to make sure I understand this. What you’re showing me isn’t just a new tool. You’re showing me a whole new set of capabilities that we now have that we didn’t have before, right?”
“What you’re showing me isn’t just a new tool. You’re showing me a whole new set of capabilities that we now have that we didn’t have before, right?”
He just sliced through the veneer of the new features and pulled out the headline. We were lucky — he continued his support for our work precisely because he was able to read between the lines, not because we were strong story tellers at the time.
This became part of how we talked about the work, but it’s not easy. Stakeholders sometimes care more about features and specific solutions than capabilities. Be sure to know which approach will matter for the person you’re speaking to.
A Maturing Approach
We definitely haven’t ‘figured it out,’ but we’ve matured in important ways:
- we’re closer than ever to having a product strategy that’s driven both by user insights and organizational priorities,
- we’re able to form cross-office teams that build from a growing set of shared processes, designs, data, and assets to tackle complex needs and challenges,
- our product teams are able to operate with greater independence and empowerment, backed by senior leadership support,
- our research, design, and engineering practices are increasingly more modern, automated, and capable of addressing complex tasks and needs swiftly,
- we’re sharing more of our own best practices internally among a growing community of ‘product people.’
Four years ago these results were seen as far-fetched. As I write this sometimes those years feels like a long time for this kind of change, but in an organization as large as ours that can sometimes move cautiously, I’m reminded that these are huge wins.
I feel incredibly lucky to be surrounded by change makers who have persisted over the years to help realize a dream that is only growing stronger.
(Disclaimer: these views do not represent the views or perspectives or policies of the NYCDOE.)
