Ask HN: How to effectively communicate results of my work to non-engineers? | Hacker News Reader

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

139 pointsjacek77 comments

In the last job I have gotten a lot of autonomy. I have been the only full-time engineer in a small team. My task was to create a machine learning model ready for production and to design and start work on the product integrating the said model.

I have felt that the team trusts me to do the job and therefore I decided that my time will be used best by applying myself to the actual development. I neglected meetings that seemed unnecessary and reduced one-to-one communication.

I have set up tools to monitor my progress with the model (like tensorboard and sacred[1]), kept meticulous issue-tracking and a well-maintained repo on Gitlab. I also have been writing short semi-regular reports on the progress of the model (current issues, things to try and test, current metrics and suggestions for the development). It turned out, no one has ever reviewed any of the above and the team relied only on my summaries during short, semi-regular meetings. My ways of communicating turned out to be mostly inaccessible to people without engineering background!

As a result I was accused of slacking off and was deemed not worthy of any equity in the newly formed company [2]. I believe that my biggest mistake [3] was lack of proper communication of my progress and complexity I was dealing with. I was also unable to convey why some things take more time than expected during modelling or software development (like data processing, writing unit tests, etc.). Hence, my questions: How to effectively communicate the progress to non-engineer team members? How do I set reasonable expectations when the team expects development time to be closer to a hackathon project than a maintainable and certified product? How do you explain the complexity and gotchas of the work that needs to be done?

[1] https://github.com/IDSIA/sacred

[2] I resigned as a result (still working on the project until the end of the year). I am now transitioning to freelancing.

[3] There were other issues on both sides too of course, but not pertinent to my questions.

View on HN

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.

Book: Pitch Anything by Oren Klaff

Get the audiobook, tone of voice matters.

