My Professional Strengths

intellogoBelow is a compilation of strengths noted in many of my performance reviews over the years.  These comments crossed multiple jobs during my time at Intel Corporation.  I edited the text to fix some of the choppiness and incomplete sentences that are normally used in a performance review document in order to save space.  I did my best to preserve the messages intended by managers.

  1. [Discipline]  Dave infused a greater level of discipline into the project planning across groups and instilled better organization within the local team.  He built an MBO planning process and an effective, consistent staff meeting that improved communication, individual involvement, and focus on results.
  2. [Customer Orientation]  Dave improved stakeholder management and helped the team flip the emphasis on acting as a victim of our stakeholders to working as direct peers and partners instead.  Stakeholder satisfaction was problematic many times during the year, but as Dave helped Nizhny drive the agenda more, problems were solved more effectively when on equal footing with other organizations.
  3. [Quality]  Dave showed his commitment to quality by leveraging the talents of his team to define what quality coding really is.  The team now has the right focus on what is needed to produce quality projects.  He has also worked tirelessly to improve the communication skills of the team by running communication and leadership workshops that will increase our reputation as a high-quality organization.
  4. [Integrity]  Dave has received regular feedback from stakeholders that he operates with a high level of integrity.  One example included his contribution to the Sales and Marketing Group performance review session.  Dave ensured that fair and accurate results were achieved amongst the numerous and varied departments across the organization.  He also exhibited a strong commitment to running the Russia Marketing Center in a professional, value-oriented manner.
  5. [Quality]  Dave’s work output and communication skills are always of the highest quality.  He is able to articulate the key messages in communications and presentations, provide the right data for the right situation, and collaborate effectively with teams and stakeholders to get the job done effectively.  Dave contributed quality content and clear messages in presentations to the Executive Management Team and to regular Ops Review meetings.  Additionally, he submitted high quality data to the Compensation &Benefits Team in order to improve salary competitiveness in the Russia market.  All these demonstrate his constant commitment to Quality.
  6. [Great Place to Work]  Dave leads with principle and has spread the trait of professionalism and responsibility to the rest of the young and inexperienced Russia Marketing Center team members.  He has challenged his people to move from being a new and untested team to a respected partner with Moscow and EMEA.  He has also inspired people to work hard but have fun.  Examples of this are the Russia Marketing Center hosting a party at the Intel Global Sales and Marketing Conference as well as contributing a video and displays to the CEO’s technical demo.  The positive, energetic spirit of the RMC is a direct product of Dave’s dedication to making it a Great Place to Work.
  7. [Customer Orientation]   Dave constantly demonstrates strong customer orientation.  He was very proactive and constructive during design and planning of the global service request system for the Software Solutions Group.  Dave scheduled a large number of meetings with customers to understand customer requirements and constantly sought customer feedback.  He scheduled meetings to discuss customer satisfaction surveys and proposed possible action items to address issues.
  8. [Quality]  Dave possesses strong written and presentation skills.  Due to this, he acts as the primary messenger for written communications with the customers or within Northwest Engineering Computing.  Dave’s presentations to the Executive Committee were received well throughout the year.
  9. [Customer Orientation]   Dave is the end user advocate for the Northwest Engineering Computing customer base.  Dave excels at ensuring a quality support experience by closely monitoring the NWEC indicators and survey data and following up on customer surveys.  He also regularly meets with customers and has provided extensive indicators for quarterly reviews and for his NWEC peer managers as needed.
  10. [Results Orientation]  Dave is imaginative and not afraid to take risks.  He came into the Security Operations Team (SOT) and the Security Architecture Team knowing little about information security and was able to quickly begin effective management of the SOT.  He is also not afraid to look for new opportunities or ways to simplify or reduce the workload.  He has introduced a new concept of site security certification which is a departure from our current ways of pushing the regions to get their security work completed.  This new concept will hopefully “pull” the regions by instilling a bit of competitiveness into the process in hopes of easing the constant pushback we get when trying to deploy new security solutions.  This is a significant departure from our normal operations method and will be an interesting experiment to improve security within EC.
  11. [Customer Orientation]   Dave is the end user advocate for the NWEC customer base.  Dave excels at ensuring a quality support experience by closely monitoring the NWEC SLA commitments and following up on customer surveys.  He also regularly meets with customers and has provided extensive indicators for quarterly reviews and for his NWEC peer managers as needed.  Dave has especially assisted with an increasingly successful partnership with the motherboard engineering team by providing indicators bi-monthly to ensure follow through on support issues and projects.
  12. [Customer Orientation]   Dave has shown a strong ability to work with the toughest and most unhappy customers and turn them into advocates of the Help Desk and NWEC.
  13. [Quality]   Dave has no qualms asking for help, it’s one of his strengths.  He wants to do the right thing so he’ll ask for opinions, suggestions, and the best way to handle a situation.  He’ll take this feedback and decide the best course of action.  He does a good job keeping the team aware of status on whatever he is working on.
  14. [Customer Orientation]   Dave is skilled at working with cross-site teams, management, and customers to create innovative, high-quality support models.  Dave’s skill in developing processes that benefit all participants has created high customer satisfaction at the Intel Engineering Technology Center and the Columbia Development Center.
  15. [Discipline]   Dave has strong analytical skills which help him in analysis of his business issues and challenges.
  16. [Customer Orientation]   Dave is a fervent advocate of the individual end-user customer.  He regularly calls customers who have submitted surveys, those who have complained about service problems, and those who have simply used the Help Desk.  This way, he stays in touch with the customers’ needs and adapts our processes to better meet those needs in the future.

Organizational Development

Fahne/ flag

Organizational Development in Action:  The Russia Marketing Center

This post is a work in progress..


In 2002, I traveled to Russia on a whim for three weeks. The country and its history entranced me.  It was also opening up and becoming the next great place to expand. Consequently, I began imagine working there. The following year, I came back and arranged a meeting with the President of Intel Russia in Moscow. We hit it off immediately and he vowed to look for a job for me. Over a year later, he found a great job for me; to start up Intel Russia’s first Marketing Center. I would live in Nizhny Novgorod, Russia 350 miles east of Moscow. Intel had a site there of about 400 people. Most of them were software developers working for a software products group. Intel wanted to grow their presence in Nizhny rather than Moscow due to cost. It was a standard model for Intel since most locations throughout the world are located in suburbs or smaller cities outside a large city. It was Nizhny’s turn to follow the model.

Job Description

I served as Director of the Russia Marketing Center (RMC) in Nizhny-Novgorod and also acted as the co-site manager for the Nizhny-Novgorod and Sarov sites. My primary responsibilities included managing the following teams which were part of the RMC:

  • Russia/CIS part of the EMEA Marketing Organization
  • Russia/CIS Channel Marketing
  • European Technical Group
  • Russia/CIS Channel Finance in the region.

The full group was 30+ people. Some of these teams reported to me directly and some are matrixed. The focus for this job was primarily on organizational development, i.e., hiring,  training, and integrating the team into the wider Intel Corporation.

How We Did It

Before I came onto the scene, The EMEA Sales and Marketing Organization for Intel created a long-term strategy to expand their reach into Russia/CIS.

A management steering committee had been set up with people from Swindon, UK and Moscow to kick off the RMC project long before I got involved. Representatives from Marketing, Finance, HR, and Operations had already rented office space and hired a few people to get the RMC going. It was my job to continue growing the team, establishing a public presence in Nizhny, and to get the new people “Intelized” and producing.

One of my earliest activities was to conduct a press conference at Nizhny’s city hall. I had barely moved to Russia and suddenly I was sitting in an assembly hall with the mayor and some university officials as if I were a dignitary. In the room were also close to 80 people, many of them media. I had a microphone and several recording devices sitting on the desk in front of me. Video cameras pointed at me and reporters with their notepads were ready and waiting. I made an opening statement about the launching of the Marketing Center and then took a barrage of questions. Most were polite softball questions and only one tough one came my way. Somehow, I managed to answer it effectively, finished the event, and went on my way. The whole experience was unreal. I had never been interviewed for anything before, let alone in a widely covered media event in Russia. I got high marks from Intel’s local public relations rep. All in all, a good start.

