Xilinx Developer Senior reviews

1. Review period is too long to be effective. A concise review process that is much more tightly coupled to real employee goals and performance therein would be a significant aid to motivation. Presently the process involves that 'root canal' of a yearly review to fill out, where everyone wastes a day or so droning on about the last year and why they were not able to achieve goals from 6 months ago that changed 4 months ago. 2. Call it a silo, call it the tower of Babel, either way Xilinx is a disjoint organization with fractured processes that differ significantly amongst all development teams. Consolidating the teams and coming up with a light-weight extensible process while facilitating greater communication amongst all the teams is probably the toughest challenge Moshe and friends face on the engineering side of the house. This contributes significantly to diminished product quality and weak execution. Some projects are exceptionally executed while others are sorely lacking--this evidences the differences in process and approach that ought to be unified. 3. Stone-age approaches to problem solving. There are many examples where we try to do things internally that are not our core competency and would be better accomplished with existing technology and infrastructure. Xilinx will have trouble being a growth investment until it starts to leverage the state of the art in its solutions. Examples include better modularity with reduced build-time dependencies, enabling the use of farm and cloud computing both in internal projects and released product, and global caching of pre-computed results to improve customer experience. This same situation has been evidenced by our lack of, or late adoption of industry standards. 3. Encouraging Hero syndrome. What this really amounts to, is rewarding fire fighting rather than fire prevention. This results in employee burn-out and masks significant problems. These problems typically can include one or more of the following: - a failure to plan and design - an inability to push back or scope back a project - ineffectively tasking/staffing a project The burden of covering for these incompetencies then falls upon the developer, who is later rewarded in a public fashion, perhaps in an all hands meeting. This happens far to frequently to be dismissed as the kind of occasional heroism that is healthy. 4. Employee investment. Xilinx's internal training program needs some work. Employee skills in all domains are allowed to get dull, leading to an ineffective workforce that is not progressive in it's approach to solving problems. It is incumbent upon employees to strive to improve themselves to remain competitive, but Xilinx could do a lot more to help. I have witnessed this in management where I have seen supposedly experienced managers think that adding 12 more people to a 4 person project will make it go 4 times more quickly (try reading Mythical Man Month to start). That is a lack of training. I have also seen a lack of training in engineering, for example where people prefer using print statements over sophisticated existing debugging programs that we have licenses for. This can be corrected with investment in training and better tool standardization across development teams. The result would be a more effective workforce. 5. Review period is too long to be effective. A concise review process that is much more tightly coupled to real employee goals and performance therein would be a significant aid to motivation. Presently there are two six month reviews and that 'root canal' of a yearly review to fill out where everyone wastes a day or so droning on about the last year and why they were not able to achieve goals from 6 months ago that changed 4 months ago. I have never felt my rewards were tied to anything I ever did for the company and the review process really doesn't facilitate this in any meaningful way. I can already see where the executive team is taking steps to address some of the above problems and that is encouraging. Wim made great changes when he joined Xilinx, but for some reason that seemed to happen less as his tenure proceeded--I hope the same is not true for Moshe and his team.