Secondly, if doing R&D, how do you update that you did a thing when it's not anything of note.
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".
- 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.
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
This is literally ignoring the setup for the problem that OP gave you.
You can also agree on service level metrics with your manager and then status those metrics. Things like uptime, time to recover.
Your second question is a little vague. Can you give us an example of “a thing”?
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.
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.
Or go once a week?
Or month?