[sound1]

Beautifully articulated! On a tangent, I always seem to have issues with my superiors because of the way I work. Most of the initial part of a project I do nothing but think about how to approach it, best ways to solve some of the problems and what pitfalls to avoid. During this period they don't get much of the status updates or progress and they get mad. Then in a short burst I finish off everything when they think that project may be delayed, and this gets them extra mad because according to them I have been secretly working hard but never told them. I really don't blame them but sadly I don't work like most people do and admittedly it is a bit of a problem for project managers..

[jogjayr]

It may help to document ideas and pitfalls as you think of them. If you're trying out things in code, leave that work on your own branches, and link from the doc. It gives managers a tangible artifact to see you're making progress. It's also valuable documentation for others after the task is done. Extra plus: come performance review time, you have a paper trail of everything you've done, everything you tried that didn't work out, everything you can take credit for.

[Denzel]

Yes, this is fantastic advice. The most effective senior engineers on my team almost always create what’s called a “start doc”. Written at a high level, the doc discusses background context, enumerates possible solutions with a pro/con list for each, and records open questions and out-of-scope issues. They’re usually only 1-3 page gdocs.

The most important part is that it opens up discussion to the team. Everyone is able to read, comment, and offer up improvements or get clarity on questions they have. After a few rounds a feedback and revision — usually 2-3 days — a decision is made and the engineer goes off to break out a few tickets and start the work.

It’s async, collaborative, efficient, visible, and just a generally pleasurable process as both an individual and teammate.

[sound1]

Great advice, thank you!