One comment he repeated several times was that parts of my text sounded "too conversational." I think meant that I didn't sound professional or academic enough.

You'd be better off asking for clarification instead of guessing at the meaning.

He also suggested revisions that increased the word count and complexity of the sentences without adding any additional meaning. I disagree with those comments and I don't like the suggested edits, and here's why:

You're exactly like me here. I also disagree with pointless elaboration.

However, that doesn't mean that there's never a reason to elaborate. You've been silent on why you were suggested to elaborate. Maybe the supervisor didn't tell you, maybe he did but you don't think it's relevant, maybe you subconsciously omitted that from the question, or maybe you intentionally omitted it.
I'm not here to judge; but it's impossible to review someone's feedback as meaningful if we don't know the problem the feedback is trying to point out.

There are reason to elaborate an explanation:

• Legal reasons
• Disambiguation that may not seem necessary to you, but may be helpful to people who aren't as knowledgeable about the subject matter.
• Rephrasing in order to avoid certain words which could be mistaken as keywords in a tangentially related subject matter (e.g. avoiding the word "class" in a C# educational application)

I get the feeling that you only presented part of the full picture.

I believe that sometimes (always?), simple language is best.

I agree with your intention, but not your statement. Not always. This is very dependent on who your target audience is.

• For laymen, simple is most often the best option.
• For experts, you should favor precision and disambiguation, even if that entails a higher complexity.
• For lawyers and legalese documentation, pedantic precision and utter disambiguation is the standard.

I also believe the impenetrable "academic" writing style of many scientists is a major shortcoming - it only hinders communication among scientists and isolates us from the public, who can't make sense of what we're trying to say.

I have yet to lay eyes on a single document that is written in a way that:

• The laymen find it clear and understandable
• The experts find it detailed enough to rely on it
• The lawyers find it disambiguated enough that there are no reasonable loopholes

If there were a writing standard that could fulfill all of these requirements, it would be the only writing standard that was in use since it has no drawbacks.

As a technical writer, you'll generally be writing documentation for experts. Experts generally don't see linguistic simplicity as the main priority. Therefore, simplicity should not be your main focus when writing.

The higher word counts, more complex sentence structures, and lack additional meaning in the revisions were a clear sign (to me, at least) that he was taking things in the wrong direction.

You're overgeneralizing. More often than not, reducing sentence complexity leads to a higher word count, and reducing the word count leads to increased sentence complexity.

If the supervisor were adding complexity and word count at the same time, his feedback would obviously not be good.

However, we come back to my earlier point that we're only hearing your side of the story. The level of detail and the (apparent) lack of common sense in the supervisor's feedback are not matching up. You are likely omitting a key part of the supervisor's side of the story (this may be unintentional, I'm not accusing you of anything).

I know there's room for subjectivity, but I honestly think the sentences I crafted are just better - and I don't want to trash them.

You tell us they're better, but you don't showcase your point. Since this issue very much hinges on whether the supervisor is correct or not; I'd say it's very relevant to include an actual example so that we can see if his feedback has merit.

If I were to defend my writing, I feel like I'd be calling his own writing skills and workplace authority into question.

Generally speaking, ask for them to explain the feedback instead of arguing why the feedback is wrong in your opinion. Asking for clarification shouldn't be interpreted as calling the other person's skills into question. If anything, asking for his explanation implies that he knows it better than you.

At the same time, I take pride in my writing and I want my published documents to reflect that.

Pride should not come at a cost to the company. If the supervisor's version is objectively more in line with the company's expectations, the supervisor's version should be picked. Regardless of whether your version was only marginally or notably worse.

I don't think we should just "go along with it" and let them sully our writing, especially if our own names will be on the published document.

With the exception of some egregious fringe cases, the customer (in this case the company) gets the product how they want it. If they stress that they want the word "computer" replaced with "puterbox" across the entire document, then that's their choice.

If the company makes demands that you personally cannot live with (e.g. ideological differences), then you can refuse the project; but this will of course have consequences. Depending on the company, this can be seen as insubordination and grounds for firing.

When you refuse a project, you should already have accepted the consequences of your refusal.

I'll start with something of a confession - I've been (and often still am) a supervisor who suggests changes to technical reports, instruction manuals and guides to functions which appear to have been written in a conversational style.

It's worth mentioning that there's a huge grey area between obscure and conversational language. In some cases it's as distinct as the formal "set the parameter" as opposed to the conversational "you should set the parameter" (in which case the formal approach is simpler), or using a passive rather than an active voice ("results were observed" instead of "we observed the results"). If your supervisor is suggesting something convoluted, it should be possible to remove that without becoming conversational.

But what this will really come down to is knowledge of the audience. It might be that your supervisor has knowledge of a house style, or the intended audience of the pilot study, which suggests the people reading the study (which may include people inside the organisation) might respond better to a more formal style.

If you believe the audience would respond better to a less formal style, this would be the line of argument that's likely to be the most effective. It's worth pitching this as a positive rather than concentrating on negatives in your supervisor's style - that's rarely a productive approach in a professional environment.

When I wrote user manuals and so on, for A Big Company, they had a corporate style guide for technical writing.

Part of it said to minimise the "reading age" or "grade level" of text: to maximise its readability. There was a tool, built-into the word processor software, to evaluate the text's complexity.

It preferred shorter sentences.

One reason it gave, to prefer simpler grammar, was that English might be a second language for many readers. And in fact, I was working in Italy. Even if text must use some technical words, it can be direct, and you can prefer simpler non-technical words.

In summary there are automated readability tests, which you might find persuasive or informative -- perhaps they're only approximate but they're independent, impersonal, objective, and cheap.

When a supervisor critiques your writing as "too conversational," they are usually referring to tone, voice, and structural formality rather than a lack of clarity. While your commitment to brevity and accessibility is a strength—especially in modern science communication—you must navigate this feedback carefully to maintain professional harmony. First, do not view this as a binary choice between "simple" and "impenetrable." There is a middle ground known as "formal precision." To bridge the gap, look for specific linguistic markers that might trigger the "conversational" label. Check for contractions (e.g., "don't" instead of "do not"), first-person pronouns (e.g., "we found" vs. "it was observed"), or subjective adjectives (e.g., "a huge increase" vs. "a significant increase"). If you eliminate these, you often satisfy the need for formality without adding unnecessary wordiness. To address the disagreement regarding word count and complexity, do not argue based on personal preference. Instead, frame your response around the report's intended audience and the goal of "functional clarity." You might say, "I used a direct style to ensure the results are immediately actionable for the stakeholders. However, I can incorporate more formal phrasing in the methodology section to align with our standard reporting style." Ultimately, remember that the supervisor holds the final accountability for the document. If their edits add complexity without meaning, try to find a compromise: adopt their formal terminology for key technical concepts, but retain your streamlined sentence structures for the explanation of results. This approach demonstrates that you value their standards while defending the core principle of effective technical communication.