AMD

AMD Markham had an amazing assortment of technical talent in all positions. All engineers I found myself interacting with were extremely competent, and for the most part, quite friendly. My co-workers were usually happy to answer any questions I had regarding their area of expertise.

As a result, I received some very good advice in regard to design methodology, which was not properly covered during my university education.

Individual teams were all focused and dedicated to their tasks. There was seldom any confusion regarding the purpose of a team or the results that were expected of them. Intra-team politics were generally quite low-key and were seldom more serious than personality conflicts among incompatible team members. Fortunately, management was able to contain even those such that team productivity did not suffer.

I also very much enjoyed the large amount of personal freedom given to employees. Work hours were not very strict, and the engineers were free to come and go as needed. It was not uncommon to see impromptu tech discussions develop over coffee. Management would generally adopt a hands-off approach, only micro-managing during crunch times, which were thankfully quite short. Team-wide meetings were also a very positive and friendly experience for everyone involved.

Unfortunately, AMD is quite old for a tech company, and it shows. To make matters worse, the AMD and ATI merger was not nearly as smooth as it could have been, resulting in a lot of conflicting processes and incompatible data organization styles.

Also, while most technical personnel were very reasonable and professional, there were some people in very high positions that let their seniority really go to their head.

AMD has been operational for over 40 years, while ATI has been going for 25 years, only 5 of which were as part of AMD. During this time, both of these companies saw momentous shifts in technology, and in many cases were right at the center of these shifts.

Over such a long time, a lot of processes were developed to address a huge range of problems that inevitably arise during operation. Unfortunately, being on the leading wave of technology means that most of these processes could not take advantage of the innovations they help to implement.

Once a company of this size defines a number of new processes, standard corporate mentality takes over, and the short-term cost of optimizing these processes becomes very difficult to justify on the balance sheets.

The result is that these decisions can easily live on for decades, until replacing them becomes an emergency concern, with all of the associated headaches, rushed specifications, and buggy implementations.

Of course, the existence of competing standards defined within the scope of ATI before it was acquired effectively doubles the number of stakeholders, and makes the problem not only more challenging, but also more pressing.

Also, as a result of the age of these companies, relevant information is extremely hard to find. The company-wide search is about as advanced as a search engine of the mid-1990s, and will only respond to some very creative search-term voodoo.

Often times, the only way to get some information is to ask someone familiar with the topic where to find the data you are looking for. This is not a difficult task when you can ask a team member, but it becomes exponentially harder the further away you have to look.

Finally, while most personnel, both technical and management, are very helpful and professional, there are a few people in senior positions that are quite the opposite.

Over the years, certain people have managed to take control of very large and important projects, and now make working in these project domains extremely difficult.

Often, these situations are a result of personal or cultural problems, but the resulting political dancing necessary to fix even the smallest issue is daunting for an engineer without a political background; this includes most of those on a non-management track.

The problems faced by AMD Markham are the same as many other companies of similar age and background. The solutions are likewise rather similar.

First and foremost, the company needs to work towards a more well-defined mentoring process to reduce the control presently exercised by senior technical personnel. This means that more responsibility needs to move from senior engineers to those down the ladder. The resulting free time should be used to train younger engineers in both design and implementation, as well as company-specific processes and information.

Next, process evaluation should be done based on more than the short-term costs of updating the process. While there are a number of areas where the change required may take up to a year of work, the resulting improvements in efficiency could easily save tens of thousands of working hours per year in the future.

Ideally, AMD should hire some real integration and optimization experts to actually integrate the old ATI sites with the new AMD processes and point out where these processes may be bottlenecking productivity. Given the scope of the problems, this would necessarily be quite an investment, but it is a vital move if AMD hopes to create and carry on any momentum to compete with the other juggernauts in this market.

Finally, AMD needs to really re-evaluate the team organizational structure. While intra-team cooperation is very effective, inter-team communication is very limited. Many teams that depend on other internal projects have very little direct communication with those responsible for said projects. Often times there is at least one, if not more, teams in between, resulting in a very long game of telephone. As a result, the amount of repeated work performed in various parts of the company is staggering. Very complex problems are solved differently by four or even five different groups, creating artificial walls between teams that should otherwise work much closer to each other.