Things Software Leaders Should Know

Reflecting on a tumultuous but ultimately successful year. Here’s what I’ve learned, re-learned, or cemented in my “2015 things (software engineering) leaders should know”:

On Measurement

  • Measure everything, as early as possible.
  • Collecting data is cheap. You will not know you need it until after you need it.
  • Do not build anything (teams, features, processes) without having a measure for success.

On Team Empowerment

  • You can never empower teams enough. Ownership is a force multiplier.
  • Convey problems to be solved and jobs to be done, not solutions to be built.
  • But: a great, empowered team still needs direction, and can take direction well when required.
  • An empowered team without appropriate context and direction will (rapidly, skilfully and with great dedication) create chaos.
  • Often mum knows best. Eat your broccoli before you have dessert.

On Coaching

  • Coaching skills are the most impactful thing you can learn as a leader.
  • You may think you’re a good coach, but you’ll be better if you actively train in coaching.
  • Allowing yourself to be coached is a powerful way to improve yourself as a coach.
  • Personal feedback is your lightsaber: be mindful where it’s pointing before you turn it on.

On Discipline

  • Maintain a to-do list. No excuses.
  • If you have people things and tech things on your to-do list, put the people things first on the list.
  • If you don’t have a great technical partner (CTO) to help tick off those tech things on your to-do list, make it your mission to get one.
  • Put Bronnie Ware’s regrets of the dying at the top of your to-do list.
 (also published on Medium)

Where are the Developers?

The amazing recruiting team at Vend have hired a few awesome software developers to add to our already incredible team. But it is hard work. Really, really bloody hard. So hard that I sometimes wonder what we’re doing wrong. Are we looking for the right people? Are we sending the right messages to attract those people? I’ve been thinking hard about what we’re looking for, and what we have to offer, and wondering if those things match up.

I think back to classic hiring articles like Joel Spolsky’s Smart and Gets Things Done for example. Are we asking the right questions in interviews? I’m pretty sure we are, but we could do better. I think about the concept of the 10x developer. Are we looking for unattainable unicorns instead of incredibly good racehorses? Maybe, but our current unicorns would get pretty lonely if we didn’t hire more.

What about our tooling? Should we be looking for a direct match there? There are plenty of opinions on PHP, but that’s only one part of our stack, and a part that we do as well as any modern dev shop, with unit tests, dependency injection, MVC, and – quite seriously – the most robust code review and continuous delivery culture I’ve ever been involved in. I could mumble about HHVM and PHPNG, but that’s just noise. Of course we’re looking at those: we continually evolve our platform just as we also include other tools where it makes sense. I’d list all the bits but honestly you’re better off coming in for a coffee to chat through it all with our crazy-talented devops crew.

It’s particularly interesting to me, coming from a Microsoft dev background, that your average PHP developer has less in common with what we build than does a high-end C# or Java dev. Emphasis on the average in that last sentence, because we all know VB6 caused the Microsoft world just as much pain as PHP; but you could argue .NET and Java have supported good, testable OO coding for longer than PHP has.

Coming back to Spolsky’s post, there’s a quote that highlights my point on tooling:

In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.

If I’m brutally honest, I think we’ve boxed ourselves in a little by advertising hard for PHP developers, when what we really need are great developers. 10x developers. Smart and Gets Things Done developers. Developers who thrive on massive growth and solving crunchy problems in a supportive team environment built on Trust and Focus.

Maybe those developers know a bit of PHP, but it’s more likely that they’re dabbling in Node or Go or some godforsaken JVM variant. All I care is that they’re passionate and intelligent, and want to share those talents with a team of like-minded individuals.

Is that so hard? In the famous words of Delia Smith: Where are you? Let’s be avvin’ you! I’d love to chat over this stuff with anyone. Or just.. you know.




Those following along at home will know that I recently wrote about the place of responsibility and ownership in software development. While valid throughout software engineering, ownership is especially important in the context of a rapidly scaling software business – we need to be able to rely on developers to get things done without a massive layer of management whom we neither have the time to recruit, nor the culture to support.

The seminal Netflix culture  slide deck (yeah it’s a doozy – I’ll wait while you read it), illustrates this wonderfully as the point where the growth rate of the business out-paces the density of high-performing individuals. This is traditionally the point where layers of management and process are introduced to deal with the ensuing chaos.

First ever 747The clue to solving this is imbued throughout that Netflix deck too: trust. Without trust we can’t expect responsibility to flourish. Without trust we sit on the shoulders of developers, imposing restrictions and demanding feedback. Proponents of Agile would call this an impediment.

So what does trust look like in a rapidly growing engineering team?

Solving the right problems