I can’t go on further without introducing my manager. Though Intel Russia’s President “discovered” me, I actually reported to the Sales and Marketing Manager for Russia/CIS. Ian was a Brit and one of the most memorable personalities I’ve come across. There was no greater fan of Ian than Ian himself. It was a wonder he could ever get his head through a door. He was damn good at what he did, but anyone who worked for him had to put up with a lot. He was the most demanding boss I ever had. If I missed anything, he was on me hard. Though he spent a ton of money bringing me all the way over to Russia, he had no qualms about dismissing me if I didn’t cut it. I figured that out because… well, he told me. He insisted that I give status on the project to every known stakeholder that existed over and over. I was a presentation machine. He was never satisfied with my pace and railed about it quite often. At the same time, we had an identical vision of what we wanted to do with Nizhny and every so often he would give me significant words of encouragement and acknowledgement of my hard work. We both were fascinated with Russia and though he lived in Moscow, he loved to come to Nizhny and spend time with my team. We both valued bringing new people in and enjoying the youthful enthusiasm that filled the office. He also wanted to expose me to as many things as possible. He was the one who pushed for me to do the press conference. He was the one who sent me all over Russia to meet customers and make speeches. And he was the one who saw promise in me to bring me over in the first place. As time went on, I got more and more used to his style and really started to get into a groove with him. On some days, he would pound on me, but then the next, after I regrouped and redoubled my efforts, he would say, “I have to give you credit, no matter how hard I am on you, you always fight back.” I can’t say I enjoyed the experience, but it did steel my fortitude under his watch. Meanwhile, we were making a lot of headway on the RMC and our stakeholders liked our results. Things were really starting to hum. Of course, then everything had to change and some even greater challenges came up.

The first problem that arose was the task of hiring a senior marketing person to lead my team and replace me after I left. We were now starting to learn how difficult it would be to realize all our dreams for the RMC in Nizhny. It was simply hard to find an experienced marketing person in Nizhny. Anyone worth their salt would have already left to Moscow for the big money and opportunities. My candidate options were slim. Hiring junior marketers was fairly easy, but finding senior marketers and then getting them to stay was harder. This was the first big and hard lesson we learned about doing business in Russia. Regardless, Ian was not satisfied with my progress. I had found someone who was close to the mark, but I wasn’t feeling 100% about him. A colleague in Moscow refused to sanction the hire. We fought about it a lot. At the same time, Ian was scaring the hell out of me for not hiring anyone yet. He said the guy I found was fine. Not able to stand up firmly and talk squarely about the problem, I hired the guy. After that, a lot of relationships between Moscow and Nizhny soured and my job got much more difficult.

Fortunately for Ian, he never had to deal with the residue. Not long after this situation, he announced that he needed to leave his job in Moscow and move back to England. There was some relief, to be sure, but I also feared losing all the good things I got from him. As you’ll see, I did.

Ian was replaced by Dmitri. Dmitri was Belarusian but had worked for Intel in Swindon for 9 years, serving as the Account Manager for IBM. He went to Oxford and was one of the smartest people around. In our first meeting over the phone, he dropped a bomb on me. He didn’t like the idea of the RMC being in Nizhny. He said it should be in Moscow. A week or two later, while I was in Moscow, he had dinner with me and reinforced his thoughts. He couldn’t say he was going to sabotage the project outright, but he did want to explore how much he could turn it back. I was devastated. I came all the way over here, put my heart in it, was doing a good job, and suddenly my own boss wants to put an end to it. For the next 9 months, my life was going to be rough.

I had to figure out what to do next. I always want to support my manager, but I also had a duty to deliver what my steering committee wanted from me. The committee included some pretty big players in Europe, some higher up than Dmitri. When conferring with them, they still believed we were doing the right thing and urged me to continue on. Meanwhile, Dmitri was fueling the fire with his staff, my peers, in Moscow. Moscow already had an arrogant attitude before, now it was getting worse. The President of Intel Russia, Steve, was on this committee and started having open feuds with Dmitri. It was getting ugly. Finally, Dmitri proposed that I do an in-depth analysis of the pros and cons of the project, work up the cost analysis, and everything else, and conduct a grand discussion with all major stakeholders about what we should do. I worked hours on end and utilized every resource, every ally, and every piece of data I could get my hands on to be prepared for this presentation. I went to Moscow to give my pitch. Two VP’s, my steering committee, and the head of European Marketing all attended the meeting. Dmitri and some Moscow people served as my debate opponents.  I went through the presentation and was challenged on many points. Moscow’s opinion was that we should hire fewer people and have them all in Moscow. My argument was to continue the plan of building a full-service marketing organization in Nizhny. After all the back and forth, I won the argument in a landslide. It was definitely a victory, but I felt that it was a hollow one. I just knew Moscow was not going to surrender, so the fight would doubtfully never end.

There was a brief period of peace and I continued hiring more people and developing the organization. We found some of the most fantastic people. They quickly made an impact and just about every stakeholder in Western Europe was very impressed. I was a second-level manager managing the head of Channel Marketing, Distribution Finance, Corporate Marketing, Communications Product Marketing, and Technical Support. An Irish woman ran the Communications Product Marketing and a Brit managed the Tech Support team. The three of us lived in Nizhny and loved telling each other stories of the ridiculous things we encountered in Russia. All three of us loved what we were doing and felt energized by the team. We set up marketing events all over Russia, showed great business results, and managed to take over all the work that had been done in Western Europe before. We were doing everything we were supposed to be doing and having a lot of fun doing it. The team reached a total of about 30 people. I was responsible for making sure all the teams worked effectively together. Before our organization was built, marketing had been operating out of silos by different groups located in England and Germany. Now, we were really running tightly and creating some great marketing efforts. I still did not know much about marketing, but my team didn’t seem to need that kind of help. They wanted an Intel mentor and someone to learn from about how to succeed in their new careers. None of these people, nor their parents or grandparents, had ever worked for a real corporation before. They didn’t know how to act. I had to teach them a lot and it was very fulfilling. In all cases, despite the many problems mentioned in this summary, I received very good performance reviews and achieved some of the biggest results in my career. Each day was more interesting than the last. It was truly a blessing.

Moscow still gave us fits, though, and once, when Dmitri’s boss came to Nizhny, an Executive Vice President, he pounced on him and told him to support the effort or else. Dmitri was even forced to apologize to me. (that was an uncomfortable moment, I have to say)

The only thing Dmitri could do now was go along with it reluctantly, but he did figure out one way to slow it down. He could start asking how much longer I had to stay in the job. Intel was starting to do headcount freezes and revenue growth in Russia was flattening out, so in actuality, my job was starting to become less needed. I just had to hire one more senior person, and then my tenure would cease. I think it was a reasonable conclusion, but deep down, I just felt like Dmitri wanted me out of there. Two more things popped up that made my transition out extremely difficult.  First of all, the controversial hire I made was not working out. Many people didn’t see that he was adding any value and just flailing. He couldn’t find his place, so we had to reduce the scope of his job. Eventually, it was becoming clear that I had to let him go. To fire anyone at Intel is a long, painstaking process. I always laugh when people accuse managers of liking firing people. What a joke, it’s miserable. In parallel, we did find a very good senior marketing person who was willing to move to Nizhny. I was very enthused about it since Moscow liked him. But then in one fell swoop, HR discovered that he had submitted a fake diploma, which automatically disqualified him from being hired. (this is a very common phenomenon in Russia, by the way)  Right toward the end of my stint, I got a double whammy. I had to fire someone and the potential savior got booted out. I never had time to find a replacement. It was at that point that they decided to hire the role in Moscow. Despite all that I had achieved, which was a lot, I had to end it in that way. It was very disappointing. And as I mentioned in a conversation before, about half of the people in Nizhny have since been moved to Moscow. In the end, I guess I was perhaps half-successful in the long-term. By the time I left the role, I guess I can give myself a break and say that I had been mostly successful. Some things were simply out of my hands. I always look at that job with both joy and disappointment. At least I know that I personally hired most of the people that are still in Marketing today. Dmitri can thank me for that.

Lessons Learned

The skill I learned the most is navigating through competing interests. I had to identify where I could deliver value despite unclear direction from stakeholders. I was stuck in the middle of opposing views of the future and had to figure out how I could do the right thing for the company. I also had to get real work done without there being a backlash against me to the point where everyone turned against me. I’ve looked at this job from afar so many times, and I’m still not sure what I would have done differently. The two things I would have changed, however, was not to hire the person I ended up firing, and then also looking for the second senior marketing person sooner. When hiring people, you need to have all stakeholders enthusiastic about the person. If you don’t, then even if the person is good, you risk poisoning the environment and making it difficult for him to succeed. Hiring the other marketing person sooner would have given me more wiggle room if he hadn’t worked out.

Another thing I learned that is to witness how higher level people cope with working with peers that have completely different visions. Steve, the President of Intel, was constantly fighting with Dmitri, but neither one seemed very affected by it. I suspect they were putting up a good front.  Moving upward involves dealing with these kinds of situations regularly.

During this job, I discovered that I possess a great presence in front of an audience, can think fairly well on my feet, and don’t get nervous doing public speaking. I had often done fine with corporate presentations but never had the forum to do public speaking before I went to Russia. It was a pleasant surprise to see how well I took to it.

I also learned that I can build organizations very well. I know how to hire good people and I know how to harness a team’s enthusiasm.  With one exception, I hired people that became very successful and either stayed at Intel a long time or moved to other companies and took senior positions.