(Root cause of this dysfunction is the principle agent problem, you can't fix it, everyone tries, everyone fails, accept it and get on with the job.)

Can't upvote this enough. Especially heed the advice regarding words. Even technical peers do not appreciate walls of text.

this.

if we're in a recurring, scheduled meeting, i don't want to hear the story of your life.

The cyberpunk stealth/tactics game Invisible, Inc. describes executive terminals as large devices with simplified buttons. Or something along these lines.

This was solid advice. I've been wanting to move into the CTI space and I haven't come across too many tips that break down writing an effective executive summary.

1. Have a problem statement: What is wrong from a business perspective. Example: Password are unencrypted which dramatically increases risk of class-action lawsuits.

2. Have a list of corrective controls: Staff training, audits, technical controls

3. Cost statement: X control costs $Y.

4. Risk analysis: Problem reduced by 43%.

5. Summary statement: Execute this, it pays for itself.

Bear in mind an executive summary is either superficial or its a lie. You need to have a real technical report behind the executive summary so that it isn't a lie.

CTI?

Cyber Threat Intelligence!

There seem to be multiple issues here.

This seems like you were basically in the wrong role. As the only full-time engineer, you're more than just an engineer, you're basically the IT department. So when the other departments were represented at meetings and disputes were being raised, IT wasn't represented. You failed at basic office politics. Office politics gets a bad rep because lots of people play it to further themselves, but being able to play basic politics is required to make sure other departments don't give your department all the blame.

Also, because you weren't at the meetings you weren't able to understand what the business really needed. If you understood what the business really needed you would have been delivering that and people would have noticed. Instead, I suspect you focused on the technical tasks and created a very good technical product that fit the basic idea of what was needed but didn't deliver what is needed. In the future I would suggest looking into something like BDD, it basically follows the premise that business people don't even know what to ask for, so you have to work with them in meetings to discover what the true need is. And because you weren't really delivering what was needed as far as the other teams were concerned it most likely came across as they had no idea what you were doing therefore doing nothing at all.

Basically, meetings, they're important. I hate to put it this way but I feel it's the truth, it's the difference between a software developer and software engineer. And the difference between a senior and a lead. It seems to me you would be much better suited for a role in a team where the management track stuff was dealt with by other people. I personally dislike the management track work but I understand the importance and I avoided management track roles for years to focus on writing code and solving problems.

On point, but I'd like to add that business people also tend not to know what is hard (for you to do) and what is easy, so they will NOT ask you to do things which would be useful for them and easy for you, and instead ask for things which are the opposite of that. This means you have a harder time creating value for them. The better you understand their work, the more likely you can say "I could automate that, it would be pretty easy", when they have no idea that it is the case.

I can also echo this point. One of my favourite bits is telling business how much work each thing they need is and then letting them pick what they want next. I've been surprised when they picked things that didn't seem important but they could get it by the end of the week.

Exactly this is the way my colleague lead dev asks our business guys. "This takes 3 days of work and that is like a week, you know what is more important so you choose"

My dark take on that is it’s business people’s fault that they focus on party activities and asking me to mainly play those, while pretending with useless tasks as a side, especially if what engineers view as barbecue activities actually bring home the bacon using acidic-narconian logics from Gamma quadrant.

If you think you have better understanding for the challenges and know better than the party people at materializing it or cash it out for a larger sum, just downright steal that idea and start your own company. They’ll get mad if it works, that’s hypothetical.

If you don’t, just start gliding from day one and don’t feel guilty for it. Your responsibility extends absolutely no further than your paycheck goes, not a thousandths inch more. Don’t care where the money came from. There could be micro-guilts on you for micro-not being able to meet micro-expectations, but in return you’re not paid or given equities that your achievements would be worth in the term anyway, so it’s a fair game, a fair and stupid game.

Nicely said. The really important point here is that it's quite possible OP is right and did exactly the right stuff well but didn't communicate it well enough to stakeholders.

It's also possible that OP was not doing what the business needed -- or was not doing what the stakeholders/leadership thought the business needed. People can disagree on this, but in the end it's leadership's opinion that you'll get evaluated on. You can try to convince leadership only if you are in dialog with them.

So, how would you even tell the difference between whether you were doing what stakeholders prioritized but not communicating your successes well enough, or mistakenly not actually doing what was prioritized by stakeholders/leadership?

the solution to this is going to be related to the solution to communicating successes effectively.

And to be clear, this is actually a hard problem, you are not alone OP, I've been there. In the best case, as an engineer, my manager takes care of this for me, translating business priorities to my work and advertising my successes at implementing those priorities back out. But we seldom get a best-case manager.

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.

This is it right here. You can either expect all the people hearing your stuff to learn enough about engineering to understand your engineering statuses. Or you can learn enough about what the business values in your work to rephrase it that way instead. And hopefully you already understand the latter!

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.

Thank you for your reply. You might be right about that. I worked in academia before and I absolutely loved it. Maybe that's the style of work for me.

In my defense, I think that was a special case. This was a product to be certified as a medical device. Regulations require keeping records of all changes to the code that can be linked to well-defined "software requirements" and "stakeholder requirements". This can be done in a complex spreadsheet or by linking issues/merge requests in a certain way. I chose the issues. Also, as the product might affect health outcomes, I felt responsibility to make the product as solid and maintainable as possible.

> Regulations require keeping records

Who decided to be compliant at this stage of the company, you or whoever is in charge of business operations?

> I felt responsibility to make the product as solid and maintainable as possible

Was this responsibility conveyed to you or did you make this decision on your own?

I'm clearly making an assumption here, but this reads like a case where both sides had a misunderstanding about how engineering time is spend. They trusted you with some autonomy to get things off the ground and found out you are making business decisions on your own that don't fit into resource constrained startup operations. There is always a trade-off and corners can be cut, and my advice is to be upfront about the general approach about those and find out how much they are willing to invest in robustness and product quality at a certain stage.

>Who decided to be compliant at this stage of the company, you or whoever is in charge of business operations?

Medical regulations often pierce the corporate veil and create personal liability for the developer/whoever. He may not have had a choice. If you're asking your employees to commit crimes, expect high turnover.

> You might be right

> In my defense

Reading through your story and comments, this seems to be your main problem. Better communication might be helpful but you have to be more open to feedback and criticism. At the risk of sounding rude (not my goal) this post reads like a plea for validation. I don't know you and I hope I'm wrong, just going on what I see here.

A startup company to independently develop a medical product with a novel operating principle to be certified is a certifiable distinguished subgroup of complete morons. You don’t have to feel sorry for being misunderstood by those people.

Conversely, if I were an employee spending time on meticulous issue tracking that no one was reading, and I found out my boss was very upset about that, I would be questioning why my boss only realized what I was doing when it got to the point of upsetting them so much, and I may be a little upset about them wasting my time for so long.

Seems to me like OP had an absentee boss who ultimately threw them under the proverbial bus.

He's skipping company meetings and minimizing one on one communication, it doesn't sound like his boss is the absentee one

While I was in a single-person department, I used a Jira project where I put my tasks and commented clearly about progress. Then I realized that I was the only one using it. Neither my boss nor anybody else cared whether the information was in Jira, a spreadsheet, a Word doc, or if I just verbally explained what I had done.

So I stopped tracking things meticulously in Jira and only kept basic notes of what I had done. Worked out fine.

I'd give them a raise for being low maintenance & self managing.

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.

> NEVER tell that a particular task is "easy" of "fast" to do

This is sooo true, I cringe whenever I hear developers (or anyone) say this. Especially when it's clearly to curry favor with others. It's a disservice to themselves and our entire profession.

Too many things wrong here. Quick thoughts. Hope they help (non-exhaustive):

* This is generic human communications failure, not an engineer/non-engineer comms failure, i.e. you have incompatible communication styles. They like meetings, you like async reports. Do what is necessary to align this in future. Action item: "Hey, guys, I think I'm better able to express this in a report. I'll send you one every day/week/month". Alternative: "Hey, guys, I need continuous blocks of time to work. Can we schedule our sync at the beginning of my day".

* Explicit communication is superior to all else. Requesting ACKs is superior to all else. Action item: Set calendar event to 24 h after weekly report (send on Thursday or Monday), 2 h after daily report, subject: "Ask team if they read report, post abstract in team chat channel"

* Rapid feedback is key in early companies. The rest of your team may believe that the product does not deserve firming up (say the TAM is lower than projected, you're not getting traction, etc.). Assuming "maintainable and certified" may be misunderstanding objectives. Action item: Prioritize understanding where people stand. Default prioritize order: Make it work, make it right, make it good.

In any case, team failure is usually team failure not individual failure. Presumably your friends will provide validation of your self-worth so I have provided no indictment of the rest of your team. Still, it is expected of those with executive authority (your CEO) to communicate these things to you.

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.

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

Mine as well.

We forget that as programmers text and reading is a good chunk of what we do, so we project that onto others and act surprised when the way they look at the world differs from ours.

I've found it pays to 'speak their language', look at the world the way you think they'd see it from their perspective and then things are easier all around.

> 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.

The first answer that hits it on the head. It's nothing to do with your communication, you just didn't have the equity promise in writing and this is just an excuse.

The real reason to not give you equity is because they don't have to, so more for them.

Seems like a plausible real reason would be that he didn't even bother to attend team meetings. Making oneself indispensable among peers is kind of the obvious first step everywhere on the road to getting more equity.

If you care about having someone in a meeting, you specifically ask them to attend. They didn't care because he was never going to get equity in the first place.

It is painfully obvious from your message that you haven't ever been in an executive position. As an exec, you would ask that person to come for maybe the first two or three meetings, tops.

Then you acknowledge that said person is lazy, condescending or something else but definitely not a team player that's for sure. And you move on.

Then you attend a decision-making meeting where you are to recommend a handful of people to your exec peers for equity, raises, spinoffs or carveouts.

Guess whose name won't even come to your mind when assessing the company's rising stars ?

Edit: "I neglected meetings that seemed unnecessary" see that? That's condescension. Neglect. Laziness. No conspiracy needed when self-undoing is a certainty.

> It is painfully obvious from your message that you haven't ever been in an executive position

Oh, hang on, it's suddenly occurred to me that you're being so defensive because you're in a similar situation and hoping for the best?

No son, don't rely on "recommendations" or "positive meetings". If it's not in writing, it's worth nothing. Get it written down and fuck the "rising stars" bullshit. If it's worth anything, it's in the contract.

You can thank me later, kid.

Swing and a miss, I moved to freelancing a decade ago and never looked back.

Heh, is the defining characteristic of being in an executive position, that you consider meetings more important than your core product?

They were never going to get equity. Life is not fair.

No good company wants to lose or alienate a valuable contributor, especially not a valuable technical contributor. If they tried to screw him then he’s lucky to be out. And if he is assessing the situation correctly then he’s asking the right questions so he can grow in his career.

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.

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.

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.

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

This looks like a lot of useful information. Thank you, I will go through it all.

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.

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.

Are you the only "Engineer" or the only "Full-Time Engineer" (i.e. employee)?

First, neglecting meetings is a huge miss. If you believe they are unnecessary, it's your responsibility to explain why, and to provide a work-around to your other team-members so they can get what they need.

Second, your question about production ready vs hackathon is a classic tradeoff with startups. There was missmanaged expectations around creating a Minimum Viable Product, vs a production ready system. Somewhere your team and yourself did not have aligned understanding of what was being delivered.

Third, did you speak to your team about their perceived value of things like meticulous ticket tracking, well maintained rep, monitoring etc? Those things do matter in the long term, but reductively in the short term, unless your business is going to generate money from your issue tracking work et al, it's a waste of time.

Ultimately it comes down to your ability to make the case as to why the time spent on the work you did, ultimately impacted the business at it's current state.

From what you wrote, while you weren't slacking off, you spent a non-trivial amount of your time on things that were not of value to the business.

Did you have anyone on your team with startup development experience?

Imagine you had built a great software product, but never checked that your alleged users were actually using it. There would be a high chance that you built the wrong thing, they weren't using it, and you wouldn't know that so you wouldn't fix it.

Your reports on progress were like that. Because you didn't check with the users (those who should have been reading the report), you didn't know that they weren't a format that was useful to them.

I'm not saying you screwed up in the way you wrote your reports; communication about technical topics is hard, and no one should expect to make it easy. But writing technical reports, and then not checking with the intended audience as to whether they were communicating what you wanted, is like writing software without testing it or getting user feedback. I bet you would never write software, not test it, and then expect that it was working, no matter how good you are at writing software.

So, in the future, think of communications such as reports as a deliverable in some ways similar to a piece of software. Check with your users, and test it (i.e. see if anyone is reading it, or understanding it if they do).

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.

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!

If you are the only engineer on a small team then:

1) You shouldn't be writing reports. 2) You should be at the meetings and a part of the team. It should be possible to say to business people there are '3 main parts i.e. web/front end, business logic, and data store' - they will understand that - and then to simply give a rough idea of timelines and complexities for each one without going into too much detail. 3) Your peers should understand this, when a team is small they have to have at least some understanding of the system. It's likely they are just bad at what they do, possibly from being inexperienced themselves.

I'm going to gather that the entire things is probably full of obvious problems, which is almost universally the case for young companies managed by young people. It gets papered over when 'some thing in the corner is blowing up'.

FYI larger companies are also full of bad practices, but they generally have some kind of baseline professionalism and systems that help them get through their daily operations which are baked in, and printing them money.

Chalk it up to experience, learn from it, move on.

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.

There are a lot of great responses here with lots of detail. But the common theme is empathy.

As a guiding principle, think about what each team member needs and how they feel. Doing so would make the type of communication that would help them accomplish their goals very clear.

Imagine a car and a driver. Now imagine the car had no gas level gauge. Instead the car has two rules. 1. A driver can enter a destination distance and get a yes/no depending on gas levels, or 2. The car will give random updates of remaining range. Maybe this is reasonable from the perspective of the car designer; I mean how often does the gas state change, isn’t it micromanaging to get updates every second?

From the perspective of the driver though, how can they determine how far to go, when to stop to get gas, whether a detour is ok or will exceed range.

Empathy goes both ways. Imagine that checking the gas levels is computationally difficult and expensive. Imagine each measurement burns a gallon of gas? An empathetic driver would agree to less frequent readings.

So empathy all the things.

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.

I've found executives don't like to be told no. If they want something done in 3 months, but it will take 6 months, let them know some options such as: 1) Pulling resources off of another project to help 2) Taking on tech debt that will make future development slower 3) Scoping down the work