Newly minted development managers coming from a technical background (and there’s an argument they should only be from a technical background), often feel to manage developers one needs to prove one’s technical prowess. I’ll admit to falling into this trap myself, especially when working with a new team. If they don’t respect me as a coder, how can I have any authority?

Here’s the thing: the problems you need to solve as a technical manager are by definition non-technical. You need to create an environment in which the engineering team can execute to their potential, and otherwise just get out of their way. The last thing you need is technical authority. I suggest you get your technical jollies forking MEAN at home, and use your fading technical knowledge when liaising with the business, but otherwise close Sublime Text or Visual Studio and walk away.

Do you trust your team to choose the right libraries, architect solutions, solve loosely-defined technical problems, and code to their best abilities? How about do you trust the team to deliver a solution that is the best mix of JFDI and polish for a given timeframe? If you don’t, then you have a problem infinitely larger than your technical abilities could ever solve.

So, what problems should you be solving in order to build responsibility and ownership in your engineering team, and build a self-propelling engine of international awesome?


Work with the business to make sure the engineering team are working on the right thing, right now. Help them understand how to build the right way. The right thing of course means the number one (or two or three) thing that must be built to bring delight to your customers (new or old).

Here’s one I prepared earlier.


You are undoubtedly right to abhor a 50-page technical specification, but you do need to demand enough information so that engineers can understand the scope of the task at hand, and ensure they can connect to the right people to get the detailed answers as they build. This might be Product Management, or perhaps direct customers. Facilitate and engage, then leave them to it; don’t dictate.

You need to be a navigation buoy in the flow between engineering and their stakeholders, rather than an hourglass through which all information must travel.


Provide space and time for the team to lay their foundations. Documentation, tooling, code reviews, training, recruiting, onboarding, communication, experimentation. All of those things that are “invisible” to customers but oh so incredibly important to the smooth operation of a dev team and the production of world-class software.

You need to be the advocate for this behaviour, explaining to the business why it is essential. But trust, trust that the team can execute this foundation work themselves.


If you’re getting a lot of the above right, then your team will be a fecund swamp of talent. Engineers will be popping up and seeking out challenges. It can be super tricky to find opportunities for growth in a small team and company, but one simple way to promote growth is to delegate ownership as much as you can, because this supports the growth of both the team and the individual – things you need to be happening as the team size grows.

You can also facilitate internal presentation sessions to foster talent within the team, then support your engineers if they want to present externally.

Use your gut feel and previous technical experience to pinpoint areas for improvement and work with each engineer individually to help them improve those areas. We’ve found some benefit in plotting a modified Urban Airship Tech Ladder across four axes, which can show where an engineer perhaps excels in some areas but can improve in others. Great food for growth!

Output will flow

I imagine some readers are having heart palpitations because I haven’t mentioned delivery, or deadlines, or output. My assertion is that if you get the above right – especially focus and clarity – output will flow. Sure you can tweak the dials on time spent on foundation vs delivery work, but only for short periods of time.

Trust the team. They will deliver.

TL;DR version: Are your engineering managers solving the right problems, or are they an impediment?





Using TeamCity and PowerShell to Deploy Automated Builds to Windows Azure

We’re building an ASP.NET MVC3 website that runs in Windows Azure, using the fabulous TeamCity as our build server. So far we have been just building and running the site locally on the build server, but we wanted to extend our build process into the cloud. Here’s what we wanted:

  • Build server runs a build and executes all tests
  • Deploy locally to the build server for our own smoke testing
  • Create Azure packages
  • Deploy to an existing Azure staging environment (retaining the same staging URL so our clients can access it)
  • If staging is all good, we can manually do a VIP-swap to move staging into production.

We found some pretty useful posts, including this one, which got us most of the way along the road. However, even that post seems overly convoluted. There’s no need to execute a cspack command line, for example. Perhaps it’s geared to older versions of the Azure tools? For the record, we’re using MVC3 and Azure tools 1.4, and we have a very basic solution with a single web role, a test project, and an Azure project.

So, assuming you already have a TeamCity build configuration that builds your web project without problems, here’s what you need to do to get your Azure packages built and deployed.

TeamCity Build Step to Create Azure Packages

This one was a lot easier than many blog posts made out. We didn’t need to call cspack via command line. Simply create an MSBuild step, point it at your Azure package (the actual ccproj file), and set the target to be CorePublish. That’s it. Once that step runs, you should see your cspkg file in the output location on your build server.

If you’re struggling with this step, make sure you have the Azure tools installed on your build server, and you might also need to copy across all the MSBuild include files from a PC with Visual Studio on it (from C:\Program Files (x86)\MSBuild\Microsoft\). Worst case you can install Visual Studio on your build server.

Open the little image at right to see an example of how this build step should look.

Create (or copy) a Powershell Script to Deploy to Azure

