patkua@work

The intersection of technology and leadership

Page 2 of 51

Walled gardens, open source and why I never publish posts to LinkedIn

Whether or not you like LinkedIn or not, it seems to have won the “social network” for professional contacts. This post isn’t so much about LinkedIn, but about some of the well-known tricks to keep people attached to a platform. These techniques are also used heavily by companies such as King Games, Facebook and Snapchat. If you work in tech, I ask you to consider where you post your personal content and what that means for all of us.

Even LinkedIn acknowledges it’s own Authentication “Wall”

Before I go on, I want to share a short trip based on my own personal history.

The growth of the open internet

When I first started working in the industry, J2EE was the new “hype” and people were still using CVS. Email was fairly common, although many were through proprietary platforms (remember Lotus Notes anyone)? Since then, the Internet exploded in popularity bringing with it many open platforms for sharing information and knowledge. You will have benefited from this generosity of knowledge. StackOverflow is now a ubiquitous, open, resource that provides invaluable knowledge for people in tech. Platforms such as WordPress enable anyone to share their views or experiences with the world and this is what is so special about the openness for the Internet. Wikipedia is richer than any Encyclopedia Britannica could have been.

The rise of open-source

One of my first jobs working in tech was working as an intern with Bell Labs. I worked on a perl-based testing system that allowed people to run test scenarios on multiplexers and hardware located within a telephone switch. I remember really clearly how everything was written in-house. You needed a logging library, you’d write it yourself. You needed an error reporter, there was an in-house custom built solution for that.

Since then, the world has really changed. Open source has changed the way that we develop. We literally build on the work of previous generations. We compose libraries and frameworks to focus on what our business problem is, instead of rebuilding common utilities again and again.

Stay a responsible web citizen and keep your content open

If you are in technology, you have benefited from the openness of the internet. Avoid posting your public content to walled gardens such as Facebook, PInterest or LinkedIn which require users to login *before* they read the content. Be a good web citizen and keep your public content open. I will continue to do so (by posting to this blog) and I hope you will too.

Three tips to become a public speaker

I am grateful that I have had a chance to do a lot of public speaking. Speaking at conferences and user groups has many benefits: You meet new people, you are introduced to different ideas, you often get to visit new places, and share your own ideas and experiences. I am particularly thankful for many wonderful memories where people have come up to me, sometimes years later, to mention they saw a talk of mine and thanked me for sharing my knowledge and experiences.

Over the years, I have also helped many people with their own personal journey of speaking at conferences or events. I found myself repeating several tips that, in this blog, I want to share with you.

1. You have something to say

People early on in their speaking journey often throw this statement up as their first mental hurdle:

“I have nothing to say”

What’s fascinating about this statement is the assumption that everyone has heard and learned everything there is in our industry. Considering that the technology industry is constantly evolving with its tools, platforms, languages and practices, there will always be someone who hasn’t been exposed to some idea or some experience. Everyday there are more and more people coming into technology, each with a different background, and there will be something they have not read, listened to, or learned yet.

You have an opportunity to share your own lessons learned. You do not need to be the expert, and you do not need to be a person who has invented an idea to share your own knowledge. We all stand on the shoulders of giants, and as long as you attribute other people’s ideas, you should not worry about this.

For ideas for talk topics, consider:

  • What problem did you solve in own environment, that others might learn from?
  • Have you applied a certain technique/approach in a context where it is not so usual?
  • In learning a new tool, framework or practice, what lessons and traps did you discover along the way?
  • With a repeated experience, or practice, have you uncovered some general principles that work for you?
  • Is there something that you found difficult to find information on the Internet? If you can’t find it, it’s likely that others cannot as well.

As I wrote in a previous post about preparing a proposal for a conference, experience is super valuable and attached to a relevant topic, or a slightly different spin about a technique or tool, you can offer others a different perspective, and insight.

Everyone has something interesting to say. Find a friend, a coach, or a mentor to bounce ideas off and see if there is an interesting experience you can share.

2. Start off small

I don’t know anyone who started their public speaking career by launching into a keynote, or presenting at one of the largest or most popular conferences in their industry. Agile software development teaches us to start small, gather feedback and learn to adapt and refine your talk.

