In the talent code, author Daniel Coyle tells us that "Greatness isn't born. It's Grown. Here's How" and I must say, the book really does deliver.
The premise of the book is simple. Traditionally, there has been a misconception that certain people are born to do certain things. When we look at a leader in any given field, we think that they were born to do this, it was in their genes. The book aims to prove this notion false, providing instead an alternate explanation, and that is that we are all myelin beings.
Myelin is a insulating material grown on axons in the brain, essentially ensuring that electrical signal travels fast and without loss of amplification. The explanation follows that the more we practice something, the more Myelin forms around the neurons that make up that action. The more myelin that forms, the better and more accurate the brain can transmit that signal. This is essentially the difference between the tops in a given field and the average.
There are three elements needed to grow myelin: deep practice, ignition, and master coaching. Combine these three, and you are destine to greatness in any field that you chose.
Deep practice is the concept that one must practice to be good at something, but it can't just be "any" type of practice. The practice that helps grow myelin is "deep". There are basically two components to deep practice.
1) Practice at the edge of your ability
Essentially, practice is only effective if it pushes you. You have to practice something that makes you use your brain, makes you concentrate on what you are doing.
2) Break down complex tasks into their core components, and practice those over and over
When practicing at the edge, you have to work to break the complex task that you are doing into it's core components. By doing that, you can then create exercises to practice each of those core components. The more you practices it, the more myelin will coat the electrical path in your brain.
Ignition is basically the passion behind what you are doing. The author has many stories about leaders in their field and the various events that "triggered" their ignition. Essentially, ignition is a switch, it is either on or off. Further, you can trigger ignition using primal queues. Most of these queues are tied to the words that we use.
The last ingredient in talent is master coaching. The best description of master coaching is from a quote in the book. "Great teachers focus on what the student is saying or doing ... and are able, by being so focused and by their deep knowledge of the subject matter, to see and recognize the inarticulate stumbling, fumbling effort of the student who's reaching toward mastery, and then connect to them with a targeted message."
There are four virtues to a master coach.
1) The matrix
2) Perceptiveness
3) The GPS Reflex
4) Theatrical Honesty
Summary
This was a great book and a great read. What I liked about it is how it confirmed a lot of what I already though was true about talent. Master coaches are required because they have already broken down a complex problem into it's parts, and are experts at teaching those parts and further .... the synthesis of those parts into the whole. Because they have already practiced doing this with the art they are teaching, they have also applied this ability to the act of teaching itself. They know to watch for queues, can adapt teaching patterns to the student, and are genuine people. Ignition is the passion that keeps the student going forward. For me, it was my uncle showing me how to make the background color on my C64 switch using basic. After that, I was hooked! Lastly, it is the deep practice. If you are passionate about something, you are always going to strive to improve at what you are doing. You can only do that by practicing at the edge.
I think my only criticism of the book is how "easy" the author makes this sound. I guess after the years of research he has put into it, he sees it clearly and can articulate it well. I, however, still feel that finding the combination of master coaching, ignition, and deep practice to be a rare thing.
Saturday, April 4, 2015
Sunday, February 8, 2015
Book Review: The Five Dysfunctions of a Team
Notes
- Dysfunction 1: Absence of Trust
- "is the confidence among team members that their peers' intentions are good, and that there is no reason to be protective or careful around the group"
- Basically, team members should feel comfortable being vulnerable with one another
- Tools To Address
- "Get to know each other games"
- Builds a personal connection that relationships can build on
- Evaluate shared models
- Express what each person feels they contribute / could contribute better to the team
- Discuss
- My Thoughts
- Running evaluations such as Strength finder might provide valuable insight
- Leader
- Take the first step!
- Dysfunction 2: Fear of Conflict
- "All great relationships require productive conflict in order to grow"
- Should be productive ideological conflict
- Maintain respect... somehow!
- Focus on ideas, not on people
- Healthy conflict is actually more efficient then no conflict
- Tools To Address
- Make it part of the culture
- Moderate as much as possible, but don't protect
- Dysfunction 3: Lack of Commitment
- "Commitment is a function of two things: clarity and buy-in"
- This does not mean consensus!
- Better to make a bold move and change then waffle
- Tools To Address
- End the meetings with a review of key points
- Establish clear deadlines and responsibilities
- Leader Role
- Take a chance and be prepared to be wrong
- Dysfunction 4: Avoidance of accountability
- "the willingness of team members to call their peers on performance or behaviors that might hurt the team"
- Peer pressure works!
- Tools To Address
- Publish goals and standards
- Team rewards
- Leader
- You can't do this alone, create the right culture!
- Dysfunction 5: Inattention to results
- "the tendency of members to care about something other than he collective goals of the group"
- Team status and individual status vs company goals
- Tools To Address
- Rewards that address good behavior
Summary
This is actually the second time I've read this book. The first was during a previous job. I was involved in leadership training, and my wife recommended that I read this book in conjunction with that training. At that time, I noted that the company I worked for actually possessed several of these dysfunctions, but didn't even know it. One particularly vivid memory comes to mind.
I was talking with a manager, and they commented about how the 360 review (that they had self selected to do) was a stunning success. That person commented that nobody had anything negative to share during the process, and that was a good mark to their record as a manager. If you get a chance to read this book, you'll note that this is probably as a result of dysfunction than as a result of stellar management techniques. There is no way to please everybody, and there is no way that everyone "just agrees" with the approach you are taking.
This book is actually quite well written, and I highly suggest picking it up. The "fable" approach is quite nice, and allows for a lot of color to be added to help describe the finer points of the dysfunctions noted above. Further, the dysfunctions are actually broken out and discussed in a chapter near the end, which makes for a great reference at any time!
Saturday, January 3, 2015
Scripting a basic network in Azure
Azure has a strong PowerShell API that allows for scripting of all components within their infrastructure as a service offering. In this blog post, I am going to use parts of this API to create a basic network that I can use to further build on later.
Here is a diagram of what I am trying to build.

