6 things you need to know when working with developers.

I regularly find myself in situations where business people work together with developers on projects. This collaboration works much better than it did 10 years ago, for example. Nevertheless, there are always situations where tensions arise. In the majority of cases, this is simply because these business people know very little about software development and developers. Here are 6 points that you as a business person, such as a project manager or stakeholder, should bear in mind. And no, the list is not exhaustive.

This computer freak!

I often hear people in the business refer to developers as computer freaks and portray them as introverted eccentrics who develop and maintain strange algorithms and languages. A freak is not a nice thing. And the work isn’t weird or funny either. It is rather complex and abstract and not very easy to understand if you don’t look at it in detail. And that’s exactly what the vast majority of business people don’t do.

And: Just because someone is good at programming doesn’t mean that they are well versed in general everyday computer stuff. So if you ask your nephew who programs applications at Google at the Christmas party if he could have a quick look at “the problem” with your ancient Windows 95 computer, that’s about as presumptuous as asking an engine specialist to sweep out your garage. Don’t do it.

“That’s quite simple”

This saying is the ultimate proof that you probably don’t know that much about development. Provided, of course, that it really isn’t that simple. How often have I heard this sentence from customers over the last 10 years, for example. It usually goes hand in hand with an unwillingness to deal with the connections and details in the background. The customer is reduced to the visual and yes, it’s usually really quite simple à la: “The blue button has to go up and click to check the credit limit.” However, the fact that this requires data that may not even be available in their ERP system is a detail they don’t want to deal with.

Arguing about the “right” technology

If you ask 5 developers for their opinion on a technology, you usually get 7-10 answers. There is no such thing as the “right” technology and if there’s one thing I’ve learned, it’s that technologies are also a matter of taste and are subject to fashion trends. There are always frameworks that are currently in vogue and every developer focuses on different areas in their work. The stupidest thing you can do as a business person is to get involved in this discussion. Because you have no real knowledge of the different technologies, nor is this discussion something that will help you in general.

Dragging developers along to internal company political meetings

Another typical classic is to take developers along to these super important internal company meetings. For the vast majority of developers, especially the “radicalized” and good ones, these meetings are boring. For them, there is usually far too much “noise” in relation to the “signal”. And it can also be rather dangerous for you as a business person, because many developers, consciously or unconsciously, lack a certain sensitivity for the political and tactical. This sometimes leads to the unvarnished truth simply being put on the table in front of all senior executives. And this truth is sometimes not particularly pleasant in projects, for example. So don’t bother your developers with internal company stuff unless he or she explicitly requests to attend the meeting.

8 hours is not the same as 8 hours

Many business people believe that development work is targeted and straightforward. But that’s exactly what it doesn’t do: sometimes things have to be tried out. Sometimes you come to the conclusion that part of the code needs to be rewritten. The more complex the requirements for the application, the less straightforward the development process. Working as a developer is also exhausting. It requires a long attention span. This effort must be compensated for in order to maintain performance. I think these legends of people who have “coded through” 16 hours in a row are nonsense. It’s certainly possible, but it’s not productive, healthy and/or good for the quality of the code. So understand from a business perspective that development takes time, time to develop on the one hand. But also time to question and validate what already exists and what needs to be created. And time to relax in between.

“Now we need a very precise and reliable estimate”

The very precise estimate is, so to speak, the staircase joke of the digital industry. Surprisingly, not a month goes by that I don’t hear this from some corner. And I can understand this wish from customers, of course it would be nice to know exactly when something can be delivered and how much it will cost. Paradoxically, it’s usually those customers who can’t yet say exactly what they want in the product who want precise estimates.

I am happy to repeat it here on behalf of all developers in the world: there is no exact estimate. This is bad news for all fixed-price fanatics. But it’s actually nothing new, because even complex projects outside of software development can’t really be estimated accurately, as many prominent examples show.

The need for precise estimates leads developers to build in excessive safety margins to avoid overshooting later on. These inflated budgets then lead to overestimating the time available. A vicious circle.

It is much better to work with scenarios and approximate values. This is usually a from / to estimate that recognizes gradations that are linked to circumstances that are not yet completely clear. E.g. for “interface xy” we need between 20 and 40 person days. Approx. 20 PT if system a) already has an API, around 30 PT if system a) already has connectors or 40 PT if everything has to be developed. So do yourself and your developers a favor and don’t bother with the “exact estimate”.

This article originally appeared as part of my “Transformed!” column on t3n.