Keeping executives out of JIRA and focused on higher level strategic dashboards is a key success factor for the software development process.
As a Chief Technology Officer (CTO), my responsibilities span a wide range. At the highest level, I gather input from customers and produce software and systems that meet their needs. The naive view would be to create a long list of requirements and the tests that validate them, MilSpec style. However, the realities of managing a software development organization mean that my duties go far beyond getting lines of code written–it’s about building the organization.
The CTO’s responsibility isn’t only about delivering software. Our responsibility extends to building organizational capabilities. This includes cultivating technical skills, building frameworks, tools, and automation, defining strategic architecture, and (of course!) keeping engineers happy and productive. We work towards these goals while managing technical debt, trading off “good enough” delivery time for future refactoring.
The impact of all this is that only a very small slice of my world fits into an issue tracker. Regardless, the vast majority of team conversations, both with developers and with executives, revolve around reviewing data and reports from JIRA. It’s telling that I have a scrum board permanently open in a browser tab.
JIRA’s larger-than-life presence in the CTO’s daily worldview makes it easy to think that a small slice of data represents the entirety of a development organization. However, not only is this view not comprehensive, but it can be misleading. It’s easy to forget that the map is not the territory.
Even holding myself to these mental reminders, it’s easy to get caught up in “feature focus.” We’ve had meetings where the entire executive team, an engineering manager, a UI expert, and four engineers are reviewing the backlog. Suddenly, I look up, and realize that we just spent 45 minutes discussing the finer points of button placement for a single JIRA ticket.
No one is awash in excess engineering resources. This is especially true in a startup like ours, where our customer and market demands far exceed our capacity. Every hour is precious, and time spent walking executives through implementation details is time lost on delivering code. Followers of the Agile Manifesto will recognize this as “servicing the wrong priorities.”
When I consider these types of challenges, my Computer Science training takes over and I view the organization through the lens of software design principles. In software, we have the concept of “separation of concerns,” where we strive to encapsulate code and data behind a well-defined interface.
Applying that here, I see that the executives want assurance that we’re making progress against our strategic goals. Customer facing staff need to know when features will be delivered in a functional state. Engineers, of course, want to know what to build and when to build it. JIRA works well for engineers, but it is hard to use it to track progress at the strategic level. It’s great for seeing the trees, but terrible if you’re interested in the forest.
This means that we need to focus the level of executive conversations to provide just the right level of detail while keeping us out of the weeds. (As a side note, when I was describing this to a peer, he described it as “minimizing the attack surface” during management briefings. Amusing perspective!)
JIRA gives us plenty of tools at a detailed level, but a huge selection of third party tools shows how it falls down on aggregation. Even with that, we still need to connect the features we build, not just to the technical strategy, but also to business goals. At Praxie, we’ve done this with what you might call an “extended” Kanban board (We use our own software, of course, but you could do this manually).
Under this model, we assign JIRA tickets to groups using labels, though you could also use epics. Those labels reflect all the tickets that are needed to realize an actual feature, like “Invite external users to a shared board.” Above that, we group these into strategic themes, like “Increase Virality.” Using this, I can show which features are in progress, in research, etc. I can also show how we’re doing on our strategic themes, making sure that we’re working on the right thing.
In our environment, we surround this central “work area” with cards that define our broader objectives. Together, this allows everyone to see the full context, ensuring that we’re all aligned. We see the corporate goals, we see the strategic themes, and we see the progression of high-level features. And, since we’re pulling data from JIRA, the engineering staff doesn’t have to change the way they work, and the CEO doesn’t need a JIRA account!
The beauty of this approach is that it allows me to have a high-level conversation with the CEO and CMO, where I talk about progress against the strategic themes, which is what they really want to know anyway. I can also show people when their favorite feature will arrive. At the same time, the conversation stays well out of the weeds, helping me save engineering hours for making software instead of sitting in meetings.
You can see this approach laid out in a sample board, which shows how a simple project fits into this model.
How do you approach this problem? If you don’t have a plan, we’re glad to show you how we do it in Praxie. If you’re happy with your process but are looking to upgrade your tools, we can help you with that, too! Feel free to reach out and share your stories with us.
As co-founder and Chief Technology Officer of Praxie, Michael Rothrock is a seasoned technology executive and entrepreneur with vast experience spanning both large enterprises and success
ful start-ups. With two decades of experience in large scale collaboration, mobility, and mission critical systems, Michael formerly served as Chief Platform Officer at MaxPlay. VP of Product and Services at ionGrid, building the company and leading it to a successful sale to NetApp. Earlier in his career, Michael held a series of positions with increasing responsibility at Interwise (acquired by AT&T), Orative (acquired by Cisco), and Portal Software (IPO).
