Ramblings

This was a round table discussion topic for the Nashville Product Meetup held April 2021 (“Product Lessons Learned the Hard Way“). A few of us committed to sharing a story ahead of time in order to ensure we got some traction in the conversation. Below is a story I shared. What I love about this story is that from all accounts, it didn’t “feel” like a failure at the time. But, in retrospect, I brought my “C game” and missed an opportunity.

…

When I first joined Kindful as a consultant, there were 15 people in a little office in Berry Hill. The environment was positive and exciting. Kindful had a few hundred paying customers and they were gaining traction. It felt like Kindful had a ton of potential to take the nonprofit donor management space by storm, but a LOT of work to do to fulfill the founder’s vision.

With all of this successful growth, they lacked a voice with strong management, organizational and operational experience. They were experiencing growing pains – which became more and more apparent as customer commitments piled up and timelines kept slipping. It was the perfect time for someone like me to join. I had a lot of fun getting up to speed, introducing new processes and tools, and seeing an immediate impact on the team members and customers.

However, there is one initiative that I worked on in those first 6 months that still haunts me to this day.

Remember when I mentioned growing pains? In order to keep up with the growth in customers, users, and data, our CTO was in the process of rewriting a few key features for scale.

In conjunction, one the developers was rewriting the entire UI; they called it Kindful 2.0. It had been in beta testing since before I arrived on the scene. And one of my charges was to drive the project to completion. We were under pressure to get 2.0 out the door.

One of the features to be finished was the filtering system. Users would use this system to segment their contacts based upon one or more search criterion. The CTO built an insanely powerful querying system which searched hundreds of thousands of metrics, returning results near-real time. It was so cool. But our beta users told us it was “too hard” to use.

Our Founder was on top of the feedback and asked the developers to build an easier way for customers to filter. I intercepted this transmission and got to work. I talked to internal stakeholders to understand the problem space and goals. Then we generated ideas and I created mockups. I solicited feedback on the mockups with internal team members, iterating on the design a few times. I worked closely with the developer, testing & iterating until we had something we felt we could call done.

Success, right?

Not really.

All the while, I had this nagging feeling that I was rushing through the effort. If I was honest with myself, I knew I didn’t understand the problem well enough. And if I didn’t understand the problem, how could I be sure that we were creating something useful?

We were “just” successful enough to move on. It was an insidious win. Sure, the new Basic Filters functioned, and was easier to use than the powerful query bar. But if that was our bar for success, it was a little low. We did receive feedback in beta testing that the Basic Filters feature was difficult to understand, however we didn’t get enough feedback to warrant going back to the drawing board in comparison to all of the other priorities on our list. None of us were especially proud of the feature, and for good reason. We had an opportunity to build something really useful, and instead, delivered something our users would “make do” with.

My personal takeaways from this experience were:

Firstly, to stay engaged. You know that gut feeling that tells you something isn’t right? Even when you’re under pressure, and maybe especially when you’re under pressure, pause and ask yourself where that feeling is coming from. When I look back, I see that I got caught up in the momentum of the patterns established before I arrived on the scene.

There were several points in the process where I could have paused and scheduled some direct conversations with customers so that I could have understood the problem space better. I’m embarrassed to say, but I’m not even sure I wrote user stories. Had I done that, my mistakes would have been more evident in time to be able to do something about it. Even though product development is a team sport, we as individuals have a responsibility to get above the fray to ensure that firstly, we are doing the right things, and then subsequently, that we are doing those things right.

If only I had gotten crystal clear on that lesson just a little bit sooner, we could have built something both really easy to use and really useful.

It was a bittersweet moment when we were informed that our company was being positioned as being acquired in the coming weeks. 

On one hand, it was very sweet to reach such a milestone with my team. Very sweet. Our success was never guaranteed, and we worked very hard together over the years for this type of successful outcome. When we hit a very aggressive growth goal in 2019 – after previous years of growth – it felt inevitable. But then there was a global pandemic, and we remembered that luck plays its part.

I had questions. We were two similar companies with two similar product and services offerings. There would be redundancies. There would be massive changes. I had been seriously considering this possibility for over a year at this point. But what about my team? How would they initially feel? And how would those feelings change over time as their daily work environment changed over time? And how would these changes impact our customers? 

I felt concerned. Our long tenured team had operated very efficiently, with a high level of output for years. We were worn thin from “making do” and “reaching into our reserves” for so long. Add to that, the pandemic was creating all sorts of serious personal hardships, and now we were about to add another major stressor to our team members: uncertainty and impending massive change at work. It felt risky to pile “one more” challenge on our people without in turn creating space for everyone to mentally and emotionally adapt.

Mitigating this risk was smart for multiple reasons. First, demonstrating empathy and concern builds trust and good working relationships. Second, a business is not successful without it’s people. When you care for your people, you care for your business. 

