About Graham Lea

Graham Lea is a Product Manager at Tyro Payments (with a long history as a Software Engineer) and lives in Sydney, Australia. Read more about Graham or follow him on Twitter.

Memories from 10 years at a startup

Black and white photo of four kids on an outdoor cubby houseI recently notched up ten years of working at Tyro Payments, a tiny little payments startup that I joined in late 2006 when it had about 20 people, and which is now Australia’s most successful fintech venture, Australia’s newest bank, and is fast approaching 400 staff.

Here’s a collection of some of my most vivid recollections from so far in this fantastic journey.

Getting Hired

I remember… when the recruiter for Tyro said he had a finance role, and I reiterated to him that I wasn’t going to take any job in finance. He back-pedalled, convinced me it wasn’t really a finance company and I really had to go meet them. I was reluctant, but I went along because I wanted to be in his good books.

I remember… the hook for me was one of the founders – Peter Haig – drawing the architecture they were building and me thinking 1) this is very cool and 2) this guy is very smart.

I remember… I plucked up the courage to ask where the company got its money from after three years of runway with no customers, and the founder was completely unfazed that a software engineer would ask such a question.

I remember… asking whether they really wrote tests before making any changes to the system, even to web pages, and Matt Milliss saying, “To be honest, I can’t believe how much code I wrote without tests before I came here, and how many bugs I must have created that no one has found yet.” It was a statement that shook my confidence in myself as an engineer and made me want to learn from this mature group of people that seemed to have a bunch of things figured out that most other software teams were still battling with.

I remember… I was so concerned about whether or not I’d enjoy pair programming that I asked for extra time to think about the offer.

I remember… discussing with my wife what would happen if I joined a startup and it went under and how long we thought we could survive on her salary if it took a while for me to find another job.

Startup Land

Hikers starting up a long steep climbI remember… on my first day I spent the morning pairing with Mark, who patiently spent the whole time telling me about the architecture of the system. We swapped pairs at lunchtime and I stayed on the task. My new pair, Geoff, asked me what we’d done in the morning and I said, “Nothing, we just talked about the system.” He looked at me strange, shook his head, and said “Right”. Then he changed a test, I changed the implementation to make it pass, and within half an hour we’d checked my first change into the mainline.

I remember… for the first six months having to explain to people that I worked at a company called MoneySwitch, watching their confused and concerned face, and preparing to explain that it wasn’t a money-laundering operation.

I remember… in the first office I worked in, we had no dishwasher and everyone was on a washing up roster, including the CEO.

I remember… that first office got really hot and the building aircon sucked. We had a single portable air conditioner… which was dedicated to the server room. On hot days we’d open a few windows and try to create a cross-breeze with a fan or two, but mostly we’d just sweat it out and keep going, or take a break for slurpees.

I remember… the whole Dev team – all 12 of us – used to go out to the mall to eat lunch together almost every day. There was no room to eat lunch in the office.

I remember… that the fortnightly demo involved the whole company – all 20 of us – cramming into the 3m x 10m board room and sharing a single case of beer.

I remember… when we moved to occupy two levels of 125 York St (now home to Blue Chilli) and it felt like we’d been upgraded to The Ritz.

I remember… when, less than 6 months in, my team leader proactively had my salary adjusted up because she thought Tyro had unwittingly hired me cheap based on my experience. It was an eye-opening example of how serious Tyro was about living out the company’s values.

Engineering Feats and Follies

Sydney Harbour Bridge being constructedI remember… when Ricky Yim and I got to do a spike of making a POS and an EFTPOS terminal integrate by communicating over the internet and through our system instead of over a serial cable and we got it working in a couple of days – probably Australia’s first “cloud” POS integration.

I remember… we discovered two years later that a demultiplexer in our POS integration was using a single thread to process all requests from thousands of clients and had only just started to struggle with that load. We bought ourselves about another decade of scaling by changing a config file.

I remember… I “refactored” an API between two systems that had some poorly-named fields, and a week later we mysteriously stopped paying merchants for the cashout they’d given customers. And we only knew about it when they called to complain. No one ever asked who’d made this bug happen, and instead the team had a conversation about how to stop it from happening again.

