4 ms·

Interesting. So despite the apparent success, your manager put on paper that you were "goofing off and not working"? Did he mention that verbally one or two t

by tutufan 10y ago

Interesting. So despite the apparent success, your manager put on paper that you were "goofing off and not working"? Did he mention that verbally one or two times beforehand? How did you react? Once things hit paper, I generally start interviewing. Not sure whether that was right. But looking back over my career, I usually should have left earlier rather than later in those cases.

ChuckMcM 10y ago
It was verbal vs on paper. What was in the review was that I needed to improve my time management. And oddly enough I left for Sun Microsystems not to long after that, but not strictly because of the review, rather it was that I preferred a work culture that understood what programmers did in addition to understanding what EEs did. And for what its worth, I took it to mean that I wasn't communicating how I was spending my time well enough and suggested ways that would work for both of us. I expect that had I stayed at Intel it would have been fine.
- gtirloni 10y ago
  I've a hard time communicating what I'm doing in that "research" phase. During standups, most people are reporting concrete tasks that got done and I feel a bit embarrassed to say I spent the whole day trying something out that's remotely related to the final product but was interesting for the ideas. It's stressful to have to report those things, I feel like I have to justify them, what's my train of thought, etc, and a 1-minute update has to turn into an essay. Not really sure how to improve on that. During your time at Intel did you have to report on your work quite frequently?
  - ChuckMcM 10y ago
    Intel was my first exposure to "management by objective" and "key results". And yes, there were weekly reviews of your progress. Every quarter, a set of objectives and under each objective key results, and then weekly you reported on how you were doing with respect to those. I think the key to your stress is either that you aren't clear in your head what you're trying to figure out, or your trying to figure out things that aren't actually relevant. In my life what I have done is to do get very very disciplined about what I'm to understand and how that will relate to the final goal. Not surprisingly that is different as a manager than it is as an individual contributor. If I were your manager, and you came to me with this (and I would hope your relationship with your manager is good enough that you could talk to them about it) I would start with three questions; 1) What parts of your assignment are you completely confident you can build/write? 2) What parts are you unsure of how to build? 3) What things that you are unsure about are between you and building the things you know you can build? Perhaps you can imagine how the conversation goes after you answer those questions. But lets say for this hypothetical that you were unsure if you could build a database fast enough to respond in time to meet the response requirements of the product. At that point we'd talk about what steps you could take to understand what sort of performance to expect out of a database, what variables had the biggest impact on that performance, and which databases were designed to be fast. And you and I would agree that you would spend this sprint perhaps developing your understanding of database performance. So at the stand up I'd expect you summarize and article you read, a set of benchmarks you set up, a set of test tables you created in the existing system, or maybe the top 5 blogs/books/videos you've found on analyzing database performance. At the retro I'd want to know what sources gave you the most information for the time invested, what were the time wasters, if you were more or less confident about the database choice and its performance and maybe how you had, or would, quantify your understanding with something objective. From your perspective you would probably have spent the time 'surfing the web' to find out various sources of information or perhaps prototyping some things on AWS or on a local server. If instead you came back and said, "I really don't know anything more about databases yet but I learned Rust, and got stuff running in the new Angular release and updated my server to the latest Ubuntu and read a book on containers. Then we're going to have a different talk :-)
    - gtirloni 10y ago
      That's really very useful, thanks a lot.

by tutufan 10y ago

ChuckMcM 10y ago

It was verbal vs on paper. What was in the review was that I needed to improve my time management. And oddly enough I left for Sun Microsystems not to long after that, but not strictly because of the review, rather it was that I preferred a work culture that understood what programmers did in addition to understanding what EEs did. And for what its worth, I took it to mean that I wasn't communicating how I was spending my time well enough and suggested ways that would work for both of us. I expect that had I stayed at Intel it would have been fine.

gtirloni 10y ago
I've a hard time communicating what I'm doing in that "research" phase. During standups, most people are reporting concrete tasks that got done and I feel a bit embarrassed to say I spent the whole day trying something out that's remotely related to the final product but was interesting for the ideas. It's stressful to have to report those things, I feel like I have to justify them, what's my train of thought, etc, and a 1-minute update has to turn into an essay. Not really sure how to improve on that. During your time at Intel did you have to report on your work quite frequently?
- ChuckMcM 10y ago
  Intel was my first exposure to "management by objective" and "key results". And yes, there were weekly reviews of your progress. Every quarter, a set of objectives and under each objective key results, and then weekly you reported on how you were doing with respect to those. I think the key to your stress is either that you aren't clear in your head what you're trying to figure out, or your trying to figure out things that aren't actually relevant. In my life what I have done is to do get very very disciplined about what I'm to understand and how that will relate to the final goal. Not surprisingly that is different as a manager than it is as an individual contributor. If I were your manager, and you came to me with this (and I would hope your relationship with your manager is good enough that you could talk to them about it) I would start with three questions; 1) What parts of your assignment are you completely confident you can build/write? 2) What parts are you unsure of how to build? 3) What things that you are unsure about are between you and building the things you know you can build? Perhaps you can imagine how the conversation goes after you answer those questions. But lets say for this hypothetical that you were unsure if you could build a database fast enough to respond in time to meet the response requirements of the product. At that point we'd talk about what steps you could take to understand what sort of performance to expect out of a database, what variables had the biggest impact on that performance, and which databases were designed to be fast. And you and I would agree that you would spend this sprint perhaps developing your understanding of database performance. So at the stand up I'd expect you summarize and article you read, a set of benchmarks you set up, a set of test tables you created in the existing system, or maybe the top 5 blogs/books/videos you've found on analyzing database performance. At the retro I'd want to know what sources gave you the most information for the time invested, what were the time wasters, if you were more or less confident about the database choice and its performance and maybe how you had, or would, quantify your understanding with something objective. From your perspective you would probably have spent the time 'surfing the web' to find out various sources of information or perhaps prototyping some things on AWS or on a local server. If instead you came back and said, "I really don't know anything more about databases yet but I learned Rust, and got stuff running in the new Angular release and updated my server to the latest Ubuntu and read a book on containers. Then we're going to have a different talk :-)
  - gtirloni 10y ago
    That's really very useful, thanks a lot.