Making Software Development Rocks Work in Your EOS Organization

During your next EOS quarterly planning meeting, when you get to rock planning for you software development department, ask yourself the following questions:

• Does this software initiative make sense as a rock?
• Can you make it SMART?
• Is it truly a 90-day initiative?
• Do you have clear requirements and an estimation the team is confident in?
• Is there a possibility that the priority of this software initiative may have to compete for capacity with other software projects?
• Do we understand the cost and what the return on that investment looks like?
• Have we compared this software project against others and concluded it's the most important right now to help the organization meet our yearly goals?

How many can your leadership team answer? If you said "all of them," congratulations! You're running a well-organized and high-performing software development organization. Unfortunately, you're also probably in the minority.

If you can't answer these questions, then your rocks need to be about HOW to work, not WHAT to work on.

One of the common challenges I see with companies running on EOS is that the leadership team creates rocks based on making meaningful progress on software development projects but lacks critical information to inform those decisions. More importantly, they struggle to make these rocks SMART. This transforms what should be a system for creating accountability into something that destroys team morale.

So how do you manage software development with rocks?

I use rocks in two main ways for software development organizations:

1. Improve how the department works to create visibility and transparency into what we're doing, why we're doing it, and what we expect to gain from doing it.
2. Professional development. I use competency matrices, or banding charts, to create clear personal pathways for each team member to grow in their careers.

Some examples of the first approach might be:

• Begin tracking types of work the team is performing and provide transparency on how we're spending our capacity. If we're spending 20% or more of our capacity on fixing bugs or other types of "waste," we have room for improvement.
• Build out Product Management and create a roadmap based on ROI that aligns with our annual goals.

For professional development, I create personal rocks or SMART goals for direct reports that provide clarity around areas of improvement and clear steps to take over the next 90 days. This helps individuals grow in their careers. Next quarter, I'll have them cascade that approach with their team, and so forth. This aligns well with our EOS quarterly conversations and weekly or bi-weekly one-on-ones.

These approaches shift the focus from WHAT the teams are doing to HOW the teams are working.

When focusing on these seven questions, you can quickly identify gaps in your product management and product development organization. The good news is that depending on which questions you can answer and which ones you can't, you'll gain insights into where improvement is required.

When work is made visible, it can be measured. When work is measured, it can be improved.

If you want to learn more about making this transition in you organization, book a discovery call using the button in my LinkedIn profile.