Ask HN: How to effectively communicate results of my work to non-engineers?

We built custom machine learning products for large enterprise for the last several years...So, communicating to people across with different skillsets and degrees and types of "technicality" was required to make things work.

I've written several replies here that address many things I consider important that might be useful to you[0][1][2]. These tackle communication, making sure people have access to information, tying business objectives to your activities and speaking a language that fits your audience (developers on the team, people on your team who may not be technical, people who are technical but may not be machine learning experts, CEO, advisors, investors, clients, domain experts at the client company, etc.)

These are all your "customers" to your communication product. You'll notice I went on and on about sharing meeting notes, or dispatching information to people so the message penetrates several levels and people know what they/you're doing and why.

>I am now transitioning to freelancing.

You might find a thread I tweeted[3] about this useful, too. It advises you about the benefits of dealing with enterprise as a company to make it worth your while, lawyers, building product[4], abstracting that product to expand and sell more. There's a lot of trial in there. The context is products for enterprise in the mid six figures that a couple of people could pull off by making sure they get the communication part with the client right, and other things.

- [0]: https://news.ycombinator.com/item?id=25025253

- [1]: https://news.ycombinator.com/item?id=25160534

- [2]: https://news.ycombinator.com/item?id=25176818

- [3]: https://twitter.com/jugurthahadjar/status/131066829330549965...

- [4]: https://news.ycombinator.com/item?id=25176818

Have you considered that maybe your work style is not suited to startups? It sounds like you are very methodical, which is great, but startups are default dead when they don't have a money generating product and scrappiness is needed to get something out the door. If I were your boss and I found out you were spending time on meticulous issue tracking that no one was reading, I would frankly be very upset.

Many companies aren't ready to succeed at ML until they have failed at least once. Leadership doesn't understand that building a good ML models takes more time and effort. It takes a failure of an ML project (and sometimes multiple failures) to break their preconceptions free and get them to understand how much effort it really takes. In a world where writing unit tests and refactoring are skipped to speed up execution, how many companies have the patience to build good validation infrastructure for an ML project?

There are a few ways to attack this, though all are tenuous. First, the ML project must be vital to the product. If it's not vital, then as soon as it starts slipping it will get cut. Second, you need to overcommunicate the level of difficulty and the amount of infrastructure necessary to get an ML model working. Third, it's extremely useful to have some authority and experience to point to. If you can confidently say "I have done this type of work before, and this is what it takes," you'll get much more acceptance of the longer timeline.

Of course, to keep support for your project, you needed to be better plugged in to the politics at the company. You needed more 1-to-1 communication with someone higher up, and to present your work more regularly to larger groups. It's not just to show them what's going on, but also to understand the current criticisms and the overall attitude towards your project. As with anything, if you were surprised by the result, then you weren't talking to (and listening to) enough people.

My experience is, written communication don't exist until I've mentioned a summary of it in a verbal communication.

Some people are not comfortable to express their annoyance until it crosses a point of no return. You have to proactively seek to bring out their disagreements, and resolve them.

Until you've experience in resolving a number of conflicts with the persons involved, to the extent you understand them on a personal level, you have not achieved trust. In that case, reducing verbal communication produces fuel to create an environment of mistrust and suspicion.

We got into a point where the work worth less than the meeting. The client loves talking and as long as he feels listened, everything is ok, we got the freedom, he gets the audience. I am planning to quit as it gets nowhere.

In my experience with non-techies they'd prefer you just to say "it's done" (assuming a reasonable timeframe) than go into detail on why it's not. Every new report is translated to "it's not done yet" with an excuse, which is probably why you were deemed a slacker.

Also in my own experience I can get carried away with the side tech -- spending a few days setting up a monitoring system and things like that -- is it really needed or are you scratching an itch? Small companies can't really spare the time to set up the enterprise-grade tooling if it's not one and done.

Maybe you are actually slacking, it took me a while to accept the reality myself anyway.