This was also my first experience managing managers. It was a bit tough for me, though I learned much about how to deal with very independent, headstrong people. I learned ways to make them accountable and to keep them going in the right direction. I didn’t master it, but I gained a strong sense of the issues that will always come up in these situations. It prepared me more for my software development manager position and will prepare me more for future opportunities.

I also learned how to keep fighting despite multiple obstacles and setbacks. I never gave up and worked through the stress, always stayed prepared, and showed a lot of guts. All these skills will come in handy in the future.

Performance Review

  • Organizational Development:  Dave championed the success of the RMC for the past year in several ways.  He managed the resources effectively to enable the organization to grow by approximately 17 roles and planned the integration of these EE’s, interns, and RCG’s. In Q4, Dave worked closely with C&B to analyze our salary problems and drove the necessary focal budget changes to correct our below-market position.  The impact of this effort is that RCIS region now has a bigger team for driving marketing, channel finance, and design-in support for the region for the long-term. The team still needs to grow their skills but the energy and desire are pre-requisites for future success.
  • Dave owned the visit of Paul Otellini to Russia.  Dave spent two months directing the visit team locally and engaging the EMEA and U.S. participants in order to put together a robust agenda for the trip and executed it successfully. Dave made sure that all briefing documents were published with the highest quality, that logistics ran smoothly, and that all major events satisfied both Otellini and the region.  As a result, Otellini rated his EMEA trip as his best ever and that events such as the technical demo, Russia Business Council, and the Open Forums were some of his favorite experiences of the trip.  This should give the region more visibility and spread the word of the value of our engineering and sales and marketing teams.
  • Dave owned the formation of the Energy Taskforce and it’s ultimate strategy development and recommendations for 2006.  Dave brought all key Energy players in EMEA and Russia together to consolidate efforts. Dave directed key people to create an analysis of the market so that a clear understanding of opportunities available in the market could be assessed and prioritized.  He also pieced together, with the Enterprise Sales team, potential strategies for some elements of broad marketing, advertising, certain solution stacks, and new technologies so that a united effort could be forged to maximize revenue from Russia’s energy market.

Agile Software Development

software development.png

Role Description

EMEA Software Development Center Manager

Manages operations of the EMEA Development Center which includes resource allocation, project oversight, and success indicators.  He also owns the communications and management improvement program.


During my stint as the Russia Marketing Center Director, I had begun to befriend a British manager who was leading a team of IT software developers down the hall from me. He mentioned that he was looking for an expat to groom his team and bring them to a higher performance level. Upon volunteering for it, he gave me the job immediately. Though it was a job in IT, a division I had worked in for five years before, the field of Windows software development was a very unknown quantity for me. There were close to 40 people on the team. Most were C#/.Net developers, some were data analysts and platform support engineers, and the rest were technical leads or managers. They also used a development process called Agile, something I had never heard of before. Nizhny reported into management in Swindon, England, Intel’s European headquarters. There, project managers, business liaisons, and business analysts resided alongside a large part of the customer base that used the solutions created by the Nizhny team. Despite the distance, Swindon and Nizhny worked fairly well together. Still, Swindon felt that Nizhny had to improve significantly in order to earn the right to do good projects, and even to exist. India was a direct competitor to Nizhny as a development center, so Nizhny had to step it up to succeed.

Though located in the hinterlands of Russia, they were actually working on one of the most important projects in the company. Intel wanted to completely rebuild their order fulfillment process. The Nizhny team had created an idea how to do it and built a prototype. The idea grew like wildfire throughout Intel and the Nizhny team suddenly gained charge of a major corporate initiative. Technically, they were up to the challenge. The programming talent, as I gradually learned, was unmatched across Intel. Unfortunately, their political and communication skills were so poor that it nearly destroyed them. I joined the team in the middle of a large crisis in the order fulfillment project.

Upon arrival, I had to meet a lot of people, learn their roles, and dive into the Agile development process. Not a lot clicked for a while, and it was frustrating and overwhelming. We created a new organizational structure that gave me their management team to report directly to me. Some of them were a bit doubtful that a non-developer could help them in any way. To some degree, they were right. I would never be giving them technical advice. I had to find ways to insert myself where useful and it usually fell to helping them get more “Intelized” and to grow their communications and political skills. They weren’t enthused by this since Russian culture usually states that genius should be discovered, not sold. The whole idea was slimy and disingenuous to them. As an example, one of the top technical people at Intel came to Nizhny to do a lecture. A large number of people from the entire site who did software development for other business groups attended. I didn’t understand a word of it, but wanted to attend since I was the site manager and usually hosted high-level guests. After the lecture, I asked him who were better developers, Russians or Indians? He chuckled and replied that Russians were 10 times better. I was impressed, but then he told me the other half of the story. Every time he visited Intel India, he would be swarmed by multiple developers offering white papers and examples of work they did. They wanted to learn how to contribute more to the company, etc., etc. Their enthusiasm was huge. However, whenever he went to Russia, nobody did this, nobody asked questions, nobody sold themselves. They just expected that everyone should know they are good and that all the best projects should go to them by default. That was the environment and culture I was dealing with in spades in my own team. I had to change that.

I wanted to step in sooner to start working on this challenge, but I was a deer in the headlights for quite a while trying to figure out how to fit in. Still, as the crisis they were falling into came to a head, I did find some areas where we could turn the situation around. The basis of the crisis was that the team was being accused of releasing poor quality code and were going too slow. The business sponsor was cutthroat and didn’t want to hear any excuses. There was even a little talk of taking the project away from them. While the charges made against us were a bit overwrought, I had to teach the team that perception is reality and that the perception of them sucked. I had to teach them how to fight back in a constructive way rather than to tell everyone to leave them alone and that everything was someone else’s fault. Victimhood was implanted deeply into the team culture and it was killing them.

As I met with some of the key players on the team more and more, some themes started emerging. First, they objected that their quality was not as bad as people were saying. I responded by saying, “Oh yeah, how do you prove that?” No answer. Then, as I learned more about how Agile development worked, I noticed that they were skipping a major step in their coding process, refactoring. I asked them why that was happening. They replied that the business wouldn’t let them do it and that nobody was listening to them. Their stakeholders also said that the team was like a black box. Nobody knew what was going on way off in Russia. I asked them how they communicated proactively and effectively. No answer. Many of these little insights started building into a clear pattern of dysfunction. Out of these discussions, I came up with three major plans of attack:

  1. To combat the accusations of producing poor quality code, publish code quality metrics that are agreed upon amongst stakeholders. Create an aggressive goal and report out on performance every week.
  2. To recover from skipping parts of their coding process, put together a proposal to rearrange the development schedule so that they could go back and refactor their code that kept getting worse and worse.
  3. To deal with proactive communication, create carefully crafted and timed presentations to key stakeholders to explain how the Russian team does their work, how Agile development processes contribute to their effectiveness, and how they plan to address problems.

