David Bolton Strikes Again

CTO Talk - Follow the Money

2021-08-26T00:00:00+00:00

Earlier this year I was a guest speaker at Sydney Technology Leaders, my favourite professional networking group. The subject was “Follow the Money” - a CTO’s view on how to think about budgeting, working with the CFO and finance team, and what you may need to do to build your confidence and comfort if you haven’t done this previously in your career.

The idea of managing money can be intimidating, and exactly as the meetup outline explained, it’s because the tech industry does not train people to be commercially aware. If you had been building your career in a lot of other functions, like strategy and marketing for instance, you would have been exposed to the numbers that make the business run to a much higher degree.

Unfortunately in tech, our exposure to numbers is much more skewed towards technical topics - uptime, performance, algorithms and the like. And again as hinted at in the blurb, by the time you get close to the roles where it matters, you start to understand that it’s something that you’re going to have to build your knowledge in.

So, I’d like to talk about how you do that. What’s the best way to prepare yourself?

There’s only so much that we can cover in a short timeframe, so my main goal tonight is pretty specific - it is to give you confidence that wherever you are in your career you are more than capable of understanding the money side of things to be an effective technology leader.

For some of you, you’ll already have this confidence, but I’m hoping that you can use these ideas to guide other emerging leaders in their career journey. So, hopefully something for everyone, but perhaps manifesting differently for each of you.

A MISTAKE - DON’T MANAGE A BUDGET

One of the things that I often hear is people asking to manage a budget. In fact, that’s something that I also asked a former boss many years ago… it feels like it’s the golden ticket to becoming competent with the money.

But… just having a budget to manage is not really the most effective path to competence.

When I first asked for a budget to manage I thought it would be a key part of my development – my boss at the time gave me some sage advice that was very true and that I’ve often quoted since. They said: “Dave, you’re overthinking it – when you’re in the position to have budgets to manage you will have plenty of help from finance experts and it’s not going to be nearly as difficult as you might think”. And that has proven to be very true.

What IS important though is having the knowledge and understanding to manage the budget. It’s not the management that is important, it’s the knowledge and context.

There are some things in life that you can’t learn effectively without doing it. I’m a basketball guy, and it’s well known that it just doesn’t matter how much you read about basketball, watch basketball or even practice basketball… you need to play in competitive basketball games to get match fit.

Luckily, dealing competently with money at work isn’t like that. Just like paper share trading, where you do everything but actually buy the shares, it’s possible to learn almost everything you need to know about managing the money without doing it.

A BETTER WAY - LEARN THE BUSINESS

So, what’s a better way to learn?

First, you need to find a way to get exposed to numbers that matter for the business, and frequently.

Very first thing is to start outside and work in – if you work at a listed company, read every market announcement and annual report you can get your hands on. Make notes, find someone in the company who can answer your questions. If you’re not in a public company, look at similar companies that have more public information and go through the same process with them.

Whether or not you have easily accessible public information, the next step is to find someone internally who can talk you through the main bits of how the finances work. Again, make notes, ask questions.

Now the first thing that you’ll learn in a company is that they’re going to have a bunch of jargon and acronyms around the money. Some or even most of that jargon will be standard for finance, which means you may already know it or you can learn it quickly. Some of it will be specific to the company and industry – again, it shouldn’t take too long to learn, but you’ll need a helping hand and you may not find it online. Ask for help. Someone in your finance team will be more than happy to sit down and spend an hour explaining how things work. Again, this will be much more valuable to prepare you for future budget management than just diving in and managing a budget.

And you really need to know how the company makes money. Too many technologists don’t really understand how their company makes money and what the critical levers are in the business. What are the margins that your business is built around? For instance in groceries margins are low, everyone knows it’s a volume game, but it’s also important know that margins have been shrinking over the last decade, and while in Australia a 7% margin in groceries used to be achievable (and lead the world) everything has been trending down and right now it’s well under half that.

In many other businesses, especially digital businesses, margins are much higher. This leads to an interesting thing that you will very likely come across at some point – the employee or colleague who says “we make X million/billion dollars a year and we can’t afford to spend a few dollars on Y, this is outrageous!” - it’s kind of self-evident that the number of dollars your investors or owners want to spend to make more dollars is not going to be equivalent, but I do find this one of the more amusing parts of being in charge of the money.

I did an MBA many years ago and spent a bunch of time learning about finance (am I bragging? No no no!), and the best education for me was not the MBA, nor was it managing the budget. It was the weekly trade meeting at WooliesX (digital arm of Woolworths), where I was amongst about a dozen leaders that would sit down and talk about how the business had run over the last 7 days, and all the things that worked and didn’t work, and what it meant against budget and forecast, and what we would do about it that week.

The ecommerce business was billion dollar business that was growing at 40% year on year, and during covid about 100% year on year, and there was a lot that needed to be done. Particularly early on, it was a great way to make theoretical topics very real for me. A masterclass in an expert organisation, 50 times a year. Repetition at examining the key mechanics of your business will make you more financially literate, and will be very important for you to have a seat at the table.

