Reading Time: 9 minutes

“So, do you think we’ll be the only developers at this conference?”

My coworker and I had discussed this question before. As our rented Nissan Altima pounded out the 179 miles of lakeside highway that separates Chicago from Grand Rapids, it came up again.

We suspected that developers would represent the minority among product managers and designers. The 2015 Balanced Team Summit wouldn’t focus on technical talks, after all. Instead, it would take aim at a broader problem.

The problem: too often, products merely fulfill requirements, as opposed to actually solving problems.

The cause: unbalanced teams—teams that lack necessary skills and perspectives to fulfill the needs of a product’s users.

The solution: build and maintain more balanced teams—teams that have all of those skills and perspectives—and get those teams to work together effectively.

It turned out that we weren’t the only developers at this conference, and many companies sent quite a few.

In software development, it’s a problem that agile methodologies aim to solve. By having the product owners in the room with the developers, projects can make it easy for devs to ask questions about what the system needs to do. By having the product owners write stories, projects can capture those needs. It’s a step in the right direction.

However, agile methodologies do not solve the problem of a team lacking the skills and perspectives to build an effective solution. Agile methodologies do not enforce interviewing users before building the product. They do not enforce user testing. They do not enforce designer-developer pairing. Although these things do happen in the ideal case, reality sometimes looks different. It’s hard to convince an enterprise client to undertake a whole product development strategy that differs from what the company has done for decades. It’s fun to come to Grand Rapids and talk about how to bring in more designers, more market research experts, more A/B testing. But to do that presents logistical problems:

• That’s a lot of skills. Isn’t that a lot of people? How does a company consistently find, retain, and engage that many people?
• How do we deal with fluctuations in the product development cycle where one skill is needed more than another one at the beginning or at the end? Confession: before I became a developer, I consulted for companies on pain point research and content marketing. The first one of those involves interviewing users and figuring out which needs a product should fill. It occupies the lion’s share of the beginning of the product development cycle. Content marketing basically doesn’t happen at the beginning. It starts in the middle, and it continues through launch. If I could only do one of those things, I would not have had a role for part of the product development process. What does a team member do if their role only happens for one part of the cycle?
• What do we do when a client wants to ramp down design resources and add more developers in advance of building a system? We can talk amongst ourselves about all the skills that we need on the team, but clients with limited budgets may not agree with us. And also, on an agile team, we try to solve each problem at the latest possible time so we have the most possible information to inform our solution. So what happens when design problems get postponed until after the designer is off the project?

Those problems hint at a solution that many of the conference speakers and attendees discussed at length throughout the weekend: rather than build a balanced team by hiring a large group of single-skilled people, we can form a balanced team with balanced people, each of whom possesses multiple skills and perspectives.

Right now, the software industry in particular does not approach development teams this way. We have the idea of agile processes, but not so much agile people. Instead, folks have roles into which they become more and more deeply entrenched as their careers progress.

We have developers. We have designers. We have product people. Circles, squares, and triangles. And the longer we’re a circle, square, or triangle, the rounder (or squarer, or more triangular) we get. (Gracias a Chris Wilkinson for some drawings that used this shape reference to describe this problem).

At an agile shop, developers imagine themselves playing a more multidisciplinary role. In lieu of software architects who design the whole system up front, the developers make the architectural decisions along the way. In lieu of testing staff who write unit tests for the system, the developers write tests to drive out the code that gets written along the way. Instead of code reviews from managers or seniors, developers pair to review all the code along the way.

These steps make a lot of sense for the agile process, but for some reason they only extend to certain activities. For example, rather than expect developers to make sound UI design decisions along the way, we make jokes about how developers are bad at design and offload those decisions to designers. In fact, designers and developers don’t even pair very often: it’s usually devs with devs, designers with designers. Conversely, a staggering number of designers know, and aspire to know, zero HTML or CSS or javascript. Instead, they become accustomed to a workflow in which they hand over a mock. Rather than expect designers to employ technical skills along the way, we make jokes about mocks that, completely unbeknownst to the designer, take 17 times as long to implement as something only marginally different.

We make assumptions about software teams that exclude roles for balanced team members. The team at Philosophie captured some of those assumptions in a fun tabletop card game.

This game can be used to share the experience of working in a dev shop with the clients, or more generally to provide a brief and lighthearted look into what running a software shop is like.

Here are some of the cards in the game that represent employees you can have:

One of them has development skill points. The other one has design skill points.

Only two cards in the deck have both design and development skill points. These two people are called admins, and you can play them to have one or the other:

None of the cards in the game have both design and development skill points at the same time.

Is this a problem with the game? Nah, it’s pretty accurate to the way we’ve conditioned ourselves to think about certain skills in software.

Given that the agile methodology already tasks devs with some cross-disciplinary functionalities, it should be feasible—and, I would argue, preferable—to take this even further. We can ask software consultants in one role to learn some more of the other roles, and employ them all on a project.

Then we don’t have to worry about selling a client on one skill versus another. As a given skill becomes needed on the project that the client didn’t foresee, someone already staffed there can get things started. You don’t have one person on the project just to do X, and that person doesn’t end up on the beach when X is over. No one gets left out at any given step, because balanced team members can contribute skills that fall all along the product development cycle. Consultants like that would be unique and different in the software industry right now. They would be more flexible and would have more visibility into the impact that their project will have, and can have.

Do how do we find—or build—people like that?

Although the folks at the conference agreed that we should find and build people like that, the ‘how’ question did not get very thoroughly addressed. Perhaps that’s a future direction in which to take the conversation.

That said, I’d submit that many teams have already found people like that. This weekend in Grand Rapids, I met a developer who is writing a blog post about monads and who also speaks French, Spanish, Mandarin Chinese, and Chinook, among other languages. I met a consultant who helps companies innovate—and who started out with a CS degree.

Those are just two examples, but every single person there had something like this going on. I would hazard a guess that large portions of today’s software teams are already multiply skilled. The challenge isn’t to find someone different for the software team. Instead, we could tweak our understanding of the development process to encourage team members to use and sharpen the skills they already have that fall outside the roles on their business cards.