Practice makes perfect – An age-old maxim.

I recommend first-time speakers start small, and practice giving their talks to groups as depicted in the below diagrams.

A lunch and learn (sometimes called brown bag) tend to be one of the smallest and safest places to practice your talk. Often held at a lunch-time, a lunch and learn talk often doesn’t require as much polish or preparation as other types of talks. You also have the benefit of knowing some of people who might attend, giving you a chance to get objective feedback to help you improve. Pro-tip: Ask some people attending in advance if they can give you feedback, so they can give you more specific and concrete observations as feedback.

As you gather feedback from a lunch and learn, you might then look to find a relevant user group to host your talk. A user group tends to be more formal than a lunch and learn, but are still often informal groups where you can test your talk for flow, and even discuss the talk with people who hang-around after a conference. This is a super-valuable source of seeing if you communicated your ideas successfully.

Rather than targeting a large conference, look for a smaller conference (<300 people) to submit your talk to. A smaller conference might have trouble attracting more well-known speakers, and give you less competition in submitting and getting accepted. See my tips for submitting a proposal here. You may be happy keeping to smaller conferences as you build up experience and confidence in presenting your topic. Smaller conferences offer you a number of experiences: Stepping on stage without being overwhelmed by a faceless crowd, or feeling like you can chat to people in between sessions rather than at a convention of 800+ people.

Once you master these smaller conferences, you might start to get invites or be accepted into a larger conference. These conferences are often multi-stage, or multi-day conferences which tests your ability to really perform on stage and appeal to a much broader group.

Finally, and it’s definitely not necessarily for everyone, you may even get an invite to keynote a conference. I am a big believer that keynotes are slightly different from your average conference talk. I see these as talks that should be inspirational, introduce a different idea to an audience and have a different feeling compared to other talks at the same conference. A really good keynote should be difficult to pull off, because it draws upon both your speaking experience and skills but also challenges the audience with a different perspective.

3. Discover your own style

Like many activities, public speaking draws upon many different skills and experiences. Everyone has a different approach to composing and telling their presentations, and it is this variety which keeps conferences stimulating. Over time, with more practice, you will discover your own style that resonates with your audience.

In the meantime, I recommend the following books to help you prepare:

  • Presentation Zen (Reynolds) – Written by the person who worked alongside Steve Jobs for his famous apple keynotes and provides plenty of advice for composing and designing the presentation.
  • slide:ology (Duarte) – Another great book that explores the difference of presenting information via slide decks versus other forms of documentation as well as many recommendations about effective techniques.
  • Presentation Patterns (Ford, McCullough, Schutta) – The authors of this book are well-seasoned technical conference speakers and they draw upon the ideas of patterns and anti-patterns to describe and catalogue common advice and pitfalls for the first-time conference speaker.

As you build your experience with public speaking, and you really listen to your audience and feedback, you will discover your own style that works for you, and audiences will appreciate your authenticity.

Conclusion

Developing public speaking skills takes time and effort, but if you follow these the three tips above, you’ve got a good chance at starting on the right track.

Why we wrote Building Evolutionary Architectures

When I first started working as a developer, agile was a taboo-word, seen as a fad driven by developers. Scrum was, at least in Australia, unheard of and I luckily fell into a team experimenting with XP (Extreme Programming) combining CruiseControl with CVS and the first version of JUnit.

In those days, most projects ran using some sort of waterfall process with a lengthy requirements-gathering phase, a long architectural design phase followed by problematic development and often a stressful testing phase. You were lucky to get access to a new development because there were long delays in obtaining new infrastructure, waiting for some operations person to set up the machine, configure the services and grant you access.

Fast forward to today where we have a completely different world of technology. We have rich, open source libraries that give us fundamental building blocks to focus on solving our problems. We have powerful computers with vast disk space, processing capacity and memory that enable us to build complex features without waiting for a lengthy compile or build phase. We have access to cloud services that give us even more compute power, disk space and broadband that allow us to rapidly interact with remote services, almost as if they were on a local network.

Today’s world of building software looks very different from what it looked ten or fifteen years ago. The way that we need to design and architect our systems also needs to change. This is one of the reasons why my co-authors and I decided to write the book, “Building Evolutionary Architectures