BUILD CREDIBILITY

Okay, once you’ve released yourself from the idea that you need to manage the money directly, and you’ve educated yourself about the language of finance, the next best thing you can do is focus on building credibility. What do I mean by building credibility? I mean that you want to demonstrate that you can be trusted to make good decisions and spend company money wisely.

Just like a parent begins to trust a teenager as they demonstrate their good judgement, so will you be more trusted as you demonstrate that you’re up to it.

What does this mean in the context of managing money? Well, it’s not just enough to manage to budget. Even the most finely tuned operational organisations in the world are constantly looking at how they improve, it’s a capitalist imperative. To really win friends and influence people as a tech leader you need to be able to show that you’re improving, and to quote one of my favourite business authors Patty Azzarello, you need to show how you can do Better with Less.

Patty explains this idea in her terrific book Rise. It’s important to know that this doesn’t mean you have to do more with less – it’s about redefining the work to focus on more impactful outcomes. Why am I mentioning in the context of money? Well access to money for whatever you may want to do with it (like spending more on training, or retention activities, or anything else) will be in some way dictated by whether the purse string holders believe that they can get a good return on the money, and as you build credibility you will find it increasingly easy to unlock other things.

If you can’t demonstrate this level thinking, if you purely manage to budget and just think about how to spend what you’ve been allowed to spend, then you’re going to find it difficult to get engagement for things that you want to do, it will be a harder sell because it will just sound like an ask for more.

In contrast, someone with a track record of delivering better with less will be able to partner with people in finance to come up with plans to invest in a much more sophisticated way and will have built the trust to be allowed to move forward with those plans.

Some ideas:

Can you make an area or team more efficient? (and it doesn’t need to be one of your teams!) Perhaps there was something that you did manually as your startup began, but could now be automated or serviced via a SaaS product that you formerly couldn’t afford.
Are there new revenue streams that you can unlock, if you had an investment? How would you prove that revenue stream ahead of a big investment?
Are there risks to the business and what do you need to do to mitigate them?

These are all strategic level discussions that you should be having with finance. They can and will partner with you on these things, and they will help you with the models, the business cases, the frameworks to build a plan around them… you’re not on your own.

SUMMARY

So the arc of what I’ve talked about this evening started with don’t worry about managing a budget, then progressed to becoming literate enough to partner well, and finished with strategic thinking about how you show that you can be impactful with the money that you’ve got. You don’t need to manage the money really - you can work with your finance partners on that… you can reframe your role to be to “lead” the money. And you can start doing that in any role.

Three simple takeaways:

DON’T WORRY ABOUT BUDGETS
DO LEARN BUSINESS LANGUAGE
DO BUILD CREDIBILITY & DO THINK STRATEGICALLY

The Best Leadership Books 2020

2020-03-30T00:00:00+00:00

What makes a good leader? Can you learn leadership from a book?

Leadership is a mix of many things, and there’s no one gold version of leadership - different things work for different people. Some people would say a leader needs followers, but even that is up for debate – some of the best displays of leadership that I’ve seen have been when someone acted like a leader even when no one else believed in them or their work until after it was a success! And in any case, it’s beyond the scope of this post to deliver the perfect definition of a leader.

What is in scope is the subject of leadership books. Can you learn leadership from a book? Again, debatable, but what you can learn is how other people see the role of a leader, and even if you don’t entirely agree, you can certainly use those views to help inform your own.

So, based on a list I put together back in 2014, I’ve updated (as promised many times in the ensuing years!) the list to reflect my current thinking. These are selections from books that I’ve read – and I’ve got many more to read. If you have a suggestion, please leave a comment, I’d appreciate it. Also, I’d love to connect: My profile on Goodreads or LinkedIn.

First, my top five. These are all from the longer list below, they are the best of the best:

High Output Managment by Andy Grove - while ostensibly this is a “management” book, there are many leadership lessons in here, and we’re interested in leadership in the context of business. A great overview of what good management looks like – almost every newer book on management will have the same ideas as in here, just dressed up differently.
How Will You Measure Your Life by Clayton Christensen - a compelling usage of business methods applied to how we think about our lives and careers.
Crucial Conversations by Kerry Patterson, Josephy Grenny, Ron McMillan, Al Switzer - how you give feedback and have tough conversations is a critical part of leadership.
Dare to Lead by Brene Brown - vulnerability is a leadership superpower. Stop hiding behind that feeling of needing to know everything, and show your human, fallible side.
Tribal Leadership by Dave Logan, John King, Halee Fischer-Wright - a great model for thinking about teams and where they might need to focus to be truly excellent.

And here is the big list:

Self-leadership
Career skills for a leader
Business leadership
Team leadership
Setting vision & motivating people
- Fish!
- Mindset
- Drive
Leadership when starting a new role
- The First 90 Days
Giving feedback
- The One Minute Manager
Tough conversations
- Crucial Conversations and Crucial Confrontations
- The Coward’s Guide to Conflict