When given a task, I've explicitly asked which out of time, scope, and quality, is the most important to them.

Another important thing to keep in mind is that you get to choose the situation you are in. For future jobs it might be worth carefully evaluating who you will be reporting to and working with and their background. Even if they are not an engineer, have they worked with engineers before? Do they have realistic expectations around timelines? Do they have a level of understanding to at least talk at a high level about what you are working on? If the answer is no, it might not be the right job for you.

It's also worth understanding the working styles of the company you will join. I had previously been at a company with 100 engineers that focused on agile and used lightweight processes like tracking tasks on notecards in swimlanes on a physical wall. The next company I joined was over a thousand engineers and expected JIRA tickets for everything and writing large numbers of docs and getting sign offs from numerous people and departments before starting work. I know see that the first way of working is a better fit with my natural style, but you may fit in better with the second way.

For your situation, it sounds like the non-engineers had unrealistic expectations of what could be done with ML and how fast. Was there a discussion around timelines and you ended up going greatly over them? Or where you just going off to work and then they decided you weren't getting enough done.

I agree with everyone else who says that you have to understand your audience and tailor your message for what they care about.

When you live minute by minute in problem solving a very detailed, specific thing within a broader goal, you start to think that the detailed, specific thing is the outcome and is very important.

But it is not. To most people.