For number 1, I told the team to go into a room without me and discuss in Russian what metrics and goals they could use to show whether they were doing a good job. I put it in their own terms. How would YOU measure yourselves? If you choose some ways to measure yourselves, what is a good number and what is a bad number? Can you automate these metrics so they are easy to report regularly and consistently? With some reluctance, they agreed to take on the task and spent a large chunk of a day figuring it out. They came back to me with several specific metrics: They were:

  • Code complexity – a way to determine whether lines of code were written efficiently. (Apparently there is a way a software tool could read the code and determine this. Don’t ask me how, but it worked well. Code complexity should not exceed __%. (can’t remember the number)
  • Code coverage – all code should be written with tests proving that the code works every time. (called unit testing). Needed to exceed 90%.
  • Defect rate – after a release, there must be a very low rate of bugs in the product during the first 90 days of use. (can’t remember the number)

I took these numbers to our stakeholders and got agreement that these were appropriate ways to measure quality. If they met these goals, suspicion of quality problems would decline. We got our development tools to report these out daily and found out that we were significantly below goal in all of them. We opened our kimonos and showed where we were at the time. The honesty actually helped our cause more than hiding the data. Our stakeholders could see where some work could be done to improve. Week after week, we reported our numbers out and each time, they improved. Our hard evidence quickly began to fight off the negative subjective opinions and the hysteria began to cool off.

Number 2 was a hair raiser. The business sponsor only wanted more features added to the tool and only seemed to want to work harder, not smarter. He was well respected in his own circles, but considered to be a jerk to many on our side of the fence. My proposal was to stop building new features for an entire quarter so that we could clean up our code and do some redesign to make the code more stable and easier to update. To our business sponsor, this was a complete anathema. I was in a sticky situation since I was new to software development and feared I would lose my nerve as the two sides clashed. I managed to talk to enough stakeholders to get support for my idea and we were able to press the sponsor hard enough to get him to agree. Once the decision was made, I put all our best people on the job to rip through every jot and tittle of code to fix what ailed us. They spent three months on it and I could see that some remarkable results were coming out of it. Once we announced we were done and we were back to building features, we had to prove that we were moving faster with higher quality. Within a short time, it became very obvious that we achieved this. I still remember the conversation I had with the business sponsor after having so many battles with him. He said, “Ok, ok, I drank the kool-aid. I get it. You were right.”  After that, we cruised and released one hell of a great software product. Intel’s CEO was even getting regular updates on its status. Eventually, he (Paul Otellini) visited Russia, met our team, and viewed our product demo and work methodology.  As a result of our efforts, we completely changed the way Intel delivered product to our customers worldwide. I was extremely pleased.

For number 3, I must confess that I did most of the talking for Nizhny for a long time. Early on, there were too many critical moments that had to be managed very carefully. I’ll talk more about this one later on since I took some major steps to improve their skills in this area.

Big Changes

IT began to make some huge waves about needing to fix Intel’s SAP environment because it was a complete mess. It was so bad that SAP could not support an upgrade to a newer version since Intel had customized the current version so much. Now, a major call for all hands on deck was made. My boss took this call seriously and felt that this was the end of C#/.Net development. To head this problem off, he petitioned to have our team convert into an SAP team. He eventually achieved this and then announced this to our Nizhny team. At first, nobody knew what to think. SAP was a completely different animal. Ideally, you only configure the tool using standard features. It should not need any coding at all. Inevitably, SAP doesn’t have all the features a company wants, so they have their own programming language, ABAP, to allow for more specific customization. Our team was encouraged by this aspect since it gave them an opportunity to write more code. In the midst of this transformation, we even got a project given to us called Salesforce Automation. The only thing we had to do was get 40 people trained on an entirely new platform and technology. I was given a large budget (can’t remember the number) to bring in trainers for some things, to send them to Moscow or UK for others, or to fly in Intel people from the U.S. or India to teach us in Nizhny. It took a few months and a lot of effort to make this happen. Fortunately, one of my managers took on the task of managing this logistical nightmare and did it well.

As the training proceeded, as the understanding of the project we were given came more to light, and as the direction of IT became more clear, we started to realize that we would not be allowed to do any coding. IT made a rule that any new releases had to use the existing features in SAP and no new features could be added by writing code. This sparked a flash of panic and existential plight within our team. These guys code. That is their life. They don’t want to do anything else. If they don’t code, they don’t stay. Nobody believed it, but the reality began to brew.

Despite the trouble lying ahead, there were some very positive times while the order fulfillment project was in progress. We still had a large number of developers focused on other projects of smaller size. We developed many smaller tools that helped Intel’s Sales and Marketing Group. Our group was in high demand and so we even used an outsourcing company in St. Petersburg to do some of our work. We eventually absorbed all our resources. Each outsourced project still required some internal resources to manage it, so we did run out of capacity. This did not deter project managers in Swindon and the U.S. to continually approach us to try squeezing in another project. I had taken ownership of all resource management, so everyone called me, begging for resources. I managed all personnel in Microsoft Project and tracked each person’s time for the months ahead. Our general rules were that each project required a technical lead, a data analyst, and a developer (either internal or outsourced). Each person could only work on two projects at once. As workload varied based on what step in the project life cycle they were in, personnel did become available for additional work in short windows of time. It was then that I could bring in a new project for a time until the resource had to jump back into one of their other two projects. This ebb and flow occurred constantly and it was my job to play God on who did what and when. I also relied upon a priority system set up by upper management. If I had to choose between projects, I would compare their priorities and make a decision. Of course, it never worked that simply. The priority system hosted categories of priorities and so many projects often possessed the same priority. This was stupid but inevitable in a bureaucratic state like Intel. Project Managers would push to ridiculous lengths to utilize my people and rack and ruin was threatened if I didn’t. It was annoying, but manageable. Sometimes keeping track of over thirty people made me a bit confused, so I was frequently reporting out my resource logic, writing on white boards, and working the team to see if they could just squeeze one more thing in. I tend to stay reasonably disciplined when dealing with these situations and had to say no a lot. However, I did try to stretch the system as far as I could until I could see my people get pulled into too many directions. It was always a fine line and someone was always there to second-guess whichever choice you made.

We succeeded in developing a lot of really cool tools, our reputation was back on track, and we were humming. I learned a lot more about the Agile development process and I started to feel like my head was above water. It took at least a year. I also sat in on a number of SAP training courses, but I must confess, it helped me little.

Getting back to the brewing problems, a re-org took place and caused some significant political blowback. My manager in Swindon had reported to someone in the U.S., but now, he had to report to another manager he loathed on site in the UK. My manager was very ambitious and had campaigned hard to report directly to our new Director in the U.S. His ambition and his ego could scarcely handle having to report to an Intel “lifer” who possessed a very bad reputation. This manager had a history of leaving bodies in his wake and thus created a lot of enemies in Swindon. The gossip was continually revealing that he had HR investigations ongoing for his behavior with past employees and his reputation as a back-stabber and manipulator was entrenched. From day one, my manager, David, and his manager, Brian played power games against each other, and each struggled to take the other one down. Just about every conversation I had with David was a monologue about the evils of Brian. David and I were friends but I wanted to keep a safe distance from the fray. Our team was doing well, Brian liked my team, and I never had to work with him closely enough to feel the effects of his reputation. My main beef with him was that he would not confront some of our most serious problems, especially with project priorities. That was more of a tactical frustration for me, though, so I was able to carry on largely unfettered despite the turmoil in Swindon.

Months later, David announced that he was leaving Intel and joining a company called Exigen which specialized in software outsourcing and consulting. They had recently bought out our outsourcing company in St. Petersburg and David likely got a good offer from Exigen as a result. Already, there was a curious entanglement developing that I couldn’t grasp just yet. Suddenly, Brian became my manager and a new set of uncertainties came to pass.

As David was nearing his departure, he called me and said something strange. He said, without being able to tell me more details, to have a “Plan B.” I started feeling a strange mood around our group about this, but couldn’t tell what he meant. I didn’t have much time to think about it since I was just about to start my 10 week sabbatical. Intel gives employees 2 months plus your vacation time off every seven years, so it was my turn to take advantage. I stayed in Russia for about a month, then went to the U.S., and then to Ukraine during my time off. It was then that all hell broke loose.

During my month in Russia, I started getting calls about people on my team leaving Intel. I was trying to keep a bit of distance from it since Intel largely requires you to stay away from work completely during your sabbatical. However, the more I heard, the more alarmed I became. One by one, some of our most skilled people began leaving… and they were going to Exigen. As it turned out, Exigen decided to set up an outsourcing center in Nizhny. Our outsourcer in St. Petersburg was the one who made it happen. The President was a close friend of David, so the whole situation started getting sinister. I couldn’t reach David, so I knew he was avoiding me. I guess our friendship was over at that point and it was all just business, as they say. Upon hearing of the exodus, our Director from the U.S. called me and commiserated with me about the growing disaster. He and I had always gotten along well and he committed to saving the team regardless of what happened and that I would be the one to stay on and fix it. Still, I had over a month to go on my sabbatical, so I had to grit my teeth and try to enjoy my time off knowing that my work world was falling apart. I probably had the worst sabbatical on record at Intel. I went back to the U.S. and then on to Ukraine, receiving reports almost every day about who else was leaving.

Finally, my sabbatical ended and I returned to work. Though not everybody who resigned left yet, I pretty much knew who would stay. We closed ranks and I reassured them that I would work “110%” to rebuild the team. Curiously enough, they seemed far less upset about the situation than I. I have to admit, I was devastated and shaken. I felt like I was betrayed by people I thought I trusted. Some of my best people and best friends left. I took it very personally. It was my greatest challenge to even show up to work each day. Still, I managed to keep a brave face and I think it helped the team feel like there was something worth staying for.

The most fundamental reason why people left is that they were terrified that all C#/.Net development would cease and that their true love would be taken away from them. Ironically, it was David who had brought SAP into the picture in the first place, and then caused all the ensuing turmoil. There were also rumors that the Nizhny team was inevitably going to be cut from Intel entirely. They felt it was better to leave now with an opportunity in hand than to get laid off later. This was never going to happen, but I think David had sown so much negativity into the group, that people were willing to believe anything.  Another catalyst was the historical leader of the group, Dmitry. I was brought in to help him manage the team. He didn’t like it much but went along with it as best he could. Gradually, though, many outside Russia lost faith in his ability to take over after I left. I was only supposed to be there 18-24 months, but seeing that the team couldn’t afford my loss and being that I still loved being in Russia, I was asked to stay on longer than expected. Once Dmitry learned this, he started to make his exit plan. The consequences of this were very Russian. Russians are clannish and usually stay loyal to the alpha-male. A couple years before, Intel’s head of marketing in Moscow resigned and took half the marketing team with him. With Dmitry leaving, many who had worked with him for a long time felt like they should follow him to Exigen, too. He was only one factor, though. Some of the people who left had already broken ranks with him, but he still carried enough weight to help tip the scales for several people. The last bit of irony was that everyone that left swore up and down that David did not spearhead this whole thing. I found it hard to believe, but what was done was done.

So after the smoke cleared, here were the casualty figures. We lost 20 out of the 32 people we had on the team at the time. We lost a large chunk of our most valuable people. We were pretty much wiped out. Fortunately, a handful of key people stayed. I had a short list of the remaining people in my mind. If any one of them decided to leave, that would be the end and I’d have to give up. They didn’t (and are still there to this day), so I had hope that we could turn this thing around. Another consequence of this event was that our Director flew over to England and fired Brian on the spot. I guess David’s master plan was complete. Honestly, I didn’t cry over it. Brian had so much baggage around him that it was bound to impact me eventually. If we were going to start over, I guess a clean slate was the better way to go.

At that point, I was asked to put together a presentation about how we were going to rebuild and how we were going to get Commissions tool rewrite done. I spent hours preparing for it and then presented it to the Director, his staff, and some other key stakeholders. Without patting myself too much on the back, I really nailed the presentation and got approval to move forward. I had a great plan, but I still needed the gumption. Fortunately, I had it despite quite a bit of stress. It was all in my hands now.

I still remember holding our first group meeting after the exodus. Normally, the room was filled to the gills, but now, there were 12 people sitting there. It was surreal. I explained that I was given full authority by the Director to rebuild the team. I was given several headcount and could start interviewing. We had a big project coming up and we had to gear up for it. The team seemed to get on with it and morale was surprisingly high. (I have no idea why, honestly)

For over a year, we had been slated to take on the next monster project of IT. The global sales force needed a brand new commissions tracking tool and everyone wanted us to do it. After the draining of our team, I though that there would be no way in hell that we would retain it, but we did. It was supposed to be project managed out of Swindon with most of the business analysts coming from there, so it was still the most sensible plan to team them up with Nizhny developers. It was also the case that the U.S. management had determined that we only needed 8 developers for the project, so our team could easily absorb it. I was given some headcount to fill some specific skill gaps, but I was not given full license to grow the team back to its previous number. Intel’s financial situation was slipping a little and IT was cutting back a lot, so there was little funding in the company to fund development projects. We’d just get by doing Commissions and not much more. It wasn’t such a bad thing since Commissions was going to keep us plenty busy.

Since we were starting with a clean slate, I decided to do a few things differently when rebuilding the team. The biggest complaint from outside Russia was that we were always a black box, communicated poorly, and would hire people with no buy in from outside stakeholders. In the past, Dmitry was famous for hiring people without telling anyone, a big no no at Intel. Swindon would cry out at times, “Who the hell is that guy and where did he come from?” This was my first time hiring for the team, so I decided to invite Swindon people to join my interview team. Two of my best colleagues took me up on it and we began looking for four new developers. We let the Russian team determine the candidates’ technical skills and then myself and my colleagues would interview for their soft skills. In the end, we hired some very good people and we got buy in from a wider spectrum of stakeholders. Swindon had more skin in the game than ever before and it helped us work better together.

I won’t go into the hiring process more except just to say that it was difficult to find a communicative software developer, let alone a good English speaker in Russia. We made some compromises, but overall, our team was much more outgoing and hungry to contribute to Intel.

To continue with Commissions, the project launched quickly and stakeholders weren’t much interested in waiting for my team to recover from our strife. The best developer, Stas, who stayed with us, took the technical lead position and began plotting out how to develop the application. The Project Manager, Alan, came from Swindon. About three business analysts were also located in Swindon. Our key customer who administered commissions for most of the company also joined the team. She was located in Massachusetts. The BA’s wrote the requirements and also received a lot of input from HQ in California. The list was absolutely huge. I was quite nervous about whether our shiny new team would be able to get up to speed fast enough to make a visible contribution early on. Earning trust early is always a key advantage. It didn’t take long to see that we weren’t operating at a fast clip and rumblings from afar began to come my way as to why. We had less time to maneuver than a lot of other projects. Most often, we would set a deadline for a project, but it wouldn’t be a disaster if it was late since most projects weren’t calendar-sensitive. However, Commissions had to be released by the beginning of the following year (about 14 months away) because it was impossible to use two different commissions tools in one fiscal year. When we started adding up all our estimates for completing the list of requirements, our forecasted end date was WAY past January 1st.

Recall a while ago that I mentioned that HQ had estimated that 8 developers could get the job done. This guess came from a consulting company and the number stuck in the heads of everyone and couldn’t be dislodged. As the project progressed with our 8 people on board, we were not making much of a dent in the requirements list (called the backlog). That was the prompt for doing what too many companies do when problems arise,.. look for a head to lop off. That head was mine. At one point, the Director went on Windows chat and lambasted me for falling behind. That was an extremely unsettling event. He then pounced on me in a conference call with most of the worldwide stakeholders in attendance. He blamed me for not hiring more people to staff up the development team. I was taken aback since no manager at Intel was allowed to hire people without headcount approved for them. You can’t just hire people whenever you feel like it. I tried to remain calm and responded that I would be happy to hire more people upon approval. I guess that was my approval. Two people from Swindon called me afterwards wondering if I had survived the show trial and admitted that they would have crumbled to dust if it had happened to them. They were fairly outraged at what happened to me. Believe me, I felt like crumbling to dust, but I guess my skin was getting thicker over the years. I went ahead and opened new reqs for developers and started hiring more. It took me a long time to get over that dressing down. This is an area of improvement that I really want to work on. I actually think the Director felt like his butt was on the line more than anyone and I happened to be walking by when he decided to throw a grenade.

We brought on more people and grew beyond 8 developers for the project. Though we passed this imaginary line, stakeholders still felt that this should never have happened. I felt like I was carrying a Scarlet Letter after that. Eventually, though, people in HQ finally started seeing the light. Our chief sponsor in HQ left Intel and a new guy came along. We barraged him with explanations of why the resource estimate was completely off. He finally understood and agreed to expand the team even further. At its peak, we had 22 developers on the project. Four were added from India, four were added in the U.S. and our team grew to 16. People finally realized that I wasn’t so stupid after all.

We still got nailed repeatedly for going too slow. I agonized over this. It was clearly possible that we had too many new people on the team and that they weren’t up to speed. I held numerous conversations with Stas to figure out what was going on. He did his best to explain that they were creating a complicated but very powerful architecture for the application and that this would take time in the beginning. In the Agile process, the team estimates how much work they were going to do in a given week. Multiple times, we came up short. I instructed them to be more conservative on their estimates which helped a little, but the spotlight was still stuck on us. When we added the Indian team to the project, they were frequently outperforming us and it was noticed. We investigated further and found that they were skipping a lot of steps and straying from our standards. Once we trained them more, they started to slow down a little. Though it doesn’t sound like one, it was a victory for us. Perception is reality, as I’ve said before, and it looked better if both India and Russia were working at a similar clip. As a side note, I must mention that somewhere in this timeframe, the Project Manager, Alan, became so stressed out that he had to take sick leave and get counseling. That’s how crazy this project got.

Though pressure eased off a bit, it was still there. To combat this, we decided to let two external parties audit our code and our methods. At the time, Microsoft was bugging me a lot to come in and tell us how they could help us with our development. Of course, they were wanting to sell us something we didn’t want to buy, but I did work with their European Director to get them to review our work for free. (this was a long game, but it worked) When they looked at our code, they were extremely impressed and felt that we were on the cutting edge of design and code quality. The code was also highly maintainable. It’s a very important concept in software development. To be maintainable means that code can continually be added on to the design without making the architecture a mess. In the long run, this made development and updates go faster and make the code more bug free.

We then also contacted the head of the Agile Users Group inside Intel who was located in Arizona. He was considered to be the expert in the company on Agile software development. Our team admired him and wanted him to look under the hood. Upon review, he was amazed at what the team was doing. We got his blessing, too, so things were looking up. Needless to say, I beat the drum HARD to every last stakeholder about these two endorsements. The India team was even giving us good reviews, so this trifecta redeemed us in front of the entire organization. The pressure valve was finally released. We stood justified for our work and people finally got off our backs.

Regardless of quality of work, there were still more requirements than time. We had to start making some hard choices about scope. We had wanted to build both a client tool and a web tool for the application. The client tool was meant for the commissions administrators who needed a very fast interface. We needed the web tool so that we could make it easy for the salespeople to access it. We didn’t want to make them install a client tool on their laptops since it was a lot of overhead to make sure they set it up properly. This tool was going to thousands of salespeople and we feared that there would be a huge problem getting non-technical salespeople up and running without too much trouble. We started talking about canceling the web tool for the first release since the client tool had a higher priority to be released. The client tool was also easier and faster to build. I’m a personal enemy of releasing a client tool to the masses. Intel had too many of those littering our environment and most of them sucked. I really winced when we had to communicate this idea. I though there would be a huge backlash. While there was some whinging, we actually got the approval and overcame a big hurdle. We had also wanted to release most of the tool by January 1st. However, it was clear that we couldn’t do that either. We went back and started figuring out what we absolutely needed by what date. Our review showed that we only needed a specific portion of it released in January specifically for the commissions administrators. By February, we needed a little more, and finally not until March did the salespeople really need to use it. With that analysis, we re-planned our schedule and released the tool in stages. Oftentimes, users didn’t even notice that we were continually updating it behind the scenes since they couldn’t see missing features if they didn’t need them yet or even know that they would exist in the near future. It was a very clever plan and the backlog finally got under control for us. Once Q1 started, we phased out the old Commissions tool and phased in the new one. It occurred quite seamlessly. We even developed a very easy installation process for the salespeople and there was nary a peep from them about problems. The release was almost anti-climactic since it went quietly and successfully. Normally, we did a lot of celebrating when we released something, but I think all of us throughout the organization felt like there was just too much more to do to feel like the job was “done.” I left Intel in May of that year and we were still busy working on it. In fact, it continued for the rest of the year and even three years later, the team still has resources dedicated to it. All in all, it was a successful project and most of the salespeople at Intel today use the tool we made. I got to see a project from conception to release, bore the political burdens and overcame them, and got to watch a lot of talented people make something out of nothing.

Other Parts of the Job

While all the activities above were going on, some other activities were operating in parallel. Amidst everything, we kept a small SAP team on board, hired two new people for the effort, and actually began delivering SAP releases extremely successfully. The other activity was my extensive work with the team to improve their leadership and communication skills.

Despite the grand exodus and flight from the SAP monster, there were still three people left behind that wanted to continue doing SAP development. Only one was a permanent employee and the other two were college interns. None of them were programmers, so they felt no need to leave Intel like the others. We still had a Salesforce Automation project to complete and for whatever reason, our stakeholders let us continue with it despite the loss of resources. I managed to get approval to hire one of the interns and then go externally and get another person. This was all going on when I was trying to hire C#/.Net developers, so it was a trying time. I included growth in SAP development in my presentation to the Director and he let me move forward with that too. (I must mention here, as I just thought of it, that our Director, though mercurial, really loved the Nizhny site and wanted Intel Russia to be successful. He loved to visit Russia, drink tons of vodka, gamble, and play pool all night with my team, too. If he hadn’t felt this way, we would have probably been dead.)

At this point we now had two direct hires who knew the project and had been trained well in SAP and one new hire who had experience in a similar enterprise system but didn’t know SAP specifically. There are very few SAP people in Russia, especially outside Moscow, since the regional economies in the country are still quite behind the West. We hired the new guy because we felt he had good aptitude, a great attitude, and he was Stas’ brother-in-law. (that’s how it works in Russia. Intel Russia was full of family members) Mikhail was nothing short of miraculous. He learned SAP very quickly and even had to learn quite a bit of English along the way. I don’t know how he did it. The three of them plus one intern were actually able to produce an outstanding release and received huge accolades for their efforts. We were seriously under-resourced and we still got the job done. I’ve never seen such driven people in my life. Andrei and Katya worked tirelessly and it scared me a bit as to how hard they worked. Katya was only 22 and just out of college. She is still one of the most brilliant people I’ve ever met. All the planets lined up for me on this one. I got them most of what they needed, especially the political support, but the rest was all them. From that point on, IT started looking at my team as a very important part of SAP development in the company. Since we hired most of our people from one of the local universities, I worked closely with the professors there to put SAP into their curriculum. I also obtained $10,000 from our University Relations department to fund their startup costs. The news made the local paper and TV and to this day, the Higher School of Economics teaches SAP at their university. Again, humility evades me. I did all of that along with Katya. We really did something special.

Leadership and Communication

The other activity was building leadership and communication skills. This started before the exodus. I chose some of the top people in the group and offered the opportunity for anyone else who wanted to improve themselves to join. At least 12 people participated. First on the docket was presentation skills. I needed them to be able to communicate with their Western stakeholders better so that they would be taken seriously. I wouldn’t be there forever, so I couldn’t do all the talking for them. They would have to take care of themselves. With that, I rotated them through multiple sessions per week and had them practice making speeches and writing PowerPoint presentations. It was painstaking work. I had to break bad habits (Russians have terrible presentation skills. Their entire communications culture has been learned by watching aging Communist bureaucrats reading hour-long speeches that would bore anyone to death. I saw it everywhere I went.) I made them practice extemporaneous speaking, operations reporting, influence and recommendation presentations, etc. I also made them write PowerPoint presentations about their own areas of interest at work and taught them how to engage the audience and excite them to adopt their views. We went over and over and over on this until they were blue in the face. It lasted several months. I then invited a smaller group to read a book on Leadership. There were 18 chapters on 18 specific themes. We took one a week and discussed the topics in every meeting. It made a huge impression on them. One of my former colleagues told me, close to two years after I left, that they still held the speaking sessions. They call it “the Molinari Repetition” since they realized how important it was to keep practicing over and over. I was very touched. Even as several of the people were leaving during the exodus, they came up to me privately and said, “Please don’t take this personally, us leaving was not your fault. I will never forget the leadership and communications lessons you gave me. They were some of the best things I ever learned.” I guess it was good that they said this because it was the only thing that kept me from killing them!

Key Learnings

I learned soooo much during this job, I don’t know where to begin. At the very least, I learned how to work with a different culture and to overcome the added difficulty that always transpired. Everything was harder. People wouldn’t understand me, bad cultural habits got in the way, and an enormous number of problems emerged that had to be solved during my tenure. If I had had the same problems in the U.S., it would have been half as hard to fix. I learned persistence more than anything. Living in Russia, working in Russia, surviving in Russia always required an extra push. That’s why I came home so confident in myself since I felt like I could handle anything that came my way.

I really learned leadership. Even when everything looked doomed and people didn’t believe that things were going to work out, I still succeeded. Many times in the past, I had wilted when the pressure got too strong. I was able to get past those older barriers more effectively. I still have a long way to go, but I did get a lot of good hard, experience under my belt.

I also learned a lot about politics and doing really big things. The bigger the thing, the greater the politics. I learned to expect pushback whenever I was trying to do something new or challenging and I managed to navigate through the complexity, the personalities, and the blind corners.

I also learned a lot about software and Agile development. I’m still not very technical, but I understand how much of the process works. I know how to get into something new and learn enough about it to make a contribution and I know I can do it again.

Performance Review Accomplishments

These were the line items written in my performance reviews during the times described above:

  • Project Management:  Dave allocated resources and supervised several projects that completed successfully.  Those included CRA, TDF, ISMC, FIRST, eSales, and MPES.  Though Dave moved to EAS during the year, he continued to own the resourcing, outsourcing, and stakeholder management for all BAS projects since the local BAS manager was struggling to do it alone.  He also drove TDF business stakeholders to accept the need to do a technical release in order to repay technical debt.  Though controversial at the time, it has proved to be critical to the success of TDF.  The impact of this is that the Nizhny team delivered quality applications to its customers and empowered the team to take ownership of the quality level of their projects.  Without Dave’s vigilance and direction, most projects developed in Russia risked failure.
  • Process Improvement:  Dave diagnosed several problems with project planning within the CBS Prioritization Team (including NN).  He worked with key stakeholders to create (actually re-formulate) a comprehensive “rules of engagement” that was ratified by CBS.  As a result, all groups benefited from a dependable process that caused better resource planning, clearer expectations amongst groups, and a needed discipline so that operations could run more efficiently and with less frustration.
  • Quality Improvement:  Nizhny software quality was challenged during the year and Dave took strong measures to address the issue.  Dave gathered important quality indicators, analyzed specific projects, and reported out results to upper management.  This resulted in an improved assessment of NN’s reputation, but more work was needed to make quality a more proactive effort.  Dave worked with stakeholders to build a comprehensive view of how quality should be measured and perceived.  He drove an internal team to build a dashboard that measures key areas of success on an ongoing basis.  While all is not finished, Dave has instilled an attitude within the NN team that quality must not only be committed to, but measured and proactively communicated to outside stakeholders.  This will continually improve NN’s reputation and effectiveness into the future.
  • Mentorship and Management Improvement:  Dave created numerous activities for developing and improving employees’ performance to Intel values and enhancing management and leadership skills.  Dave initiated a more comprehensive MBO planning process, developed a new culture that was created collaboratively with the team, and repeatedly mentored the team to contribute more proactively to their reputation and future. Dave conducted numerous leadership workshops with the management team and also created a communication program where several key team members were invited to practice their presentation skills every week in order to advance their ability to communicate to outside stakeholders.  With these efforts, the team has begun to improve their strategic thinking abilities, have learned better ways to influence, and have honed their presentation and English skills.

Information Security Experience

Information Security

Role Description

My job description expanded with the added role of managing the division’s information security operations team. This was a global role responsible for 30,000 Unix/Linux systems across 51 sites. I retained my core job but was able to add the additional responsibilities since I had developed my local team into a strong, self-sufficient group that could manage themselves.


In one fell swoop after an extended vacation to Nepal, my boss met with me and told me that I was now put in charge of managing our organization’s information security team. I knew nothing about information security and told him so. He encouraged me to figure it out… fast! The role was to implement security measures to our Unix/Linux environment by direction of our division’s information security team. I quickly assembled a team at our multiple sites and began organizing the work we needed to do. In order to succeed, I took several important steps to build the team.  They were:

  1. Create a team charter
  2. Develop ground rules and team norms to set expectations on how team members should work, interact, and perform.  It was both a top down and bottom up exercise.  I needed to set expectations as a leader, but the team needed to contribute and buy in to these rules.
  3. Create clear goals.  This required pressing the divisional team to do the same.
  4. Develop roles and responsibilities so that team members and their manager knew what was expected of them. Most did not know what they were supposed to do at all in this area since the work required was unfamiliar to them and the division was too far removed to engage with them effectively.

Figuring out what the goals were from the division was not easy. As we began communicating with them for direction, we found huge gaps in how we were supposed to conduct our work. Requirements were fragmented and instructions were non-existent. We were still held to deadlines, but the quality of work and assistance provided from the division was weak and nearly useless. I made several complaints and gave numerous suggestions over the course of a few months in order to improve the situation. Division sensed that I had a strong grasp of what needed to be done and how to do it, so they eventually appointed me in charge of the program. This was a big step in my career and my responsibility level skyrocketed instantly.


I was given 21 Unix administrators for my global team that were located in nearly every part of the world.  Those representatives were located at the sites below.  These administrators supported 51 sites in total.

North America:

  • Hillsboro, OR.
  • Dupont, WA.
  • Folsom, CA.
  • Santa Clara, CA.
  • Chandler, AZ.
  • Hudson, MA.


  • Cavite, Philippines
  • Bangalore, India

Europe, Middle East

  • Copenhagen, Denmark
  • Haifa, Israel


In order to move such a scattered group forward, I needed to establish effective communication and approachability with the team members as a group and as individuals.  I set up meetings with each one of them, got to know them and their daily challenges, and then began piecing the team together. I also met with their managers in order to get their buy in since I would need to take more of their employees’ time and focus. Without this, the administrators would inevitably get pulled into local issues that always crowded out global ones. This was not an easy task. Upper management was good at creating programs that required results, but did not create a system of accountability to make it happen. I had to do that on my own to get results.

Specifically, I did two things that aided this cause:

  1. Embedded my goals into the administrators’ quarterly objectives
  2. Presented status regularly to upper management about my program’s efforts

Both these steps helped me gain visibility and commitment from my many stakeholders. As a result, information security became a formal part of my team members’ jobs. Middle management gained scrutiny by our divisional director when I would report out in their staff meetings on my progress. If some regions failed to get work done, these middle managers were told to get committed and devote resources to the work. I leveraged another important piece of the puzzle, that of working with a staff manager as my sponsor. Without her, my job would have been much tougher when trying to deal with the middle managers who preferred to worry about their own priorities.

I did the same thing as I did for my regional team, i.e. creating a team charter, ground rules, goals, etc. and then set out to get the work done. Still, there were more challenges to overcome. Many of the administrators had little experience in information security themselves and were frequently unable to implement the measures recommended by the security architecture team. The architecture team was made up of extremely skilled security experts. They did not have any patience to help my people out and possessed no sense of how to enable people to perform their duties. I had to leverage them in a productive way and so I pushed to become an advisor on their team. Upon joining the team, I pushed for two important things, 1) Get my team trained properly, and 2) Get the uppity security experts to write documentation and teach my people. To get the training, I investigated the various resources available that an industry consortium provided. I managed to secure numerous training books from them and also flew in my team members to the U.S. to take an extensive training course. This brought us very far, but I still needed cooperation from the security experts. I met with them individually and made my case for how they could do some upfront investment in documentation and teaching that would create a more self-sufficient team. Their constant complaint was how inept my team was, so if they could take a few steps to fix this problem, then they could get past this irritant, and move on with their desired duties. Slowly but surely, they began their work to document how to do a long list of measures that I had collected into a master plan. Simultaneously, I would go to the divisional staff meeting and explain clearly the scope of work needed to be done and what I needed to get it done. Soon, I was getting support from above and a growing cooperation from below. I kept a tight measurement system going about what items we had completed in each region and each site. As I checked off more and more items, the security experts could see that we were making real progress and became more helpful in continuing the momentum.