There you go! A list for a lifetime. I’ve read all these books (and more), and while I can’t claim they’ve made me a perfect leader, the investments I’ve made in reading about leadership have paid me back many thousands of times over. Leaders are readers!

Have you read any good leadership books?

Public Persona

2015-09-17T00:00:00+00:00

Last week I presented at the burgeoning and always enjoyable Sydney Technology Leaders Meetup on the (pre-selected) topic:

Public persona - How important is it to be involved in the community? Is speaking / attending meetups or conferences helpful? Is blogging, involvement in Open Source, or anything that gets notices outside of your office good? Necessary? Or just a distraction from delivering the goods where you are?

I was a last minute fill in for someone dropping out, so I only had a couple of days to prepare, but it’s a topic that I have a bunch of opinions on, so the prep was relatively easy.

I used Canva to create the slides, which was super simple (only complaint - 30 slide limit! And I had 33 slides).

Anyway, without further ado, I’m sharing the slides from my talk, with presenter notes included (because the slides won’t make sense on their own). Enjoy!

Negative Capability - Agile Australia 2015

2015-07-02T00:00:00+00:00

Earlier in the year, I read about a concept that intrigued me and felt applicable to my every day worklife. Based on that moment of inspiration, I delivered the following brief lightning talk at Agile Australia 2015. As an aside, prepping for a 5 minute talk is taxing, and I found my CTO Summit talk in December 2014 far less difficult, despite being many times longer – it turns out trying to have a single message clearly articulated in a specific timeframe (i.e. not much shorter than five minutes, but definitely not longer) is a challenging task!

The brilliant young 19th century romantic poet John Keats coined the term “Negative Capability” in 1817 at just 22 years of age. His idea was in reaction to Samuel Coleridge’s reductionist approach, which sought out definitive answers, and left no room for doubt. In contrast, Negative Capability is, to quote Keats:

“… when man is capable of being in uncertainties, mysteries, doubts, without any irritable reaching after fact and reason.”

Fast forward 200 years, and the most useful wisdom I’ve read all year is to “embrace your discomfort” - when you’re uncomfortable, don’t become restless, stop and accept the discomfort, because you can probably learn something if you are okay with being outside your comfort zone.

Uncertainty and discomfort are not foreign ideas for the Agile world, after all, a key catch cry for us is to “embrace change”. On the other hand, we use 5-whys and root cause analysis reflexively - when faced with uncertainty, we ask ourselves, “why?”, over and over again.

For example:

Why can’t we get all our teams to agree to use the one toolset?
Why can’t the marketing team give us more notice for their next million-dollar promotion?
Why do customers keep changing their minds?
Why do executives give us mixed messages?

There may be answers to our questions… but they may take a long time to find out. And in the end, the answers may just be stories that we tell ourselves.

But don’t think Negative Capability is an idea against enquiry. As Dave Snowden (who keynoted here a couple of years ago) has written, Negative Capability is not against fact and reason, but recognition of its limits. So even while we work to bring order to disorder, just being in the state of chaos requires a certain mindset. To quote Dave again: “embracing uncertainty requires discipline”. Being strong in Negative Capability means being able to be confident with ambiguity.

Along those lines, Colin Powell once famously said: “I can make a decision with 30% of the information, anything more than 80% is too much.” – now there’s a man who is comfortable with uncertainty.

General Stanley McChrystal outlines in his book, “Team of Teams”, how his Special Forces teams in Iraq would win every battle, yet were losing the war. In his assessment, they were very capable, but they lacked the resilience to deal with changing circumstances.

I like the resilience shown in the story of Barbara McClintock, a geneticist who stopped publishing in the 1950s because her peers were sceptical of her controversial work. Her approach was based on, in her words, “the time to look, the patience to ‘hear what the material has to say to you,’ and to have ‘a feeling for the organism’”. She was awarded a Nobel Prize in 1983. Barbara had clearly developed a strong Negative Capability – it would have been unsettling to have your work doubted for so long, but she was able to be comfortable enough to persist with the uncertainty of this for decades.

A great example of the practical use of this idea comes from earlier in my career. A young member of one of my teams was thrust into a leadership position, where he started doing great things, just as I’d expected. But it was also clear that the ambiguity of leadership and management was causing a great deal of stress for him. Over the course of three or four months and despite a lot of coaching, it became clear that he was being caused so much angst by the uncertainty of the position he was in, that he was unable to provide the leadership required, and while I’m confident that in time he will be better able to handle these situations, it also highlights to me how useful a developed sense of Negative Capability would have been to him. I knew he was missing this internal resilience, but I didn’t have a term for it at the time. Negative Capability is the term, and just knowing the concept has made me capable of seeing where it is lacking, and being able to work towards addressing that deficiency.

Some of you might recognize uncertain situations that you deal with in your organizations:

Perhaps the company’s budgeting process asks you to project things in a way that makes you uncomfortable
When you manage people, you are guaranteed to be dealing with uncertainty on a daily basis
Maybe you deal with erratic third parties where your organization has little influence
And I’m sure you can think of many more examples

