The intersection of technology and leadership

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:

Book Review: Scaling Teams

This weekend I finished reading Scaling Teams by Alexander Grosse & David Loftesness.

I know Grosse personally and was looking forward to reading the book, knowing his own personal take on dealing with organisations and the structure.

tl;dr Summary

A concise book offering plenty of practical tips and ideas of what to watch out for and do when an organisation grows.

Detailed summary

The authors of the book have done a lot of extensive reading, research and talking to lots of other people in different organisations understanding their take on how they have grown their organisations. They have taken their findings and opinions and grouped them into five different areas:

  • Hiring
  • People Management
  • Organisational Structure
  • Culture
  • Communication

In each of these different areas, they describe the different challenges that organisations experience when growing, sharing a number of war stories, warning signs to look out for and different approaches of dealing with them.

I like the pragmatic approach to their “there’s no single answer” to a lot of their advice, as they acknoweldge in each section the different factors about why you might favour one option over another and there are always trade-offs you want to think about. In doing so, they make some of these trade-offs a lot more explict, and equip new managers with different examples of how companies have handled some of these situations.

There are a lot of links to reading materials (which, in my opinion, were heavily web-centric content). The articles were definitely relevant and up to date in the context of the topics being discussed but I would have expected that for a freshly published book. A small improvement would have been a way to have them all grouped together at the end in a referenced section, or perhaps, (hint hint), they might publish all the links on their website.

What I really liked about this book its wide reaching, practical advice. Although the book is aimed at rapidly growing start-ups, I find the advice useful for many of the companies we consult for, who are often already considered very succesful business.

I’ll be adding it to my list of recommended reading for leaders looking to improve their technology organisations. I suggest you get a copy too.

Three ways to handle CFRs

Cross-Functional Requirements (CFRs) are some of the key system characteristics that are important to design and account for. Internally we refer to these as CFRs, although classically they might be called Non-Functional Requirements (NFRs) or System Quality Attributes, however their cross-cutting nature means you always need to consider the impact of CFRs on new or existing functionality.

In the Tech Lead courses that I run, we discuss how it’s important that the Tech Lead ensures that the relevant CFRs are identified and accounted for either in design or development. Here are three ways I have seen some CFRs accounted handled.

1. CFRs satisfied via user stories and acceptance criteria

Security, authentication and authorisation stories are CFRs that naturally lend themselves to actually building out testable functionality. It’s important to consider the effort the risk and, in my experience, is important to start implementing these early to make sure they meet the needs and can evolve.

For these sorts of CFRs, it’s useful to identify these as natural user stories, and once implemented become acceptance criteria on future user stories that touch that area of the system.

As as example, authorisation can be dealt with by introducing a new persona role and what they might do (or not do) that others can have:

As an administrator, I would like to change the email server settings via a user interface, so that I do not need to raise an IT change request for it.

If this is the first time that this user story is implemented, then some acceptance criteria might look like:

  • Only a user with an administrator role can access this page
  • Only a user with an administrator role can successfully update the email setting (check the API)
  • Users with no administrator access receive a 403 or equivalent

