Why Developers Invent Problems, Support Agents Feel Like Janitors, and Marketers Think The Product is Lousy

10 minute read

There are some frequent problems in software development, that surprisingly share the same root problem. Some of those problems are:

• software developers get bored and start to “invent problems” rather than fix ones actually given them.
• Support agents can feel trapped in a dead/end position of perpetually cleaning up after developers mistakes (and as a result, have double the average turnover rate.)
• And marketers can find themselves promoting a product they have no say in, leading to a quick burnout.

If team members know nothing of the domain, motivation, and strengths of each other, there will be more conflict, waste, and inferior software. In this post, I’ll explore the benefits of developing software with not just cross-discipline teams, but cross-discipline individuals– that is, team members who are software developers, support agents, and marketers, all rolled up in one.

Different Roles, Different Priorities

To start, let’s take a deeper look at each role and what their natural motivation is.

Software Developers

They write the code for the software. Their top motivation is for the software quality– regardless of how much existing users like it or potential users request it. That’s because they don’t usually get to decide what features get included, they’re just told to build something and then build it.
They do, however, decide how it’s built (what frameworks and tools are used, how the code is organized, how efficient and secure it is), and ultimately how long it will take (despite whatever deadlines others try to impose).
They very rarely deal with actual users, nor the fallout from late delivery or bugs.
If they are focused solely on code quality, they are likely to embezzle their time endlessly restructuring to meet current “best practices”, rather than delivering working code. Ironically, “high quality” code doesn’t always mean “not buggy” code. Code can meet the latest “best practices”, just do the wrong things, and so be buggy.

Support Agents

They answer existing customers’ concerns. Their top motivation is to keep them happy, which primarily means having bug-free software– regardless of how messy the code is, or how few features get shipped. It’s ironic that the more features get added to software, and the more times it’s updated, the more bugs will be introduced in the process. This means supports agents’ jobs are easiest when no new features are added or code refactoring happens.
Support agents know best how a new feature will be received by existing users, and how upset they will be if things break.
Which is a difficult role to be in: they are basically janitors: cleaning up, and answering for, other peoples messes, and quite powerless to prevent them from being made.
At an extreme, they best know what customers need and have the least power to fulfill those needs.

Marketers

These are the people deciding what features go into the software to make it sell and then try to sell it. Their top motivation is to increase sales –regardless of code quality, or how many bugs get introduced in the process. That’s because they usually don’t know how the code works, much less how their requested features will mess it up, and they don’t deal with angry customers (unless they are helping with support, which I’ll be advocating later.)
Their time is primarily spent analyzing competitors features, market trends, and statistics (eg page views, conversions, sales). They may also be meeting and learning from other marketers (often owners), and possibly writing product announcements and tutorials, which will give them feedback about what features are most needed next.
If they are also considered the “product owner”, and not just an advertiser, they’re perceived as the ones in charge but they are powerless to make any changes themselves. At the extreme, they don’t care who gets ran over so long as they reach their desired destination.

In summary so far,

• developers want high quality code,
• support agents want to keep current users happy,
• marketers want increased sales.

Of course, we’d ideally like all of those: high quality, happy users, and increased sales. But those with experience know compromises are reality. If you narrowly focus on code quality, you’ll have fewer releases and impatient customers. If you keep current users perfectly happy, the code get riddled with patches and you miss acquiring new segments of customers. If you increase sales by releasing features too soon, developers know they’ve delivered junk and customers do too after they’ve used it for a week.

Often these different goals lead to conflict. And the winner of that conflict isn’t always the individual or team whose argument has the most merit (which is hard to measure, because each has totally different expertise and motivation.) Often the winner is the most obstinate. This is not a recipe for success.

The Benefits of Being Cross-Disciplined

Maybe your team mixes the roles I’ve described, then you’re probably on the track I’m advocating: it’s best for each worker to not only understand the others’ roles, but have experience fulfilling those other roles too.
Developers make good support agents because they know the underlying code that may be buggy, and so will be faster at finding solutions. Also, they have the power to permanently fix problems in the code.
Developers make good marketers because they know what features can be added very easily (“want to move that widget to the footer? That will take me 5 minutes, tops”) and which ones will require a complete overhaul of the system (“Wait, you want to perform the registration over the REST API? That will require duplicating logic in the web view, or extracting it into a business layer.”)
Support agents make good developers because they know real customers’ needs trump the often-theoretical benefits of changing code to meet “best practices,” and that sometimes a quick fix is better than an elegant, extended refactor that accomplishes the same thing.
Support agents make good marketers because they are most familiar with current users needs, and can judge when a new product will cause more problems (because of bugs and support requests) and so is actually best not even being planned in the first place.
Marketers make good developers because they are focused on delivering features in a timely manner that improves sales and the bottom line, rather than just impressing their developer buddies from other teams, or their own desire to make their code feel like poetry.
Marketers make good support agents because they are able to enact the changes needed in the product that will resolve users’ concerns, rather than just say “I’ve taken note of your request, we’ll make that improvement someday.”

