“If it didn’t ship to Prod, it didn’t happen.”

We’ve been seeing patterns in our projects where our software development team is struggling to have an impact. They are busier than ever, but never feel like they are accomplishing anything of value. They are making recommendations and changes but are only able to affect their small team within a much larger organization. After several projects where this pattern repeated, I started looking for ways to address these issues and influence a broader group of people. I discovered two ideas that are gaining momentum within the DevOps community.

The concepts of “outcomes over outputs” and “project to product” capture these feelings we’re having. Too often we find ourselves inside projects that are solely focused on how many tickets (output) we can complete from the backlog. The team has no idea where the tickets came from or any understanding how they will benefit the user (outcomes).

Furthermore, these projects are created and funded by certain decision makers. They need to create work for their teams to do and track how much those activities cost. These projects will have a defined start and end, with a total budget. Once the project is complete, the team moves on to the next project without considering whether everything was completed or if it will need ongoing maintenance (which we can pass off to a new team that doesn’t have any context).

However, if we shift that mindset from project to product, the teams would be created and aligned to a particular value to the user. That team would exist to know their user, continuously update their product in the user’s best interest, and be measured on how much value they are providing. This team should be cross-functional and have everything they need to go from idea to production within the team.

As I talked to other folks at 8th Light, common stories emerged. Our teams were isolated from the larger organization, and the people that were supposed to be working together could not break the systems that kept them apart. I started thinking about how to break this cycle and what we could do to rethink the way software development happens.

Then I heard about the Prodacity Symposium by Rise 8. I knew I needed to attend and meet others who were investigating these same concepts. I felt like I discovered a new club; a secret society where people were actually changing the world (or at least several minds).

The conference was oriented towards government software teams, but these problems are not just for the government. Besides, I’d spent the last few years on a government project and would have no problem fitting in. Over the course of two days, we rethought everything. From hacking the bureaucracy to delivering continuous value to end users.

The Stakes

Although these ideas may seem like current buzzwords, they could not be more important. The event kicked off with a sobering realization from Josh Marcuse and Bryon Kroger:

“The stakes could not be higher. If the United States government cannot get this right, we may lose our place in the world.”

We are significantly behind in terms of software competency. We’re not leveraging the data we collect (or even collecting it at all). We’re busy fighting against the commercial tools that could actually help us quickly improve things. Our applications are significantly out of date or just not useful to their intended users. And, the rest of the world has already moved on to advanced machine learning and artificial intelligence. We’re moving at a rate of change similar to airplanes instead of microprocessors: one every 20 years instead of one every 4.38 GHz.

So maybe we shouldn’t expect billions of changes a second, but the best companies in the world are able to change their software thousands of times a day. What have they figured out that the rest of us could learn from? How might we adjust our mindset such that we’re not just saying we’re “agile,” but actually delivering value continuously? How do we ensure that our companies and products also don’t become obsolete?

The People

If the mission is to increase the rate of value for the users of our products, we can’t just talk about improving the software engineering team. We need to expand our scope to cover every person within the software development life cycle. We must think about the coordination necessary from problem to solution to production. When you think about that, you start to realize the costs of that coordination and the toll it takes on your teams.

As the keynote speaker, Gene Kim shared his current work around the costs of collaboration. His new thesis revolves around this idea:

“People spend too much time, energy, and effort connecting with whom they need to communicate and collaborate — often requiring searching for the scores of teams we are dependent upon, and then the difficult part of convincing, cajoling, re-prioritizing, deconflicting, escalating, and politicking to get what we need, often to no avail.” Source

Balance the Team

In her new book, Farther, Faster, and Far Less Drama, Janice Fraser outlines an idea she’s calling “leverage the brains.” Our organizations have many smart people. They are really good at what they do, and we tend to block them off from the rest of the world or don’t give them decision-making authority. For instance, we place a product owner in the middle to act as a gatekeeper between the development team and everyone else. The developers can’t talk to the actual users, and the product owners spend all their time fielding questions and relaying information.

If we could break down those walls, we could put product, design, and development together as a core team. They all get an equal seat at the table and work toward the same outcome. We take away a point of information handoff, saving time and preventing information from being filtered (accidentally or purposely). Then we let that team actually ship features to users, learn from fast feedback, and iterate.

Balancing teams can be difficult from the inside, however. Oftentimes, the organization is structured such that specialties are siloed for specific reporting or hierarchy or legacy purposes. The individuals don’t feel like they are “supposed” to talk to or join other departments or can’t make that decision. As leaders, we need to recognize this tension and work to remove barriers.

Organize for Success

Over the past several years, I’ve been doing more project management and less project delivery. One of the greatest realizations is that I cannot directly affect a specific task anymore, but rather have to influence and enable others to accomplish those tasks. I can only imagine that this disconnect increases the higher one rises within an organization. Once towards the top of the management hierarchy, there are fewer levers to pull to accomplish things. However, there are two specific areas that leadership can directly affect.

Admiral (Retired) John Richardson and Lt. Col Max Reele did some work in this area and discovered that team organization revolves around a team’s proximity to its users and how many lines of authority exist. If a team is close to its users, it can easily see what the problems are. They have high visibility into the best things to do next. If a team is not close to its users, all of those reports are second or third-hand and are heavily filtered by the time they reach the team. Without this context, the team is left to draw their own conclusions. We want them to make informed decisions using their expertise but aren’t giving them access to the right information.

But just seeing the problem isn’t enough. If a team needs to get an authority (or in most cases, several authorities) to sign off on an idea, that process significantly slows the whole operation. The more people a team needs to interact with, the longer things will take (see cost of complexity). And the longer things take, the slower a team learns the right thing to do and the more frustrated they get with everything.