How we initially process and react to uncertain situations is perhaps even more important than how we bring order to them. If we don’t have the ability and discipline to use our Negative Capability, then we may not even get the opportunity to use our sense-making tools and frameworks.

Thank you.

Find a Mentor, Be a Mentor resources

2014-10-23T00:00:00+00:00

Supporting links for my talk at the Sydney Technology Leaders meetup:

Leadership Books

2014-07-13T00:00:00+00:00

I was asked this week to recommend some books on leadership. Once I sat down to respond, I found it wasn’t easy just to recommend a couple of books. So, I’ve come up with a list by area of great leadership books I’ve read (I’ve spent about an hour on this, but I suspect I’ve missed some of my favourite books too). Which books you might be interested in will depend on what aspect of leadership you are interested in. Some of these books are more “management” books, but I think they’re important for prospective leaders too.

Self-leadership
Business leadership
- The Fifth Discipline
- The Goal
Getting teams to work together
- Tribal Leadership
- Peopleware
Setting vision & motivating people
- Fish!
- Mindset
- Drive
Leadership when starting a new role
- The First 90 Days
Giving feedback
- The One Minute Manager
Tough conversations
- Crucial Conversations
- Crucial Confrontations

Probably best place to start is with the “self-leadership” books. I’ve read all of them, so this is just MY list, there are many, many, many books on leadership I’ve never read.

Any other thoughts on good leadership books?

Excellence Through Code Reviewing

2014-06-06T00:00:00+00:00

Do you do code reviews in your workplace? How often? What’s the experience like? I find for many programmers, code reviewing is not treated as a skill, but an annoyance, and that is a sad state of affairs.

The practice of code reviewing is indeed a skill that can be learnt and improved. It’s a skill that is vital part of a professional programmer’s toolkit. It’s a critical safeguard for deploying robust and maintainable code. Yet, it is constantly overlooked or marginalised as optional.

When I first started writing this blog post (months ago!), I downloaded a whitepaper from Smart Bear, a software company that creates a tool to assist with code reviews, called Best Kept Secrets of Code Review. In the whitepaper was an excellent quote about code reviewing that resonated:

“The reviewer and the author are a team. Together they intend to produce code excellent in all respects, behaving as documented and easy for the next developer to understand. The back-and-forth of code-and-find-defects is not one developer chastising another – it’s a process by which two developers can develop software of far greater quality than either could do alone.”

The justification for code reviews is simple: “given enough eyeballs, all bugs are shallow” (also known as Linus’ Law). No one can argue against reducing the number of bugs, right? Plus, as per the quote above, it won’t just be killing bugs, but increasing the quality of the software overall.

Those points alone should be strong enough, but on top of that there’s what I see as the “killer feature”: code reviewing is probably the best way outside of pair programming (and in some ways, it’s even better) for teaching and learning the craft of developing software.

If it’s so simply compelling, why is code reviewing overlooked? Probably because it sounds like such a trivial thing to do: I’ll look at your code and tell you if it has any issues. Put that way, it really is simple, but as always the magic is in the details. How much code should we review? How long should it take? How much should we “allow through”? How often should we review? The points of difference for code review approaches can be quite lengthy.

What are some of the problems with code reviews as practiced in many places?

They are cursory, seen as a speed bump on the way to being “dev complete”, and as such they’re not done thoroughly enough.
They’re only done by senior or lead developers as they’re seen as the only ones capable of reviewing code.
They’re avoided because they are too revealing, too invading, too scary.

And I’m sure you could think of more reasons too.

I don’t think they’re good reasons, and in my experience they’re actually easily defeated. If a team of programmers decide to change their culture to emphasise code reviews, it’s actually quite an easy thing to do. But it does require the intention to get started.

If we assume we can override the inertia of not doing code reviews, then we’ll want to know how to do good ones. Here is what I think makes up a good code review:

It is an iterative process, not a one off - by that I mean we shouldn’t wait for the “end of coding” to do the review. Have someone review the code at points throughout the progress on a task, not just at completion.
It should not be “cursory”, you need to invest some time in it (but not too much!)
A concise checklist can dramatically improve effectiveness
Code reviews are blame free zones
Code reviews are about learning, knowledge sharing, quality.
Code reviews are empirically better than not code reviewing.
Code reviews should be a simple process
Code reviews are assisted by checklists
Code reviews should be performed by everyone, not a select few

And here are a few notes on how to be a good code reviewer:

First off, pay attention to the list above!
Treat a code review as the important learning opportunity that it is - both for the reviewer and reviewee.
And most importantly: remember that code reviewing is a human process

What does a “human process” mean? It means that during a code review you are dealing with people, even as you inspect computer code. The code may be deterministic (hopefully!) but the individual whose code is being reviewed is as fallible as you or I. It pays to remember to keep it focussed on learning and quality, and remove blame from the equation.