To directly answer your question: go to the meetings. Meetings are a way to reset your slacker status to "not a", no matter how boring or pointless they are or how accurate it is (it's why managers love them). They're also sometimes a decent way to share information with the team without relying on having written it up nicely if you get to talk before the snacks come out.

Of course this is just one guy's assumptions and opinions. They could just be jerks.

,,I was also unable to convey why some things take more time than expected during modelling or software development''

For a business it doesn't matter why you don't ship on time. I bet the team would have been happy if you ship something much simpler on time actually. DHH was writing about the philosophy, that features can be dropped/changed by communicating, but the timeline has to be hard in business.

In any project, you need some basic milestones/OKRS + something measurable, like a KPI. If the management layer around you did not structure their communication with you around these, that was their shortcoming perhaps.

You could certainly have compensated by putting these in place yourself, which would have shown some initiative and leadership.

For example, you could conceptually divide your project into various stages, with milestones in each, then communicate any road-blocks that prevented you moving to the next stage.

You could also create a KPI for your model (or a few KPIs), like a % success-rate for a classifier against some kind of benchmark data-set. Even non-technical people can understand "we're at 60% now, and we aim to get to 95% by the end of the project".

Ultimately, people do not care about the unusual edge-case or bug that you're dealing with - they care about the output. Perhaps structure your communication to focus on outputs, not the minutia of technical steps along the way.

Back a decade ago when I was doing cyber security work we would have to generate executive summaries of our reports. The only way for this to make any sense is to imagine the audience is an ADD 3 year old. Here were some of the factors that determined an executive summary:

* Very few words, and no jargon. Every statement is a meaningful fragment, like a subtitle.

* Colors, but not too many. Think of a pie chart.

* Numbers. Executives love numbers, but be careful. The numbers have to mean something that contains very few words and no jargon.

* Keep it short, because they don't care anyway. They are just concerned that something was wrong, something was done, and finally risk was reduced. All your words and fancy colors are quickly discarded so that a quick pass reassures them emotionally.

That is exactly how I would brief a business partner today unless I have full faith they are actively involved in the health of the product. It isn't that they are stupid, but that they don't care and you cannot make them care.

The real thing you're trying to fix is how I become a more valuable member of the firm and get paid more. I don't think you need more communication from you to everyone, you should be listening to what the boss really wants and checking if you're delivering.

Also communicating what salary you're expecting. Maybe you accepted the job at a salary and they thought you were happy with that.

The problem I see is that you need to have a feedback loop with your company on what the outcome of your effort is while keeping in mind what the company's expectations are.

If the company is trying to grow by pushing out a product ASAP, it's definitely not the right strategy to be taking the time to write the most correct, accessible, documented and maintainable code. That's the kind of time you need to be taking in tech debt for speed and pushing something that's mostly correct, brings in revenue and has tangible results. Iterative improvement is key as long as it's visible to the people who actually control it (your bosses/managers) and those who actually use it (customers).

Remember that when you start something new, the expectations are not high. It's a completely different thing if, for instance, you're Amazon and you're releasing the next managed software solution. That would be something like a core competency, be supported by several teams and to an extent already be expected to have certain results.

I have been successfully using screen flow recordings. Short videos. Some people still don't watch but it helps me avoid answering same question twice.

Have a drink with them.

As a general advice: Always communicate in terms of what the recipient cares about. If your recipient is a business person, you should communicate in business terms. No-one really cares what things you are trying out, issues you have et.c. - only the consequences for them / the business. It may seem like this is just two sides of the same coin (and it is) - but which side you approach it from makes a massive differences in the communication.

A startup cares about business traction, functionality that helps existing or getting new customers. So a status update should be on how one is now closer to (or unexpectedly further away from) that. Note also that in a startup vision of the product, usage scenarios, user groups and business model often tend to evolve over time. You must make sure that you are up to date with the latest learnings, and that your development plans are inline with these. If you don't make sure to do this, your work may be perceived as (and/or be) irrelevant to the company success.

Unfortunately, since you're the only engineer on the team, there was probably an unspoken assumption that you would also fill the role of an engineering manager who, in a bigger company or team, would not just drive progress from the engineers, but also communicate that progress back up to the non-technical members of the leadership team in terms of the "why does this matter" aspect of whatever tasks you or your team is completing. That is NOT an easy thing to learn, often it's trial-and-error feeling out what language and method of communication is best received by the other internal stakeholders in the company. My entirely anecdotal experience has been that, when you first start at a new position like this where you are expected to communicate tough concepts to folks with no training in those concepts, it's often best to go straight to the high-level strategies and goals of the company/CEO/CTO/etc. Take those desired outcomes and map your work to them, putting on paper exactly how your work will enable those goals and coming up with some initial thoughts on how to quantify your progress toward meeting those (sometimes admittedly unquantifiable) strategies. If you then report regularly on those metrics, that goes a long way toward explaining the "so-what" of the tasks you're doing.

Unfortunately the "Machine Learning" startup scenario is very grim in my opinion, everyone wants to jump on the wagon but 99% of entrepreneurs don't know what they are talking about, so the fault is not all in your lack of communication, in my opinion, some people just want too much and expect to get it for free or almost. The hard part is that in software engineering in general, more so in Machine Learning, the expectations by non technical people is always exaggerated. My advice is to always talk about dates and deadlines, it is all that most people care about, make always clear what you did to go from point A to point B, what effort it cost and what it generated in return. NEVER tell that a particular task is "easy" of "fast" to do, it will be your end. Always give the right importance to every one of your choices and your actions, obvioulsly do not allow anybody to take credit for, or to minimize the importance of your work.

Why are you still working on the project?

They obviously do not value you. Leave and take your info with you.

Understanding your audience is one of the most important parts of effective communication. If you are not spending time on finding out what various stakeholders in your organization want (in general... and out of you) and care about, you will not be able to effectively communicate with them.

Expressing what you want and care about, being open and vulnerable is also another part. They should feel like they know you and when you say something, they shouldn't have to guess where you are coming from.

This is easy to figure out if you spend time communicating with them. By ignoring meetings, you have missed out on those opportunities. Meetings are not completely unnecessary; wherever you got that impression from, you got it wrong. You have to figure out which meetings are important to you and which ones are not, obviously. But to know that, you have to be in enough of them. Some meetings present opportunities to know what is required of you and also communicate what you've been doing. You should never miss those. I highly suggest you read the book High Output Management by a former CEO of Intel to learn more about what meetings are... and a whole lot of other things.

Who was communicating to you this whole time? How did you figure out what was required? What were you going by? Whoever was doing that part is much more valuable than you. From the organization's point of view, they will not even notice that you are gone.

I suggest you learn these things and move on. Next time, if you want to work for a company, look for a company which is actually looking for someone like you and willing to compensate you fairly for your contributions.

> I have been the only full-time engineer in a small team

> As a result I was accused of slacking off and was deemed not worthy of any equity in the newly formed company

You've been screwed over, probably deliberately, if you were doing this work before the equity agreement was made.

I see stories like this a lot. It seems great to us when we can write down everything in the task tracker and skip the short meetings. It's always helpful when digging things up later on, identifying issue history and communicating with other people who are directly working on the issue with you.

But there are a lot of other people who have other full time jobs to do and they will not have time to dig through all of those meticulous notes, no matter how productive you're being. If you don't take the opportunities to communicate regularly, you become invisible to those same people.

When they make an assumption and a decision that you aren't working as hard because you're not reporting in, even if you have the documentation showing everything that you've been doing...at that point it's now become a confrontation. To convince those same people who's good graces matter that you are correct, you have to point out to them that they were wrong. That becomes a no win situation for you.

Excessive meetings are clearly bad, but meetings that are intentionally short are often done so out of respect for everyone's time. Attend them. Communicate. Brag on yourself. Talk about the interesting problems that you're solving. Communication reassures people of progress even if your natural inclination is to go into a hole and come out the other side with a finished product.

There's an old expression that summarizes all of that pretty cleanly.

"Out of sight, out of mind."

Been seen.

I'd consider taking a communication course or two at a community college or university.

And, perhaps joining some sort of group that requires communication-- Toastmasters is one well known one.

Communication is a skill in-and-of itself. Sales & Marketing work generally teach communication involving expressing the benefits of thing to a potentially interested party. If you're able, perhaps try to get into some sort of part time sales/marketing role, such as helping out at a farmers market booth on the weekend.

Also, check out some college communication textbooks. They have a plethora of interesting advice and strategies.

I'm advising top management for a large corporation and can stress what others here mentioned as well: communicate often, in simple terms, and in written form

Executives have a lot on their plate and usually work on a wide variety of topics at the same time. Therefore try to help them when they have to switch context

Concrete example:

* create a (bi)weekly status report with four sections (achievements last week, focus this week, current risks/impediments, decision needs)

* to every risk add a measure (don't admire the problem but bring a solution)

* to every decision need add the alternative(s) (usually something like "Option A", "Option B", "Option do nothing") and show the pros and cons

* show your vision and achievements. Every manager has another boss and will need marketing material to advertise what an important kind of work is going on. Show what you are working towards ("We want to use state of the art AI to improve drug development") and where you stand right now ("We have built the foundation by creating a structured training data set with records of more than 1 million drug trials")

* use abstraction to simplify (not "we switched our legacy adapter from SOAP to REST" but "we switched to a future-proof interface integration")

Regarding the meetings, cancel enough to show you are busy but participate in enough meetings to stay on people's minds

Concrete examples to improve meetings:

* ask for an agenda for each meeting and for your expected contribution

* keep meeting minutes, send them around if no one else does that

* everything that is dicussed should be related to actions that have been undertaken (status update) or will be undertaken (next steps). Every action has to be assigned to someone and has to have a due date

* I mentioned it before, focus on solutions not on admiring a problem (not "no one is providing the data we need" but "We currently lack the data. Who can we contact today to get access to the research data?")

While I don't know whether this would have helped you in the case you described, these are some general points for management communication that offer a good return of investment from my perspective.

Some good advice in this thread, but missing the most important thing: people & process.

(1) You need visibility. You don't seem to be plugged in - what were the CEO's goals? How did his exec team manage towards them, what orders were passed down, and how did you execute on them? If you don't know, it's because you weren't plugged in - for all you know, you _were_ irrelevant.

(2) How to get visibility? You need to set meetings: project kickoffs, 30-day SteerCos, quarterly updates, AND end-of-project readouts. Out of sight, out of mind. You need to get in front of people who matter, and explain the value of what you do in a way that they can claim credit to their boss.

(3) When you get in front of $important_people, you need to speak their language. Show them the money (your exec summary is always the same: I [made, saved] $X M in the past Y months, which is Z% of total revenue). Mark progress against a roadmap. Make pretty presentations they can forward to their boss. And talk slowly (not so they can understand, but so _you_ can avoid looking silly).

When you're a freelancer, the above is _more_ important, not less. I'm sorry you got screwed (if engineers have to be good at business management crap, WTF are business managers for?) but these are, I think, the skills you're looking for here.

A good book to read on this is The First 90 Days by Michael Watkins, if you're curious.

Several practical steps:

1. Take a thinking styles test, like the HBDI (https://en.m.wikipedia.org/wiki/Herrmann_Brain_Dominance_Ins...)

People in executive roles frequently tend "Yellow / Blue" in their thinking HBDI thinking style.

HBDI certainly isn't gospel, but it can help frame the people around you and make sure your communication includes thinking style elements they connect with.

2. One time each week, make a short, bulleted summary of what is happening in words that can be understood by anyone. I first saw this technique in a lab mate. He made them in powerpoint, kept them in a binder, and was ALWAYS ready to make an account.

3. Make peace that detailed documentation should be for your benefit, and occasional CYA. Even most technical people you report to will want a summary.

4. Many decisions in business are made by people that are able to operate on gut feel. Sometimes this is works well, sometimes it doesn't. However, the outcome is largely immaterial. This is because people who only direct when information is complete don't end up leading, either formally or informally.

Appealing to the "gut" sensitivities of the de facto leaders of your organization will almost always increase your visibility.

Hopefully this helps!

This is a common problem I've both experienced as a data scientist at a start up, and heard about from friends who work in data science/machine roles at larger companies. I'm both not surprised, but sorry to hear, this experience will result in you leaving your current position. That stress sucks!

I think there is a multifactor problem with building a work product that other people in the company don't fully appreciate, and without gaining full "buy-in" to take the risks and time investment needed for success.

Part of this problem is communication: you need to be your projects own advocate, and communicate clearly how "model performance is X" and for profitability under assumption Y, we need "performance of at least Z given ...". This could take substantial time, but someone needs to do it, and it's the only way to justify the time investment in your model as a necessary business expense. Model training is just not important, where the model is in terms of business application is the only thing you should be communicating to a small team.

The other problem, I've found, is that some teams are far less willing or able to understand that the technical challenges of machine learning/data science are not quite the same class of problem as software engineering, and the deliver/work cycle can be both slower and less determinant. People read this as you not getting stuff done (your fault). The best remedy I've found is just to deliver early and often, which is sounds like you've done.