I made an organizational change that also aided my work. Running meetings with a global team was extremely impractical due to time zone differences. Those far away were having the most difficulty achieving goals due to communication problems from the center. I split my team into two so that the meeting times were more agreeable to international team members and attendance and attention improved. I also appointed team leads for each of these groups who helped me keep discipline and communication going within the team. These two leads sat in time zones that could communicate better with my remote sites. I also gave them more training and an open door to contact the security experts. They relished their roles and improved drastically the functioning of our larger team. To supplement the attention needed for the remote sites, I stayed online my entire waking hours so that anyone could call me at home or at work for help.

We made tremendous headway, but we still had a number of measures that never quite got done. I needed to increase the awareness of these gaps to upper management, so I tried a new method. I wanted to put some peer pressure into the system so that the different regions could feel a sense of competition with their fellow regions. I created a program called Site Certification to do this. Since I had a comprehensive list of everything needed to be done at all 50 sites, I developed a “certificate of completion” for each of them. As each site completed their deliverables, they would receive an award in the divisional staff meeting. Each region owned numerous sites, so seeing other regions achieve certification could compel them to work hard to outdo their peers. The program was approved by division, but by this time, we had really gotten closer to achieving our goals. I had been regarded as an extremely successful program manager and was ultimately given a brand new mess to fix. Site certification didn’t proceed as formally as I hoped, but it lived in spirit. When I left the team, my leads kept it alive at a lower level for the months to come. They achieved all the goals eventually, so though it didn’t happen as I had planned, the work got done and the overall program was a huge success.