A team that is close to its users and has the ownership to make decisions is a team that has the opportunity to be successful. Now they can get into a state of flow, optimize their processes, and continuously ship to production. As leaders, we need to recognize when barriers are preventing this level of collaboration and trust our teams to make the right decisions for the product.

The Five Ideals

Now that we have the right people on the team, and the right organizational structure to empower the team, it’s up to the team to create an environment for good work to happen. Building on his work from the Unicorn Project, Gene Kim articulates the best areas to focus on with the five ideals. These are the markers of a high-performing team and are an excellent starting point for establishing baseline team dynamics.

• Locality & Simplicity: Can the team make decisions and work within their scope without impacting or relying on other teams?
• Focus, Flow, & Joy: Do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? Does our work bring us joy or are we bored waiting on others in the system?
• Improvement of Daily Work: Are we consistently paying down technical debt and removing obstacles to productivity? Is anyone focused on making our tools fun to use?
• Psychological Safety: Does everyone on the team feel safe to talk openly about problems so they can be solved (or even prevented in the first place)?
• Customer Focus: Is everyone working toward a common goal of improving the value for customers?

A happy team does better work than an unhappy team. When folks feel like they have autonomy over the way they work and are making progress toward a shared goal every day, they get into a state of flow and everything seems to click. They are more motivated to solve problems and become energized with their work. I’d love to be part of this team, and I’m certain others would as well.

The Systems

Now that we’ve reorganized and reoriented the people, we need to take a look at how they do their work within the systems that are in place. No matter how high-performing the team is, if they are stuck inside a toxic system they will quickly become low-performing and highly frustrated.

Hack Bureaucracy

The organizations we’ve built are often created over long periods of time. They develop cultures, norms, and processes that become disconnected from their original mission. There may even be good reasons why rules are in place, but for people working within those systems, it can be difficult to see a path forward.

Fortunately, there are usually people who understand how the system works. In their new book, Hack Your Bureaucracy, Marina Nitze and Nick Sinai outline the strategies for how to get big things done from any role in the system. They developed many different ways (56 in fact) to approach the problem.

Most systems will push back strongly to brute force attacks. But if we find the cracks and understand where the system breaks down, we can start to inch our way closer to a better future. It can sometimes feel like pushing a rock up a hill, but having perseverance and thinking differently will pay off in the end.

Make Work Visible

Many of us probably have some sort of work tracking system (i.e. JIRA, Trello, Asana, etc.). Many of us also probably dislike something about that system. When was the last time we rethought how that system should work? Is it giving us the information we need and are we using it to help us?

In her book Making Work Visible, Dominica DeGrandis showcases the true potential of a work tracking system. She highlights the 5 “time thieves”: too much work-in-progress (WIP), unknown dependencies, unplanned work, neglected work and conflicting priorities. I think we can all relate to these. We have a project board that shows the list of tasks we’re supposed to be working on, but it never reflects the hidden work that we actually spend all of our time on. Managers use them to see who’s working on what at a glance, and incorrectly talk about optimizing for 100% utilization, but never make the connection that these practices are antithetical to the way people work.

By making all of the work visible, teams can begin to highlight the areas that suck our time. We should be honest about what we’re actually doing and able to have conversations about realistic solutions (see psychological safety). The whole organization can understand the various constraints and see exactly why projects break down and don’t ship on time.

By measuring all the tasks in progress and properly categorizing the work effort, we can rebalance our efforts toward the things that matter. Are you spending the right amount of time on paying down tech debt, working on developer productivity, and fixing bugs for users? Or is the bulk of work on new feature development that’s always behind? Is everyone at 100% utilization thus leaving no slack in the system for unplanned activities? Rethinking our tracking tools can immediately help team flow and increase happiness. It could even provide more value to our users with a better product.

Cloud Native Patterns

With our bureaucracy hacked and our work tracking under control, the last bit to consider is the system that our products live within. For those of us working on digital products, the cloud has completely changed everything. We no longer need to think about physical servers or late-night security patches. We can deploy at any time and our products can be continuously improved. It’s now faster to fix forward rather than roll back when an issue occurs.

To gain the benefits of this new world, we need to consider new patterns and platforms. In Cloud Native Patterns, Cornelia Davis discusses how the cloud has changed software development and what we can do to make that system work for us. Are our applications sufficiently decoupled with the boundaries in all the right places? Do we properly handle service outages and failover gracefully? Understanding the system where our products live, and what new benefits come with those systems, can greatly improve our products and ultimately deliver value for our businesses and customers.

The Call To Action

The world we live in today is moving faster than ever. Change is happening at an unbelievable pace. The companies and countries that have adapted to that pace are starting to pull away from the ones that haven’t. The gap is starting to be noticeable and it’s about time we stopped to consider where we fit in this new world. Are our organizations and teams still organized to deliver value once every 20 years? Are our systems capable of adapting to continuous input and output?

It’s time we shifted our teams to thinking about products instead of projects; outcomes instead of outputs. This will not be easy. In his talk, Paul Gaffney summed it up well: It will take honesty to admit there’s a problem. It will take alignment from everyone across the entire organization. It will take clear goals, standards, and processes so our teams feel safe to do their best work. It will take transparency to work out in the open, for all to see. It will take rethinking all of the systems to ensure they are working together to deliver the best outcomes. It will take perseverance to keep pushing uphill, everyday.

Walking away from Prodacity, I was inspired to not only capture the ideas shared at the conference, but articulate some of my and my colleagues at 8th Light’s experiences and aspirations. We are seeing these patterns on many of our projects and now have the clarity to know how to help. This is just the beginning of the conversation. If you think your company or team could benefit from a shift in mindset, let’s talk about how we can help!