In general, everyone better understands the requirements and priorities of others, which helps them better do their own job.

This is similar to how Steve Case, author of the Third Wave, argues the future of tech “requires a broader skill set” and “the engineering side of things will continue to be important… [but] having the perspective of some of those [non-tech] worlds is important.” He’s saying you can’t just focus on tech, you need to also know the domain and it’s needs. Similarly, I’m saying workers can’t just focus on their role, they need to think and understand the broader team.

Why do we divide into separate roles anyway?

Given the benefits of being cross-discipline team members, why does no one advocate for it? I don’t think I’ve ever seen a job description like “developer and support agent and marketer combined in one”. If the idea has merit, there should be some precedent.
Well, I haven’t seen it so explicit before, but I do see:

• One-person shops are exactly this: the same person designs the software, develops it, and supports it. (I’ve been experiencing exactly this with my recent WordPress plugin Print My Blog.)
• I’ve read of small teams taking turns doing support.
• Managers usually have previous experience doing the jobs of those whom they manage – managers who have never done the work of those they manage are rarely liked!

I think the separation of roles exists because it makes each individual’s position simpler: I do one thing, have one manual, and am replaceable. I don’t need to keep learning. And most importantly, I don’t have the breadth of knowledge the boss has, and so won’t know better than them, and they’ll be secure in their position. If everyone just knows their role in the assembly line, the boss’ position is uncontested,

Oppression and the Industrial Revolution

I think the major precedent for why we default to assigning individuals specific roles is the industrial revolution.

The industrial revolution was an epic development of western society that enabled a huge increase in output and production.

Society shifted from dependence on craftsmen and their guilds to large factories filled with low-skilled workers. That meant highly-trained labourers weren’t needed, and output was multiplied.

But the industrial revolution also had its downsides, which we usually neglect.

• It led to lower-quality goods because of that lower-skilled labour, and it circumvented the labour guilds that previously controlled quality.
• It’s benefit was reduced unless items were produced in vast quantities, requiring one-size-fits-all products.
• Because of the very high cost of establishing a factory, there were relatively few of them and so fewer competitors.
• It kept workers low-skill and low-wage by restricting them to only knowing a tiny part of the overall assembly process; they could only work in the assembly line, not make complete products themselves.
• The easily-replaceable workers and indispensable factory owners led to a much greater divide between the rich and the poor.

We don’t usually think of restricting individuals to roles as oppressing them. Many individuals are happy enough filling a single role, but I think there are similar consequences to those of the industrial revolution: lower quality, one-size-fits-none solutions, less competition, workers kept low-skill, and greater divide in profits.

So, What is to be Done?

This is all well-and-good, but how does one acquire cross-trained individuals on a team? You can’t have all employees doing whatever they want wherever they want, right? (Actually, GitHub did for years.) Yes, it can be difficult to figure out “who’s responsibility is that?” if everyone’s responsible for everything. But let me suggest one way to have a team of cross-discipline individuals…

Idea: Take Turns

When I got out of high school, I actually worked in a spice factory. Here’s what we did to avoid boredom, keep employees engaged, and give them a breadth of know-how: we took turns. One day you were mixing spices, the next day filling jars, and the next you were packing them.

The same could apply to developing software. Eg, if you have 3 employees, for a month one could be the assigned marketer, another one the developer, and the last could be the support agent. And at the end of the month, the marketer would take on development, the developer would take over support, and the support agent would take over marketing. You’d still know who’s responsibility a job is, just based on the calendar. Plus, everyone gets real-life experience doing each of the roles, and build a wealthy breadth of experience.

Imagine This

In January, you’re the marketer. You analyze current sales, watch competitors and the industry, do outbound marketing, content marketing, and handle pre-sales calls, and learn what potential customers need.  All the while, getting ideas and designing for the next big feature.

In February, you’ll be ready for the next stage: being the developer. You don’t have to wait for someone else to build that big feature you imagined in your head last month: you get to do it. You won’t have miscommunication about design or which features to prioritize, can’t complain the spec isn’t complete, and you won’t need to invent another problem to keep yourself amused: you have one month to make your great idea happen. Just adjust the scope to fit into your time frame, and aim to release a bit before month-end.