Key Learnings

Out of this experience, I gained several new skills and lessons. First, I learned how to lead a global, multi-cultural team effectively. I learned the best ways to communicate with people from far away and to understand how to motivate them and remove barriers for them. I also gained great experience in setting a direction, tracking progress carefully, and developing a very clear understanding for my team and stakeholders of the work that needed to be done. I also sharpened my skills in working with multiple levels of management, getting buy in, and putting goal pressure into the system. Additionally, I learned to work with very arrogant, prickly people, turn them around, and get them to cooperate and help. I also gave all my team members a sense of purpose, mission, and pride. I worked with very enthusiastic people and I think I created the environment that cultivated it. I also gained valuable experience in getting tasked with huge amounts of ambiguity. I didn’t know anything about the subject matter, I didn’t know how to motivate people across the world, and I didn’t know how to get such a large and vast body of work completed. I worked hard to learn these things, (granted, by getting a lot of bumps and bruises along the way) and got results. I think this was one of the best achievements in my career.

Performance Review for my Security Efforts

  • Dave became the leader of the EC Security Operations Team (SOT) and really focused on driving process with the SOT and keeping the team on track.  To bring structure to the team, Dave developed the team’s charter, job description, and set clear expectations.  Dave communicated with each member’s direct manager to gain their support and commitment for security activities.  He set up meeting structure to ensure full participation (East/West coast) and worked against quarterly objectives.  He also developed two members as team leads who are responsible for running weekly meetings and drive completion to action plans.  Dave grew the SOT from 12 people to 21 and increased the number of sites owned from 35 to 51.  Dave worked with the Security Architecture Team (SAT) to try to define process and process and procedures for requesting and working with the SOT members.  Dave played a key role in trying to manage the time the SAT is requesting from the SOT for new projects as well as keeping them on track with their regular security operational tasks.  EC improved Unix audit scores from 85% to 90%, moved sites to nearly 100% ssh and chpasswd usage, drove central logging to 36 sites, and conducted numerous audits.  The impact is that the EC organization has moved to an unprecedented high level of security compliance which significantly improves the protection of Intel IP.