Go forth and review! It really is as simple as that, and I can’t think of anything that will build an engineering culture and raise the standard of code produced by a team as quickly and effectively. As a little starter: remember that there are millions of lines of open source that can review and you don’t need permission, just go ahead and do it (and for some inspiration for the sorts of things that may be interesting to cover in a review, see Fabien Sanglard’s site for the many interesting and public code reviews that he has done.)

Interviewed for Codr.TV

2014-06-01T00:00:00+00:00

I was recently privileged to be interviewed for Codr.TV by Dan Draper and Kieren Wuest. We spent about forty five minutes talking about two main areas: the habits of highly effective programmers, and interviewing tips for both sides of the table.

The whole experience was excellent, the guys made me feel very comfortable, and I think we uncovered some interesting material. My only other experience in front of a camera was a rushed bit for a promo video for NewsFoundry54 that you can see here.

So, Dan and Kieren have been hard at work editing Codr.TV episodes, and during that editing they managed to pull together a “Part 1” extract of our chat:

I’m particularly fond of the Byte covers they found to accompany the footage. See more Byte covers here

Update: I dive deeper into some of the topics I mention in this interview in a post on my programming journey

NewsFoundry54

2013-10-08T00:00:00+00:00

(all images aside from video are from Dushan Hanuska)

I joined News Corp Australia six months ago (and boy, that time has flown), spending the first eight or so weeks meeting literally hundreds of people across a variety of locations, hearing about our multitude of products and generally absorbing as much as possible.

One of my observations from this time was that we had great people, but that they were too fractured - project teams were quite disparate, and although they were often facing similar issues, they didn’t have the relationships and networks to share their experiences and knowledge, and thus we were solving the same problems in different ways at different times.

In time I accumulated a list of a few things to help with, and a chief one was fostering connections across teams and functions. But in a busy and large media organisation, driven by major events and deadlines, how do you build in time to create these important cross functional relationships?

Separately, I also believed we should work to inspire our people too, and help them see what they were capable of. In discussion with our Head of Innovation, Mark Drasutis, we talked about running a “hack day” to loosen everyone up a bit from the constraints of day to day work. For Mark’s role, it would also be a key signal of our intentions around fostering innovation. Mark and I share many common philosophies around innovation and organisations, and our conversations were always full of energy.

After a couple of false starts (coordinating over a hundred people across a dozen projects is tricky!) and with great executive level support, we managed to find a date and with the help of friends at Fishburners set about planning for an epic innovation event: #NewsFoundry54 was born!

The outcome

There were a few concerns: would we get everything planned in time? Would we be able to excite everyone into participation? Would the event and results be compelling enough that we’d get the chance to do it again? Could we make it amazing?

Well, I’m happy to report that the event was a tremendous succcess. While we had a slow lead up, when we reached the kickoff day the groundswell of action and support was phenomenal. Over 54 hours, from midday on Wednesday to late Friday we had a frenzy of activity with over 100 participants and a lot of additional help on top of it.

In the end, there were twenty projects delivered, and you can see some of them in this video:

Twitter and Photos

Great digital creativity by 19 News Corp Australia teams during Hackathon today in Sydney: #newsfoundry54! Well done, News Corp (I judged)!
— Earl J. Wilkinson (@earljwilkinson) August 30, 2013

and:

Impressive pitches at #newsfoundry54. I'm glad I don't have to decide pic.twitter.com/occ7VCJEWb
— Adam Thomas (@adaromas) August 30, 2013

and:

#NewsFoundry54 is go! Massive turnout pic.twitter.com/VSci8wwPKT
— Dave Bolton (@lightningdb) August 28, 2013

and:

Team Taste Party are playing Backstreet Boys #devshame #newsfoundry54
— Workout Shaker (@workoutshaker) August 29, 2013

and more at the “#NewsFoundry54” hashtag.

How we did it

Firstly, we absolutely couldn’t have done this without the help of Peter Bradd from Fishburners. Both Mark and I had hectic regular day jobs to attend to, and while we’d each run innovation events before, Peter had run over half a dozen of these for a variety of organisations over the past three years, so his expertise and availability were invaluable. Also a special mention for Daphne Hazelhoff-Need who was crucial in coordinating and navigating the organisation.

Each of the following steps could be a blog post in itself, but I will let them stand as dot points with minor notes, and perhaps delve into particular points in future posts. Anyway, broadly here’s how we pulled it together:

Decide on what we’re trying to achieve
Decide on who to involve - News Corp Australia is a busy media organisation with thousands of employees - who would want to be participate? Who could spare the time?
Decide on the parameters - timing, themes, rules, judging criteria, judges, prizes
Decide on the mechanics - what space could we organise
Build a shared presence for communication - using our wiki
Preempt major questions and collect FAQs
Plan out communication - aiming to keep everyone engaged and excited without swamping them

Assorted key factors

