Last year, while I was developing my talks, I saw a bit of bad advice. I didn't recognize it at the time. Instead, I saw it as a goal to reach. The forum was a private one, and I've long forgotten who the players were. But here is a reconstructed, summarized view of what spurred me to try:
elph1120: You know what I love? A speaker who can do an entire talk from one slide.
612kenny: OMG yes. I saw someguy do that at someconference. It was amazeballs.
elph1120: Yeah, more speakers should do that.
This is bad advice. Don't do this.
Now to explain what happened...
I saw this, and decided to try and do that for my DevOpsDays Minneapolis talk last year. I got close, I needed 4 slides. Which is enough to fit into a tweet.
See? No link to SlideShare needed! Should be amazing!
The number one critique I got, by a large, large margin was this:
Wean yourself from the speaker-podium.
In order to do a 4-slide talk, I had to lean pretty hard on speaker-notes. If you're leaning on speaker-notes, you're either tied to the podium or have cue-cards in your hands. Both of these are violations of the modern TED-talk style-guide tech-conferences are following these days. I should have noticed that the people rhapsodizing over one-slide talks were habitues of one of the holdouts of podium-driven talks in the industry.
That said, there is another way to do a speaker-note free talk: the 60-slide deck for a 30 minute talk. Your slides are the notes. So long as you can remember some points to talk about above and beyond what's written on the slides, you're providing value above and beyond the deck you built. The meme-slide laugh inducers provide levity and urge positive feedback. If you're new to speaking this is the style you should be aiming for.
A one-slide talk is PhD level speaking-skills. It means memorizing paragraph by paragraph a 3K word essay, and read it back while on stage and on camera. You should not be trying to reach this bar until you're already whatever about public speaking, and have delivered that talk a bunch of times already.
As John Nicholson was traveling in and around New Zealand I was asked by Pete if I could co-host the Virtually Speaking Podcast again. It is always entertaining to join, Pete is such a natural when it comes to these things. I euuh, well I do my best to keep up with him :). Below you can find the latest episode on the topic of vSAN Customer Use Cases. It includes a lot of soundbites recorded at VMware World Wide Kick Off / Tech Summit, which is a VMware internal event for all Sales, Pre-Sales and Post-Sales field facing people.
You can of course also subscribe on iTunes!
"Virtually Speaking Podcast – vSAN Customer Use Cases" originally appeared on Yellow-Bricks.com. Follow me on twitter - @DuncanYB.
Whoever came up with the name “Human Resources” deserves a medal. Such a descriptive, helpful, and seemingly useful name. Why yes, I’m human and I sure could use some resources. Purely viewed by the name, Humans Resources or HR seems like such a great idea. These are the people who are responsible for looking after your people whether it’s their health, compensation, or career.
So, why do we freak out when HR is in the building? What’s with the hush whispers when you see your boss huddled with HR in her office? Layoffs? Reorg? Has anyone seen Ryan today? HR’s presence typically makes folks paranoid. I’ll repeat that: the folks whose job it is to be resources for humans collectively gives us the shakes. What happened?
It’s not HR; it’s your culture.
Disclaimer: I’ve never worked in HR, and all of my observations regarding HR have been made without what I assume is the daily toil of having a gig where the expectations are so high, but corporate support is traditionally low. However, both as manager and as a former employee of an HR-focused start-up, I know a bit.
Simplification: There are all sorts of different jobs inside of HR and depending on the size of your company, your HR team may have one or all of them. Benefits, recruiting, compensation, training, it’s a long list. For the purpose of this article, let’s consider HR to be the folks who are responsible for helping a team thrive. They have many other jobs, but that’s the one I’m thinking about in this piece.
HR is a tough gig. They have constraints which often leads to unique behavior that affects their reputation. Two examples:
As a support team and a cost center, HR traditionally does not receive a lot of investment. How many folks is your manager responsible for? Ok, how many is your HR partner responsible for? My guess is your HR person has 10x the number of people for whom they are responsible. This under-resourcing has interesting consequences.
First, because of their limited numbers, they logically gravitate towards informed decision makers because these humans are an early warning system regarding what is and isn’t going well. This network helps keep them informed as to the state of the company.
Second, because of their allegedly human-related skills, they are called in when there are people-related problems. This means you only see them when something is going down. These infrequent appearances when the sky is falling contributes to their grim reaper reputation.
Finally, when they do arrive because the sky is falling, they are informed because of the carefully built information gathering network, but when they start talking, they don’t sound like you. They, like every group at your company, have a language all their own, which when accompanied with the penchant for showing up when the shit is going down makes their language the language of trouble.
All of these attributes contribute to the problematic reputation of HR. Yet, in two decades of work I’ve discovered that when the team is freaked out by HR, it’s not HR, it’s the culture. Something is rotting.
Culture == Values
Your company has values regardless of whether you’ve painted them on the wall or produced an employee handbook. They exist as a result of the Old Guard employees working together, making decisions, and successfully building the company.
Values exist as stories. Back in our first building, Christine once stayed up all night working on a single performance bug that ended up revealing fundamental flaws in our architecture. The implied value? Persistence or perhaps craftsmanship.
Values exist as people. When I watch Brad run a meeting, I realize how poorly I run my own. The implied value? Everyone’s time is valuable, efficiency, or maybe constant improvement.
Values are principles or standards of behavior, and in a group of humans, they are first defined by the founding employees and then evolved over time by the leadership team. Painting them on the walls or writing them down in an employee handbook makes them accessible and obvious, but it is how these values are consistently applied especially during times of crisis that gives values value.
When I hear, “I don’t trust HR,” I ask, “Why?” The answers vary, “They are political. They are risk mitigators. They protect the company… not the employees.” There are humans in HR who exhibit this behavior. However, it is equally likely there are humans at every level of leadership who exhibit this behavior, and all are allowed to behave in this way because of the values of the company.
Has Anyone Seen Ryan Today?
The rule is: in the absence of information, humans will make up a story to fill the vacuum. When this happens, listen to the story because not only do they usually find the worst case scenario, it’s a situation that reflects the perception of your company’s values.
Where is Ryan? Well, he left early on Friday and was out all day on Monday. I think he’s checked out and you know what we do to checked out people here? HR fires them without warning.
No, HR doesn’t fire people without warning. No, Ryan is not checked out. He’s just sick, and his manager forgot to send a message to the team. The issue here is that the team believes HR has nefarious unchecked power and in my experience they rarely do. They are capable, overworked, emotionally intelligent humans who I call when I need help.
Yes, they swarm around disasters. Yes, they have access to a lot of information. You should hold them to them a high bar. More importantly, you should understand how in the world your team comes to hold seemingly irrational beliefs because their existence is not a sign of their character of your team, it is a sign your culture is rotting.
Over the past couple of months I have had more and more discussions with customers and partners about VVols. It seems that Policy Based Management and the VVol granular capabilities are really starting to sink in, and more and more customers are starting to see the benefit of using vSphere as the management plane. The other option of course is pre-defining what is enabled on a datastore/LUN level and use spreadsheets and complex naming schemes to determine where a VM should land, far from optimal. I am not going to discuss the VVols basics at this point, if you need to know more about that simply do a search on VVol.
When having these discussions a bunch of things typically come up, these all have to do with design and procurement considerations when it comes to VVol capable storage. VMware provided a framework, and API, and based on this each vendor has developed their own implementation. These vary from vendor to vendor, as not all storage systems are created equal. So what do you have to think about when designing a VVols environment or when you are procuring new VVol capable storage? Below you find a list of questions to ask, with a short explanation of why this may be important. I will try to add new questions and considerations when I come up with them.
In many cases, especially existing legacy storage systems, an upgrade is needed of the software to support VVols, ask:
When it is clear what you need to support VVols from a software point of view, ask:
And then there is the control / management plane:
Note, as it stands today, in order to power-on a VM or create a VM the VASA Provider needs to be available. Hence the availability model is probably of importance, depending on the type of environment you are designing. Also, some prefer to avoid having it implemented on the storage system, as any update means touching the storage system. Others prefer to have it as part of the storage system as it removes the need to have a separate VM that needs to be managed and maintained.
Last but not least, policy capabilities:
I hope this helps having the conversation with your storage vendor, developing your design or guide the conversation during the procurement process. If anyone has additional considerations please leave a comment so I can add it to the list when applicable.
|groundswell||a buildup of opinion or feeling in a large section of the population|
|cock-a-hoop||extremely and obviously pleased esp about a triumph or success|
|beset||to attack on all sides; assail; harass|
|tawdry||showy but cheap and of poor quality|
|cordon||prevent access to or from (an area or building) by surrounding it with police or other guards (think of "do not cross" yellow tape)|
|ratched||(same as wretched) of poor quality; shabby or filthy in appearance; unfortunate conditions or circumstances. 'hot mess'|
|beckon||make a gesture with the hand, arm, or head to encourage someone to come nearer or follow|
|sidle||to move close to someone in a quiet or secret way|
|detente||the easing of hostility or strained relations, esp between countries|
|emissary||a person sent on a special mission, usually as a diplomatic representative (a messenger)|
|gingerly||in a careful or cautious manner|
It's not as widely known as I hope, but there are a host of workplace protections that apply to non-union, salaried, overtime exempt workers. Not all of them are written into the legal code, and are, in fact, work-arounds. To explain what I'm talking about, read this:
I asked people who had reported harassment or assault to their employer to tell me what happened after.-- ashe dryden (@ashedryden) October 12, 2013
23 of 25 were fired within 3mos.
This is a small sample-set, but it works to illustrate the point I'm about to make.
If you find yourself in the position of reporting a coworker to HR for harassing behavior, suddenly find your performance reviews solidly in needs improvement territory, and get fired later; there are workplace protections that will help you get through this, and make the life of your harasser less good.
To get there, here are a few facts and common practices that contribute to the firing, and what could happen afterwards:
Performance Reviews, and Career Improvement Plans
These are often used as the basis for a firing decision. Not all workplaces do them, but many do. It may be hidden in the OKR process, in 360-degree reviews, or another company-goal tracking system, but it's still there. Sometimes they're simple exceeds/meets/needs-improvement metrics, or 1 to 5 ranked metrics, and always have manager input on them.
All of them have some component of plays well with others as one of the tracked metrics. No one likes working with assholes, and this is how they track that. Unfortunately, tattling to mommy that Kenny was mean to her is often seen as not playing well with others.
Buying Your Silence
The severance process you go through after termination is there to buy your silence. Employers know full well there is a marketplace of opinion on good places to work, and if they can keep you from bagging on them on Glassdoor or social media, that's a win for them. You also get a month or two of paid healthcare as you look for someplace new. The method of doing this is called a non-disparagement clause in the severance agreement.
Laws are there to incentivise people to not get caught
If you have a good enough papertrail to plausibly bring suit against the company for one of the legally protected things like racism or sexism, there are strong incentives for them to settle this out of court. Everyone has a price, and most people have a price that doesn't include a written admission of guilt as a requirement. This is why there are so few actions brought against companies in court.
Of the three Westrum Typology types of corporate communication styles (Pathological, Bureaucratic, Generative), it's the pathologic that fundamentally treats non-managers as objects. When you're an object, it doesn't matter if your fee-fees get hurt; what matters is that you're on-side and loyal. If you are seen to be disloyal, you will need to find a new master to swear your fealty to or you will be disposed of through the usual at-will / severance means.
Not all companies are pathologic. The studies I've seen says it's less than a quarter. That said, if the company is big enough you can quite definitely have portions of it that are pathologic while the rest are generative.
That's a lot of framing.
There are certain legal nightmares that companies have with regards to labor laws:
All of these actions are massively public and can't be silenced later. The fact of their filing is damnation enough.
This works for you, even though none of these are likely to come about for your specific case. You see, they're trying to avoid any of that ever happening. To avoid that happening they need to buy you off. Don't think that this is their way of protecting the bad man from any consequence. It's their attempt to, it's up to you to make it actually painful.
Once the third person has been fired and levered themselves into a $200K hush-money severance package, you can guarantee that The Powers That Be are going to sit the bad man down and explain to him that if he doesn't stop with the hands, they're going to have to Do Something; you're costing us a lot of money. One person doing that is just a whiner trying to extort money. Two people getting that is an abundance of whiners. Three people getting that begins to look like a pattern of behavior that is costing the company a lot of money.
This only works because the consequences of simply ignoring your whiny ass are now dire. Thanks, New Deal!
Transmission Control Protocol/Internet Protocol (TCP/IP protocol suite) is a set of rules and protocols enabling data communication between computers. Developed in the mid 1970’s and widely adopted in the early 1980’s, it has been the de facto standard of computer networking for over 35 years.
TCP/IP provides the necessary framework for two points connected through a network to exchange information. In the Protocol Stack, the set of protocols used in a communications network, TCP/IP plays a particularly important role in two specific layers:
Transmission Control Protocol is responsible for establishing reliable data exchange between applications. This ensures that data is not lost or misinterpreted along the way: TCP confirms that the message sent is the message actually received.
TCP undertakes the task to open a channel of communication between the two computers. It breaks the data into small units of information (“segments” or “packets”) as required, confirms correct delivery and reassembles them at the destination.
The other, equally important task is to send the data to the correct recipient. This is the responsibility of Internet Protocol, that determines how data will find its intended destination through interconnected networks. In other words, IP dictates the roadmap that data will have to follow. IP ensures that all packets include the information necessary for each node to be able to forward them to the next.
TCP is activated with every network request/response. For example, in an HTTP request, TCP takes over as soon as the browser knows where the request should be routed, i.e. after DNS resolution has been completed. Based on the socket provided (combination of IP address and server port), the request will reach the target computer and application through the network. The necessary communication channel will open up and data will be broken down to appropriately sized packets. Then, they will be sent over to the server. While the server handles the request and prepares the response accordingly, TCP makes sure that this particular connection channel remains open until the response reaches the source of the request successfully.
While moving data around, TCP/IP protocols annotate segments with extra information (headers) in order to be able to perform all the above tasks successfully. Headers include information regarding the segment sequence number, a number (checksum) to allow confirmation of data validity and information about sender and recipient.
This added information allows data to be segmented and transmitted as efficiently as possible, making sure it is correctly restructured at the destination, without worrying about structure during transportation. But it also plays an important role in the Three-Way Handshake.
Unlike User Datagram Protocol (UDP), reliability is a top priority for TCP/IP. UDP serves as an alternative to TCP for different types of communication services where there is no time or need for confirmation that the correct message was successfully received by the intended party. An example of a case like that is a voice call over IP.
But in most cases, such confirmation is absolutely necessary.
To ensure reliability in communications, TCP establishes a verified connection between the client and the server computer before actual data is transmitted. This is done through the Three-Way Handshake using three segments (hence the “three-way”).
Click here to read more about the Three-Way Handshake.
TCP/IP comes with utilities that assist admins diagnose and understand problems in network performance. The most well-known of these utilities is probably Ping, that allows you to test whether your computer can open a communication channel with a certain host to exchange data, and how fast.
In a way, Traceroute takes the Ping utility a few steps further. Data transmitted through networks almost always goes through intermediate nodes before reaching its destination. Traceroute is especially designed to identify all the routers or other network devices (“hops”) between the source and the destination and measure the rate at which data is exchanged with each router. So the purpose of Traceroute is twofold:
Using specific switches, the Traceroute command can be configured with regard to maximum hops, timeouts for each reply, hostname resolution and other options.
Traceroute takes advantage of the “TTL” field found in all packet headers sent around the internet. TTL stands for Time To Live and indicates the maximum number of hops that a packet is allowed to travel to before being discarded. The purpose of this is similar to a timeout: if a packet is moved around without finding its destination it is wise to discard it after a reasonable number of nodes visited. In order for TTL value to work, all routers are configured to reduce a packet’s TTL value by one before forwarding it to the next node. When a packet is discarded, the router sends a special message all the way back to the source, so the sending host knows where a packet was discarded from.
Traceroute exploits this behaviour by sending packets to a destination and making sure that every time a packet reaches a new intermediate hop it is actually discarded so that a message is sent back containing the intermediate router’s information. Then the packet is send again with TTL increased by 1 so that it won’t be discarded from hops that have already been visited before. The process is repeated until the packet reaches its destination host. There, it is designed to be “unusable” rather than discarded, i.e. the final hop also sends a message, albeit a different one, so that Traceroute knows it is time to stop resending packets.
Here’s how it all works:
So Traceroute can prove very useful when a certain host seems unreachable or when you notice an unexpected delay in a data transfer. Traceroute can reveal where the bottleneck might be and help you decide on corrective or alternative action.
In general, to analyze results, we look at the round trip times recorded by Traceroute. For each hop, Traceroute actually sends 3 packets (with different port numbers so that they are completely distinct) so that the sample is more reliable.
Here are a few rules of thumb when reading these results:
What about you? What is your experience with Traceroute?
I’m a member of New Westminster’s Advisory Committee for Transit, Bicycles and Pedestrians (aka ACTBiPed), and we had our first meeting of the year on February 2017. Since they’re open to the public and only one member of the public routinely attends (the always awesome Mary Wilson), I’ve decided to post a little report after each meeting outlining the things that we do and learn in these meetings to help shed some light on the City’s efforts to make sustainable modes of transportation safer and more appealing.
Because last night was the first one of the year, we had to deal with the administrivia first: Oath of Office, don’t be a jerk, that sort of thing. Did you know that as a member of an advisory committee I’m not allowed to take bribes? Shocking, I know!
The first proper committee work we did was to receive and endorse the 2017 ACTBiPed Transportation Work Plan, which gives a summary of the things that the Transportation Section of the City is planning on bringing to the committee in 2017 for our consideration. Our work is largely guided by the City’s Master Transportation Plan, which has the following four targets to achieve before 2041:
Since we’re concerned with sustainable modes of transportation (transit, cycling, and walking) a lot of what the city is planning to hit targets 1, 3 and 4 fall under ACTBiPed’s remit. In 2017, some of the areas they’re planning on bringing to us include:
We endorsed this work plan, and I’m looking forward to seeing more details on a number of these items.
We then received a report from Engineering Services about the 2017 Pedestrian Crossing Improvement Program. The first thing to note about this is that the budget of $250,000 for this program has not yet been approved by council, so it’s subject to change.
Engineering Services has identified 9 locations in the city that would benefit from some sort of improvements to make crossing the street safer for pedestrians. The procedure to identify these locations is a little complicated, involving vehicle traffic counts, pedestrian traffic counts, vehicle speeds, distance from another control device, number of collisions, and the demographics of pedestrians in the area (is it on a Safe Route to School, are there a significant number of vulnerable pedestrians such as seniors or people with disabilities, and so on). They also use these statistics to determine what kind of improvements are warranted — it makes no sense to put a pedestrian activated traffic signal on a quiet street with very few pedestrians.
Punching in all of the numbers and doing some analysis, Engineering Services came up with these proposed improvements:
There are another two that Engineering Services hopes to improve in 2018:
Judging from the discussion around the table, the last one is going to be a little controversial. It’s fairly close to the pedestrian crossing at Royal Avenue and Stewardson Way, and there isn’t a lot of pedestrian traffic at Royal and Eleventh. It has a lot of vehicle traffic, and that vehicle traffic is moving quickly (67.5km/h in a 50km/h zone). But importantly, of all the crossings analyzed this crossing had the second-highest number of collisions, and even worse, it had a pedestrian collision. Pedestrians surveyed say they do not feel safe at the Royal/Stewardson crossing, and this crossing would make pedestrians feel and be safer crossing Royal at Eleventh.
We endorsed the 2017 Pedestrian Crossing Improvement Program, and since that was the last item on the agenda, we wrapped up the meeting.