Long phases of designing an architecture will likely result in an architecture that will be cumbersome to build. Zero architectural design will fail to meet what we deem as a software’s “fitness function.” Instead, developers need to consider how their systems will adapt to change and we’ve looked at modern software development practices, methodologies and processes to understand what supports change and, more importantly, what typically hinders change.

If you’re interested more in this topic, then check out this page on how you can learn more about building evolutionary architectures.

Quotes on metrics and numbers

I published an article a few years ago, called “An Appropriate Use of Metrics.Martin Fowler, who hosts the article, tells me that it receives good regular readership. As someone who has been working as a consultant, I’m aware of how an inappropriate use of metrics can really incentivise the wrong behaviour, destroy company and team cultures and drive incongruent behaviours between teams and people.


Source: From Flickr under the Creative Commons licence.

In this post, I thought it’d be worth sharing a few quotes around numbers and metrics. I’ll leave you to decide where they may or may not be useful for you.

Tell me how you measure me, and I will tell you how I will behave.

Source: Eliyahu M. Goldratt (Father of the Theory of Constraints) from “The Haystack Syndrome” (1980).

What can be counted doesn’t always count, and not everything that counts can be counted.

Source: Often attributed to Einstein but the Quote Investigator suggests crediting William Bruce Cameron (1963).

Not all that matters can be measured.

Commentary: An alternative form to that above often attributed to Einstein.

What gets measured gets done, or What gets measured gets managed.

Source: According to this blog, there doesn’t seem to be a definitive source.

It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.

Source: W. Edwards Deming from “The New Economics.”

(One of the Seven Deadly Diseases of Western Management) Management by use only of visible figures, with little or no consideration of figures that are unknown or unknowable.

Source: From W. Edwards Deming’s Seven Deadly Diseases of Western Management.

Data (measuring a system) can be improved by 1) distorting the system 2) distorting the data or 3) improving the system (which tends to be more difficult though likely what is desired).

Source: Brian Joiner via the article, “Dangers of Forgetting the Proxy Nature of Data.

The most important figures that one needs for management are unknown or unknowable.

Source: Lloyd Nelson (Director of statistical methods for the Nashua corporation) via Deming’s book, “Out of the Crisis.”

When a measure becomes a target, it ceases to be a good measure.

Source: Also known as Goodhart’s Law phrased by Marilyn Strathern.

If you can’t measure it, you’d better manage it.

Source: Management consultant, Henry Mintzberg

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.

Source: W. Edwards Deming. No concrete source found except for Brainyquote.

Conference Tips: Submitting a Talk Proposal

I have been keynoting and speaking at conferences for more than ten years. I also contribute to a number of conferences as a reviewer, giving my thoughts to conference committees on evaluating potential talks/workshops. In this post, I want to share a number of attributes I look for, when reviewing a conference submission. It may help you as a person who wants to submit an idea to a conference. I won’t promise that your talk will be accepted if you follow these tips, but I do hope you end up with a better chance.

Conference talk preparation

Make it relevant to the conference

Some people use a scattershot approach – preparing a single talk that they send to all types of conferences. As a reviewer, it’s relatively east to spot these ones. At an agile-themed conference, there’s a loose tie to a talk titled, “Introduction to Kubernetes.” At a developer-focused conference, there’s a loose tie to talk on “Optimising flow with Kanban” unless there’s an agile twist to the conference. Talks with loose-ties will perform poorly against well-targeted talks that are very relevant to the conference theme and audience.

Consider who the conference attendees are and what themes/tracks the conference has to see if you can make the content more relevant.

Use the Goldilocks rule for talk descriptions

A talk can be too abstract when it tries to put in too many buzzwords without adding any practical information. Want to talk about microservices, docker, or continuous delivery? Great, but let us know how your talk is different and useful. A talk can also be too specific with a very narrow lesson or target audience. Great that you want to talk about how you managed to optimise the smallest possible CSS, using X tool! Is it relevant to a conference focused on software architecture?

Follow Goldilocks and make sure that your talk abstract is just right by considering how your description gives some weight and more meat to your talk. Conceptual talks with examples are a good start. A super narrow topic can be fine as long as it really unique or interesting for potential attendees.

Bonus tip: One sentence talk abstracts are normally too short.