We had good discussion on how to reward winners, and in the end we decided we would donate to charity on behalf of every participant. For me this was a good move, since while prizes or rewards are nice, I wanted to avoid a “punished by rewards” situation, and appeal to people’s intrinsic motivation.
Some distance between planning meetings and the actual event turned out to be useful - it gave people the chance to build relationships, explore ideas and plan an approach.
Having everyone in the same space was important - the energy concentrated in that part of the building was immense, and getting people away from their regular workspaces and mindsets was important. As a side note: this required some fast work from our infrastructure team to provide enough wireless access points.
The volunteers on the help desk were lifesavers - they weren’t busy all the time, but having people there to answer questions was priceless.
Gaining executive level support, including half a dozen of the most senior people in the company as judges of the finale turned this from a sideshow to a focus and has built support for ensuing events.
T-shirts! Custom t-shirts printed in a variety of colours gave the event a vibrant flavour… the only problem was that we didn’t get enough of them!
The challenge of carrying over the mindset and energy from this event to everyone’s normal working life is a tricky one - there’s so much to love about the innovative approach, but is it really practical or sustainable to work like this all the time? No, but we did encourage people to think about how they could alter their regular approach.
Flexibility with the “deliverable” - originally we’d stipulated “no Powerpoint” and “must be working code”, but the truth is that our teams were a mix of programmers, product people, marketers, sales and editorial – and only some of those could write code. The other groups also have valuable contributions, and sometimes that meant building Powerpoint slides to show business models etc.
Documenting the experience via Twitter hashtag #NewsFoundry54 means we’ve got a record of (some) of the event. Hopefully next time more people see the value of adding their voice on social media.

Things to improve for next time

Print more t-shirts!
Ensuring our technology participation is inclusive – we didn’t do a good job of making some areas feel welcome. For instance, our technology t-shirts actually said “Developer” on the back, when it really should have said “Technology”.
Making sure technology factors, especially proxies and firewalls, are sorted out before the event. Even with warnings and advice, too many people lost time trying to get their setup working. Having said that, we had some success with Red Hat’s OpenShift PaaS offering to help get things going more quickly. Thanks to our operations team and Red Hat for help with that.
Perhaps having a better plan for an “after party”. After all the effort, many of us collapsed down to a nearby pub, but a bunch of people got lost and it while those who made it had a blast celebrating to the early hours, it was a bit of an afterthought.

And next?

Ultimately NewsFoundry54 was a thrilling and exciting ride that I am very proud to have been a part of. The ideas and execution were the stars of the show, but the sense of shared purpose, the collaboration, the sharing and the excitement were just as notable. While innovation and startup events are not necessarily new in the cutting edge tech communities around, they are still significantly unknown for a lot of people in large organisations, and as such it can be a challenge to explain what they can do for a company. Now, everyone in News Corp knows - they were either there to experience it directly or have heard about it through the grapevine, and we’ve already seen great carryover into everyday work.

Yes, this is an event that will be reprised, and I can barely wait for the next one!

Training a Graduate Software Engineer

2013-06-16T00:00:00+00:00

Previously I’ve written about universities and industry preparation of students. At the time of writing that post, I was working in a large company with a compact digital department that mainly utilised Ruby and front end skills, and now I’m working in a giant media company with a sizeable digital operation, which has just shown to me how tricky it is to make a great curriculum that caters to industry as a whole. Overall, however, the move has changed the specifics of my views, but not the general philosophy.

If we take decent graduated software engineering students, or students doing industrial placements during their degree, how would we best prepare them for industry? If people have the desire to be good software engineers, what do we need to do to equip them with the skills to be desirable in a team?

Here is what MY post-graduation curriculum would look cover, to create engineers for MY specific needs:

Test driven development
Agile processes focusing on collaboration & teamwork
Advanced version control
Continuous delivery
Refactoring
Caching strategies for the web
Building services & APIs
Front end technology bootcamp (getting started with JS, HTML5 & CSS3 intros)

A crucial note here is that aside from Agile processes, the main things I want covered are backed by computer science fundamentals at some level. This is an important note: the existing curriculum of a computer science degree is not redundant, as one of the opinion pieces mentioned in my previous post suggested.

We could teach these subjects to students after graduation, but could these subjects be taught as part of a university course? To some degree, yes, but it is not as simple as that, as the teaching would happen within the construct of university teaching. A course in an Australian university is usually twelve to thirteen weeks long, with a fulltime student usually doing four subjects per a semester. Face-to-face time for a course is usually an hour or two of lectures a week, and another hour or two of tutorial time. To develop many (not all) of these skills students need to be around their peers with expert guidance – they’re not skills that the majority of students will just pick up by reading a book.

With only a few dozen hours of facetime in total per course it would be a real challenge to cover anything more than the basics if we tried to cover the bulk of this in a single course. If we changed the approach from a single course to a whole semester covering industrial skills, i.e. four concurrent subjects, then we might have better success. Let’s see how that might look:

Subject 1: Being an Agile developer
- Test driven development
- Refactoring
- Advanced version control
- Continuous Delivery (covering CI, but also how version control, CI and automated testing fit together to deliver to production)
Subject 2: Working with others
- Agile team skills - collaboration, user stories, roles, planning
- Building a team and delivery culture
Subject 3: Supporting web applications
- Caching strategies for the web
- Building services & APIs
Subject 4: Building in the browser
- JavaScript
- HTML5 & CSS3