This new role addition often means considering new acceptance criteria for every story going forward (if it should be accessible only by administrators or by all.

2. CFRs satisfied through architectural design

Scalability and durability are often CFRs that require upfront thinking about the architectural design, and perhaps planning for redundancy in the form of additional hardware, network, or bandwidth capacity. A web-based solution that needs to be scalable might draw upon the 12-factor application principles, as well as considering the underlying hardware. Failing to think about the architectural patterns that enable scalability and start coding will lead to additional rework later, or make it even impossible to scale.

3. CFRs satisfied via the development process

User experience is a CFR which often requires people, making automated testing much more difficult. An application where a high level of user experience is best dealt with by ensuring that a person with a background in UX is involved and that certain activities and feedback cycles are planned into the software development process to continually fine-tune the user experience as an application evolves.

Changes to the development process might include explicit user research activities, continuous user testing activities, the addition of an A/B capability and some training for product people and the development team to ensure that the developed software meets the desired level of user experience.


Every system has their own set of Cross-Functional Requirements (CFRs) and it is essential that teams focus on identifying the relevant and important CFRs and find ways to ensure they are met. In this article, I shared three typical ways that CFRs might be met.

How else have you seen these handled?

Automated Tests for Asynchronous Processes

It’s been a while since I’ve worked on a server-side application that had asynchronous behaviour that wasn’t already an event-driven system. Asynchronous behaviour is always an interesting challenge to design and test. In general, asynchronous behaviour should not be hard to unit test – after all, the behaviour of an action shouldn’t necessarily be coupled temporally (see forms of coupling).

TIP: If you are finding the need for async testing in your unit tests, you’re probably doing something wrong and need to redesign your code to decouple these concerns.

If your testing strategy only includes unit testing, you will miss a whole bunch of behaviour which are often caught at high level of testing like integration, functional or system tests – which is where I need asynchronous testing.

Asychronous testing, conceptually, is actually pretty easy. Like synchronous testing, you take an action and then look for a desired result. However unlike synchronous testing, your test cannot guarantee that the action has completed before you check for the side-effect or result.

There are generally two approaches to testing asynchronous behaviour:

  1. Remove the asynchronous behaviour
  2. Poll until you have the desired state

Remove the asynchronous behaviour

I used this approach when TDD-ing a thick client application many years ago, when writing applications in swing applications was still a common approach. Doing this required isolating the action invoking behaviour into a single place, that, instead of it occurring in a different thread would, during the testing process, occur in the same thread as the test. I even gave a presentation on it in 2006, and wrote this cheatsheet talking about the process.

This approach required a disciplined approach to design where toggling this behaviour was isolated in a single place.

Poll until you have the desired state

Polling is a much more common approach to this problem however this involves the common problem of waiting and timeouts. Waiting too long increases your overall test time and extends the feedback loop. Waiting too short might also be quite costly depending on the operation you have (e.g. hammering some integration point unnecessarily).

Timeouts are another curse of asynchronous behaviour because you don’t really know when an action is going to take place, but you don’t really want a test going forever.

The last time I had to do something, we would often end up writing our own polling and timeout hook, while relatively simple is now available as a very simple library. Fortunately other people have also encountered this problem in java-land and contributed a library to help make testing this easier in the form of Awaitility.

Here is a simple test that demonstrates how easy the library can make testing asynchronous behaviour:

package com.thekua.spikes.aysnc.testing;

import com.thekua.spikes.aysnc.testing.FileGenerator;
import org.junit.Before;
import org.junit.Test;

import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static java.util.concurrent.TimeUnit.SECONDS;
import static org.awaitility.Awaitility.await;
import static org.hamcrest.Matchers.startsWith;
import static org.junit.Assert.assertThat;

public class FileGeneratorTest {

    private static final String RESULT_FILE = "target/test/resultFile.txt";
    private static final String STEP_1_LOG = "target/test/step1.log";
    private static final String STEP_2_LOG = "target/test/step2.log";
    private static final String STEP_3_LOG = "target/test/step3.log";

    private static final List<String> FILES_TO_CLEAN_UP = Arrays.asList(STEP_1_LOG, STEP_2_LOG, STEP_3_LOG, RESULT_FILE);

    public void setUp() {
        for (String fileToCleanUp : FILES_TO_CLEAN_UP) {
            File file = new File(fileToCleanUp);
            if (file.exists()) {

    public void shouldWaitForAFileToBeCreated() throws Exception {
        // Given I have an aysnc process to run
        String expectedFile = RESULT_FILE;

        List<FileGenerator> fileGenerators = Arrays.asList(
                new FileGenerator(STEP_1_LOG, 1, "Step 1 is complete"),
                new FileGenerator(STEP_2_LOG, 3, "Step 2 is complete"),
                new FileGenerator(STEP_3_LOG, 4, "Step 3 is complete"),
                new FileGenerator(expectedFile, 7, "Process is now complete")

        // when it is busy doing its work
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (final FileGenerator fileGenerator : fileGenerators) {
            executorService.execute(new Runnable() {
                public void run() {

        // then I get some log outputs
        await().atMost(2, SECONDS).until(testFileFound(STEP_1_LOG));

        // and I should have my final result with the output I expect
        await().atMost(10, SECONDS).until(testFileFound(expectedFile));
        String fileContents = readFile(expectedFile);
        assertThat(fileContents, startsWith("Process"));

        // Cleanup

    private String readFile(String expectedFile) throws IOException {
        return new String(Files.readAllBytes(Paths.get(expectedFile)));


    private Callable<Boolean> testFileFound(final String file) {
        return new Callable<Boolean>() {
            public Boolean call() throws Exception {
                return new File(file).exists();

You can explore the full demo code on this public git repository.

The Gift of Feedback (in a Booklet)

Receiving timely relevant feedback is an important element of how people grow. Sports coaches do not wait until the new year starts to start giving feedback to sportspeople, so why should people working in organisations wait until their annual review to receive feedback? Leaders are responsible for creating the right atmosphere for feedback, and to ensure that individuals receive useful feedback that helps them amplify their effectiveness.

I have given many talks on the topic and written a number of articles on this topic to help you.

However today, I want to share some brilliant work from some colleagues of mine, Karen Willis and Sara Michelazzo (@saramichelazzo) who have put together a printable guide to help people collect feedback and to help structure witting effective feedback for others.

Feedback Booklet

The booklet is intended to be printed in an A4 format, and I personally love the hand-drawn style. You can download the current version of the booklet here. Use this booklet to collect effective feedback more often, and share this booklet to help others benefit too.

Reflecting on the Tech Lead Skills for Developers Course in Brazil

Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.

The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.

One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.

I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.

I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.

5 tips for using Retrospectives as a tool for dissent

I recently shared this article on twitter from HBR, True Leaders Believe Dissent is an Obligation – the spirit of which I wholeheartedly agree. Effective leaders should not be surrounding themselves with yes-people because you need a diverse set of opinions, perspectives, skills and experiences to effectively problem solve. You can read more about How Diversity Makes Us Smarter, Research on how a Diverse group is the best solution for problem-solving tasks and Kellogs’ perspectives on Better Decisions Through Diversity.

Celebrate Dissent Photo

Photo from Vipez’s Flickr photostream

A challenge with many leaders is creating the right environment to allow dissent. I draw upon Retrospectives as a useful tool and here are some tips if you are a leader looking to use it effectively.

  1. Be clear about your motives – I can see some types of leaders who want to use retrospectives as a way to get to blame (which is definitely not the point). It helps to be explicit upfront about what you expect from people and to let people know if there will be consequences. If people feel like retrospectives are being used to “find dirt” or for blame, people will refuse to actively participate in future sessions or simply lie.
  2. Find an independent facilitator – I address a number of the trade-offs of an independent facilitator in The Retrospective Handbook and when you’re a leader running a session, there will be times you will want to participate. Playing dual roles (participant + facilitator) can be really confusing for those simply participating, so I recommend at least starting retrospectives with an independent facilitator.
  3. Allows others to talk first – Leaders often come with a level of explicit or implicit level of authority. Different cultures treat authority differently and it pays for a leader to be aware of the significance that is automatically added to your words by holding back and allowing others to speak. Focus on listening first and foremost, and ask clarifying questions rather than being the first to put your opinion on the table.
  4. Pick a topic that affects all participants – When choosing participants, make sure that the topic is relevant and that everyone can contribute different perspectives for. Although outside opinions about a particular topic are often welcomed, retrospectives are best when people can share their experiences. If, as a leader, you are gathering a group of people who don’t regularly work together around a common topic, reconsider if a focused retrospective is a good solution.
  5. Keep an open mind – There is no point in gathering a group of people if the leader is going to follow through on an action they thought of previously to a retrospective. Consider scheduling a retrospective early on, very focused on information gathering and generating insights as a first part, and then a second part with a smaller, focused group on the next steps. By having time to digest the new information, you may find you end up with very different solutions than what you first had in mind.

When used well, retrospectives can create a safe space to invite people to dissent and create an ongoing culture of challenging the status quo.

You may not need a Tech Lead, but others do

Vinicius sent me a tweet about an article he published called We don’t need a Tech Lead in response to an older article of mine, “Do we need a Tech Lead?”

I wanted to respond earlier, but tweets were too restrictive. Here’s my response.

The argument against Tech Leads

The article rebuts the necessity for a Tech Lead with the following points (emphasis author’s, not mine):

  1. Well functioning teams in which people share responsibilities are not rare.
  2. When a team is not functioning well, assigning a tech lead can potentially make it worse.

There are many great points in the article. Some of the points I support such as how sharing responsibilities (also known as effective delegation). Distributing responsibilities can be one way effective teams work. Other points lack essential context such as the title (it depends), while other points lack concrete answers such as how to turn a dysfunctional team into a highly performing team.

Are well-functioning teams rare?

I’ve worked with at least 30 organisations over my career as a consultant, and countless teams, both as a team member (sometimes Tech Lead) and as an observer. I have seen the whole spectrum – from teams who function like a single person/unit to teams with people who simply tolerate sitting next to each other, and where one can’t miss the passive-aggressive behaviours or snide remarks.

The article claims:

that the “tech lead is a workaround – not a root cause solution


Tech leads could alleviate the consequences only

Unfortunately the article doesn’t explain how or why the tech lead is a workaround, nor how tech leads alleviate just the consequences.

The article gathered some discussion on Hackernews, and I found some comments particularly interesting.

Let’s take a sample:

  • (gohrt) Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
  • (vidhar) …we live in reality where lots of teams are not well-functioning some or all of the time, and we still need to get things done even when we don’t have the time, resources or influence to fix the team composition then and there.
  • (ep103) If I had an entire team of my great engineers, my job would be easy. I’d simply delegate my duties to everyone else, and we’d all be nearly equal. I’m jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.
  • (shandor) My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (EDIT: i.e. tech lead responsibilities)
  • (doctor_fact) I have worked on teams of highly competent developers where there was no tech lead. They failed badly…
  • (mattsmith321) It’s been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions.
  • (jt2190) I’ve been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted… These teams (if they can be called that) produced software that had little to no overall design.

Do these sound like well-functioning teams to you? They don’t to me.

Office Fight

Image from David Trawin’s Flickr stream under the Creative Commons licence

Well-functioning teams do exist. However it is clear that not all teams are well-functioning. In my experience, I would even say that really well-functioning teams are less common than dysfunctional, or just functioning teams. For me, the comments are proof enough that well-functioning teams are not everywhere.

It is actually irrelevant if well-performing teams are rare – there are teams that definitely need help! Which leads to the question…

Does assigning a tech lead to a poorly functioning team make it worse?

In my talk, What I wish I knew as a first time Tech Lead, I explain how acts of leadership are amplifiers (can be good or bad). Therefore assigning a bad tech lead to a poorly functioning team will probably make it worse. However I don’t think organisations set out to give teams bad tech leads.

If a team is poorly functioning, what do organisations do? Simply leave the team to stew in its own juices until things are resolved? That’s one option. Doing nothing is a gamble – you depend on someone in the team to take an act of leadership but the question is will they? I’ve seen many teams never resolve the very issues that make them poorly functioning without some form external intervention or assistance.

Most organisations try to solve this by introducing a role who has some authority. It doesn’t necessarily need to be a Tech Lead, but when the core issues are technical in nature, a good Tech Lead can help. A good leader will seek out the core issues that prevent good teamwork, and use their role to find ways to move them towards a well-functioning team. Sometimes this may mean calling meetings, even if the team do not want to have meetings to reach an agreement about how the team handles certain situations, tasks or responsibilities. A good outcome might be an agreed Team Charter or some clarity about who in the team is responsible for what. A team may end up with a model that looks like they do not need a Tech Lead, but it takes an act of leadership to to make that happen.

The wrong analysis?

The article suggests that a full-time Tech Lead introduces risks such as a lack of collective code ownership, decision-making bottlenecks, a single point bus factor, and (reduced) impact on motivation. I have seen teams with and without Tech Leads both suffering from these issues. In my experience, teams without a Tech Lead tend to have more issues with knowledge silos, no cohesive view and less collective code ownership because there is little motivation to optimise for the group and individuals end up optimising for themselves.

The issue is not caused by whether or not teams have a Tech Lead. Rather, these issues are caused by a lack of a technical leadership (behaviour). The Tech Lead role is not a prerequisite for having technical leadership. I have seen teams where strong, passionate individuals will speak up, bring the team together and address these issues – which are acts of leadership. I have also seen dysfunctional teams sit on their hands because individual (job) safety is an issue and these issues go unaddressed.

My conclusion

The article misses the subtle but important point of good technical leadership. A good leader and Tech Lead is not trying to own all of the responsibilities – they are there to make sure they happen. There is nothing worse than expecting everyone is responsible for a task, only to find that no one is responsible for it.

“The greatest leader is not necessarily the one who does the greatest things. (They) are the one that gets the people to do the greatest things.” – Ronald Reagan

The extent to how much individuals in a team can own these responsibilities is a function of the individuals’ interests, skills and experience. It depends!

Asking whether or not teams need a Tech Lead is the wrong question. Better questions to ask include what’s the best way to make sure all of the Tech Lead responsibilities are fulfilled, and what style of leadership does this team need right now.

Fixing ssh on Mac Sierra 10.12.1

I recently upgraded my mac to the latest OS only to find out that my ssh command wasn’t working.

>ssh <strong>servername</strong>

resulted in:

> .ssh/config: line 18: Bad configuration option: useroaming
> .ssh/config: terminating, 1 bad configuration options

which looks like because I added in the following entry to my


file in response to a previous SSH vulnerability:

UseRoaming no

This vulnerability looks like it’s been fixed:

« Older posts

© 2017 patkua@work

Theme by Anders NorenUp ↑