Make your talk title and description match

I don’t claim to have the best talk titles, but I really make sure that the talk descriptions builds on what is eluded to in the talk title. I have see too many submissions where people have a catchy title, and then the description doesn’t match the topic at all. It sometimes seems like two completely unrelated topics and I give the submission a low rating because it’s hard to predict what it will actually deliver.

Define concrete learning points

Although some talks are intended to be inspirational, many talks are there to help others learn about a particular circumstance. You will attract the right participants, and help committees select your topic if you can explain what you hope audience members will learn. I look for three to five key points in a 50-60 minute talk that make your talk stand out from others. The more concrete (and relevant) these learning points are to the audience/conference, the better.

Avoid the sales pitch

Unless you are at a vendor conference, I favour talks that are not overly product focused. This becomes more difficult when the field is highly aligned to a specific topic or technology. Amazingly I have seen many talk submissions made, as if the marketing department of some mega-corporate technology vendor (wonder who that could be, cough cough) made it on behalf of someone else. Please provide something useful, rather than words that don’t add substance.

Draw on real world experiences

People love hearing stories about problems and solutions for technology conferences, and real world experiences or case studies can be really strong vehicles for demonstrating lessons learned. Distilling case studies into higher level conceptual, design or architectural learnings rate highly (assuming it is relevant to the audience).

Use your editing tools

Although I don’t expect all submissions to come from people where English is the first language, please make sure you run your submissions through some sort of spellcheck or grammar check. It’s very painful as reviewers if every third word has a typo and we can’t understand every sentence. If we can’t understand them, chances the conference attendees will not be able to understand them too!

These basic tools are built into almost all text editing program, so please use them.

Conclusion

Having a conference talk accepted isn’t really a mysterious process. There are certainly things that make the life of a selection committee or reviewer much easier if you follow the tips I provide above. Although these tips don’t guarantee your proposal will be accepted, following these will make sure that they don’t automatically get rejected.

Good luck!

Just Published: Building Evolutionary Architectures

I’m very proud to announce the release of a new book that I co-authored with Neal Ford and Rebecca Parsons whilst I was at ThoughtWorks. Martin Fowler writes the Foreword (snippet below):

While I’m sure we have much to learn about doing software architecture in an evolutionary style, this book marks an essential road map on the current state of understanding

Building Evolutionary Architectures

It marks the end of a very long project that I hope will have a positive impact on the way that developers and architects consider building and designing software. We will also post related news to our accompanying website evolutionaryarchitecture.com

You can find the book available on:

Enjoy!

Starting as CTO at N26

I’m excited to announce that I’ll be taking on the Chief Technology Officer (CTO) role for N26 (formerly Number26), Europe’s first mobile bank with a full European banking license, and who is setting new standards in banking.

I’m joining an exciting and talented team based in Berlin, Germany – one of the favourite start-up cities in Europe. In my new role, I’ll draw upon more than a decade of my consulting experiences with the well-respected and industry-changing technology firm, ThoughtWorks – best known for leading the adoption of agile ways of working (particularly its technical practices), publishing open-source software like CruiseControl (the first widely used Continuous Integration servers) and Selenium (well-known automated web-testing tools), and sharing ideas through books like Continuous Delivery and the Lean Enterprise. I’m really looking forward to applying my experiences guiding organisational design, building evolutionary architectures, developing technical leaders all while sustainably delivering value for our customers.

What will be different?

After many years as a consultant, I realise that working with a product organisation is a different beast. I look forward to having some responsibility to instigate and guide changes throughout the organisation and living out the long-term consequences (both good and bad!) of my actions. I know that this is often a missing feedback loop for consulting. In my role, I’ll be able to invest more in challenging and growing people and building out new technical and organisational capabilities.

I also look forward to spending a bit more time “at home”. I still expect to travel for my new role, still speak at some conferences but I hope I will have a bit more say as to when and where I’ll travel to, based on our business needs rather than where clients happen to be based. Did I mention that I’ll also be based in Berlin, and it’s a great city with a very good balanced lifestyle? I might even get a chance to further develop my German again.

Why FinTech and N26?

