Introducing The Rest Of The Damn Owl

Software development has a dismal record of achievement when it comes to delivering what’s needed on time and on budget. After (mumbles) 20-something years in the business, I’ve seen my fair share of disastrous software development projects. I contributed to a lot of them.

During a career this long you get to work on all sorts of projects in all sorts of sectors - but there’s been one common factor in every disaster.

Communication failures.

Either the business people couldn’t communicate to the developers what they wanted; or the developers couldn’t explain the limitations and trade-offs of the technology. It’s neatly illustrated by the famous cartoon of the rope swing:

The business speaks a different language than the customer, and the engineering team speaks a different language than the business. End result: inability to deliver what’s needed on-spec, on-time, on-budget.

Good business obsess about understanding actual customer needs. Even if it’s something they’ll never use themselves, product managers spend countless hours trying to understand the context in which they’re dealing with their customers. They expend huge effort trying to talk to customers in their terms.

Just as the business shouldn’t expect the customer to change their language to suit the business, so we as engineers shouldn’t expect the business to change theirs.

The onus is on us to figure out a way of reliably communicating to the people who - bluntly - pay our wages.

Software is incredibly complex, and to try to manage that complexity we’ve developed conceptual frameworks to build pictures of the software which we as humans can work with. Relational databases, model-view-controller frameworks and REST APIs are all examples of using structures to map real-world complexity into consistent patterns.

Business has developed their own sets of models, frameworks and language just like tech has. If we developers understand these - and can use them to communicate - we stand a better chance of building that shared understanding which is needed to eliminate the communication problems at source.

This means that we as developers have to change the way we approach communicating with the business. We’ve got an an advantage, though - because our paradigms and frameworks change a lot faster, we’re used to change. In fact, you could say that picking up new frameworks is all in a day’s work for us.

Learning about the frameworks of business is what this is all about.

If you want to learn about software development though a formal process, then one route is an academic degree in computer science or software engineering. In the business world there are equivalents - but at a management level, the most established path is the Masters of Business Administration degree, or MBA.

An MBA is a post-graduate academic degree that’s awarded after successfully completing studies of various business-related topics - finance, marketing, the psychology of management and so on. Many of the most successful business leaders have gone through this study, and one of the arguments used by business schools to persuade you to part with the large sums of money these programmes cost is that these letters will turbo-charge your career.

(It’s not all positive, though - “MBA” is also sometimes shorthand for numbers-obsessed, heartless cost-cutting and short-term thinking, late-stage capitalism at its worst.)

Here’s the secret, though - at its heart, an MBA is no different to the things we do as software developers. They condense complex, multi-faceted concepts into models and frameworks that you can use to understand the world.

If you’re comfortable with the ideas of model-view-controller framework, you won’t have a problem understanding how to use the 4Ps framework to understand how marketing works. Just as relational databases build a picture of the data underlying a business, motivational psychology frameworks could help you understand why people behave the way they do.

Over the next weeks and months, I’m going to tear down the MBA into manageable and understandable parts that you can use as part of your daily work as a software developer.

I’ll give you the patterns and frameworks that you can use to understand how your business works. You’ll become familiar with the language that can help you better understand and communicate with your customer, the business.

Hopefully, you’ll be able to break down some of the communication blockers, and reduce the friction.

It’s all about building the swing right, first time.

Up next

In the next post, I’ll walk you through the 6 main topics that an MBA covers, why they’re relevant, and give you an early look at some of the models and concepts which we’ll be covering.

After that, we’ll dive into the content itself. To keep it as relevant and interesting as possible, I’m going to move around the topics - looking at the psychology of teams might be followed by a tool for calculating whether a company’s profits are sustainable or not.

That’s not usually how things are done on an MBA course - the study process is much more linear - but this series is about making the topics useful in the day-to-day.

I won't go full-on with references to the original academic research (“real” academic content sometimes feels like it’s more reference than original) but if you’re interested in digging deeper, these links might help you.