Most people are not knowledgeable about your specific problem or challenge. Most people don't care, or don't have the time to care. If they understood it all, they wouldn't be asking for a meeting.

What they need to know is not all the process and challenges you overcame, but the outcome. What did you achieve, what were you not able to achieve, what do you need to finish the problem?

If you cannot provide those level of answers (and quite early in the presentation), then people are going to get lost (or turn off) if they don't have the mental / time resources to understand the minute details of what you're trying to tell them.

Unless you're giving a purely technical talk, you need to think about the implications of your work, not just give a summary of it. Summary is condensing all the things you did, but staying at the same level of detail. Implications take additional work to think through.

Showing lines of code is not telling people the implications and conclusions of your work. It's showing them process. It's boring. Showing them tensorboards (unless something really interesting happened) is also not implications.

It takes work. You have to think through, and put yourself into the shoes of someone who has not followed your work at the detail level, and spoon feed them decisions they can make based on your findings, not your process. If you were presenting to the CEO for 5 minutes, would you be talking about your gradient descent optimization? No, you should be thinking, what does the CEO need to know to act on the information I'm providing? You need to do the thinking for the other person, and have thought through that yourself.

And just once again, please for the love of god, don't show lines of code.

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.

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.

Who is your manager? You can ask them for help with this, and they should have been helping you with this all along. But yes, doesn't mean they actually will or be good at it. But part of the solution is try getting help from your manager.