In March, guess who has the joy of supporting that new feature? You do. You’re going to hope you caught all the bugs before release, and had a design that actually bore users’ real needs in mind. You’ll see what parts they really liked (“oh cool, it’s faster”) and which parts they didn’t care about (“That’s great it’s all redesigned under the hood, but can I do anything new?”)

That’s the end of the cycle. In April you’ll again do marketing, having just had a month dealing with current customers and their actual needs. You’ll probably have a ton of ideas for content marketing and pain points your customers need addressed.

Notice how priorities kinda fit into place when you’re getting experience with the whole development process? Each stage benefits the next?

Objections?

Wouldn’t this lead to more miscommunications? It certainly requires creating a better paper trail and documentation, so the next person can pickup where you left off. That’s probably a feature, not a bug. If you’re writing a WordPress plugin, for example, making developer documentation so good that a traditional marketer understands it will surely be appreciated by customers trying to extend or modify it.

What if there is a steep learning curve to the role in your organization? I suppose that means the first few cycles won’t be very productive, but everyone will be learning a lot very quickly. An extreme example is a hospital with very different roles: doctors, janitors (and others, but let’s focus on these). This idea probably isn’t appropriate in that situation, but would have some major benefits still. For example, janitors would be better at properly sanitizing rooms if they had more knowledge of surgery. And believe it or not the inverse is true too: doctors would learn something by taking a turn cleaning up. That’s how penicillin was discovered!

Does taking turns in different roles make it hard to become an expert in one? Yes, you might not keep up with the latest trend in software development quite as well. But you’ll instead be focused on solving users’ real problems, so that again seems like a feature, not a bug. Besides, you could periodically take a longer cycle, eg spend 2 months doing development instead of 1, in order to more fully immerse yourself… just don’t forget to come back out afterwards and get a breath of air!

Oh, and what about teams larger than three? Have three small groups who cycle through the roles. Or what if you’re from a really big organisation? Yes you’ll probably need some adaption.

Ok ok, if you’re not sold on the above idea, you should at least look for ways to give your team members chances to experience the wider process. Have them take one day a week to fill another role, or once a month. Something. This would still give some very valuable experience and perspective to help everyone do their own jobs better. No, they might not need it to be happy. But they might need it to have properly aligned priorities and be really working toward the goals.

Won’t Employees Leave?

If you’ve given employees knowledge of how to market, develop, and support a product, won’t they leave and start their own? Maybe. Good for them. And you. Let me explain…

BaseCamp created “Know your Company” and 6 months after its launch, that product became a separate company. Far from being put out by this, Basecamp’s owners became advisors/shareholders of the new company (like being promoted from captain of a ship to admiral of a fleet). It sounds like it was a win-win situation.

If an employee leaves and starts a successful company because of what they learned at yours, they’ll probably talk glowingly of it to all their customers and partners, and themselves become a great partner. It could be great for your business.

But what if they defiantly become your competitor? Well, chances of that are reduced if they’ve felt appreciated and empowered by you, rather than oppressed and restricted.

What’s more, if employees feel like they have a real impact on your company (they’re not just another cog), and are able to unleash their full creative power on it, why would they want to leave? (And lastly, employee contracts with a non-compete clause fix this too!)

Besides, some of you must have already asked, “What would Jesus do?” He said

Henceforth I call you not servants; for the servant knoweth not what his lord doeth: but I have called you friends; for all things that I have heard of my Father I have made known unto you.

John 15:15

Jesus knew it was better to have friends, and share all the knowledge he could with them, rather than trying to restrict them to just being servants. I think a team of elevated friends is bound to be more effective than a team of suppressed servants.

The End Result

When developers are also support agents and marketers, everyone’s motivations are aligned. You don’t have developers perpetually improving the code in ways that don’t improve the bottom line while users languish in the support forums.
What I’m suggesting does present some difficulties. Valuing cross-training over specialization is a bit of a change in mindset. I suspect many will resist the change (alignment) in priorities. And it is clearly more work: you need to learn more aspects to what makes good software, rather than sticking to your domain of expertise.
The end result of having everyone equally cross-trained is cooperation instead of competition, aligned priorities, and a fair balance between code quality, new features, and customer satisfaction.

What do you think? Please let me know in the comments.

Cover Photo by Patrick Hendry from Unsplash.com

PS: In case anyone is wondering, my current employer, Event Espresso, is very good at listening to and empowering team members. These are thoughts that have been brewing in my head since before I started work with them 7 years ago, and are inspired by what I’ve seen in the wider software development world.