In the diagram above, the Azure virtual network is the base. While configuring the virtual network, you will need to know some basic information such as the address space you intend to use, the subnets you would like to configure, DNS servers that will be used for the environment, and S2S or P2S connectivity details. For my purposes, I am going to use the following configuration:
Address Space: 10.0.0.0/8
Server Subnet: 10.1.0.0/24
DMZ Subnet: 10.2.0.0/24
Secure Subnet: 10.3.0.0/24
Client Subnet: 10.4.0.0/24
DC1 - 10.1.0.4
DC2 - 10.1.0.5
There are two commands that the Azure PowerShell API has to interact with vnet configuration. The Get-AzureVnetConfig allows you to export the existing configuration to a file. The Set-AzureVnetConfig takes an XML configuration file and apply that config to the subscription. One interesting quirk is that these commands are used to control all virtual network, dns, and local network configurations. If you, say, used the get command to get the XML, deleted a virtual network config, and then used the set command to apply it, the corresponding virtual network would be deleted (or attempted to be deleted).
This quirk throws a slight complication in my script. In reality, I want to add a new virtual network, and if it already exists, skip to further steps down the line. It turns out that powershell makes interacting with XML quite easy, and creating the corresponding add scripts are actually quite simple to do.
Here is the code I use to add my virtual network configuration to an existing configuration file.
The code above basically goes through the two steps. Firstly, add the DNS servers that you wish to reference in the vnet. Second, add the VNET. Here is a reference for the AppendDNSTo function.
Now that the basic vnet has been created, we need to create the "firewall" between each zone as depicted in the diagram. With the recent addition of multiple nics, I could see a few different ways to do this, potentially using 3rd party solutions. However, Azure also provides the concept of Network Security Groups which can be used. These are basically stateful firewalls that can be applied to either a VM or a subnet. What is also interesting is that they come with a default ruleset that is easy to work with. After installing mine, here is what the rules came out to.