Goals

Participate in defining the goals of the company. Define your goals, that are derived from the goals of the company. Report on progress on achieving the defined goals.

Setting the goals will involve a lot of meetings.

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.

Is there any agreement in place that prevents you from completing the project independently and selling it to them later?

what problem did the model solve? eg, did it predict something, optimize?

I've found that communicating results of an ML model to non technical stakeholders is as simple as:

1) we are building the model to predict X 2) the model currently predicts X with Y% accuracy 3) I am doing X/Y/Z, eg feature engineering, to improve accuracy

Have a drink with them.

>How to effectively communicate the progress to non-engineer team members?

The TL;DR is use the confusion matrix output from the ML library you're using to demonstrate model accuracy, false positives, false negatives, and so on.

The long answer is much more complex: Are you doing MLE work? DE work? DS work? Why are you using ML? Is it required for your current project? You haven't stated what kind of work you're doing. How you present has to do with what kind of work you're doing, so a clear answer can not be given, only a generic one.

A data scientist, for example, typically has to sit in tons of meetings hearing the business challenges over and over again, finding a way to solve the business problems, and then building a model to demonstrate feasibility and then proof of concept. They then presentation this proof of concept to sales, marketing, management, the board, or whoever else it pertains to as a way to solve their problems in an automated fashion with such-en-such percent of accuracy using a confusion matrix. The business then ruminates on this and then often comes up with more requests or modifications to the initial model, or a request to improve accuracy, or they're satisfied. When the model is satisfactory it gets handed off to a software engineer (machine learning engineer, data engineer, infrastructure engineer) who then takes their ideals and developts it onto a server and gets it connected up so that the customers end up getting that service. The engineers built it / put it all together in the end. The data scientist researched it.

Your situation sounds like you were thrown into a data scientist role and are approaching it like a software engineer, which is not an ideal way to go about things. I could be wrong. It could be the other way where you shouldn't be using ML to solve the problem, or you're productionizing other people's models. If you're truly doing engineer work, then you can show that customers are getting the service you're providing, which is a different kind of presentation, typically just updating management, not having a large company wide thing. Maybe you're expected to be management? That's a different story too.

,,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.

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.

Why are you still working on the project?

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

It seems to me that they were looking for any excuse to cut OP out of any equity to keep more for themselves.

Or OP was doing busy work the whole time, making reports and filling forms no one was ever going to read. Why would you grant equity to someone whom you see skipping team meetings, to someone who doesn't bring actionable results and questions to their peers?

"Be active and useful in your work environment" is not even "office politics", it's just basic company life. Getting it brings you rewards, not getting it gets you fired or sidetracked.

I'm guessing: You didn't deliver tangible results and therefore were deemed useless. It was likely one "things are going well!" update after another, while still failing to deliver the most rudimentary of results that a low-level analyst armed with Excel and some basic SQL delivered.

Results that impact the bottom-line are the only thing that matters. If you cannot align your work to that, you're going to be undervalued and viewed as useless.

Reply on news.ycombinator.com