Diagnosing Your Software Organization

Introduction

One of my favorite books on product management is Marty Cagan’s Inspired: How to Create Products Customers Love. Even though it was published back in 2008, the concepts it lays out about organizing software teams are timeless.

In it, Cagan talks about product management as the challenge of discovering a product that is valuable, usable, and feasible. It’s a great way to think about the role of a PM, but as a consultant, I’ve also found it’s a surprisingly powerful framework for diagnosing and fixing issues with software teams.

In my experience, a typical software organization is made up of three groups: the business, designers, and engineers. The specific roles these groups play and processes they follow vary from company to company, but what doesn’t change are the core strengths and concerns of people in each group. Business owners, designers, and engineers are all good at different things that are all necessary for creating great products.

What I soon realized is that the concerns of those three groups actually map directly to Cagan’s three aspects of winning products. Business owners focus on making sure the software is valuable to customers and the business. Designers care about the user experience and application flow that make the product usable. Engineers are constantly asking how the software will be built so that the execution is feasible.

Pattern of Success

So what does this say about what a highly functioning product team should look like in the ideal case?

The most successful product teams I’ve ever seen smoothly integrate members of all three groups in joint activities from the beginning of the project all the way through the end. These teams have engineers weighing in on the feasibility of product ideas. Designers on these teams are creating prototypes to validate usability and add clarity to discussions. During development, the business folks are managing backlogs and responding to technical feedback every day.

These teams succeed because all three groups and their respective concerns are being included and worked on throughout the process.

Diagnostic Framework

Teams that don’t successfully integrate business, design, and engineering tend to fail in very predictable ways based on how they separate the groups and their concerns.

Remember Conway’s Law? Loosely put, it says:

“Organizations are constrained to produce designs which are copies of the communication structures of these organizations”

By applying the transitive property to Conway’s Law (Thanks Mrs. Stein), it’s reasonable to assume that we can learn a lot about the teams and communication structures of an organization simply by looking at the designs they produce.

Patterns of Failure

As a consultant, I have to regularly walk into organizations, each with its own unique teams, skill sets, tools, and processes, and figure out where things can be improved as quickly as possible. Instead of getting caught up in budgets, timelines, head counts, velocity, infrastructure, etc, my first step is usually to look at the work products the team has created in the past and see what they tell me about the relationships and communication patterns that might be the root of the problem.

Using this framework, there are a few different patterns which have repeatedly come up. Here are some of the more common ones.

Waterfail

You see this pattern most often in large Enterprises where big projects are staffed with a multitude of specialist groups working in a serial waterfall. They have talented staff in the business, design, and engineering groups but the groups work independently and in sequence.

The business group makes decisions that fulfill their responsibility (valuable), without regard to the other groups and floats those decisions down stream to design. Those decisions, made in isolation, create immovable constraints that design now has to work around to achieve their responsibility (usable). With luck, Design will hack their way around those constraints and produce a compromised UX, adding more constraints to the stream and floating the dirty water down to engineering. Sitting at the end of the line, Engineering has the hardest time delivering on their responsibility of making the software feasible.

In the best case, this process slowly produces mediocre software with clunky UX at unnecessarily high cost. In the more common case, it just fails.

This problem is a little harder to spot than you might think. Most companies will categorically deny that they run waterfall and their PMP certified Agile coaches will swear up and down that they run an “agile process”. Unfortunately, in most organizations that just means that they stand up during their status meetings and call their BRD’s “stories”. One way to tell if an organization falls into this category of failure is to look for the following signs in their products:

1. UX Hacks - The UI might be sleek and beautiful, but the business constraints caused the UX to suffer. Look for excessive text explanations and warning messages designers put in place as a hedge against interactions they don’t believe in. Maybe spot some complex interactions stuffed into a modal because an important use case was added to the specs too late.
2. Poor App Performance - Slow page loads, multiple login redirects, processor intensive rendering, etc. are a good sign feasibility was considered last.
3. Antiquated Tech - Out of date frameworks and architectures that suggest insufficient time is given to technical planning.
4. Broken Windows - Because no one group really takes ownership over the finished product, “Not my job” syndrome runs rampant. You may find obvious errors, easily fixable UX problems, and phoned in copy.

Media Company Fail

Some organizations are run by business / marketing people who really care about visual appeal and user experience. You see this a lot in media or marketing companies. The business owners work closely with designers to create flashy and unique websites and applications. Unfortunately, engineering is an afterthought and feasibility suffers. The first time the dev team sees the work it’s only 2 weeks before the scheduled launch, and the designs can’t be implemented without serious compromises. Some signs to look for:

1. Immersive UI - Give designers power and they’ll create amazing and unique things. Sometimes that’s not for the better. Full page experiences and excessive animations are usually a good sign the design team has cozied up too closely to business without being checked by engineering.
2. Poor Mobile support - Design and business folks sometimes fall in love with designs as presented on a 27’’ thunderbolt display, and pay less attention to mobile cases. Often times, the design looks ok on mobile, but the mobile-friendliness is only skin deep, with large payloads unfit for 3G connections and non-mobile friendly UX interactions.
3. Poor Performance - Again, slow page loads and processor intensive rendering are a tell tale sign that feasibility was overlooked.
4. Flashy colors - Sometimes strong colors look great in mockups, but garish in implementation. When engineering is left out there’s little time to discover and adjust for these mistakes.

Technical Co-founder Fail

Some companies are run by a combination of business and tech teams. These are the kind guys that keep two copies of “The Lean Startup” on their desks - one for them, and one for anyone who happens to talk to them that day. They understand their app’s value and have the development chops to get code into production quickly. Unfortunately, it’s their lack of attention to design and UX that leads them to fail fast and fail often. Some signs to look for:

1. Bootstrap UI - Their site looks like every other bootstrap site ever created. It’s “good enough for now” and they plan on “doing some UX” later.
2. Complex Interactions - It’s too easy for strong business and technical teams to assume that their users are just like them. They end up prioritizing advanced user features higher than they should and provide little guidance for beginners.
3. Spreadsheet UI - Business oriented managers design interfaces that resemble the tools they use. They LOVE Excel, and there is no one to explain that the interface doesn’t translate to other platforms.
4. No Mobile Support - Business and Tech design and develop on desktop form factors and don’t do a great job empathizing with users’ needs and flows. This leads to a “mobile as a feature” or “Mobile Next” mentality.

Conclusion

These are just a few patterns of organizational dysfunction I’ve seen and their tell-tale signs. There are a few more variations, but they all stem from the same root cause: A lack of open collaboration between the business, design, and engineering teams that ensure products are valuable, usable and feasible (Thanks Marty).

I think it’s safe to say that most technical problems are actually people problems in disguise. The most successful organizations are going to be those that can evolve their processes and relationships to build the trust, transparency, and cooperation necessary for creating great products. These ideas aren’t new or unique. As a matter of fact they were the basis of real Agile software development in 1999, but they’ve proven surprisingly elusive for most organizations to implement.

As a diagnostic tool, this framework has been extremely useful for me to learn about the possible problems with our clients’ processes. If you’re still skeptical or want to learn more, send me a link to your team’s work product and let us guess how you might be organized!