There, now that could work. Of course, the problem with this course is that it is built for my needs as a hiring manager in a particular company context. Would it work for everyone? No, and that is the problem with trying to insist that universities need to teach these courses. Could these work as individual electives? Perhaps, but then I wouldn’t be hiring an industry ready developer if they hadn’t covered the breadth of the curriculum outlined above.

Could a company work this curriculum into on the job training? Absolutely, but to really be effective at it would require teaching skills that most companies don’t have the capability or bandwidth to deliver. And relying on external training partners is not likely to be achieveable from a cost perspective, particularly when it is can be difficult to retain talent - investments that walk out the door are an issue.

So what is the answer? I think this could be fixed by a combination of approaches. Universities should consider how they teach practical subjects of being a software practitioner, in particular: version control, automated testing and refactoring, and some exposure to a wider variety of commercially popular languages. Then companies need to have a great approach to building teams, and could probably do so at a reasonably low cost with little impact, since building great teams should be one of their chief objectives anyway. And finally, companies can support both internal and external communities to help drive skills in areas such as web development and browser based technology.

Obviously coordinating this level of knowledge building across institutions like would be difficult, particularly as a single university sends graduates out to dozens or hundreds of different companies, but with some level of cooperation this could be a decent approach.

A final note on this subject is that it must be highlighted that a professional developer needs to take a lot of responsibility for their own progression in these areas. I recognise that some students will not struggle with motivation, but exposure – they don’t know what they don’t know, and that can make it hard to learn.

I’m interested in other thoughts in this area. I have spent a small amount of time with universities this year, and it has piqued my interest further, as I think faculties are asking themselves about how to stay relevant in a world where there is so much online education as well. For mine, universities are definitely still relevant, but they do need to adjust as well, just as companies need to come to the party.

Learn To Code

2013-03-02T00:00:00+00:00

I absolutely endorse this! Not because we need more engineers (we do), but just because it is an amazing way to learn to think, to easily accomplish something that can be widely useful to other people, and it is a simple path to a sense of achievement. For those reasons alone, coding is worthwhile.

Dan Levinthal and Competitive Advantage

2013-02-28T00:00:00+00:00

Tonight I was lucky enough to attend a UNSW AGSM innovation night featuring Dan Levinthal from The Wharton School, an extremely highly cited world-class business thinker. Here are some of my raw and barely edited notes on his talk ‘The Short Shelf-Life of Competitive Advantage: The role of innovation and adaptation’:

Sustained Competitive Advantage vs Renewal

Is sustained competitive advantage realistic?
Between 1957 and 1997, only 74 firms from 1957 S&P 500 survived, and only 12 of them outperformed.
Perhaps we should just accept that competitive advantage is temporary
Rather focus on “renewal”: new opportunities, exiting existing positions
“It’s not the strongest of the species that survive, but the one that is most responsive to change” - Darwin
“The ability to learn faster than your competitors may be the only sustainable competitive advantage”

Exploration - Exploitation

Evolving entities:
- Need to survive in present and adapt to enhance survival in future
Always opportunities to improve an organisation, it is never perfect
Competitors are also improving

Challenges of exploration and exploitation

Exploration vs exploitation is disruptive vs sustaining

Myopia of learning

Learning is feedback driven - fast feedback
Exploitation/sustaining is immediate, exploration/disruptive is distant (and may fail)

Real options

Early “stage-setting” investments may provide good options later
Staged/structured experiments
This only works if you can easily terminate an option
- But you don’t know if something is working or “in the money”
- Failure isn’t good for one’s career - so there is incentive for people to make it look like it worked

Select & variety

Dan credits Clayton Christensen’s thinking here
Selection criteria: existing customers may not want it
So, challenge of finding viable applications

Discussion

Dan throws the floor open to audience questions, with some thought starters on the screen:

How do we go about managing less successful experiments?
How do we acount for career consequences?

(At this point I was handed a microphone and embarrassingly asked an asinine question, Dan was very gracious about it though)

Summary

I was glad that I’ve recently read Clayton’s Christensen’s Innovator’s Dillema book, as it was so relevant to the presentation. It’s certainly an area that is super relevant to my current career path.

An interesting evening. I sat in the front row and typed notes, but in future I’d love to be bold enough to bring my Wacom tablet and sketchnote this sort of event. Will need to practice some more!

Sketchnoting The Effective Executive

2013-01-04T00:00:00+00:00

I was first introduced to “mind maps” through Tony Buzan’s books in the early nineties, and since then have used them often to quickly outline ideas. I also used them extensively during my Masters degree. I have a friend who has been doing animated mindmaps to outline books and ideas, and I’ve really enjoyed those too. So, when I first heard about the idea of “sketchnoting” (I believe through Sacha Chau’s blog), it was an easy sell. A month or two ago, I purchased Mike Rohde’s Sketchnote Handbook (which I reviewed on Goodreads), and just in the last week I’ve finally had a chance to put pen to paper to sketchnote a couple of my favourite books of 2012.

