IT has announced the work-from-home policy and site strategy we've been hearing about for the last year or so. There we no real surprises, and most of the rumors were accurate. There are preferred locations for IT work around the world, and everybody is expected to be in the office at least 4 days/week, with one day as a work-from-home day (with your manager's approval). Having higher numbers of IT people at specific sites makes a lot of sense. You get more density of people at a single location, likely working on similar projects.
The idea that everybody needs to be in office 4 days/week is raising a lot of questions. We haven't gotten a good explanation why someone who doesn't have any peers or internal customers in their office can't work from home most of the time. If you have a job where you're working by yourself or are always on the phone, how can it possibly make any difference where you sit? These situations are rare, but the new policy comes across as "because we said so" rather than something based on logic or reason. I get that allowing someone to work from home sets an expectation that they may always be able to do so. And it puts managers in the position of having to answer questions of "why her and not me?" and "what will it take for me to get a work-from-home job?" So from the perspective of consistency, this makes sense, but needs to be better communicated.
It's also kind of funny. Years ago when IT and eBG starting moving our jobs offshore, they told us that it didn't matter where people sat, and that since we were all connected we could work from anywhere. "This is the future" they said. Many of us were not convinced, and complained that by breaking up in-tact teams it would be more difficult to get work done. That not being able to solve problems with small, co-located work groups would slow us down. That the kind of brainstorming breakthroughs we take for granted when face-to-face would not occur on the phone. We were convinced that efficiency, team affinity, quality, and results would all suffer.
"Nonsense!" they said. "You guys are stuck in your old office-bound mentality. If you can't make this work, then you don't want this to work! In the Internet age people will be working from home, or on the road, or anywhere else they can get connected." But now the reasons they're giving for wanting everyone back in the office are exactly the reasons we gave for not waiting to send work offshore: lack of efficiency, poor teamwork, and bad results.
As we watch the slowly moving pendulum of irony swing back the other direction, you have to wonder if JJ and those on IT staff have any sense of how absurd this all seems.
Saturday, August 18, 2007
C U When U Get There
Posted by
Intel IT Guy
at
7:44 AM
21
comments
Labels: leadership, management, people
Wednesday, July 25, 2007
Who are you? (Who who, who who?)
I have a post written about some of the upcoming challenges IT is facing, but after reading the comments from the last couple of posts, it seems clear that many readers aren't really sure what most IT people do for a living at Intel. Many of my posts have have assumed this is common knowledge, which is my bias showing. PC and server support are clearly important to Intel (and any other corporation), but they are not all IT does, and account for a relatively small percentage of IT resources and budget. My goal here isn't to be defensive, but to provide a baseline so there will be some context in future posts.
As some commenters pointed out, IT is pure overhead - it's not Intel's business, and it doesn't generate revenue. But IT is nonetheless essential for Intel to conduct business. We do almost 100% of our business via eCommerce - billions of dollars worth of transactions flow through those systems. Who built those systems? Who maintains them? How do we know they're accurate and reliable? The answer is that it's mostly IT. With all those transactions and products moving around we can get our revenue numbers each quarter to a fraction of a penny. I couldn't begin to explain all the complexity here, and it doesn't begin to compare to the complexity of a processor, but it's still complex. And for the most part all these apps run reliably. The same is true for our planning tools, sales tools, and HR systems. Like any other large corporation, we have thousands of databases that all need talk to each other. Some are purchased apps/databases (SAP, Peoplesoft), some are custom, and many are hybrids.
IT has hundreds of application programmers: A lot of people who write SQL, VB and C#, a few C/C++ programmers, and ton of people who customize code for tools like SAP. There are also database design and architecture people. Practically none of our business apps know how to speak to each other natively, so we have to design the data and interfaces to make them compatible, or have them share data via some middle-ware tools. We also have a lot of database support, network support, information security, and business specific tool support people.
Each group at Intel has a set of tools they need (or want) to run their business, and it's IT who people design, develop, implement, and support them. This includes all the work done for Intel's external web sites as well. Sales and Marketing must have hundreds of tools supported by IT. In addition to developers and database people, you need project managers, some program managers, QA people, release management/integration, and application support. We also need to release regular updates of purchased tools. Enterprise upgrades aren't a matter of just slipping a DVD into a drive: when a app is highly customized and/or integrated with other tools, it can't simply be upgraded. The ripple effect may required changes to dozens of other tools, which creates a ripple effect for development, testing, release, and support.
The picture I'm trying to paint is one where there are thousands of applications and databases that run Intel's business 24x7, most of which are undergoing upgrades and changes on a regular basis. Every week there is some kind of huge application, networking, email, security, or other change/upgrade taking place. The IT environment is anything but static.
A question I hope you're all asking by now is: why? Why is the environment for Intel business so complex? Why do we have so many changes? Why do Sales and Marketing (and Finance, and HR, and the product groups require so many tools? And why can't we just buy tools off the shelf and implement them and save all this development and integration cost? I'll try to address that in my next couple of posts, but will give you a hint: it's not IT who decides how many tools the business groups need, nor when a purchased tool isn't adequate.
And btw, I don't begrudge the engineering and manufacturing their place at the top of the Intel food chain. Some brilliant, dedicated, hard working people are designing, testing, and manufacturing amazing products. But once they're doing designing and building them, they have to go out the door. How they get sold, accounted for, and supported all requires systems that IT require IT people to support them.
Posted by
Intel IT Guy
at
6:23 AM
12
comments
Labels: efficiency
Friday, June 29, 2007
Pieces Don't Fit Anymore - follow-up
The last post generated a relatively high number of comments, and I want to address a few of them. Someone made the point that employee blogs don't contribute to productivity. As measured by what? I have no idea if my blog helps productivity, but I like to think that it isn't hurting any. I'm fairly sure that Jeff M's internal blog adds a lot to productivity. At the bottom of a previous post I mention why speaking out can help. If people feel some empathy from others, or have an opportunity to vent, or realize that they're not alone, how can that not help? I can't speak for this blog, but I know other blogs have had an impact on management decisions and communication. If people feel that someone else is speaking out and it makes them feel better, how can that not be good morale, and therefore good for productivity?
I found it almost quaint that one commenter seems to think that IT is around to fix laptops. There's no point in me trying to defend the role IT plays, or to compare the value of IT to Intel manufacturing. IT is a pure cost center, and needs to be run as efficiently as possible. If you don't get why losing people at the top of the performance and skill set pool is bad for Intel, then I can't explain it to you. There actually will be impact beyond getting your laptop fixed.
The only comment I considered blatantly incorrect was the one stating that employees with over 10 years experience add less value and don't have good ideas. No doubt there is some dead wood at Intel, but if you've been there more than a couple of years, it should be obvious that length of tenure is not a factor in focal. Everyone is required to be competitive. There are a few places people can hide for a while, but the process is fairly good at eventually identifying below average performers. One indicator of innovation at Intel is invention disclosures and patents. Go take a look at correlation between patents and tenure, and then get back to me on the lack of fresh ideas from experienced employees.
And then there was the commenter who wrote:
It's damn annoying to keep reading complaint after complaint from those in a service organization lamenting about how hard they have it. What, not enough time to work on your level 32 Dork-Wizard on World of Warcraft?
which I found quite funny. He also pointed out IT people are expendable. True. But he may want to consider that, like all Intel employees, he is expendable as well.
Posted by
Intel IT Guy
at
6:12 AM
5
comments
Wednesday, June 20, 2007
Pieces Don't Fit Anymore
I've been having conversations with people recently about whether or not IT staff actually wants people to leave, and if their actions are encouraging them to do so. As I mentioned previously, attrition seems to be high. We're hearing that IT wants their employees to work at "hub" sites, and will be getting more restrictive about allowing people to work from home. Nobody really knows what this means yet. The impression by IT employees is that these changes will have some impact on convenience, flexibility and work/like balance. Are we being told that we need to work elsewhere if we want these perks?
Intel is unique for many reasons, and one of most unique features has been they way that many, if not most, employees approach their jobs. Intel instills sense of ownership for solving issues that most other companies do not. If there's a problem that is being caused elsewhere, you are expected to address it and to help resolve it. Everyone is expected to understand the strategic goals of their group and to help move toward them. This sense of ownership for items you don't directly control leads to a far better and more efficient solutions.
IT seems to be challenging some of these differences relative to other companies, primarily cost. Money is always and issue, and some IT managers are saying that the cost of IT at Intel is 5x that of other companies, such as Dell. It's possible that Intel spends more in IT than do other companies, but 5x is a ridiculous number. I haven't seen any evidence that shows this is an apples-to-apples comparison. This claim seems so outrageous that I've completely discounted it as propaganda. I discussed some of the pitfalls of comparing our IT spending to other IT shops here.
I have a friend who left Intel a couple of weeks ago to go work for Nike. In this short time he's already seen a dramatic difference in attitudes between the two. Practically no IT people at Nike have laptops. When he asked about it the answer was "why would you want a laptop?" The idea of working from home, or being able to connect and work flexible hours, or longer hours, is foreign to them. I'm not saying that IT people at Nike don't work hard, just that their mind-set isn't to be able to work from anywhere, anytime like it is at Intel. I believe Intel gets a large benefit by allowing people to work remotely: they will often work an extra hour in the morning or evening because they can, and because it's beneficial for their job schedule or that of others. It's a lot easier to call into a 7:00am meeting from home than from the office.
Another difference my Nike friend pointed out was that IT folks at Nike seem to be less invested. Nike appears to be more of a classic IT shop than Intel, where people tend to work with business groups in a more segregated manner. This isn't bad, it's just different, and it isn't Intel. And if you look at costs, it might even be cheaper. But it requires a service attitude rather than one of ownership. It allows people to say "not my problem" when something isn't in fact their specific problem. It allows people to literally work 8-5 and not worry about whether or not their work is helping to drive strategic goals, or if IT is going to hit their quarterly indicators.
My concern is that by moving to a more traditional, less flexible working environment, we're going to retain only the more traditional, less flexible people in IT. Do we want a group populated by people who don't take their work home with them, who don't drive as hard to solve problems, and who don't reach across other groups to solve problems? I would encourage IT staff to think hard about what the long term outcome of these changes could be.
Posted by
Intel IT Guy
at
6:41 AM
16
comments
Labels: management, morale, people
Wednesday, June 13, 2007
More catching up...
Yes, it's been far too long a gap in posting. Travel, vacation, some family stuff, and before you know it a few weeks have elapsed. C’est la vie.
In case there's anyone who hasn't seen the video of Conan O'Brian's visit ot Santa Clara, it's worth a look. I found several things about this video amazing: that Intel allowed Conan into the building with a video crew, that they allowed him to openly mock the work environment, and most surprisingly, that Sr. management embraced it. I first heard about this video in an email that had originally been sent from a Sr. VP to his staff.
Some local Oregon news: Intel is moving out of the Elam Young building. Intel has been leasing space there since 1984! And one more Oregonian article about an Intel engineer who left to start his own business. Worth a read to get some perspective on tech jobs in Oregon vs. the SF and Seattle.
Attrition in IT still seems to be high based only on my personal contacts. People are moving to other groups or out of Intel faster than I've seen previously. This could be just my perspective, as I don't have any data to validate this trend. I think losing people from IT is generally a good thing as belt tightening continues. I'd much rather see people find other opportunities rather than another round of layoffs. I am seeing some disciplined cuts taking place in IT, particularly around removing redundant tools and functions, and attrition may be related this.
When I watched Craig Barrett on 60 Minutes discussing the One Laptop Per Child initiative, my reaction was that he was well reasoned and made perfect sense. I don't see why OLPC should have a monopoly on providing cheap laptops to students. I would think they would be encouraging more competition. But Intel has the ability to look bad when trying to be competitive. There's no question that Intel sees this as a business opportunity, but I don't see how OLPC can be sustainable long term unless it's run as a viable business. One colleague described Craig's appearance as reminiscent of Dick Cheney.
And speaking of looking bad, Intel will apparently be lowering prices on processors again next month. I like seeing our expensive processors sell well. But people smarter than me have decided it makes more sense to cut prices, probably for deeper penetration of C2D and C2Q processors. But the press is positioning this an attack on AMD. Bloomberg and BusinessWeek are both saying that Intel's intent is to cause problems for AMD. I suppose that's possible. Is it not more likely that Intel's intent is to continue to win back market share and be as competitive as possible? Was AMD trying to cause harm to Intel when they were kicking our butts with their processors a couple of years ago? No, they were trying to grow their business and were worried about their bottom line. Regardless of the impact, prices coming down this quickly has to be good for consumers.
Posted by
Intel IT Guy
at
7:06 AM
0
comments
Monday, April 30, 2007
Catching up...
A few comments have come in on the last couple of posts that I wanted to address here rather than replying with additional comments. Someone wrote:
I think we're all hoping that the old growth rate and stock price will come back.
imo, it's just not going to happen for a couple of reasons. Intel now has a market cap of $126B and is in about the top 30 worldwide. There isn't a lot of headroom there. GE is #3 in market cap with $380B, but they are tremendously diversified relative to Intel. Microsoft is number #4 with $295B, but they don't have to pay for fabs. Fabs cost a lot of money, and they depreciate relatively quickly. Another reason is Intel's stock price during the .com boom was simply unreasonable for a manufacturing company. The market does what it does, but the stock price is at a more reasonable p/e ratio now than it was in 2000. I'd love to see stock back up to $30+ as well. It's going to take a lot more revenue to get it there.
There were some good comments about focal from the In the news II post. I encourage you to read those few comments if you haven't done so. They reflect the diversity of options about focal. One commenter said:
Focal pushes employees to do what will look good at focal, not what's good for the company.
There's no doubt that's true. But I'm not sure it's significantly different at other companies. People always tend to do what's best for them, whether it's sucking up to the boss, or spinning their work to look better than it is, or lying, cheating, and stealing to get ahead. Some people do these things at Intel, just like they do everywhere else.
I'll admit to being very conflicted about the focal process. As an employee, and especially as a manager, I find it an unpleasant experience to go through. Some dislike it less than I do, but I don't know anyone who looks forward to it. The idea of focal is (I think) to put some process and objectivity around an inherently subjective process. It's by no means perfect, and it can be painful, but overall I think it tends to work. It yields results that generally puts the higher performing people at the top, and the lower performing people at the bottom. Generally. Every time I've taking people through focal I've going into it worried about the outcome, and I come out feeling like it was relatively fair.
I really struggle with the idea of forced distributions. I believe this is done largely because most managers don't deal with poor performers. I see this every day. Too often people get swept into a bad category because of a forced distribution. But conversely, far too many poor performers would never be identified if managers weren't forced to do so.
One year I ended up representing three different groups in focal by myself. I don't remember the circumstances, but two other managers were not there to take their people through the process. Most of the employees were in rank groups where I was the only manager representing them. My boss made me prepare work sheets and take them through the process. The two of us sat in a room for 4 hours discussing each person, with her asking hard questions about the deliverables, and my rankings and ratings. And I had to hit a distribution.
The point is that I wasn't able to go off and just do whatever I wanted to with those people. Going through the process made me think about the people differently than I would have otherwise, and it made me identify the (relatively) slower performers. It was unpleasant, but I got to a good result. My philosophy about focal is that it needs to be improved, and the forced distributions need to be reconsidered. I think of it as similar to the system of government in the U.S: It seems broken, inefficient, tedious, and stupid some of the time. But overall it seems to work, and I'm not sure I could replace it with anything that would work better.
Posted by
Intel IT Guy
at
5:19 AM
11
comments
Wednesday, April 18, 2007
Earning some respect
AMD had announced (twice) that they were going to miss earnings for Q1. Intel products have been getting good press, and the super-geeky seem to be thrilled with the performance of Core2 Duo and Quad chips. Even Intel motherboards have gained favor with the over clocking crowd. But as recently as a month ago, Computerworld was less than flattering about Paul and Intel's 2007 product lineup.
Earnings for Q1 were good. Income was $1.61 billion, 27 cents a share. Last year was 23 cents/share. The tax settlement I mentioned earlier was a big factor and netted Intel and extra 5 cents. Analysts were expecting 22 cents, so we were right in line with the expectations. Our sales were just below expectations, $8.85B vs. an expected $8.9B. There good news here is that profit is up, since we hit the income expectation with lower than expected sales. Gross margin is 50.1%. One analyst said:
It doesn't appear that Intel is waging a price war. Rather, AMD has been cutting its processor prices in an attempt to maintain its market share gains to no avail.
That's great to hear from an analyst, but keep in mind that Intel has some good price cuts happening next week (this is public info). We'll have to see if these impact Q2 earnings. Intel foretasted Q2 sales between $8.2-8.8B. Wall street is expecting the higher number. Some analysts are concerned about rising inventory, and that Intel will be stuck with too much product. My uneducated guess is that the upcoming price cuts will take care of any inventory issues.
The other news is that Intel hit the employee target of 92K about 3 months ahead of schedule. I'm guessing this was due to a combination of aggressive layoffs and higher than average attrition.
My short take: it was a good quarter that demonstrates demand and affinity for Intel products is much better than it has been in recent years. Intel is doing well while AMD continues to cut prices and lose revenue and market share. Things may change when AMD gets more competitive products to the market.
Posted by
Intel IT Guy
at
6:15 AM
3
comments
Labels: earnings
Tuesday, April 17, 2007
In the news II redux
I need to correct something in my last post and didn't want to just slip it in there and pretend the mistake never happened. I mentioned that I was having trouble with the comments on the Silicon Forest Blog. The author of the blog sent me a not apologizing for the issue, saying it seems to be working fine, and asked how he could help. My immediate reaction was "Uh oh. I just flamed another blogger (and a real writer) for his blog comments not working without even checking to see if it was me." So I fired up IE, and it works fine. Clearly there's some issue with my Firefox configuration, but also an issue with me. I apologized in email, but want to do so here as well. Inexcusable for a tech guy from a tech company to be so careless (and lazy) when having a simple problem.
So thanks for the note, and sorry for casting aspersions on your blog. Mike is well known to readers of the Oregonian, but I highly recommend his blog as well. He's a good writer and obviously a very decent guy.
Posted by
Intel IT Guy
at
9:37 PM
0
comments
Labels: blogging
Monday, April 16, 2007
In the news II
Earnings come out tomorrow, and assuming I'm not still working on my taxes, I'll get a summary posted. Someone commented on the previous post about an article about focal in the Oregonian. (I've been trying to comment on the blog discussion about the post for the past two weeks but I can't get logged in, so I'll do it here.) Overall a good article. It's difficult to explain what focal is and how it works to people who haven't gone through it. I think it tends to sound a little more Draconian than it really is. But there is a mandate to identify the bottom of the pack (relative to the rest) and give them a strong message every year.
One correction I would make to the article is the statement that "the bottom ratings ensure that a certain number of employees are pushed out." That's not quite accurate. The goal is to ensure that the bottom employees get a strong performance message and know they have to step it up. If managers are doing their jobs (which is not always the case) an employee should know they have a performance problem before their focal review.
In preparation for earnings, a couple of more things to ponder. Tom's Hardware, a site that has not been historically Intel friendly, published an article about Intel gaining back market share from AMD.
...AMD has seen a dramatic drop in its U.S. market share for desktop retail sales.
We'll have to see how Intel positions this in the earnings announcement, but regardless this is good news for Intel. And it doesn't seem unexpected given the performance and popularity of Intel's new processors. Last week AMD also announced their second waring for earnings this quarter. I'm not happy that AMD is having problems, but I am happy that the market is embracing Intel's products. The competition between Intel and AMD is great for consumers.
Posted by
Intel IT Guy
at
8:04 PM
4
comments
Labels: earnings
Friday, April 13, 2007
In the news...
A few unrelated items that didn't fit into the other posts I'm working on but I thought worth mentioning . The Mini-Mirosoft blog had a good post recently on employees choosing to stay at Microsoft (or not). I'm not advocating that people should stay or leave Intel. From my perspective, more people are voluntarily leaving than is the norm, but I don't have any hard data. It also seems like the people leaving are in the 9-12 year tenure range. It could just be that I know more people who have been at Intel for longer periods of time than shorter. People past 14-15 years don't appear to be moving on at the same rate, nor do those with less than 7-8 years. Not drawing any conclusions, just making an observation.
A writer named Eric Sherman sent me a note to mention that he'd done an interview with Intel VP Don McDonald for an article in Advertising Age magazine. He posted the full interview on his blog. I debated on whether or not I wanted to give a magazine a plug here, but I figured the reading the short interview with Don was appropriate. (Thanks for the reference, Eric.)
Google and Intel appear to be working on a deal to get a bunch of new servers configured to their specs. I wasn't even aware that Google was running non-Intel servers. 300-400K servers is a nice number, but I've got to believe the bragging rights for winning back Google is a bigger deal than the actual sale. Nice job to whoever made this happen at Intel.
For the truly geeky: Intel is doing some platform announcements, including adding vPro into Centrino. I'm not sure what to make of them. There price on Viiv chipsets was dropped. If I'm reading this correctly, the cost to of the Viiv chipset for motherboard makers is $1. I'll post about Viiv and some other products in the near future, but it says a lot that neither me nor my über-geek friends know what it does or how it adds value. (It either needs to bring content into the home, or manage it in a new, easy, seamless manner. Think TiVo or iPod.) There seems to be push to energize the platform market, which seems to be a little confusing.
Someone asked in a comment to my previous post what I thought about "the fact that your CEO threw Intel IT under the bus for losing emails?" I'm not sure I would characterize that way. The latest news seems to be that Intel now has until next week to find the missing docs. I don't have any inside info, but I find it hard to believe that Intel intentionally lost any email and fairly easy to believe that it was lost. (Disclaimer: this is my opinion only, and is not meant to represent Intel Corporation, the CEO, or any other employees.) I delete a ton of email as a matter of necessity. I'd be drowning in email if I didn't. Unless I was explicitly instructed to keep something, and the instructions were clear and obvious, I doubt I'd know exactly what to keep. Until you're getting 100+ emails per day that all require a response or some action, it's hard to imagine how hard it is to keep up. Trying to keep track of all the email is nearly impossible. Trying to know after the fact what I saved and why would be absolutely impossible.
Posted by
Intel IT Guy
at
6:14 AM
3
comments
Tuesday, April 03, 2007
Parallax Blog II
I'm working a few posts that need a little more time. For now, a few blog updates. I've made some minor changes to this blog, and will be making a few more. I removed the email subscription option since it was ugly and nobody seemed to be using it. I'm adding a subject grouping which should be done this week after I go back and attach subjects to each post. Look for some other minor changes over the next week or two.
I'm sorry to see that Pentrino VI at The Unofficial Intel Blog appears to have moved on. He preceded me with an external Intel blog and did a nice job. I'm sorry to see him gone. I don't have any other information, but wanted to thank him for his blog and wish him well.
I'm working on a Q1 earnings post to talk about the quarter, products, and other related matters. Some recent news that may impact earnings: Intel got back $275M from the IRS this quarter based on the results of an audit. Assuming the accrue this in Q1 that could give us a little boost. Intel also announced more details the upcoming Penryn and next year's Nehalem processors. There's some opinion out there that Intel's processor designs are copying those of AMD. (There are no comments that Intel is stealing anything, just that design ideas, such as integrated graphics, are coming from AMD first). I seriously doubt that Intel is following AMD's path, but we'll see where this news goes.
Posted by
Intel IT Guy
at
7:05 AM
7
comments
Friday, March 23, 2007
Gimme Some Mooly
I would encourage every employee to read the February edition of the MPG Bulletin written by Mooly Eden. He talks about the difference between efficiency (doing things right) and effectiveness (doing the right things). He also talks about killing off products during engineering or development when it's obvious they aren't going to be successful, and finding the "wow" factor for every product he works on. I consider his newsletter to be the best Sr. Management communication happening at Intel. It's not self promoting. He addresses real problems. The style is upbeat and positive, but not filled with the type of cheer leading that has become typical at Intel. This one short newsletter encapsulates so much of what is great about Intel, and how effective leadership can really make a difference. For any VPs reading, go take a look at Mooly's newsletters. That's how it is done.
He points out that that part of taking risks is knowing that some things are going to fail. He gives an example of killing off a product and then realizing he could have shut down even earlier than he did. He didn't realize that it should have been stopped sooner, but I'll bet someone on his team did. And if so, why did it take another two months of work on an already dead product to get it stopped? This is not an uncommon situation, and Mooly stopped short of addressing why it's hard for teams to kill products, programs, or projects.
The answer is that, with the exception of Mooly and a few others, we all think we have to be right all the time. If you propose a product that fails, you risk being associated with that failure. Most project managers get vested in their projects and want to see them succeed. Nobody wants to see months of years of their work amount to nothing. Most of us resist pulling the plug even when it's obvious that success isn't possible. And in many cases people working on these products know they won't be successful, but they aren't the decision maker.
Employees would be more willing to identify programs and projects to be cut if there was less personal risk. It's hard to kill a product or program. But it's much harder to suggest to your management that a project should be killed. I've worked on large programs where my boss (and their boss) staked their reputation on it being delivered, or being delivered on time. Hearing something like "We're really against the wall on this one, we can't afford another slip" is fairly common. Even harder to deal with is "We've spent a fortune on this thing and we need to make it work." During one particularly bad year I was tasked with implementing an enterprise tool that someone had already spent money on. It was expensive, had not been successfully implemented at any other company, and would require a lot of business process change. Suggesting that we either try to get our money back or wait for the next major version was met with a fairly hostile reaction.
It's one thing to suggest that something won't work because you don't want it to succeed, or because you don't understand it. That's negativity and cynicism for the sake of it. But having some data or information that demonstrates how and why something can't be successful is exactly the kind of information managers should crave. But they don't. We (yes, I'm including myself in this group) think we can find ways to make things successful. "Maybe is just needs more time? I know it's not working now, but we'll get it right in the next version." Or it's the situation I described above where a more senior manager isn't open to hearing that something is going to fail.
People need to have the faith that they'll get rewarded, or at least not published, for speaking the truth about product or program issues. The issue is that we don't measure success on these terms. I can't think of any metric at Intel that tracks how effectively someone saved the company from taking a wrong turn. Some Sr. Managers (perhaps Mooly) may do this. But right now the only measure of success is success itself. We need to figure out how to make it safer for people to speak up and drive the right product changes sooner.
Posted by
Intel IT Guy
at
6:55 AM
2
comments
Labels: leadership, people
Wednesday, March 21, 2007
Ch-Ch-Ch-Changes follow-up
I had some good responses to the last post. I recommend reading the comments if you haven't done so. I also got a few emails and wanted to share some of that feedback well. One person noted that most Intel people aren't as generally upbeat as they used to be when replying to a "how's it going?" question. They noted that most people are just "fine" or "hangin' in there" rather than something like "great!" Another emailer mentioned that there appears to be a lack of autonomy and empowerment that we had previously, leading to lower morale. People still have a lot of work to do, but they feel less personal ownership and responsibility, at least in IT. I'll need to think about this one - is it a cause or a symptom? And is it an inevitable result of IT becoming more process focused and moving to standardized tools?
A couple of people asked about the internal blog that I've mentioned a few times. I'm hesitant to post the full URL of the blog because it contains the last name of the blogger. Given that he's already out there with another blog this may not matter, but I'd rather play it safe with someone else's identity. From the Intel network go to blog.intel.com, then click on Employee Blogs, then scroll down to the Ms and look for the only blog with the number of comments over 1000. If these instructions don't get you to the the blog, try this: ask the person sitting in the cube next to you for the URL to Jeff's blog. If that doesn't work, try the person on the other side of you. Good chance that one of them is reading it. There are several other good internal blogs as well, and Jeff has conveniently just mentioned some of them. So going to his blog gets you pointed to a bunch of others as well.
BIG EDIT: I took this post down yesterday when a couple of you emailed to asked what the heck I was talking about. I had a couple of paragraphs in here about earnings that didn't make sense. As I've mentioned, I work on many posts at once and had pasted another post into this one. I couldn't get to it yesterday to fix it so I just took it off line. Sometimes I wish I had an editor.
Posted by
Intel IT Guy
at
6:43 AM
2
comments
Labels: blogging
Friday, March 09, 2007
Ch-Ch-Ch-Changes
Some changes are taking place that I thought were worth mentioning. I've gotten several "I'm leaving..." notes from Intel people over the last week. Perhaps I wasn't paying attention, but it seems like we're either at the beginning or the tail end of another round of layoffs. Assuming people had about 2 months to find another job this would mean that they were given notice in early January. Or they just got laid off. The notes I've gotten are more from professional acquaintances rather than close friends, so I'm not asking about their circumstances. All of them seem to have landed good positions elsewhere, and their messages sound positive. Some genuinely good people are leaving us, which is inevitable with layoffs. What's odd is that I'm not hearing anything about these people leaving beyond their goodbye notes. I wonder if we've all become a little numb or accustomed to people leaving?
Our CIO has reset his expectations for monthly status reports (MSRs). He now wants us to do a short update for each quarterly deliverable we have, and then mention anything else we worked on. We should see more succinct MSRs with less marketing spin. I'm not quite arrogant enough to presume that my post on this topic was the reason for the change. But maybe I was able to influence someone who mentioned to JJ that writing long MSRs was not a good use of our time. (It's my blog, and I'll have delusions of influence if I want to.)
I just recently noticed another, more subtle change that's been taking place over the last 2-3 years: Intel people don't hang out after work the way they used to. I still have my circle of Intel friends, some of whom are in my smaller circle of close friends. We don't socialize outside like we used to. It could be that we're all getting older and other obligations keep us from stopping for a beer after work. But the old stomping grounds aren't full of Intel people they way they used to be. I'm not sure why this is, or what it means.
I also notice that people are generally working less than they used to. Don't get me wrong - I think this is a good thing overall. I used to get emails from many people well into the evening. Now it's rare that I get e-mails very far outside of business hours, except from people in different time zones. People used to work long hours for two reasons: the first was that they had to. This seemed to get increasingly common in IT and eBG as we were trying to roll out bigger, more complex solutions. But before that and until the last few years many people wanted to work long hours to get their jobs done better. Some were workaholics, but many just wanted to get the work done and appreciated an hour or two in the office when it was quiet. I still see people at work early and late, but far fewer than previously.
Part of this may be due to telecommuting, but if that were the case my inbox would still be getting hit with mail in the evenings. I'm guessing this is due to a combination of the depressed and flat stock price, and more recently the environment of layoffs. It could also be that Intel is driving people less hard to feel competitive every hour of every day. Do you see the same thing?
Posted by
Intel IT Guy
at
5:52 AM
12
comments
Labels: management, people
Tuesday, March 06, 2007
Little Black Book II
My last post didn't go over terribly well. Some people didn't get it, and a couple outright disagreed with me, which is fine. But what they disagreed with indicates to me that I did a poor job of making my point, which was this: you need to have the right solution for the problem being solved. I'm not opposed to CMMi at all, but I haven't seen any data that shows how it addresses some of the problems that IT is trying to fix. It's being held up as the one vehicle that got Flex Services (an IT team) on track. Again, I haven't seen the data. Flex getting better and them using CMMi is a correlation, nothing more. But my point isn't that CMMi is wrong or bad, just that it's not a substitute for knowledge, experience, or education.
And this gets us to the heart of the problem. How many people in IT throw more resources at a project when it gets behind schedule? How many can't see some obvious people bottlenecks in projects or programs well before they hit them? Why do projects continue miss dates for the same reasons they did years ago? Largely because this stuff is hard and unpredictable. We can't predict what a vendor will do. We can't predict that people 1/2 way around the world won't hit their deadlines. We can't predict that integration of two different systems isn't going to work well. Right?
This stuff is hard, but it's always been hard. Why are some people are really good at it, and rarely miss deadlines or resources estimates? What do they know that we don't? I think it's the knowledge that the chaos of IT systems is usually predictable and manageable. Process certainly helps, but it's the understanding of how these things work, regardless of the technology, that makes it more manageable. And more importantly, it's understanding how the people work that makes estimation successful. They work in largely predictable ways, and despite this we are constantly surprised by how teams behave.
So where is this font of knowledge? How can everyone acquire these magical skills? Some of it is experience, but a lot of what's required is knowledge and a different set of skills that have been developed over the past 30+ years. So here are some recommendations: send everyone in IT through a basic project management course. I'm still amazed that some people can't reliably manage tasks to time lines. And yes, send those who need it through CMMi training.
There are also some IT books that should be mandatory reading for all people, program, and project managers. The knowledge in these books would add far more value to IT's productivity and Intel's bottom line than CMMi. The first book that managers need to read is The Mythical Man Month. Also, Death March and Peopleware should also be required reading.
These may be somewhat dated, particularly the Mythical Man Month, and they are not a panacea for all the problems facing IT. And there are tons of other excellent books, perhaps even better books, on how to manage technology and people. But when I see people who don't understand some of the basic concepts outlined in these books making multi-million dollar resourcing decisions it makes me want to strangle them. Having broader knowledge would give us a level playing field for discussing and managing our projects and resources.
So maybe over the next six months or so we'll see some managers walking around with one of these classics that is new to them rather than the latest book off the Harvard Business Review reading list. Any other recommended reading for IT?
Posted by
Intel IT Guy
at
11:01 PM
7
comments
Labels: results
Monday, February 26, 2007
Little Black Book
We're ramping up for some big training in IT this year. Everyone will go through CMMi training. We're all likely to get re-trained in the program life cycle (PLC, also known as the program/product life cycle). The goal is to reduce all big projects into smaller "chunks" of six months or less. We're not as efficient as we should be and we need to get better at estimating and hitting delivery dates. And having a common language to use for projects and deliverables would be helpful.
This all sounds fine, but it's not clear to me what problem we're trying to solve with CMMi. CMMi isn't a process, and it doesn't teach project management. Perhaps I'll learn better how this will help when I go through the training, but right now I can't really see the connection between the problems we're trying to fix and the actions we're taking. People at most corporations tend to like new things. CMMi is hardly new, but it's new in terms of embracing a way to manage and measure process in IT at Intel.
The PLC training makes sense, and I think most people in IT need to understand it. Despite what you hear about PLC being a planning framework, it's not. It's a series of steps required to get decisions and funding from your management. It basically says you need to do some research to get a clue, turn you clue into an idea, turn your idea into plan and explain why it adds value, then get it appropriately funded. It's really just a check-and-balances process. Once you start to look at it that way and follow the process, you'll start getting more decisions approved. Tip: be sure to use the PLC graphic in your presentations to show where you are in the process. There's and cool new graphic that's identical to the old one in every way except the graphics look more expensive. (They guys who revamped Intel's logo must have had some extra time on their hands.) Middle and senior managers in IT have a Pavlovian response to this diagram and you score points just for using it. And you get extra credit if you actually understand it, although it's not a requirement.
A few years ago in the eBusiness group things were going along fine strategically, but not so well tactically. Projects were missing delivery dates, quality was not good, resource and spending estimates were poor for most programs, and customers were generally not happy. I may get into the details of this in a later post, but for now just assume this is a fair assessment of how things were going. In the midst of what some might have viewed as a crisis the group's ability to meet customer expectations, deliver, the Sr. staff were focused on strategy. In particular they spent a lot of time working in succession planning - figuring out who in their groups could replace them, and who would replace those managers.
The VP had read a book called The Leadership Pipeline and was encouraging her staff to read it, and some of them encouraged their staff to do the same. It's a good enough book. But what I found funny (and a little sad) was the way some managers would leave this book out on their desks, or occasionally carry it with them from meeting to meeting. I sat through many meetings looking at copies of this book wondering why someone had brought it into the room. I never quite figured out why people carried their books around, but I decided that these were likely the same people who wore wore calculators on their belts in college to be easily recognized as one of the clan.
So what the heck is my point? In the middle of a situation where things were going badly, the VP decided that her staff should focus on something they were already doing pretty well. They didn't focus on project management, or estimation skills, or look at who was making program management mistakes and why. They didn't question how to react when resourcing came up short, because the answer was obvious. They didn't question much about the management aspects of delivering technology, just the leadership.
I don't think the IT is going down the same path with CMMi that eBusiness did by focusing on strategy rather than tactical issues. But I think they could be missing an opportunity to fill a knowledge gap in the organization, and to help solve many problems rather than just a few. But I'm going to make you wait for the answer until my next post. I'm guessing many of you know where I'm headed.
Posted by
Intel IT Guy
at
11:54 PM
1
comments
Labels: leadership, results
Tuesday, February 20, 2007
Regular Song
Some of you are asking about my intentions with this blog given my diminished posting rate. And someone posted this comment to my lone January entry:
Excuse me, but why do you blog if you never actually blog? You actually have some interesting insights that others at Intel fail to share, but a monthly posting is about as effective as Paul having someone write his blog entries for him.
That's a fair enough question. I know that I won't keep readers without writing regularly. My intent is to post at least once per week - a goal I am clearly not meeting. It's largely a matter of time. I've been balancing some unexpected life events and some travel for work. I also spend a fair amount of time on these posts, and if don't finish one it could me many days before I can get back to it. Finding uninterrupted blocks of time to finish my posts has been a challenge.
But those are excuses. I'll do my best to write more regularly. I have plenty of topics started, but they don't always develop the way I'd like them to. During the recent lull I started a couple of posts that were intended just to get something out there, but I wasn't comfortable posting just to post.
Thanks for the interest. I'll try to keep up a more regular pace.
Posted by
Intel IT Guy
at
6:12 AM
7
comments
Labels: blogging
Thursday, February 15, 2007
Focalization #3
I'm getting a fair number of questions about the focal process this year. People aren't sure if it's very different, slightly different, or completely different from the previous process, or what this means to them. From am employee perspective focal is about the same. You should have recommend some names to your manager for 360 feedback. You should have done a self-assessment, and by now most of you have reviewed a summary worksheet or draft of your final review with your boss. Employees are now in the waiting period where their manager has likely completed ranking and rating, but they won't know anything until after April 1. For me the process as an employee was about the same this year. The only difference was that my boss wanted my to write my complete review rather than a worksheet.
For managers things are significantly different. Previously managers would go into a room and discuss every person in a rank group, usually between 8-20 people, but sometimes smaller, sometimes larger. Different rank managers used different processes for going through a session, but it was invariably a long, painful process. You needed to represent a years worth of accomplishments for am employee in 2-3 minutes. These sessions were a real power play, with managers negotiating, influencing, and doing a lot of acting to try and get their people ranked and rated fairly. Most managers tended to do a good job. There was usually some asshole in the room who thought his people were more deserving than everyone else's. But with a good rank manager and/or HR person in the room, things were usually kept in check. Depending on the size of your team and the number of rank groups they fell into, you could spend 1-5 days in R&R sessions. I usually spent at least 40-50 hours preparing worksheets, and other 30-40 hours writing reviews. Then there was additional time for figuring out pay increases, dealing with last minute budget or stock changes, and other stuff. It was not unusual for me to spend 3-4 weeks of time working on R&R.
Things could tend to break down in R&R sessions where there was an uneven distribution of power, influence, and bias in the room. I had one boss who insisted on being in all our R&R sessions as an "observer" so he could direct the outcome. It was similarly bad when the rank manager had some obvious bias and would help influence the result rather than just facilitate. The worst rank sessions were those in which the rank manager was representing their own employees. I was actually in one session where two of those happened: our boss was in the room to observe, the rank manager was representing his own people, and both of them had an obvious bias toward the rank manager's team. They were aligned on the result they wanted to see, and the rest of us were working hard to bring a sense of fairness to the session. This was an extreme case, but it's a good example of what's been wrong with the focal process: it often had more to do with a manager's political and influencing skills than the performance of their employees.
This year managers are ranking and rating people on their own. I ranked my team as an in-tact rank group. I had someone at the top and someone at the bottom. Some people are outstanding, some are not performing very well. We are being held to a distribution within our teams - I can't have an unlimited number of outstanding employees, or promotions. And I am expected to identify a percentage as poor performers. This is still a difficult task, especially for those with small teams. But it's far easier than spending days lock in conference rooms with other managers, influencing and arguing to try and get the right result.
We had one 3-hour meeting with my boss where we reviewed each other's results and and rolled up summary for the team. My boss needs to hit a distribution as well, and we didn't. So we had some conversation about who else could or should be given a poor performance message, and who really didn't deserve to get a promotion. Some of the old behavior came out, and some managers were overly defensive about their people. That's always going to happen. Doing this in 3 hours vs. 3 or more days was a huge improvement in process and efficiency, and yielded about the same result we would have gotten with the old process. And we still aren't quite done and will need to spend another hour or two working on our distribution. But considering what we used to go through, it's big improvement. Focal isn't perfect, and still takes up more time than I would like. I credit Paul with challenging the old process and for allowing these changes to take place.
Posted by
Intel IT Guy
at
6:04 AM
3
comments
Labels: focal
Thursday, January 25, 2007
Been gone a while
It's been exactly a month since I posted, which is far longer than I expected. I took some post-holiday vacation and have spent much of the time since digging out and preparing for focal. I should get back on track and post some of my wip writing over the next few weeks.
I bought a new PC over the holidays just because I felt compelled to own the latest, greatest Intel offering. I really wanted a Quad, but couldn't justify the cost and don't really have the need. I suppose I can always upgrade to Quad processor in the future, especially given how quickly prices seem to come down on new processors. As a consumer, I think it's great that Intel processors are relatively cheap. By "cheap" I mean that the performance I'm getting from my new Core 2 Duo is stellar compared to a Pentium that costs almost as much. I did a fair amount of reading before buying, and was surprised to see that tide has decisively turned toward Intel processors among every group I could find, even the overclocking crowd who have been AMD evangelists for years. While reading our Q4 earnings I got to thinking about how we've essentially abandoned two great brands (Pentium and Intel Inside).
Q4 results were posted last week. It was a good news/bad news kind of announcement, and overall I think were somewhat disappointing relative to the success our products have had. Earnings were in line with expectations ($9.7B) and earnings-per-share were $0.01 higher than expected. Gross margin was up slightly, but not quite as much as expected. We set a sales record in Q4, and the average selling price (ASP) of processors was up. Overall it was clearly a good quarter. The outlook for Q1 seemed a little timid to me, which is why stock is down. If sales are up and ASP is up, why isn't our margin increasing as fast as we expected, and why is the Q1 outlook lukewarm? One analyst thinks it's because pricing is too low. The idea is that Intel is willing to sacrifice revenue to win back some market share, and Paul made a comment to this effect during the earnings conference call. I'm not smart enough to tell you whether or not it's wise to sacrifice revenue for market share, but it's clearly good for consumers.
Given how good the press is for Core 2 processors, I'm left wondering if part of the problem is due to brand recognition. Pentium and Intel Inside used to be plastered all over everything. Now it's Core 2 Duo and Core 2 Quad, which is hard to memorize, hard to pronounce, and confusing to think about. "Did you say Core tutu? What's a core?" are questions I've gotten from friends. Actually, I don't get those questions from friends until I prod them by asking what they they've heard about the new Intel products. After they ask "what products?" and I tell them Core 2 Duo, they look at me like a dog trying to decipher which direction a sound is coming from. "Core what?" is the typical response. Core 2 Quad might be easier, and I hope that a year from now we're selling only Quad processors so I can quit try to explain (badly) what "2 Duo" means. I hope someone is working a brand strategy for the next series of processors that will be as simple and popular as Pentium was.
I'm guessing that we moved away from Pentium because we needed to convey that our new processors were truly new, and built on a different architecture. I'm not sure why we abandoned Intel Inside, other than we were re-branding everything. I don't have any problem with Leap Ahead as a slogan - it's sounds good. The problem is that Inside had to be one of the most recognized logos in the world. We've spend years training consumers to ask for "Pentium" by name. People simply aren't going to ask for a "Core tutu" when buying PCs, and it wouldn't matter because that product will be replaced by Quad processors or something else. What we've lost is the word association that can be used for a whole class of products over many years. I don't think it was wrong or bad to move beyond Pentium, but we haven't replaced it with anything else that consumers can relate to.
RIP Pentium, you served us well.
Posted by
Intel IT Guy
at
5:35 AM
6
comments
Labels: earnings
Sunday, December 24, 2006
All I Want For Christmas...
I've been to three holiday parties where most of the attendees were Intel employees. One thing is certain when you get together with a large number of Intel people: there is going ot be a lot of work discussion. After having heard some stories and spoken to many employees outside of my typical circle, here's are some things I would like to see changed in 2007. These are small items, which could easily be delivered.
1. No more monthly status reports (MSRs) in IT.
Out of all the things I could ask for, you're probably wondering why writing a monthly status would be such a big issue. Well, it's because it's a time consuming task that is completely pointless. My December MSR was due on the 7th of the month. For October and November it was due on the 10th. How can you label a status report "December" when 75% of the work it covers was done in November?
Most of Intel quit writing MSRs at least a year ago. They had degenerated into personal marketing documents that everyone sent around to everyone else, and that nobody particularly wanted to read. You send an MSR to your boss. He combines all those from his team, adds his own stuff, and sends one to his boss. And so on up the chain until you see MSRs from the top level managers. But all this rolling up of status reports takes time, and each management layer wants a few days to work on their own MSR. In no reasonable scenario can I conceive how an MSR needs to be due before the middle of the month.
Since my November MSR was also due before the 10th, I do have about a full month's worth of accomplishments in my December status. But by the time the IT VP rolls out his status, some of the work I mentioned in mine will be about 7 weeks old. What's the point? We take time to write a report that nobody really reads, and that doesn't give any critical information. If you need some project indicators, have people roll those up monthly or quarterly. We all have quarterly goals. If you want a brief status against those, I'd be happy to comply, especially since I'm already doing that anyway, in addition to my MSR.
And now let's get to the part this whole nuisence that really bothers me: we're supposed to be in the middle of a big corporate efficiency effort. How is having everyone write a brag sheet every month and then taking 3 weeks to roll it up to the top levels helping to run the company, or in any way efficient? I'm sure some of you are thinking "but how much time could it take. Just scratch out a few lines and call it good." Here's a summary of two conversations I recently had with my manager about MSRs:
Boss: We're getting complaints that people are spending too much time working on their MSRs. Look, these should be really simple and straightforward.
Me: Well, I know you like it a certain way, and doing that takes time. I'm spending at least 45 minutes on mine.
Boss: That's way too much time. If you can't do it in 15 minutes you're spending too much time on it.
2 weeks later
Boss: Your status really wasn't very good this month. It took me a long time to parse out what you had written for my own status report. I need you to do a better job writing your status so I don't have to spend as much time on mine. Ideally I could just cut and paste what you wrote into my status.
Me: OK boss, sorry about that.
JJ, please do us a favor and kill off status reports in IT.
2. Allow people to attend staff meetings for their managers.
This is a new one for me. I just learned about this at a party this weekend.
There is a long (and good) tradition at Intel of managers picking someone on their team to cover for them when they are out. This allows the manger to feel that things will be taken care of, and it's a great opportunity for someone on their staff get better exposure, visibility, and experience. It's often used as a way to groom people. So if an IT staff member had someone on their team cover for them, that person would typically attend IT staff meetings and be interacting with their boss's peers.
But the CIO has apparently decided that he doesn't want anyone attending IT staff meetings who is not already on IT staff. The reason he gave was that someone covering might feel intimidated and not speak up, and they they might not know the answers to some questions. That's absolutely true. But it's also the whole point of having someone cover. It's an opportunity for them to see how they might intereact with more senior managers. It doesn't matter if they have all the right answers. If a permanent member of staff doesn't know the answer to a question, do you kick them out? No, you ask them to find the answer.
He said that instead, he would prefer to have staff members find peers, other IT staff members, to cover for them. Who has a better chance of looking out for a group of people: someone who works for the manager, or someone who is competing with that manager? I think the CIO and his staff might be overthinking this. This is simply one of the silliest management decisions I've ever heard of, and the more I think about it, the more silly it sounds.
There is of course the concern about someone hearing something when covering for their boss, but that is handled easily by just asking the person to step out of the room if the discussion or agenda moves to a topic they should not hear. We do this all the time, and it's just about that easy: "Bob, could you please step out while we discuss focal results? Check back in an hour to see if we're done." This is typically only necessary when discussing focal, salaries, or HR issues.
Following the CIO, most of IT staff also decided that none of their staff should cover staff meetings for them for them either. (Interestingy, I haven't heard about this from my boss.) So those of you in IT who cover for your bosses, you won't be attending any staff meetings for them any time soon because you might hear something inappropriate, because you're too intimidated to answer questions.
The reasons given for this policy don't make any sense. It smacks of JJ not trusting us and putting up a firewall between his staff and the rest of IT.
3. Sr. management to speak honestly about why no Sr. managers were fired this year.
For much of the year, Intel employees have been asking via blogs, in open forums, and coversationally why the people responsible for overstaffing Intel aren't being held accountable. Initially there were no answers. And then we starting getting some vague answers like "we all made mistakes, and we learned from them." This is just bullshit. The problem could have come from the very top; maybe Craig sent unresonably high staffing goals. And I don't expect the board to do anything about that. But there are also dozens of mid and senior level managers who blantly practiced empire building. They schemed and oversoldelse to grow their groups to the largest possible size for their own good, not for the good of the company.
Go find those managers with less than 100 people calling themselves "Director" of something and you'd have a good start on rounding up the worst offenders. Since senior people obviously aren't getting fired or demoted, it would be nice to know who is being held accoutable for the mess that was created.
4. Quit telling us how hard it was to fire people.
This last one is really easy. Senior mangers, including Paul and many VPs, need to quit mentioning how hard it was to fire people this year. I'm sure it was hard. But you know what has even harder? Actually getting fired. Next to that would be knowing that you may be fired, but having to wait 4 months to find out if you needed to start looking for another job. Those of you saying "it was the hardest thing I've ever had to do" never had your jobs at risk, and you're probably the people responsible for creating the situation that required the lay offs. You guys don't get to play the sympathy card. So please stop doing it.
Posted by
Intel IT Guy
at
1:14 PM
8
comments
Labels: CIO, leadership, management