3 ms·
Performance Is Contextual
- ilaksh 3y agoOne aspect of this that is not mentioned is how performance is being measured, and the actual task and level of difficulty. Many managers may only be seeing some surface level work product such as new screens, form fields, or number of tickets completed. There are often many ways to accomplish a task, or something close enough to the original goal that the manager probably will accept it. Oftentimes a task is assigned that is quite challenging as given (unbeknownst to the manager that assigned it). A typical response by many engineers may be to basically "go around" the task once they find out how difficult it is. This could involve using a third party component, or just skipping the aspect of it that is really difficult and making it a TODO. The manager may be happy to accept these workarounds because it keeps things moving forward. They see the engineer as being productive. But you might run into engineers who are perhaps actually more capable, see the assigned task as written as being significantly more valuable than one that involves a loose interpretation or workaround, and decide to attempt it. This could mean that instead of spending a few hours, they are working on one task for a few days or more. Suppose that they eventually accomplish the task with the full scope as it was written and without workarounds. This might really be a significant new technical capability for the software and much more valuable in the long run than any potential workaround. But a manager may not realize that at all, and may simply see the engineer as being less productive than his peers who instinctively avoid really challenging tasks. It would be simpler if software engineering was like many types of jobs, but it's not. Everything can potentially turn into research and solving unknown problems.