I remember… us being (equal) first to be accepted to be an acquirer for Medicare EasyClaim online claiming, and the excitement and enthusiasm of being part of building this huge new thing that was going to help improve the country’s public health system. Today, Tyro processes more than half of all the claims on the EasyClaim system, despite four other major banks offering EasyClaim services.

I remember… a litany of small tools that I built at home and brought to work: Canopy, the Maven multi-project build UI; Mini-Rest, a tiny Servlet library that forced people to use proper REST semantics; SodaTest, a Scala-based integration testing framework intended as a replacement for FIT; “Who’s the Expert?”, a smart contributor scoreboard for Bitbucket Server; and probably heaps of others I’ve forgotten.

I remember… relishing the opportunity to be part of rebuilding the accounting system from scratch to fix its performance and maintainability issues. It’s still humming along half a decade later!

I remember… half-jokingly whinging to my boss about how it was coming up to 12 months since I’d been working on nothing but the accounting system, and I might have to find another job if I was going to be doing nothing but accounting for the rest of my life. He moved me off that piece of work a week before 12 months.

Levelling Up

Red and white mushroom, like one used in the Mario game for a power upI remember… when I and three others were pulled aside to a corner of the office (we didn’t have any meeting rooms) to meet Mike Cannon-Brookes. He was considering joining our board but he wanted to meet (and grill!) some of the senior Engineering staff first so that he could check whether we were as good as our management team said we were. He joined, so I guess we did okay.

I remember… asking if I could take on a few more responsibilities because I was bored and, instead of being given an extra job or two, I was told I’d be made an Engineering Lead.

I remember… first getting involved in interviewing, not having any idea what I was doing, and feeling the weight of making decisions that would significantly affect other people’s lives and the future of the company.

I remember… we used to ask people to write a function on a whiteboard to calculate factorials and it took us way too long to realise it wasn’t testing people’s coding skills at all and that just getting people to do some pairing was way better.

A chart of the size of the Engineering team at Tyro showing exponential growth from 2013 to 2016I remember… we hired so many people that we doubled the size of the team in 18 months. And then we did it again. And then we did it again.

I remember… that I was just coping to remember all the new people’s names, then I went on holiday for a week, missed four new starters, and never recovered.

I remember… when the Engineering team eventually grew so big that we reluctantly moved Ops to a different floor of the building, and communication between the two groups plummeted.

I remember… pairing with Ops on mystery catastrophe nights, all scratching our heads, ordering pizza when we realised it was way past dinner time, and that “Aha!” feeling when someone found an entry in a log or ran a query on a table that had seemed totally unrelated to the symptoms but showed something that no one expected could ever happen.

I remember… organising our first innovation sprint – ‘CodeBlitz’ – and being surprised by the different mood in the room as people were intensely focused on getting their own innovative idea hacked together within two days so they could demo it.

I remember… when we decided it would be a good idea to build our next link to another bank as its own piece of software rather than adding it to an existing monolith – one of our first steps toward a microservices architecture (before that word existed). We recently celebrated having over 100 services deployed in Production.

The Journey to the Bank

Four people in suits walking in front of a building with tall, thick columns, possibly a bank or museum, with long shadows in the early morning light.I remember… that time my boss came to me and asked if my team could start on building a bank the next week.

I remember… when we took a completely agile approach to building a bank…

“Where do we start?”
“Well, what’s the most important thing a bank does?”
“Keeps people’s money in an account.”
“Okay, let’s write a piece of software that keeps money in an account instead of sending it to another bank.”
And so we wrote that and got it working before we did anything else.

I remember… when the regulator announced they were retiring our limited EFTPOS banking license, and we were told the banking side-project was now the rush to a full banking license mission, the #1 priority of the company, and that we had 18 months to deliver.

I remember… when we were 12 months into building our core banking system, just weeks away from delivering it exactly when we had estimated… and someone uncovered 3 more months of mandatory work.

I remember… when we received the results of an external security audit of our in-progress core banking system and the synopsis was “You guys are pretty up there with your security, but here’s 15 other major things you should think about improving.”

I remember… the frankly unbelievable news that we’d been granted a full banking license by APRA. It felt like a war was over.

I remember… when we’d just finished turning on the core banking system and we were told, “Well done. Now you’ve got 12 months to build a lending product from scratch, ship it, and get customers onto it.” We did it in 6.

Time Keeps on Slipping