As a consultant, I was always skeptical about having significant long-term impact on established financial companies. With teams, or parts or the organisations, yes. With a 10,000+ person company, less so. The exciting part about working with N26 is that I will work with a strong management team to prevent unnecessary bureaucracy and to let people focus on adding value to the product and organisation. We benefit from not supporting certain types of legacy, and building software with Continuous Delivery and modern technologies first. I’ll be helping guide us away from the traps and pitfalls I have seen many customers suffer from in the last decade.

The N26 Black Card

I also like the fact that N26 is growing fast, and has already proven to meet customer needs, where all growth has been organic so far with very little advertising. Did you know that we recently hit 500,000 customers (PDF)? It’s also one of the first mobile-first startup banks with a European banking licence, which opens up a world of opportunity that a lot of other FinTech banking products do not yet have.

Here’s what TechCrunch wrote two years ago:

N26 (Number26) could be the best banking experience in europe – Tech Crunch

Bank of the future

In case you can’t tell, I’m really delighted to be leading the technology organisation behind the bank of the future. The team has already accomplished a lot so far, and I look forward to working with the team to do even more. We’re going to build an exciting place to work in the FinTech sector and have a huge impact on our ever-growing customer base across Europe. If you’d like to be a part of the N26 team and join me on this journey, did I mention that we are hiring?

Drop me a line on twitter @patkua (DM’s open), or on my email address if you’re even curious. Berlin’s a great city to live and N26 is a great place to work while you’re there.

Leaving ThoughtWorks

I started with ThoughtWorks back in Brisbane, Australia in 2004. Though not a graduate developer (we didn’t hire graduates back then), I was one of the younger members of the company. I still remember being sat down by the then-Managing Director before starting with my first client, where he said, “We’re not really sure how you’re going to work out, but we’ll go on that journey together.” More than 13 years later, I guess everything did work out, and I’ve shared the same path with ThoughtWorks a long time.

Farewell ThoughtWorks

Now, my path is heading in a different direction. I take with me many fond memories, many wonderful new friends and acquaintances, and a wealth of experiences. I have grown through working on projects across multiple countries (Australia, Brazil, Canada, Denmark, India, Germany, Singapore, South Africa, Thailand, the USA), multiple verticals (including banking, charity, energy, gambling, government, housing, publishing, recruitment, retail, telecommunications, travel and valuable goods) and playing multiple roles (architect, cat-herder, developer, facilitator, leader, trainer and many more). I’ve been able to work with companies in their early days, when they hit growth and experienced scaling problems, all the way to large established companies looking to change and transform the way they build software.

I appreciated working with so many well-respected and well-known people such as Barry O’Reilly (Lean Enterprise), Dan North (BDD), Dave Farley (CD), Gregor Hohpe (EAI), Ian Robinson (SOA guru), James Lewis (Mr Microservices), Jez Humble (CD/Lean Enterprise), Jim Webber (SOA guru), Kief Morris (Infra-as-code), Liz Keogh (BDD), Martin Fowler (Martin Fowler!), Neal Ford (Speaker Extraordinaire), Pramod Sadalage (Refactoring Databases), Sam Newman (Microservices), Rachel Laycock (Head of Tech for N. America), Rebecca Parsons (CTO) – and I need to stop now as there are so many other people I will forget off the list!

I’m grateful to have seen the company grow across countries (15 countries & 42 offices), adapting to local cultures yet keeping the “core” culture of engineering excellence, passion and a love of learning. It’s this combination plus the magic of trust that let teams live up to ThoughtWorks’ reputation. I am also proud to see our values (The Three Pillars) discussed and seen first hand, how they influence management decisions. I realised early on, that there is a delicate tension in balancing these three pillars within local and industry constraints and that there is rarely a “perfect solution.” However I truly do believe the balance is signficantly better in comparison to other companies.

I’m particularly grateful to have benefited from learning from others, watching others grow, and helping others grow. I also learned that these are not mutually exclusive options!

Where to now?

An opportunity landed on my doorstep, taking me along a different path, and means I’m off to try something different. I feel excited about my new opportunity (more on that to come!) but also excited to watch ThoughtWorks continue to grow, evolve, and continue to have a positive impact on the industry.

Book Review: 37 Things One Architect Knows