If, in general, we must strike the right balance between “focusing on execution” and “focusing on the people” (in order to create a highly effective team), then this moment felt like the right time to shift the balance more on “the people”. From a tactical standpoint, I’ve searched for new words and phrases to signal that I’m more concerned, and more available to support my team members. While we still review the status of our OKRs on a regular basis, my primary line of questioning  has shifted from “how can we accomplish our goals?” to “what priorities do we need to descope so that your don’t feel overwhelmed?”  When our busiest production support month was over, I scheduled a “day to work on whatever you want”, in the hopes that the opportunity to work on a passion project would reignite our smoldering fires of motivation.

In practice, very little of our quarterly commitments have “slipped” due to the current events. We still provide great software solutions to our nearly 3000 customers. We’re still growing. However, several team members have expressed genuine appreciation for the “breathing room”. 

It reminds me of a favorite saying of mine: “It is not so much our friends’ help that helps as the confidence of their help in need.” – Epicurus

Starting the summer of 2019, I spearheaded an effort to evolve our 15 person team into a “department of teams”. At the time, our designer, all of our developers, and analysts reported directly to me. Our team was a “well oiled machine” and worked together very effectively, however I could not in good conscious hire “even one more” direct report.

In order to enable Kindful’s continued growth, we needed to lower the “manager to direct report” ratio. Doing so would provide more support for team members through more access to a manager. Furthermore, it would allow us to increase our rate of hiring and onboarding new team members. 

When I think back to that time, it felt like being on the precipice of a daunting challenge. Every single person’s daily work life would be changed in the coming evolution. It has been said that a person’s manager can “make or break” an employee’s daily work life. I felt personally invested in my team and their careers. The very last thing I wanted to do was to hire “the wrong” manager, so I approached this task thoughtfully and delicately. My intention was to aggressively protect the progress we have made over the years in building a well-functioning product development team, while also adding new and complementary people and skill sets. 

First, I needed to create a vision for the department that I could convey to job candidates. 

To create the vision for our evolved department, I started with the status quo. I thought carefully about “who we are”: about each team member, their skills and their aspirations for career growth. Then I dove deep into “the work”: ‘what do we do on a daily basis today?’ and ‘what are our near term plans?’ I considered our products and modules. Our entire team was supporting all of our products: a CRM, multiple online fundraising tools, an API, a partner portal used by API developers, and a portal used by donor users to manage their online giving. I started writing products and their modules / features on colorful post-its and dreamed of a world where dedicated teams could focus on a specific product and it’s users. Thinking about this future, I considered our talent and experience gaps. I knew we needed managers, but what other skills do we need to hire for? These were my puzzle pieces: existing team members, potential new team members, and the products/modules. I played with the puzzle pieces (modeling with stickies, then moving to Google Sheets – my “digital sketchbook” of choice) until I had a vision of a department structure that I believed could grow with us for the next couple of years.

An evolution this large can’t be done unilaterally. So before I could talk to candidates, I needed to socialize my vision with key internal stakeholders, starting with other leaders in the C Suite, then members of my team. Once I had buy-in from the leadership team, I started to socialize the vision with members of my team, starting with those who I thought would be interested in a manager role. Now that we all shared a vision for the future, my role was to continue to evangelize it. Through conversations with internal team members I ensured that any concerns anyone might have had were carefully considered while also generating excitement about our future opportunities. Having many one on one conversations allowed everyone to feel like they participated in the process. This evolution became something that we were building together.

At this point I was able to go “full speed ahead”, recruiting 2 internal team members for manager roles. And through a collaborative recruiting process, I secured the remaining managers that I needed. 

And with the managers secured, I again began talks with each team member, this time about what team they were to be on, who their new manager would be, and what products and modules their team would be focused on. These conversations had the potential to be difficult, however they went quite well. I think we can attribute it to our culture of collaboration, open communication and respect, the cooperativeness of our team members and the conversations I had with everyone along the way.

At this point, I did a bit of a “phased” roll out of the new teams. While team members finished their work in progress, I worked closely with the managers to prepare to actively lead their new teams. I asked them to start meeting with their teams, reporting on progress, and to set up one on ones while I also drove the goal setting and product roadmaps for the next quarter. I modified our Jira configuration to work with our new structure and modified our “ceremonies” to allow for the additional complexity in our department structure. I created a weekly reporting process so that managers could report up to me, so that I could in turn would have what I need in order to continue to report to the rest of senior staff.

In summary, 6 months after my initial sticky note puzzling, we had 4 managers (5 including myself) for the 20 of us. We had 3 scrum teams, each dedicated to specific products/modules. We were in a position to be able to benefit from reduced context switching, increased focus and specialization. We now have established processes, routines, norms, and tooling for a department of teams such that we were well positioned for future challenges such as continued growth and employee turnover. We were able to hire more employees at an increased rate. 

What I feel most proud about is the fact that our team has thrived through the transition. I solicited feedback and never received a complaint during the process of assigning people to new managers, to giving people new roles, and changing our processes. Quite the opposite, several people vocalized very positive feedback throughout the process. And in our quarterly review process, I consistently hear glowing reviews of the managers and the positive impact they make on our team member’s experience.