Public binoculars with a small lake just beyond and a foggy, blurred landscape in the background.I remember… feeling like my contribution to the company was having less and less impact due to the growth and organisational changes, and starting to seriously think about moving on to somewhere else. Eventually, I realised that I didn’t have to be bound by my historical contribution to Engineering, and that Product Management might be a place where I could probably develop a new expertise and have a large impact on the company’s future.

I remember… getting up the courage to ask the co-founder and Head of Product about moving into a Product Management role, expecting to get a grilling about what product was and what skills I had that I thought would be relevant. Instead his response was just, “Yeah, that makes sense. When would you like to move?”

I asked my wife what she remembers, and she said she remembers when she would show up to the Christmas party and know everyone’s name, but nowadays I sometimes tell her I’m going to someone’s leaving drinks and she says she’s never heard of them.

I remember… starting to reflect on what I’d been part of in 10 years at Tyro and realising there was almost nothing that I’d achieved by myself; everything significant I’d been involved in had been a team effort – sometimes a team of two, sometimes over a hundred, but almost always a team. That’s how we roll.

Image credits:
Kids, older photo‘ by Joe Crawford
Start of the Steep Trail‘ by Dan Cook
Sydney Harbour Bridge‘ by gramarye
Power ups‘ by Kirt Edblom
Bankers‘ by Chris Brown
Eye of the Beholder‘ by hjl (flickr)

Marty Cagan on Product Strategy (Summarised)

Has it seemed a bit quiet here? Almost three months ago I did a personal pivot. I took a right turn from a 15+ year career in Software Engineering and managing Software Engineers, and threw my hat in the ring as a Product Manager. So far, so good. I’m loving it. That’s why “that microservices guy” is now authoring a blog about product strategy. The world keeps changing. Get used to it.

That change, though, has resulted in a bit of a dearth of blogs as I’ve hunkered down on learning about the new role and just getting my teeth stuck into it. I also find myself in a position where, rather than being able to write about things that I’ve been doing in anger for years and sharing my hard-won knowledge, I’m back to being a relative noob and sucking up everyone else’s knowledge.

But this blog has never been about “I’m the expert, come and listen to me”. It was always more of a “This is what I’m learning. Feel free to learn along with me” thing. So here we are, together, at the start of my Product Management learning journey. I hope you’ll enjoy the ride!

Product Strategy

L.B. Johnson in a Vietnam situation room. War offensives are often used as an analogy for product strategyI’ve spent the last three months getting on top of the day-to-day of PM: roadmaps, process, research, discovery, proposals, features, engineering, stories, releases, sales, marketing, launches, support, crises. All great stuff. Then earlier this week, someone said to me, “Tell me about Product Strategy”. And my response:

A shocked face, like the one I gave when asked to describe Product Strategy Continue reading

Distributed Transactions: The Icebergs of Microservices

An antarctic iceberg which, much like distributed transactions in microservices, can be hard to see and can wreck your ship.Why are distributed transactions icebergs? It’s not because they’re cool and beautiful and you have to look under the surface to comprehend them.

Distributed transactions are icebergs because (1) it’s easy to not see them, even when they’re right in front of you, and (2) if you run into one, it’s got a great potential to sink your ship. Continue reading

Why Your Resume Sucks & How to Fix It

Shredded paper in a waste bin - where the majority of resumes end up!I’ve seen a lot of software engineers’ resumes over the past few years. And most of them suck. Even the resumes of really good people who we’ve hired have often been very average.

Why is that? I’m going to tell you why, and then I’m going to help you avoid the same mistake. And while my experience is mainly in hiring for IT-related roles, this advice can be used by any job seeker. Continue reading

Subtle Is the Lord: The Science and the Life of Albert Einstein (Book Review)

Subtle Is the Lord: The Science and the Life of Albert EinsteinSubtle Is the Lord: The Science and the Life of Albert Einstein by Abraham Pais
My rating: 2 of 5 stars

Hmmm… well I think this book should have been called:
” The SCIENCE SCIENCE SCIENCE of Albert Einstein (with a tiny bit of context about his life)”

This is a book by a physicist, for physicists. (I am in no way a physicist.) To his credit, the author makes clear in the introduction that the purpose of the book is to cover Einstein’s work, and he even highlights in the contents the (very few) sections in the book which deal with Einstein’s life rather than work.