Asset Management Experience


Role Description

After leading the information security team successfully, I was asked to lead another program that was in sore shape.  The Asset Management Team was in desperate need to account for all their assets in a short period of time.


Due to Sarbanes-Oxley requirements, Intel had to account for all of its assets. Our division was struggling to complete this task, so I came in to make it happen. We needed to physically track every computing asset that we supported worldwide. The number was over 30,000 systems. It sounds a bit funny, but all these systems were accounted for on the network, but we simply didn’t know where all of them actually resided. We had to look in every nook and cranny, under desks, in data centers, etc. until we could find every one, bar code it, scan it, and then make sure it populated into our asset database. Once we achieved that, we had to dump the information into a master database for the entire company. Each step created challenges.

Getting It Done

I was given a team of about 16 people that represented all 50 sites we supported worldwide. I had to take over from the division’s asset manager who simply became overwhelmed by the task. She stayed on the team to help. Sometimes that was good, sometimes it wasn’t. She was tirelessly dedicated to her job and lived and breathed this type of work. She just didn’t have the skillset to take on a global project. She was a bit resentful of me taking over, but did manage to handle the situation maturely. The only real obstacle was that she had a very narrow view of how to get the work done, narrow in the sense that her ideas were too big for what was required. She was ex-army, rough around the edges, and had no political skills. It was going to take some special care to keep the project focused properly. I had to balance the raw objective of getting the assets tracked with her desire to create a comprehensive asset management process. Normally, I liked to do that sort of thing, but we had deadlines and I had to choose wisely when to leverage her ideas and when to cast them aside.

