Today marks eighteen years in my Intel journey, so I am keeping up the tradition of writing a blog entry on this day, as started with http://vzimmer.blogspot.com/2012/02/anniversary-day.html. The title exponentiates '.next' versus '.next.next.next'-style usage. This makes me eligible for a half-sabbatical, too. Since the last posting I've firmly moved into the new Seattle office. Below is a picture of the facility from across the street. It is located in south Seattle, adjacent to the International District.
I managed to get a cube-with-view, too.
The view also affords me a vantage in case of an invasion https://twitter.com/vincentzimmer/status/565562482383527936
So with a new office and work anniversary afoot, I will continue my blogging tradition. I'll begin with a few thoughts on being an engaged engineer. These sentiments include:
1. Being present
Even before chancing across http://www.forbes.com/sites/ellevate/2015/02/20/why-face-to-face-meetings-are-so-important/ this evening, I have always believed in face-to-face engagements in the workplace. Although I've always worked at a remote site, namely WA-state Intel, I purposely go out of my way to visit the larger sites, such as Intel in Hillsboro, OR, or the headquarters in Santa Clara.
It's imperative to have such meetings early in an engagement so as to build rapport, and then possibly maintain the relationship remotely for subsequent collaboration. Showing up demonstrates that 'you care' and that the other person 'matters.' Nothing can substitute for these gestures.
Also, having badged into five Intel sites across three states during the preceding four-day-week using plane, train, and automobile, I have recently practiced what I'm preaching on this topic.
2. Saying you don't know
A colleague in Oregon last Thursday suggested I treat this topic, although I've opined on it before. So here goes.
Another behavior I've observed includes reluctance of many technical leader to say "I don't know." Not having the immediate answer is OK. Just commit to following up and supporting the party. Feigning understanding doesn't help your standing with the other party or the overall business goals.
The technology and business landscape changes constantly. Strictly speaking it's impossible 'to know' everything.' But it is possible to keep and open mind, customer-oriented disposition, and desire to 'learn.' Let an occasional 'I don't know' help fuel the fire of curiosity and pedagogy.
I've touched on the former two items in past blogs, but I have yet to treat the next topic.
3, Ownership
In general, ownership can be powerful in that it highlights the party culpable for furthering a business or technical agenda. Recently, though, I've seen the dark side of ownership. For example, in some discussions people will assert "I own that." This is a variant of the logical fallacy of argument from authority in that the act of ownership is posited in lieu of providing other data, such as results.
Instead of 'ownership', I am more of a fan of 'helping lead,' 'coordinate', 'drive'. What matters is the business result. None of us truly 'own' anything in the company. The upper management, and reductio ad absurdum, the stockholders, 'own' the company. We are entrusted as employees, and especially as technical leaders, to drive a goal.
On the flight Friday morning, a senior manager gave me a nice definition of a leader. Minimally, a leader must 'have followers' and 'make changes.' I'd say that's necessary but not sufficient. Sufficiency may include a qualification of change such that it is 'conducive to the growth of the business,' and followers who 'grow and advance in their careers' as a result of the interaction. Good stuff.
So next time I hear "I own X," I'd rather hear "This is what we've produced with X."
So speaking of X's, let's talk about security and open source.
On the security front, I don't want to say too much other than note that I'll be speaking at CanSecWest (CSW) next month https://cansecwest.com/post/2015-02-01-11:00:00_Speaker_Announcements. The title of my talk, "UEFI, Open Platforms, and the Defender's Dilemma", sums up my thoughts on platform security.
To begin, let's dissect the title. The first portion of the title UEFI provides mechanism, such as many of the technologies found on http://www.tianocore.org and also recent write-up's like http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf.
The next portion of the title Open platforms provides a great opportunity to demonstrate a reduction to practice of these technologies, with a goal of demonstrating the design intent of the specifications in bits.
Finally, the defender's dilemma element of the title will review the relative asymmetry of platform defenders to the attackers. The cardinality of the attack presentations at this conference, namely 3 offense UEFI talks, to my 1 defense talk, brings this home. In fact, I represent one of the few defense talks hosted to be found in this conference series.
So let's get to the mapping of our three behaviors to the elements of the title. I will present in person so I get a check-mark on #1 of Being Present without much fan fare. On the topic of saying I don't know, I will not take the posture of being the omniscient guru of firmware. Instead, I want to enjoin the researchers in a dialogue, learning from them as much as I might be teaching. And I may up uttering those 3 humbling words more than I'd like. Finally, I would never claim to "own" platform security. There is a rich community of security professionals with whom I have the honor of working in the UEFI forum, open source community, and as professional colleagues. We all collaborate on providing a solution. I might lead in some venues, such as the UEFI Forum, but I am loathe to ever say I 'own' this topic area.
So that's for CSW next month.
Another application of these 3 behaviors to an X an include open source and open platforms. I've talked in the past about how thing like Intel(R) FSP can support various open source ecosystems and my excitement around Intel(R) Quark-based platforms like Galileo having open sourced their EDK II implementation. I also noted in my Intel Developer Forum 2014 talk that a book was coming. Well, the book Embedded Firmware Solutions: Development Best Practices for the Internet of Things has been published and can acquired via http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/ or http://www.apress.com/9781484200711.
An interview with the authors was also recently posted, too http://www.se-eng.com/2015/02/authors-of-embedded-firmware-solutions-include-key-industry-architects-of-open-solutions/.
I am a believer in collaboration, too. This book adds Google and Sage to the list of companies with whom I've publicly presented and co-authored material. Examples can be found at https://www.linkedin.com/in/vzimmer and includes AMI, Cisco, Dell, HP, IBM, Insyde, Intel, McAfee, Microsoft, NICTA, Phoenix, SuSE, Toronto.
So how do the three behaviors map to this topic? The easiest to answer is 'being present.' In the earliest days of Intel FSP and this book I had the opportunity to meet my colleagues in Mt. View, San Jose, and San Francisco. In this various venues I helped forge a relationship that evolved remotely, but the pioneering engagement was face-to-face.
And on the topic of "I don't know", I have to cite the spate of libre boot emails I received internally and externally in the wake of announcements like http://www.fsf.org/news/libreboot-x200-laptop-now-fsf-certified-to-respect-your-freedom. I don't know the extent to which the various business partners can open, but I'm always open to learn about the various viewpoints and desires of the ecosystem. But I do believe in more openness and transparency, just as 'open' is in my CSW title and talk, and the book above talks about 'open' solutions.
And finally, I don't 'own' open source firmware and platforms at Intel. I am luckily to have spent the last 15+ years on a team that has been open sourcing reference implementations of industry standards and firmware. We recently posted some elements of http://firmware.intel.com/projects/minnowboard-max to http://www.tianocore.org, such as https://github.com/tianocore/edk2/tree/master/Vlv2DeviceRefCodePkg and https://github.com/tianocore/edk2/tree/master/Vlv2TbltDevicePkg. These packages, and the ability to absorb Intel FSP binaries from http://www.intel.com/fsp, along with the more granular source plus binary builds, shows progress toward more open platforms in this community.
So that's about it for the inaugural blog of 2015. I've marked a work anniversary with a blog three-years-running on this date, I discussed three behaviors, and finally, I mapped those three behaviors to two case studies.
I have been invited to co-present at the Open Compute Summit http://www.opencompute.org/community/events/summit/ocp-us-summit-2015/ next month, too. I should have conjured up a 3rd case study on this topic area of "firmware and Cloud" challenges" to have a 3-3-3 balance in the former paragraph, but work beckons and time to close up this entry.
Have a safe and happy rest of 2015 to all.
I managed to get a cube-with-view, too.
The view also affords me a vantage in case of an invasion https://twitter.com/vincentzimmer/status/565562482383527936
So with a new office and work anniversary afoot, I will continue my blogging tradition. I'll begin with a few thoughts on being an engaged engineer. These sentiments include:
1. Being present
Even before chancing across http://www.forbes.com/sites/ellevate/2015/02/20/why-face-to-face-meetings-are-so-important/ this evening, I have always believed in face-to-face engagements in the workplace. Although I've always worked at a remote site, namely WA-state Intel, I purposely go out of my way to visit the larger sites, such as Intel in Hillsboro, OR, or the headquarters in Santa Clara.
It's imperative to have such meetings early in an engagement so as to build rapport, and then possibly maintain the relationship remotely for subsequent collaboration. Showing up demonstrates that 'you care' and that the other person 'matters.' Nothing can substitute for these gestures.
Also, having badged into five Intel sites across three states during the preceding four-day-week using plane, train, and automobile, I have recently practiced what I'm preaching on this topic.
2. Saying you don't know
A colleague in Oregon last Thursday suggested I treat this topic, although I've opined on it before. So here goes.
Another behavior I've observed includes reluctance of many technical leader to say "I don't know." Not having the immediate answer is OK. Just commit to following up and supporting the party. Feigning understanding doesn't help your standing with the other party or the overall business goals.
The technology and business landscape changes constantly. Strictly speaking it's impossible 'to know' everything.' But it is possible to keep and open mind, customer-oriented disposition, and desire to 'learn.' Let an occasional 'I don't know' help fuel the fire of curiosity and pedagogy.
I've touched on the former two items in past blogs, but I have yet to treat the next topic.
3, Ownership
In general, ownership can be powerful in that it highlights the party culpable for furthering a business or technical agenda. Recently, though, I've seen the dark side of ownership. For example, in some discussions people will assert "I own that." This is a variant of the logical fallacy of argument from authority in that the act of ownership is posited in lieu of providing other data, such as results.
Instead of 'ownership', I am more of a fan of 'helping lead,' 'coordinate', 'drive'. What matters is the business result. None of us truly 'own' anything in the company. The upper management, and reductio ad absurdum, the stockholders, 'own' the company. We are entrusted as employees, and especially as technical leaders, to drive a goal.
On the flight Friday morning, a senior manager gave me a nice definition of a leader. Minimally, a leader must 'have followers' and 'make changes.' I'd say that's necessary but not sufficient. Sufficiency may include a qualification of change such that it is 'conducive to the growth of the business,' and followers who 'grow and advance in their careers' as a result of the interaction. Good stuff.
So next time I hear "I own X," I'd rather hear "This is what we've produced with X."
So speaking of X's, let's talk about security and open source.
On the security front, I don't want to say too much other than note that I'll be speaking at CanSecWest (CSW) next month https://cansecwest.com/post/2015-02-01-11:00:00_Speaker_Announcements. The title of my talk, "UEFI, Open Platforms, and the Defender's Dilemma", sums up my thoughts on platform security.
To begin, let's dissect the title. The first portion of the title UEFI provides mechanism, such as many of the technologies found on http://www.tianocore.org and also recent write-up's like http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf.
The next portion of the title Open platforms provides a great opportunity to demonstrate a reduction to practice of these technologies, with a goal of demonstrating the design intent of the specifications in bits.
Finally, the defender's dilemma element of the title will review the relative asymmetry of platform defenders to the attackers. The cardinality of the attack presentations at this conference, namely 3 offense UEFI talks, to my 1 defense talk, brings this home. In fact, I represent one of the few defense talks hosted to be found in this conference series.
So let's get to the mapping of our three behaviors to the elements of the title. I will present in person so I get a check-mark on #1 of Being Present without much fan fare. On the topic of saying I don't know, I will not take the posture of being the omniscient guru of firmware. Instead, I want to enjoin the researchers in a dialogue, learning from them as much as I might be teaching. And I may up uttering those 3 humbling words more than I'd like. Finally, I would never claim to "own" platform security. There is a rich community of security professionals with whom I have the honor of working in the UEFI forum, open source community, and as professional colleagues. We all collaborate on providing a solution. I might lead in some venues, such as the UEFI Forum, but I am loathe to ever say I 'own' this topic area.
So that's for CSW next month.
Another application of these 3 behaviors to an X an include open source and open platforms. I've talked in the past about how thing like Intel(R) FSP can support various open source ecosystems and my excitement around Intel(R) Quark-based platforms like Galileo having open sourced their EDK II implementation. I also noted in my Intel Developer Forum 2014 talk that a book was coming. Well, the book Embedded Firmware Solutions: Development Best Practices for the Internet of Things has been published and can acquired via http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/ or http://www.apress.com/9781484200711.
An interview with the authors was also recently posted, too http://www.se-eng.com/2015/02/authors-of-embedded-firmware-solutions-include-key-industry-architects-of-open-solutions/.
I am a believer in collaboration, too. This book adds Google and Sage to the list of companies with whom I've publicly presented and co-authored material. Examples can be found at https://www.linkedin.com/in/vzimmer and includes AMI, Cisco, Dell, HP, IBM, Insyde, Intel, McAfee, Microsoft, NICTA, Phoenix, SuSE, Toronto.
So how do the three behaviors map to this topic? The easiest to answer is 'being present.' In the earliest days of Intel FSP and this book I had the opportunity to meet my colleagues in Mt. View, San Jose, and San Francisco. In this various venues I helped forge a relationship that evolved remotely, but the pioneering engagement was face-to-face.
And on the topic of "I don't know", I have to cite the spate of libre boot emails I received internally and externally in the wake of announcements like http://www.fsf.org/news/libreboot-x200-laptop-now-fsf-certified-to-respect-your-freedom. I don't know the extent to which the various business partners can open, but I'm always open to learn about the various viewpoints and desires of the ecosystem. But I do believe in more openness and transparency, just as 'open' is in my CSW title and talk, and the book above talks about 'open' solutions.
And finally, I don't 'own' open source firmware and platforms at Intel. I am luckily to have spent the last 15+ years on a team that has been open sourcing reference implementations of industry standards and firmware. We recently posted some elements of http://firmware.intel.com/projects/minnowboard-max to http://www.tianocore.org, such as https://github.com/tianocore/edk2/tree/master/Vlv2DeviceRefCodePkg and https://github.com/tianocore/edk2/tree/master/Vlv2TbltDevicePkg. These packages, and the ability to absorb Intel FSP binaries from http://www.intel.com/fsp, along with the more granular source plus binary builds, shows progress toward more open platforms in this community.
So that's about it for the inaugural blog of 2015. I've marked a work anniversary with a blog three-years-running on this date, I discussed three behaviors, and finally, I mapped those three behaviors to two case studies.
I have been invited to co-present at the Open Compute Summit http://www.opencompute.org/community/events/summit/ocp-us-summit-2015/ next month, too. I should have conjured up a 3rd case study on this topic area of "firmware and Cloud" challenges" to have a 3-3-3 balance in the former paragraph, but work beckons and time to close up this entry.
Have a safe and happy rest of 2015 to all.
