I would recommend reading the chapter "The Dignified Professor" from the book Surely you're joking mr. Feynman. [1]

Richard Feynman was one of the best physicists from the 20th century. He helped creating the atomic bomb, and he worked on quantum electrodynamics. He received the Nobel prize in Physics in 1965 for his work on quantum electrodynamics.

When he worked at Cornell he suffered from a (small) burn out. He did his teaching duties, but, for his standards, produced very little more than that. He was worried that others would be disappointing in him, as it was impossible for him to live up to the expectations of others. This is were he developed an interesting idea: "You have no responsibility to live up to what other people think you ought to accomplish. You have no responsibility to be like they expect you to be. It's their mistake, not your failing." [2]

If this task doesn't have measurable outcomes, or if you have nothing to report, than so be it. You tell that you have nothing to report. The company hired you to do this task, and they took a risk by putting you on this task. If you have nothing to report, than it's their responsibility to do something with that. Not yours. If they want to know why you have nothing to report, they will probably ask you to explain why you have nothing to report.

Footnotes:

[1] - Actually, I recommend reading the whole book. It's very funny and interesting at the same time.

[2] - Page 199, changed "I" into "You".

That can be tricky. You should consider writing specifications for your work/role that:

- Are labeled with the name of the task: R&D; Solving Scaling

- Indicate what's improving over time and what the general workflow involves

- Show how you personally track that progress in a log or other methods

- Help you demonstrate that you are qualitatively improving the situation

(- Over time: Develop into some helpful metrics you can measure, as you make observations about these systems)

In such cases it usually helps to give reports in a linear narrative format. Other reports, e.g. quantitative reports on qualitative work, probably won't do your work justice for now. But that just means you use a different lens to examine or present the work.

If it's nothing of note, at the bare minimum it should be presented contextually as an organized part of a broader/longer narrative (even if you need to summarize the narrative).

Good luck.

One idea is maybe breaking down a big problem into smaller ones. If there are a few possible avenues to attempt for an RnD project maybe try one or a couple of them at a time - if they don't work then you can mention what happened and that you'll be moving on to try other options.

Probably a lot of this depends on the organization and how work items are tracked. Best of luck, i'm of the impression nobody really likes update meetings

Do something of note, something that wows, and you will be excited for the meeting. If there is something else that needed to be done, explain why it was important for it to be done. If there are too many meetings in a row where you don't feel there's much to report, it could be an opportunity to reflect on goals / prioritization.

“Do something of note, something that wows”

This is literally ignoring the setup for the problem that OP gave you.

Putting more pressure on themselves sounds very counterproductive.

Solving scaling issues is solving a problem. You’ve allowed the company to increase revenue by adding users. You can brief “increased capacity by X%” as an accomplishment.

You can also agree on service level metrics with your manager and then status those metrics. Things like uptime, time to recover.

> how do you update that you did a thing

Your second question is a little vague. Can you give us an example of “a thing”?

Being intentionally vague but with R&D you might not know exactly how to deliver the end goal, you're experimentally stabbing in the dark hoping to find something that works, or works well enough that you can take another step into the dark. Might need to retract and try something completely different but it's not a given that you have achieved anything substantial that won't be thrown out today or in a month.

That's what you could report in your status meetings. I tried X, but it failed because Y. Then I installed Z and tried doing X again and then this happened.

As a team lead, I'd be more interested in hearing what you're thought process has been and what you've tried rather than just hearing about the final outcomes.

I used to work with a very senior engineer who is now retired who had a job which involved VERY LITTLE OR NO WORK.

This may or may not be your situation. He was one of the happiest people I have ever met.

I think you are feeling the default urge to look and feel productive all the time. I know exactly the feeling. It often looks bad and feels bad not to be hyper coding all the time.

The reality is that you may be, many many times, running some system which is mostly complete and your job is more of an insurance policy against the ultra bad things that happen if that system goes down.

And hyper coding is simply not required. And dealing with the psychological and social effects of knowing you are running at 10% capacity is overwhelming and hard to deal with.

It may be the case that this system may realistically involve very little work. Bug fixes and code enhancements. And that is actually fine as far as everyone around you is concerned, they may not even care. At all. As long as that system runs and you seem to be working.

So back to my friend who is now retired.

He had this down to a science. He focused on organizing discussions. So he would ask you to come to a meeting and ask you about some small detail of whatever he is doing. Then he would go: “wow, I hadn’t thought of that. That’s really something. Really great, let me think about that more.”

He would make everyone feel like a genius. Or host a group discussion with similar theme.

Then he would find some way to give you credit for your idea or suggestion. Everyone loved him.

After watching him operate for awhile it made me realize how much most engineers overvalue “genius intelligence” and being hyper industrious versus … seemingly very simple human to human interactions and the reality of how people think and work.

The reality is that the true performance criteria for you in the majority of environments is how much everyone around you likes you and thinks you are great. I realized that’s what this guy was doing after having +30 years of experience on me. And I assumed he knew something I didn’t about doing “deep career time.”

So if seeming more busy is your root problem, just realize that people:

1. Probably don’t care about what you are doing 2. Want to feel smart and consulted for their genius opinions 3. Given credit for something you are doing

If you do those three things, with the right people, your report is kind of irrelevant.

Does anyone care about this system? How does this system result in other people getting a promotion? If you figure that out, everyone will love you.

Your reports will read like; “had a discussion about best approach to unit tests with James and he suggested some important optimizations which I have made.”

You have scoped your problem as an “engineering” problem when it is realistically More of a “peer psychology management” problem.

As long as you are likeable, that’s what really matters imo. If I understand the situation correctly.

Elon musk would probably hate this answer. He probably realistically has a ton of people doing exactly this working for him. And they are his favorite people because they want to hear his genius ideas.

Don't go?

Or go once a week?

Or month?