Business value, part 2
I offer some examples and solutions to help product engineering teams refocus on why they are employed - to realize business value for their employers.
Hi, this is Peter with the next edition of the Professional Manager newsletter. I publish this newsletter to illustrate what decent, seasoned, professional engineering management could look like.
This is the second of a two-part series about the importance of focusing on business value. This edition will offer some examples and solutions to help product engineering teams refocus on why they are employed - to realize business value for their employers.
Business value matters for individuals also
Previously, we established how business value is essential for leaders and their teams. However, we have not touched on why individuals should also relentlessly pursue it. Most of the time, Corporate America wants us to help them grow their business. Demonstrating your ability to do so will
Make you indispensable to your employer.
Help you build trust with your bosses (CEO, Founder, CTO, VP of Engineering, etc.).
Earn your license to innovate.
Make a case to chip away at tech debt.
Make you more marketable to other companies.
Make others want to work with you - at least your true professional colleagues.
Make your company more successful.
It is abundantly clear that you cannot go wrong with pursuing business value!
Refocusing on business value - playbooks
We previously discussed two instances when I helped engineering organizations find ways to get excited about pursuing business value and for them to start winning. In this edition, we will go over the playbooks I developed.
“Brilliant” engine, “obstinate” customers
In the previous edition, we discussed a situation I had on my hands with a “brilliant” engine and “obstinate” customers.
All business metrics are going in the wrong direction. The team is blaming the customer. The principal architect and the rest of the leaders think they invented the iPhone of software. You’ve got a Rube Goldberg machine on your hands. The competition caught up, and it is your job to turn this ship around. Welcome to the team, Peter!
When I took the driving seat, I first validated that all of the poor KPIs we saw were accurate. It was devastating to find out just how far behind the competition we found ourselves by pursuing our Rube Goldberg machine that no customer wanted. I knew things could not continue the way they had been. There were two fronts on which I executed change:
I partnered with the product leader (PM).
I changed the mindset of the engineering org I inherited.
Customer Pilots
When the product leader and I established that we could not continue on the path we had been on, I convinced him that we needed to line up a handful of pilot customers who would be excited to participate in the requirement gathering and product development process. We had two guiding principles for this process to be successful: we had to earnestly listen to the customer and stick to a barebones product to deliver.
Listening to the customer
To learn from the customer, we approached product development with great humility - which was essential because, as you may recall, the previous regime has been touting this “brilliant” engine that our “obstinate” customers didn’t want. We told our handful of pilot customers that we were desperately excited about their input into our hypothesis and would have loved to learn from them “why our engine wouldn’t work?” ; “what difficulties they’d have integrating with our contract?”. Through this learning process, our pilot customers voluntarily disclosed how they integrated with our competitors. Not every customer wanted to be part of our pilot. Some no longer trusted our brand and our ability to deliver software that works for them. And that was ok; we needed engaged customers excited to be part of our pilot program.
MVP
We were laser-focused on the handful of pilot customers and their needs, disallowing any conversation beyond a Minimum Viable Product (MVP) and placing any “nice-to-haves” in the parking lot. We brought along our new principal architect to all customer calls so that they could understand the common needs across customers. We rejected requests to customize for any of our customers and informed them of our reality - the best way we could serve them was by building out our platform, not by becoming a custom development shop.
Bringing the organization along
When I started to lead this org, it was tempting to blame the old guard for their poor decisions. It was painful to experience the arrogance and delusion about the system they built. At the same time, I also knew that most of them were solid engineers who were allowed to run with an idea that would never be successful. Moreover, I needed them to buy into the new vision for us to turn the ship. We needed a common understanding of the lack of business value this org has been adding. This required the engineering organization to acknowledge that we had a problem. I advocated for bringing new energy to the senior ranks of engineering. Together, we defined and tracked toward early successes.
Acknowledging that we had a problem
The engineering team was oblivious to how big of a problem we had on our hands. I had to ground us all in the realities of our business - that we were quickly losing our competitive edge. I started to put business results front and center of most interactions. We reviewed adoption (good) and feature requests (bad) KPIs weekly. Once we stopped admiring the engineering feat that our “brilliant engine” was and started to focus on our lagging business results, convincing engineers that we needed a drastic change became more straightforward.
Bringing in new energy
Now that we were all operating in the realities of business results, we needed to start designing a new system - validating every feature with our customers. I convinced the CTO that we would only make traction if I could bring new energy to the senior engineering ranks. I temporarily enlisted two trusted principal architects to help us with the design. We then had three principal architects on the team, and thus I instituted some checks and balances. Previously, the single principal architect was allowed to push his vision and overrule everyone else on the team by pulling rank.
Small and early wins
We were focused on business results, had a well-defined MVP, and brought fresh air to the technical decision-makers. It was critically important to put some early wins on the board. We organized weekly org-wide demos. We established that
our demos needed to showcase working software.
every team had to show progress. Every week.
we would celebrate every baby step towards progress.
we would be ok with imperfect demos.
we would prioritize feature and team integration points.
The Results
A tight partnership with the product team, humility with our excited pilot customers, grounding ourselves in the realities of business results (and not just in “brilliant” engineering), introducing checks and balances in technical design decisions, and celebrating small wins from the very beginnings resulted in us building a new engine a quarter of the time it took to build the previous engine. Nowadays, one of the biggest leisure brands in the world runs its integration with large clients on the software we built.
Social Club Inc
In the previous edition, we discussed my experience at Social Club Inc.
Engineering leaders cannot articulate what their teams are after. When I provide constructive feedback, leaders reporting to me take that as an indictment of our working relationship. We are working on products that are not selling. We are perpetuating this casual atmosphere by hiring underqualified leaders. Not a recipe for success. Enjoy fixing this, Peter!
After spending my first 60 days taking notes, asking questions, and finding patterns, I formed a hypothesis about what may be broken with the org. My idea was that most engineering leaders prided themselves as “people managers” and had no interest in technical details. I believe the best engineering leaders must straddle exceptional people management and a keen interest in technical details. To change the culture at Social Club Inc, I changed the EM requirements, routinely measured team progress as told by EMs, and gathered input from the team to set a new direction for the org as a whole.
Redefining the EM Role
Changing the culture of frontline and senior managers is no small task. When I showed up, engineering managers (EMs) laughed at me when I asked whether they had their team’s code checked out. They’d tell me, “Peter, at Social Club Inc, we delete your IDE when you become an EM.” An engineering director told me, “Oh no, I don’t bother with the details. I operate more as an executive.” All of this conflicted with my fundamental beliefs about engineering leadership.
To change expectations for any job profile, you need to formalize your new expectations. Once I realized that we only had a loosely defined engineering leadership rubric, with hardly any measurable accountability, I started to work on a much more effective leadership rubric to define success in the role.
Measuring Progress
The most critical part of the new rubric was demanding an intimate understanding of the progress a leader’s teams were making - weekly. I also started to mandate ways for engineering leaders to showcase their technical curiosity. Admittedly, these rubrics all served to uplevel the engineering leadership team I inherited. About a year later, I realized I subconsciously omitted critical areas - like the more senior you are, the more organizational impact you need to have. Still, I feel this was the right move. I needed to uplevel the leadership before I could start building forward, and for this, I needed a somewhat tailored set of expectations.
Forming alliances with senior individual contributors
I quickly tried to form alliances with staff and principal-level engineers to have another view of the engineering organization. Once we established rapport, I asked them questions like
How do you think the engineering organization could better serve the business?
What do you think is broken with our organization?
What do you think is working well?
What would you focus on in the next month if you were in my position? Two months? Three months?
How could I serve you best? How could I serve the engineering org best?
I wrote down everything they said. I then distilled the information into a comprehensive org analysis, which I presented to some senior executive team members.
The Results
As I was exiting my first 100 days, I had a plan that my boss approved. Before my first anniversary, I coached up more than half of the engineering organization’s leadership. Folks who fit my expectations of exceptional engineering leaders took on more responsibilities. We also hired a handful of great leaders who fully understood what they were signing up for. By the end of my first year, we had a highly functional, business value-oriented leadership team. As importantly, we created an engaged, high-functioning engineering organization who were ready to realize business value.
Summary
This edition covered some of my playbooks to demonstrate how I turned around engineering organizations that were lost and no longer focused on what mattered to an engineering team.