One luxury we had was an actual database administrator who could customize our asset tool on the fly. He could make bar code scanners work better with the tool and could manipulate the system so that it could upload our data to the master system. He was generally a reliable order taker, so he made my job a lot easier. For the rest of the team, I got a representative or two from all regions to pound the pavement and track the assets. In comparison to my information security program, this was on nearly equal footing in global reach and scale, but it was still a simpler job. It took less time but still managed to create a lot of headaches. I didn’t need to study asset management or train my staff. It was a fairly straightforward task, but the enormity of the asset base and a zillion little, pesky problems required a large percentage of my time.

Once again, I used my experience in starting up teams and programs and set the charter, ground rules, responsibilities, and goals. As before, this work was considered a second priority for my team members despite the fact that we had a legal requirement to get the job done. I had an entirely new stakeholder to deal with, i.e. “Mother IT” who loved to control everything and was a huge morass of bureaucracy. It was hard to even find who was responsible for what and to know who mattered and who didn’t.

To the regional middle managers, this was a necessary but mundane task to provide resources for. It was therefore even more important to make my goals visible to upper management in order to get commitment. The team members were reasonably motivated and ultimately enjoyed contributing to the effort.

I did have to do a little homework. There is such thing as an IT Asset Life Cycle. My asset manager was hopelessly devoted to it, so I tried to humor her by learning it and trying to implement the steps suggested in this model. My memory of this portion of the program has faded significantly. I know we analyzed a lot of flow charts and wrote a lot of documentation, but I can’t remember how it all contributed to the effort, honestly. I think it did help to have this as a foundation, since it assisted us in dealing with asset procurement and making sure anything new that came in the door was tracked properly. It also helped establish a process for retiring assets and making sure they were removed from the system. As it turned out, these two parts of the chain were what caused us to get into a mess more than any others. Bottom line was that this program was more than just hunting down assets, it was intended to be a platform for making sure all assets got handled properly throughout their lives.

After the launch of the team, I needed to find ways to measure status and progress. There were already a few thousand assets tracked properly, but the reporting was not very robust or reliable. I had to give this priority to our DB admin beyond most other duties. Most people were hot and heavy about getting items scanned. I had to refocus the team to make sure we had a useful metrics system. No metrics, no management support. Once we did get our first run of useful reports, it showed that some regions (like the asset manager’s region, for instance) were in great shape and mostly needed to clean up some stragglers. Other regions were a complete mess, especially Europe and Asia (and my own region!). I had to learn the right methods and then extrapolate them across the entire division. Some regions didn’t even have bar codes and scanners, so buying those and distributing them was one of the early orders of business. Once we knew where we stood, I gave my first presentation to divisional staff about where we were. I got good attention to the matter and commitment was less difficult this time around since it was less complex, could utilize less-skilled technicians, and had Mother IT breathing down their necks. Still, some regions continued to lag behind, so I had to increase awareness by sending out regular reports to divisional and regional staff.

As mentioned above, we had to get the data in front of people in a clear and concise way. We really hit the jackpot when my French representative on my team created a masterful looking e-mail interface for our report. Every week, we sent out a beautiful, clean, and useful report on what percentage complete each region was. It was our best and most effective weapon. I hardly had to do any convincing to middle management since our divisional director got the same report and could see plain as day how his management team was performing to goal.

Along the way, we had several irritating problems. Sometimes the bar code scanner didn’t work, sometimes the assets wouldn’t load into the database properly, sometimes we knew we had assets on the network but couldn’t find them, and sometimes we just couldn’t get all the data to transfer to the IT database correctly. There was a lot of painstaking work to prioritize the work, get the right fields to populate, and get the regions to follow procedures we put in place. Bit by bit, the database admin got closer and closer to making the tool work more reliably and the screaming from IT became less and less.

The other difficult problem to overcome was to make sure the entire division embraced the asset life cycle process. Technical support engineers were constantly buying or borrowing computing assets from every direction and plopping them on the network. They’d also take them off the network, stick them in a closet or send them to another site and do nothing to track their physical locations. We had to create a thorough process that wasn’t too overbearing but could close all the gaps that humans create for themselves. To this end, we documented a very solid process via a great amount of feedback from engineers at the sites. We also had to put together an enforcement policy so that the process would stick without having to chase people around all the time. We had to automate everything we could. This is a difficult task when talking about physical locations of items that can be moved willy nilly at any time. It was especially difficult in Europe since many of the sites were small and didn’t have the personnel to watchguard the process. Once we did get a reasonable process in place, we set up training sessions across the globe to make sure people were doing things properly. We also set up a way to cross-check the assets we showed on the network with the assets we showed in the asset database. Whenever we had a mismatch, we required my asset management team to investigate it and work with the local support engineer to account for the system properly. Gradually, we closed more and more holes and the accounting of our assets improved quickly.

In some cases, we had to fenagle odd computers so that they would report all the data that IT required. Some systems would easily report out information such as serial number, model number, operating system, hardware configuration, etc. quite easily. Others didn’t. We had to enlist savvier engineers to develop scripts to pull that data out on a case by case basis. Again, this was a painstaking process that often seemed to be a situation of managing exceptions rather than managing the norm.

The last step in the chain, that of dumping our data into IT’s central repository, became a pain in the ass, too. Suddenly, things became political since IT was objecting to our division having its own database. They just wanted us to load our system information into their repository directly. There were too many reasons why we couldn’t do that beyond just the time required to shift gears entirely. I had to get upper management to fight that requirement off. I also worked hard to solve our data transfer problems so that it would be one less thing for IT to complain about. If we could make the transfer work flawlessly, then they would likely leave us alone. Ultimately, that strategy worked. Once we fixed our irritating database problems, the data transfer became routine, they saw our data loading and catching up with all the other divisions, and what was done was done.

In the end, our weekly status reports revealed where regions weren’t performing and enough pressure was put on them to address the problems. I didn’t have to be as much of a bad guy as I did during the information security days. The data spoke for itself. We grew closer and closer to the 90-100% goal in place for tracking our assets and the urgency and hysteria in the program began to wind down. The timing was good since I reached a point where the program could manage itself and my division could prepare itself to see me go on to Russia.

Lessons Learned

As usual, I had to learn how to work with a prickly personality. There’s always one in the bunch, it seems. I found the right balance in working with her. I really wanted her to feel like her opinon mattered and that some of her grandiose plans could be realized. That kept her motivated and supportive. If I had lost her support, she could have brought the whole program down. I had many leadership and management techniques that I could teach her so that she could see how to get things done without acting like a drill sergeant. I think she appreciated that and made it much easier to get her on board.

I also reminded myself how valuable it is to get something to measure as soon as possible. Data draws attention to itself and requires a lot less manual intervention to convince people what goals and behaviors are needed. Getting the team to contribute instead of just having them take orders is another valuable lesson. I can’t tell you how pleased I was to have my French team member create that report. It was a striking moment for the program and I will always encourage people to use their creativity and inherent desire to help as much as possible.

Finding the right people who have the right skill at the right time is an invaluable instinct to have. I seem to possess this skill fairly well and so it’s always good to reach out to people you don’t expect can help to come in and save the day.

Lastly, despite the grandiose plan my asset manager had, I was very glad I didn’t skip over it too much. The IT Asset Life Cycle created a great foundation for our work and it gave us more credibility when people saw that we were using an industry model as our process. Sometimes, people get turned off by this, so you need to use this wisely. But in this case, using a tried and true way with some theory behind it gave us that extra strength to convince people we were doing the right thing.