The first thing to do is install the Windows Azure Platform Powershell Cmdlets on your build server. Just install the package, and remember to run the “StartHere.cmd” file to install and configure the Cmdlets.

This is where we needed to do some jiggery-pokery. The original script we found was rather aggressive. It completely removed the existing staging deployment, then recreated it. The downside of this is that it changes the staging URL. Our modified script is below. This new script assumes an existing staging deployment exists, and will upgrade it. Ideally we should modify the script a tiny bit to deploy a new staging deployment if one doesn’t exist (in the else block).

We’ve also made a small change so that the staging URL is emitted as part of the build script (see the write-host $azureProperties.Url line).

Obviously you’ll need to insert the appropriate certificate thumbprint (you’ve got a management certificate in your Azure console right?!), and your subscription ID. The best way to test that you’ve got this right is to execute the script from the PowerShell command-line on your build server. It took us a few goes to get it bang-on, but once we had everything right, we could see the deploy happening in real-time.

$cert = Get-Item cert:\CurrentUser\My\your-management-certificate-thumbprint
$sub = "your-azure-subscription-id"
$buildPath = $args[0]
$packagename = $args[1]
$serviceconfig = $args[2]
$servicename = $args[3]
$storageservicename = $args[4]
$package = join-path $buildPath $packageName
$config = join-path $buildPath $serviceconfig
$a = Get-Date
$buildLabel = $a.ToShortDateString() + "-" + $a.ToShortTimeString()
if ((Get-PSSnapin | ?{$_.Name -eq "AzureManagementToolsSnapIn"}) -eq $null)
  Add-PSSnapin AzureManagementToolsSnapIn
write-host Getting service...
$hostedService = Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | Get-Deployment -Slot Staging
if ($hostedService.Status -ne $null)
    write-host Service found.

	$currentService = Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub
	write-host Updating staging deployment...
		| Set-Deployment -slot Staging -package $package -configuration $config -StorageServiceName $storageservicename -label $buildLabel 
		| Get-OperationStatus -WaitToComplete

	$azureProperties = $currentService | Get-Deployment -Slot Staging
	write-host $azureProperties.Url

	write-host Done!

} else {

	write-host Existing staging deployment not found!


TeamCity Build Step to Deploy Azure Packages

From there, it’s a simple step to call the script from your build server. Click the image to see how we do it (with placeholder parameters – use your own).

The parameters required in order are:

  • Path to your published package location
  • Package filename (the ones that ends in .cspkg)
  • Service configuration filename (.cscfg)
  • Hosted service name (aka DNS Prefix in Windows Azure console)
  • Storage service name, if this is different to the hosted service name


There you have it. When you execute this build configuration, you should see the staging deployment being replaced in-line, with zero downtime. If you’ve given your staging URL to client for UAT purposes, they will be able to use this same link and see the updated code as soon as it is deployed. Hooray!

Developers: Keith Patton talks Windows Phone 7

[box type=”info”]This is one of a series of sponsored blog posts highlighting New Zealand companies working with cutting-edge Microsoft technology. If you’re interested in Windows Phone 7 development, you should download the free Windows Phone Developer Tools and start building your own Windows Phone application.[/box]
I’m not kidding when I say that Keith Patton from Marker is one of the top Windows Phone 7 developers in New Zealand. He’s behind  a couple of the most popular apps in the New Zealand marketplace, and one of the top games worldwide. The list of applications he and Marker have created is stupendous in terms of quality:

  • Alphajax: currently one of the top games worldwide, with rave reviews.
  • Yellow: a business and personal directory search application, with location and maps integration.
  • Air New Zealand Mpass: an application to list your Air New Zealand bookings, including on-screen barcode display for self-service check-in.

“Developing for Windows Phone 7 was one of the most enjoyable phases of my development career”

I think Keith sums it up best when he said that developing for Windows Phone 7 was “probably one of the most enjoyable phases of my development career”. One of his gems of advice is that coding for Windows Phone 7 should “feel like fun”. If it doesn’t, you’re probably doing it wrong!

Keith and I first met in Las Vegas, where we traveled to the MIX conference in 2010 to learn about the Windows Phone 7 developer tools. Since then, he’s been coding away, learning the best development techniques, and fine-tuning his applications. I took some time to sit down with Keith and talk about these applications, and his experience creating them.

This interview is a bit more of a deep-dive than the previous interviews: Keith describes the development techniques and frameworks he uses to create his apps. There’s some real gems of information in there, including Keith’s overview of Caliburn Micro, dependency injection (shout-out to MicroIOC), and more. We also talk a little bit about performance techniques and workarounds. So if you’re starting or experienced in Windows Phone 7 development, it’s worth watching. You can also pick up some of Keith’s tips and tricks from the Marker Blog.