Despite knowing that, I made an attempt to read through the book hoping to stretch my brain on the topic of physics. Pretty much every page has at least a couple of formulas, which I skipped straight over, and much of the content is discussing either the details of the most recent formula or how it was arrived at and inspired by others. For a layperson, these parts are sometimes very interesting and sometimes unintelligible. The start and end of the chapters usually provided some (scientific) background on the papers and periods of Einstein’s career, and these served to form an interesting history of physics over the late 19th and early 20th centuries.

I did learn a lot of things. I learnt about the old, mistaken concept of an aether. I read the material about special relativity slow enough to grasp most of it and to be able to explain it to others in laymen’s terms. As for general relativity, I understood very little except that Einstein managed to solve the age old riddle of what caused gravity and predicted a few other related phenomena, such as the bending of light around the sun, which were later confirmed to great fanfare. I saw how Einstein worked mostly alone, especially in his early years, having very little knowledge of what else was going on in the world of physics, even re-discovering some phenomena by his own derivation because he wasn’t widely read. I was looking forward to reading about his involvement in the development of the atom bomb, but came to learn that all he did was write a letter urging the US to get to work on it. I saw how theoretical physics is so, so, so coupled with complex mathematics; Einstein in fact teamed up with gifted mathematicians in order to solve some of his biggest challenges. Most surprisingly for me, I learnt that, aside from relativity, Einstein made massive contributions to quantum physics, and that he spent a large part of his career on that issue and on trying to unify it with relativity. And finally, I learnt that, without his make-up on, Charlie Chaplin looks like this.

I struggled my way through to the half way point trying to read every page, but had grown very tired by that point, so I made a resolution to only read pages with no formulae on them and I sped through the rest quite quickly without feeling like I was missing much.

tl;dr – If you’re a physicist, you’ll probably love this book. If you’re not, you probably won’t, but you might learn some interesting stuff by reading it.

View all my reviews

Why “Don’t Use Shared Libraries in Microservices” is Bad Advice

A man licking an ice cream while a dog tries to lick it as well. Reminiscent of the kind of undesirable coupling created by shared libraries in microservices

Sharing isn’t always a good idea.

If you’ve read a bit about microservices, you’ll probably have come across the mantra, “Don’t use shared libraries in microservices.” This is bad advice.

While the sentiment is borne from real issues and there’s real wisdom to be gained in this area, this little statement is too pithy, lacking the relevant context to make it useful. Consequently, it’s open to misinterpretation, in particular to being applied too liberally, and I’ve seen it misunderstood a number of times recently.

What’s the Context for Understanding Shared Libraries in Microservices?

Only recently, I’ve picked up that different people mean different things when they talk about using shared libraries. Continue reading

My Key Takeaways from APIdays Australia 2016

On March 1 & 2, 2016, I attended APIdays Australia in Melbourne. (Actually, I also spoke! I’ll write more about that later.) I’m a chronic note-taker at conferences and I like writing my notes up afterwards both for my own reflection and so I can share them with others. Here are the key platform and API takeaways I’ve pulled out of my notes from #APIdaysAU16.

Innovation

APIdays Australia 2016 welcome poster: "API days - Platforms for Innovation"Innovation has been established as the main driver of economic change.

If people have to fill out an application to innovate, it’s not going to happen.

An innovation model for organisations based on the way ants achieve the colony’s goals:

  1. Powerful central mission with loose structure
  2. Maximise learning and sharing of learning
  3. Constant experimentation
  4. Freedom to look for the next horizon

Elon Musk: “Failure must be an option. If you’re not failing, you’re not experimenting enough.”

People in your organisation who think differently to others may well be key innovators. Don’t shut them out of the organisation.

Building Platforms

“Platform” is chiefly an idea to expose the core of your business in a way that can be used to compose new business ideas more easily, either by your own business or by others.
Continue reading

Are You Being Too Agile?

Man lying under a tree daydreaming about the future. Proabably not what you'd call "too agile"Confession of a Chronic Futurist

I have a confession to make. I used to be a dreamer at work. Worse than that, I used to invest significantly into putting my dreams into motion.

What did that look like? It meant that when I was tasked with building a Model-2 presentation framework for the company I was working for, I bunkered down for over a month and came out with this massive framework that was going to be a solution to the whole world’s problems. It was basically most of what Struts did and some parts of what Spring does, before either of them existed. There were good things in there, and the company used the framework for many years, but I’m sure more than half the code I wrote never got used. I’d latched onto a good idea and run a marathon, but the team really only needed me to walk a mile.

