Why Managers Should Understand How Developers Work

As managers, we easily get frustrated with developers. Maybe they can't build a certain feature; or a bug fix you deemed critical to your business is too far down the backlog for comfort.

The reality is that we get frustrated with developers mostly because we don't understand their reality. The same is true for developers' lack of understanding of business — they get frustrated with us too.

I know this because I’ve filled both roles, in positions like data analyst and business analyst, and business positions like CEO, Founder, and Partner.

We’re all guilty of it to a certain degree. As managers, we project revenue well out into the future and envision a business model without considering the technical pieces.

This doesn’t mean we need to restrict ourselves; but it does underline the importance of adhering to a project scope and creating business-technical alignment.

That being said, there can be cases where the business scope supplied is unrealistic, or on the other hand, too shallow and not encompassing of a full user journey. This can result in scope creep and an over-budget, delayed product, or on the other hand, an insufficient product.

Sadly, a lot of companies aren't mature enough in their management approach to avoid these circumstances. Developer conversations are often stuffed with incomprehensible jargon that managers don't understand, resulting in misaligned deliverables. If one developer hardly understands another developer, how could they expect management to understand? Business decisions are also at times brought into the process when the developer work is done and it'd take immense effort to make requested changes.

To leap over this barrier may require us, as managers, to know a bit more about development.

This isn't to say that managers have to become technical wizards, but having a basic grasp of tech can make a huge difference in smoothing processes, helping teams build a superior product, and improving your work.

Understand Good Code

You hired your developers to code your product, so you want to know what good code looks like versus bad code. Generally, good code has a few things: Readability, organization, testing, and optimization.

Code is read more than it is written, so it should be clear to others, including with comments to describe the code. It should be organized in a logical, straightforward structure. It should be well-tested, with tests serving as executable specifications of the code.

Understand Debugging

A lot of times developers spend is on "debugging," not coding. If you don't know what this entails, you'd probably wonder why they're not spending time coding.

Debugging is identifying and removing errors from code, which usually involves using various debugging tools, understanding the code base, and understanding the product fully.

Understand Libraries

A lot of the code in your product won't be, and shouldn't be, from scratch. There's no point to "reinvent the wheel," and code libraries exist so your developers can use what's already out there.

Good libraries are open source (so their quality can be verified), licensed under an open license, mature, and have some "social proof" of being used by other projects.

Understand That Tech Is Always Changing

As a manager in tech, you probably know that the industry is moving extremely quickly, but keep in mind what the implications of this are for your developers. Because things move so fast, they'll spend time doing things like taking courses, continuing their education, reading blogs, and attending developer events to stay up-to-date.

Understand That Developers Solve Problems

Just as you're solving business problems, developers write code to solve problems. Sometimes, an attempt to solve a problem creates more problems, and some problems are harder than expected. Like in business, it's not always easy to forecast how many resources it would take to solve a problem, or if it could even be solved.

Understand Environments

From a non-technical perspective, you might imagine using your future product on your iPhone or Mac. However, the product needs to run in different environments, on machines with different resources, in different time-zones, on different screen orientations, and so on.

Depending on what you're building, your developers have to take all of these into consideration.

Understand Resiliency

The product being built isn't just solve X, Y, and Z, it's to solve X, Y, and Z while being resilient to bad inputs and bad interactions. A user should be able to use the product incorrectly without causing some major malfunction, and a hacker shouldn't be able to easily break in.