The author of 37 Things One Architect Knows, Gregor Hohpe, has a lot of experience to share, already having published the hugely successful and still highly relevant book, Enterprise Integration Patterns book in 2003. More than a decade later, Hohpe published his experiences playing the Architect role across many different organisations and shares useful tips and tricks for the modern day Architect.

Grab a physical copy of 37 Things One Architect Knows here or get the ebook as a published bundle Tools for Tech Leads and Architects

The term Architect is certainly overloaded, and although his book is aimed at describing the role of a Transformational Architect (one who can help shift traditional organisations into thinking, planning and acting more digitally), there are many different gems that Architects in all types of situations can benefit from.

Hohpe describes the Architect role using the analogy of a large building and the interplay between the Architect, the elevator and traversing the building up and down; “Be sure to stop in the “engine room” and various floors from time to time,” is a useful reminder for Architects to avoid staying in the Penthouse (aka Ivory Tower) and understand the value that a well-informed Architect can add when they truly understand the issues in the “engine room.” He has kindly also published an expanded version using this metaphor on Martin Fowler’s Bliki.

The book is divided into five different sections:

  • Architects – Exploring the various interpretations of the term Architect, and his perception of its responsibilities.
  • Architecture – Useful tips and approaches to understanding, defining and shaping decisions.
  • Communication – A really key area that Architects need to develop and draw skills on to be succesful.
  • Organisations – An explanation about the relationship between the Architect and the interactions and world they find themselves in.
  • Transformation – A call to action for Architects.

Hohpe has a great story-telling skill, and with cute and memorable chapter titles like “Control is an Illusion”, “If You Never Kill Anything, You Will Live Among Zombies” and “You can’t fake IT” there are useful cross-references contextualising the pragmatic advice gathered over his long career in technology.

Buy this book if you want to be a more effective software architect. You will learn some of the false assumptions or traps unexperienced architects fall into when they take on the role. You can order a physical copy of 37 Things One Architect Knows here or get the ebook as part of a bundle, “Tools for Tech Leads and Architects”.

The Technology Landscape in Singapore

Earlier this year, I held my Tech Lead Skills for Developers workshop in Singapore and Thailand. It was a short and busy week including some customer visits and a talk on Building Evolutionary Architectures for the local community.

As a consultant, I’m lucky to travel to different parts of the world where I have been able to compare technology industries and cultures around the world. Please note that the following observations are simply my observations and not necessarily backed by research.

Extreme Shortage of Developers

Talking to a number of managers, it’s apparently very difficult to find experienced and very good developers. There seem to be a number of reasons for this including how Singapore Universities aren’t producing enough software developers, a country limit that ensures a consistent ratio of foreign and local talent and a culture that values higher status over getting things done.

Dense and active community

Singapore reminds me a lot like London. The financial sector has a big impact on the technology market. London is much more diverse from that perspective. Singapore, like London, is a small dense population with a very good public transportation network. The public infrastructure enables many community meetups as people don’t have to worry about driving, traffic or how long the commute might take and thus enables a lot of learning to be done.

One of people I met during my time at Singapore, Michael Cheng (or @coderkungfu), organises the Engineers.SG website, where they go around to meet ups, film the talks and put them online.

Above is a picture of Michael and I during the course I was running. What he organises is no small time-commitment, and is a huge service to the community and makes the content available to a much wider group.

High Power Distance Index (PDI) matters

Accroding to Hofsted, a researcher on the cultural dimensions of countries, Singapore has one of the highest PDI ratings. This means that ranking, titles and the relationship between titles matter more to people in Singapore than in countries with a lower PDI (such as the US or the UK).

Translated into the local market – almost everyone wants to be a manager.

One person was telling me about one team where they had two developers building software and eight managers managing! It wasn’t of any surprise to me that this team worked in a finance industry. It also didn’t surprise me that not a lot of work got done!

Singapore is following, not yet leading in technology

Singapore is known for its passion and drive to make a big difference for its size. I see many great things changing on the island state, however I see many other challenges in their market that simply investing in programmes as a nation won’t necessarily change.

If you want any other perspectives on this market, I’d recommend reading a couple of this articles:

« Older posts Newer posts »

© 2018 patkua@work

Theme by Anders NorenUp ↑