Pragmatic Redemption

Then came the revelation of my software engineering life: agile. Continue reading

Tribal Leadership by Dave Logan et al. (Book Review)

Tribal Leadership:
Leveraging Natural Groups to Build a Thriving Organization
by Dave Logan

My rating: 5 of 5 stars

So, the story goes that our CEO, Jost Stollmann, asked Mike Cannon-Brookes, co-founder & co-CEO of Atlassian and one of Tyro’s board members, something along the lines of…

“If you had to recommend just one book to your leadership team, what would you choose?”

And Mike recommended: Tribal Leadership. I think I can see why.

What’s the book about?

The book is about the results of ten years of research by the authors and how they found that people in organisations form tribes; that each tribe has a prevailing culture; that the cultures can be roughly grouped into five different levels; that the culture of the tribe can be an indicator of organisational success; and that the culture of individuals and of tribes can be “upgraded” through the levels using actions they describe, undertaken by tribal leaders. (Note that it’s not about leaders trying to create tribes in order to succeed – the tribes are a natural phenomenon, and the benefit comes through recognising them and influencing them. It does talk about building and enhancing networks within tribes.)

The book is well-written (i.e. not boring), contains lots of case studies and interviews, has excellent summaries at the end of each chapter (no highlighting necessary!), and it doesn’t just focus on what to do to become “great” – it also covers basket case cultures and how to start progressing people out of there.

What did I like about the book?

The number one thing I like about this book, as a leadership book, is that it pretty quickly gets a thoughtful reader looking not merely at their own actions and what they can do to improve, but also at how the people around them in the organisation are acting and interacting. You start to think about how to improve the company by influencing the culture, not just about how to improve your own output and your team’s output by doing a few things differently.

The main premise of the book is pretty simple to understand and start putting into practise: people’s culture can be detected by the language they use, and also affected by the language those around them use. So, people in Stage 3 tribes (where most corporate cultures are at) are all about personal accomplishment and they’ll say a lot of things that basically translate to “I’m great”. In contrast, people at Stage 4 are all about forming and maintaining good working partnerships with people around them, and their language will come out as “We’re great”.

As soon as I started reading all this, I could see how problems which I’d observed at work were caused by the behaviours detailed in the book. I also started to see problems I hadn’t noticed before, or areas that were about to be problems, based simply on how people were talking to each other or about each other. I recognised in myself some things I’d been doing which were contributing to holding the culture back from where it could be.

The book has many examples of great companies to aspire to, and not just the ones you’re used to reading about. Yes, there’s analysis of raging startup successes like Zappos, but there’s also a lot of time spent describing a hospital that focuses on creating excellent customer experiences.

The book has great advice, much of which is easy to start following, and it changed the way I behave, even as I was reading it.

Should you read it?

If you’re in any kind of leadership position, in any kind of organisation, I highly recommend this book. Maybe it won’t change your world, and you may not have all the influence you would need in order to affect the whole organisation. At the very least it should help you to start seeing the culture around you for what it is, and start to move it forward from the position you’re in.

Buy it on Amazon

View all my reviews

Top 10 Reasons Java Programs Envy Scala (Presentation)

From the archive: Originally posted in October 2011, I was reminded today of this post from my old blog, Graham Hacking Scala. I thought I should bring it over and give it a bit of a refresh…

In October 2011, I presented a talk at the 2nd meeting of the (then) new ScalaSyd Meetup. I talked through the “Top 10 Reasons Java Programs Envy Scala” in an attempt to give Java developers a taste of some little things that could make them much more productive if they switch to Scala.

Interestingly, in almost 4 years, very little has changed. Yes, Java 8 now has lambdas, but the standard collections library still makes very little use of them, forcing you to convert any collection to a stream before lambdas can be used, and pretty much nothing else mentioned in the talk has made its way into Java SE. People are still writing up lists of how to use Java better, but the fact is that a lot of Java best practices are either built into or easier to achieve in Scala.

Anyway, if you want get the real scoop on Java vs Scala and hear what all the Scala kids are raving about:

  1. hit play on the SoundCloud recording below, and then
  2. follow your way through the Prezi below that.

Continue reading