The first of those was Peter Drucker’s The Effective Executive (my Goodreads review). Here is my “sketchnote” for the book:

I’m mostly pleased with it. It is a bit more dynamic and visual than my mindmaps have been in the past. I tried to draw a few things using simple shapes, as Mike recommends, and they sort of worked. I was also concerned about “managing space” on the page, but this wasn’t too bad. With a mind map, since everything is radial, white space and space management wasn’t so much of an issue. And it turns out I was able to capture the major thrusts of the book without running out of space, however I could see this being an issue with some sorts of books.

I’ll have some more sketchnotes, and perhaps some of my old mindmaps for contrast, to post in the coming days.

Sketchnoting How Will You Measure Your Life

2013-01-04T00:00:00+00:00

After my first sketchnoting attempt, I next sketchnoted another of my favourite books from 2012, Clayton Christensen’s How Will You Measure Your Life. I used a slightly different style this time, going for a column based layout rather than radial, and tried some other drawing techniques. Again, mostly happy, but also looking forward to improving. I think I’ll be referring to these visualisations often, much easier to use as a refresher than a book or more linear notes.

Education and Software Engineering

2012-12-16T00:00:00+00:00

Recently I read Michael Fox’s post on Australia needing more software engineers and Mitchell Harper’s SMH opinion piece on the deficiencies of our university system for teaching software engineering. Interesting. I’ve done a bunch of hiring of engineers in Sydney over a number of years, so I’ve an opinion in these areas too.

Is it true?

Wanting to know if it was an accepted statistical fact, I quickly scanned the Department of Education, Employment and Workplace Relations skill shortage lists, but this didn’t reveal any particular shortage in IT generally. Anecdotally and through my own experience, recruiting engineers can be difficult, but we’ve also never had a shortage of applicants, even for niche roles. A lot of the difficulty arises in finding top notch talent, not finding people to interview.

So the issue is not volume, but talent, and it is a skills shortage. We have the people, but the people don’t have the skills. This makes sense: people in software engineering are well paid, and get to do interesting, challenging work, so there is no doubt that it’s an attractive role. Knowing that you want to work in software engineering and having desirable skills are two separate things.

Does university teach how to be a good software engineer?

Reflecting on my own undergraduate education (studying Information Systems at the University of New South Wales), the computer science curriculum was geared towards fundamentals. The first year course was taught in Haskell, which I think many professionals would agree is a great introduction - it makes prospective engineers think in functions and side effects and is an ideal teaching language. The sum of these subjects is a good background in computer science, not an industry ready developer.

Even today (review the curriculum here), the focus is mostly on core computer science and mathematics. There is nothing related to practical industry needs, or web development, or best practices for organising work and teams. Reviewing Stanford’s computer science curriculum shows a remarkably similar set of subjects, so if we have a problem I don’t believe it is restricted to Sydney or Australia.

What is the role of university anyway?

The big, age old question is whether it is the role of university to prepare students for industry? For Harper, the answer is “yes”: “Australian universities are not producing workplace-ready engineers”.

While in my opinion it’s not the job of university to prepare “workplace-ready engineers” (I’m of the opinion that the fundamentals and theory perspective is the proper focus for 90% of a degree, and that a career ready engineer will develop on the job), I do think that there should be some level of preparation, and a suitable level of preparation would be relatively easy to deliver to students. One or two semester long courses on industry practices would be give an undergraduate student a good head start.

In reality there will never be enough time in an undergraduate degree to fully prepare a student for industry (my suggestion of one or two semester long courses would have to take a strong opinion on languages and processes, and would just be the start). Harper says that “They’re quite simply not being taught the right languages, methodologies, processes and problem solving concepts”, but even to teach the “right” languages in the “right” way would take such a chunk of a student’s time that there’d be precious little time left for the real science to be learnt. Indeed, for Harper’s BigCommerce, the right language would be PHP, and would most certainly be counter-productive for young engineers to learn. I’m surprised to read Harper saying that they’re not being taught problem solving concepts at university, and I’d like to know more precisely what he means by that.

Students are being taught to be engineers, but mostly industry is more interested in half-engineers, half web-developers. The best web developers have built on fundamentals, the type of fundamentals a student learns at university. Some good web developers have self-educated and not attended university, and for the right individual there is no doubt there are probably few careers that accomodate the self taught so well. There are precious few shortcuts to learning those fundamentals though.

The real problem

So, industry wants graduate engineers who can hit the ground running and can deliver value straight away with the particular languages and processes that a specific company has chosen, and has no time to develop individuals with potential. Why blame universities for not catering to this type of demand? University needs to deliver timeless knowledge built on science and learning, not cater to the whims of a fast paced industry, trying to predict every fad that comes along.

Companies can complain, but there’s a quick way to solve this problem: take students with potential and train them with your languages, your processes, your engineering ideals. This is also the slow way to solve the problem, but hey, better than complaining.

(I plan to write a separate blog post about what my training for a graduated software engineer would cover).