While not complete for my purposes, it is a good base that allows you to get started with network security groups quickly.
Here is a function I wrote to help with adding NSG to the subnets. It is pretty simple. Create one, and associate with the subnet.
While I don't have anything in this virtual network to test with, I was able to quite simply confirm the configuration. I now have a script to build out a basic network in any subscription. Cool!
Here is a diagram of what I am trying to build.
In the diagram above, the Azure virtual network is the base. While configuring the virtual network, you will need to know some basic information such as the address space you intend to use, the subnets you would like to configure, DNS servers that will be used for the environment, and S2S or P2S connectivity details. For my purposes, I am going to use the following configuration:
Address Space: 10.0.0.0/8
Server Subnet: 10.1.0.0/24
DMZ Subnet: 10.2.0.0/24
Secure Subnet: 10.3.0.0/24
Client Subnet: 10.4.0.0/24
DC1 - 10.1.0.4
DC2 - 10.1.0.5
There are two commands that the Azure PowerShell API has to interact with vnet configuration. The Get-AzureVnetConfig allows you to export the existing configuration to a file. The Set-AzureVnetConfig takes an XML configuration file and apply that config to the subscription. One interesting quirk is that these commands are used to control all virtual network, dns, and local network configurations. If you, say, used the get command to get the XML, deleted a virtual network config, and then used the set command to apply it, the corresponding virtual network would be deleted (or attempted to be deleted).
This quirk throws a slight complication in my script. In reality, I want to add a new virtual network, and if it already exists, skip to further steps down the line. It turns out that powershell makes interacting with XML quite easy, and creating the corresponding add scripts are actually quite simple to do.
Here is the code I use to add my virtual network configuration to an existing configuration file.
$networkConfigurationPath = [System.IO.Path]::GetTempFileName()
Write-Host $networkConfigurationPath
Get-AzureVNetConfig -ExportToFile $networkConfigurationPath
AppendDNSTo -filePath $networkConfigurationPath -dnsServerName "PIA-DC1" -dnsServerIP "10.1.0.4"
AppendDNSTo -filePath $networkConfigurationPath -dnsServername "PIA-DC2" -dnsServerIP "10.1.0.5"
$subnets = @{
"Server" = "10.1.0.0/24";
"DMZ" = "10.2.0.0/24";
"Secure" = "10.3.0.0/24";
"Client" = "10.4.0.0/24";
}
$vnetName = "PIA"
AppendVNetTo -filePath $networkConfigurationPath -dnsServerRefs @("PIA-DC1","PIA-DC2") `
-vnetName $vnetName `
-vnetLocation $location `
-addressSpace "10.0.0.0/8" `
-subnets $subnets
Set-AzureVNetConfig -ConfigurationPath $networkConfigurationPath
Remove-Item -Path $networkConfigurationPath
The code above basically goes through the two steps. Firstly, add the DNS servers that you wish to reference in the vnet. Second, add the VNET. Here is a reference for the AppendDNSTo function.
function AppendDNSTo{
<#
.SYNOPSIS
Helper method to add DNS to an existing Azure network config file
.DESCRIPTION
Appends a DNS entry to an existing config. If it already exists, will continue without error
.PARAMETER configPath
The path to an already existing configuration
.PARAMETER dnsServerName
The Name of the new DNS Server
.PARAMETER dnsServerIP
The IP of the new DNS Server
.PARAMETER failIfExists
Instructs program to throw error if DNS already exists
#>
param(
[Parameter(Mandatory=$true)]
[string]$filePath,
[Parameter(Mandatory=$true)]
[string]$dnsServerName,
[Parameter(Mandatory=$true)]
[string]$dnsServerIP,
[bool]$failIfExists = $false
)
TestGivenPath -filePath $filePath
$xml = [xml] (Get-Content $filePath)
$dnsServers = $xml.NetworkConfiguration.VirtualNetworkConfiguration.Dns.DnsServers
if ($dnsServers.ChildNodes | ? {$_.name -eq $dnsServerName}){
Write-Debug "DNS Server already exists"
if ($failIfExists){
throw "DNS Server Name provided already exists in config file"
}
}
else{
$dnsServerToAdd = $xml.CreateElement("DnsServer",$xml.DocumentElement.NamespaceURI)
$dnsServerToAdd.SetAttribute("name",$dnsServerName)
$dnsServerToAdd.SetAttribute("IPAddress",$dnsServerIP)
$dnsServers.AppendChild($dnsServerToAdd)
$xml.Save($filePath)
}
}
Now that the basic vnet has been created, we need to create the "firewall" between each zone as depicted in the diagram. With the recent addition of multiple nics, I could see a few different ways to do this, potentially using 3rd party solutions. However, Azure also provides the concept of Network Security Groups which can be used. These are basically stateful firewalls that can be applied to either a VM or a subnet. What is also interesting is that they come with a default ruleset that is easy to work with. After installing mine, here is what the rules came out to.
While not complete for my purposes, it is a good base that allows you to get started with network security groups quickly.
Here is a function I wrote to help with adding NSG to the subnets. It is pretty simple. Create one, and associate with the subnet.
function AddNetworkSecurityGroupAndAssociate{
param(
[Parameter(Mandatory=$true)]
[string]$nsgName,
[Parameter(Mandatory=$true)]
[string]$nsgLabel,
[Parameter(Mandatory=$true)]
[string]$subnetName,
[Parameter(Mandatory=$true)]
[string]$vnetName,
[Parameter(Mandatory=$true)]
[string]$location
)
New-AzureNetworkSecurityGroup -Name $nsgName -Location $location -Label $nsgLabel
Get-AzureNetworkSecurityGroup -Name $nsgName | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName $vnetName -SubnetName $subnetName
}
While I don't have anything in this virtual network to test with, I was able to quite simply confirm the configuration. I now have a script to build out a basic network in any subscription. Cool!
Subscribe to:
Posts (Atom)