Here are just a few of the things that I took away from the conference.

When to make quick decisions

I learned the most from Nicky Thompson’s excellent talk, “Making work (and life) less stressful by making better decisions”. This was jam packed with information to help us understand how our brains work (both for and against us) when it comes to decision making and useful advice and models to help us make better decisions.

One of the many useful things that she shared was the HOT method for thinking about whether it making a quick decision makes sense.

1. How Happy would you be with the decision in a year?
2. Would you be Okay if this was the only option?
3. Is it a Two-way door? (Can you reverse the decision?)

Video / Slides and transcript

Lowering the bar on Managing incidents

Martha Lambert’s brilliant talk, “We should all be declaring more incidents”, really challenged my thinking.

She made an compelling case for the value of lowering the bar on incidents and having many more of them. We get good at things we do often and so having more incidents means that we get better at dealing with them. Also, this helps us respond more quickly and communicate better with users and stake holders and so builds trust and empathy.

As someone who has prided themselves on making incidents a rarity in my teams this was uncomfortable. But I am also aware that I have been encouraging my teams to lean into “never being wrong for long”, over “releasing zero bugs in production”, for years, which lines up with having more incidents. This makes me want to experiment with lowering the bar on incidents in future.

Video

Challenging my people pleasing behaviours

Nikita Rathi’s talk, “Pleasing everyone, except yourself: Overcoming people-pleasing tendencies to become a stronger engineering leader”, was really affecting.

It was delivered with grace, vulnerability and empathy and made me think about the problems that my own “people pleasing” traits create for me and how I judgemental I can be about these behaviours in myself.

I can’t do justice to the power of this talk in words and so encourage you to simply watch her amazing talk.

Video and slides

Building a culture of learning

My favourite quote of the conference came from Sorrel Harriet in her talk, “Learning is a core capability of software teams; here’s how to measure it”.

We need to care less about progressing individuals along predictable pathways, and more about creating an environment and culture in which people will learn continuously and autonomously.

Video

I also enjoyed Hywel Carver’s talk, “How to completely fail at learning”. His advice to “SCALE” learning looks spot on:

• Solve problems
• Continuous learning
• Assess what’s needed
• Limit scope
• Engage with humans

And I can’t help but notice that coaching fits very well with this in terms of supporting learning.

Video

Other topics

There were too many other great talks to mention them all. But two particularly thought provoking ones that stood out were Amy Roberts-Hoad’s talk, “Go with the flow: Embracing and supporting menstrual needs in tech”, and Birgitta Boeckeler’s talk, “AI for software development: A reality check”.

All in all it was a privilege to be there. Thanks to all the staff, speakers, attendees and everyone who I met and made me feel so welcome.

I’ve really enjoyed getting back to going to conferences and 2023 has been a good year with Brighton Ruby, CTO Craft Con in May and November, and LeadDev Berlin. I am looking forward to 2024 with CTO Craft Con in May and LeadDev and LeadingEng in London in the summer.

The best engineering leaders know that you can have both speed and quality when developing software. Indeed, the only way to keep up the pace of delivery is to build high quality software. Everybody wins.

However, all too often, it can feel like you are not in control of the quality of your code. You can feel like your team doesn’t have time to develop high quality code. You can feel like you are forced to make a trade off between the quality of code and speed of development. And when you do you typically end up with neither.

How do you take back control of your code quality? How do you get your team and stakeholders to believe that this will enable you to develop faster? What practices do you need to put in place to make this true>

In this talk I illustrate the dynamics between team members and with stakeholders that lead teams to lose control of code quality.

And I share a set of practices and techniques that you can take away and use to support your team to take control of their code quality, deliver rapidly and keep stakeholders on your side.

Transcript

I am proud of my work in all the roles that I had as a start-up and scale-up CTO.

But I learned how to be a CTO the expensive way.

By this I mean that, for most of my career as a CTO, I learned by making mistakes again and again and slowly improving over time. These mistakes were paid for by the companies that I worked in. These were also paid for by my teams and I because of impact that these mistakes had on both their and my wellbeing.

As a start-up or scale-up CTO we constantly face new challenges and need to learn new skills.

Making mistakes is inevitable when we are learning. But we can learn faster. And we can reduce the costs of our mistakes and our learning for the companies we work for and for ourselves and our teams.

Much later in my career I started working with a professional coach.

I continued to make mistakes. But my coach supported me to reduce the negative impact of these mistakes by avoiding some common pitfalls and by identifying when things were going wrong sooner. They helped me to accelerate my development by enabling me to learn faster from my experiences. They enabled me to make better decisions by better understanding myself and the situations I was in. They supported me to build better relationships with my teams and peers. They also helped me feel calmer, more in control and less alone when I was finding my role very stressful.

These benefits were cumulative. The value of the improvements in my performance as a CTO vastly outweighed the costs of coaching for the company I worked for.

I also benefited personally, in both the development of my skills and in my awareness and acceptance of myself and of those around me.

If I was able to go back in time to the point when I first became a CTO and offer myself one piece of advice, it would be to get the support of a CTO Coach.

A CTO needs a CTO coach if they want to improve their performance. If they want to serve their teams better. If they want to learn faster.

Thanks to Marc Adler for asking me this question in an AMA (Ask Me Anything) on the Rands Leadership Slack and inspiring me to write this article

Falling for this stereotype can lead to a sense of helplessness about motivating engineers because, “we can’t introduce cutting-edge technology here”. Or, even worse, the introduction of a new technology solely to satisfy this assumption.

In my experience, just like other people, engineers have a diverse range of motivations. These extend well beyond technology.

To understand what motivates the engineers that you work with you need to ask them. What are they most proud of? What energises them? What motivates them? What do they find most rewarding? What does a fulfilling day at work look like for them?

It is also valuable to ask about factors that demotivate and frustrate them, as reducing these can have a significant impact on their motivation.

What are key motivations for the engineers that you work with? Ask them and you will find out.

I’ve reviewed hundreds of CVs over the years. Applicants who make it easy for the person reviewing their CV to see that they are a great match the role have a much better chance of getting an interview.

Here are some things you can do to improve the story your CV tells to the person who is reviewing your application.

1. Make it quick to scan and easy to read

   The design does not have to be beautiful but your reader likely to be in a rush and so you need to make it easy to navigate and read.

   Keep it simple. Make sure that it is not too busy. Make it easy to pick out keywords (bold/underline). Keep it reasonably well spaced.

   Be careful about using jargon. Who is going to be reviewing your CV? Are they likely to understand the jargon you are using? If not, avoid it.

   Keep it to less than three pages with all the most important information on the first page.

2. Show that you meet the requirements for the role

   The person reviewing your CV should not have to guess whether you meet the requirements of the role that you are applying for.

   The person initially reviewing your CV maybe the hiring manager, or it maybe a recruiter or a member of the HR team. Either way they are unlikely to spend much time deciding on whether you are a reasonable candidate. Make it really easy for the person reviewing your application to see that you are right for the role they are hiring for. This may mean adapting your CV to the requirements of this particular role.

   Review the requirements of the role you are applying for. If necessary, update your CV to make it clear that you meet these requirements. You may also find it valuable to update the summary section in your CV (see the next point) to ensure it tells a story about how you are the right person for this role.

3. Include a brief summary

   The person reviewing your application will form a story about you from your CV. Make it easy for them by writing a few sentences to tell the compelling story that you want them to see.

   This is an opportunity for you to tell the reviewer where you are heading in your career and why their role is right for you.

4. Include your achievements

   The person reviewing your application wants to know what you are capable of and to be confident that you will be able to deliver in the role that they are looking to fill.

   Build their confidence by telling the reviewer what you have achieved in your roles. For each role you list in your CV make it clear what your impact was and why this mattered.

5. Include testimonials

   The people who have worked with you in the past know better than anyone how great you are to work with. Ask some of them for testimonials which show off your relevant strengths.

   Include one or two of these in your CV to give the reviewer more confidence that you are the right person for their role.

   These testimonials will also build your own confidence.

6. Get feedback

   It can be very hard for us to describe ourselves and our own achievements. Another person looking at your CV will be able to give you a clearer view of how you are presenting yourself. They are also more likely to spot mistakes and typos.

   Share your CV and the description of the role you wish to apply for with some people that you trust and ask for their feedback and advice. How would they view your CV if you were applying for the role? What is missing? What feels irrelevant? What changes do they suggest?

Good luck with your applications.

Note: If you are a hiring manager who is finding it difficult to make decisions about whether to interview candidates based on their CV/cover letters then it might be worth considering asking specific questions of candidates rather than asking for a CV. Collaborative Future have shared their experiences of taking a CV-less approach to hiring.

“Technical debt” is a metaphor that is often used in software development as part of trying to explain some of the trade-offs we make when designing software, and the costs that we incur because of the lack of quality in our software.

However, the metaphor “technical debt” often hides a whole host of misunderstandings.

Here are some of the many ways that this metaphor confuses communication.

When people hear the “technical debt” metaphor, it suggests to them that…

1. …the cost will be predictable, like a financial loan’s interest payments. Yet developers know that the cost of “technical debt” is unpredictable. It is hard to assess up front and is likely to vary as the context that they are working in changes.
2. …it is cheap, because financial debt has been cheap in recent decades. Yet developers know that “technical debt” is often very expensive.
3. …we are making explicit choices about when to accumulate it, like choosing to take out a loan. Yet developers know that “technical debt” is often accumulated without discussion or explicit decision making.
4. …it is quantifiable and constant, like financial debt. Yet developers know that it is not quantifiable in any meaningful way and it can be radically changed by shifts in external context.
5. …each bit of “technical debt” is interchangeable, like money. Yet developers know that some bits of “technical debt” are much more costly than others and it matters which bits you choose to pay off.
6. …there can be code with zero “technical debt”. Yet developers know that all code is a liability and all valuable code has “technical debt”. This sets unrealistic expectations for developers and stakeholders.

The biggest problem in communication is the illusion that it has taken place. With so many misunderstandings built into the metaphor of “technical debt”, is it any wonder that conversations about prioritising work on “technical debt” are frustrating?

If you are finding your own conversations about “technical debt” frustrating then take some time to reflect on whether any of these misunderstandings might be occurring. If they are, then it is probably worth explicitly talking about them.

An alternative is not to use a metaphor at all. Talk in concrete terms. Talk about the specific work that you recommend to and/or are carrying out to improve code quality and the positive impact that this will have on developer productivity.

I wrote a version in Javascript to make them easy to explore in your browser.

Enjoy.

We set out to improve on this by adopting more agile practices across the company. I am really proud of the way in which everyone has embraced the changes involved and of the impact they have had in enabling us to make better decisions and work together more effectively.

There were many elements to making these changes but one important part of this was to make sure that the underlying agile principles were well understood and acted upon by everyone involved in making decisions about our software. This included members of our leadership, sales, customer success and design teams as well as our product and engineering teams.

What we did

One of the ways that we worked to achieve this was by running an agile principles study group which we opened up to the whole company. We based our study group around the excellent Troubleshooting Agile podcast, which includes 12 episodes (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12) that are dedicated to discussion of each of the agile principles in turn.

We met every fortnight and before each study group session we would listen to the podcast episode about the corresponding agile principle.

Our format for each session developed over time but, thanks to a suggestion from Jeffrey Frederick, we settled on the following format for these sessions - the timings are fairly rough.

1. Have one member of the study group summarise the key points made in the podcast (5 mins). We did this to make sure the podcast was fresh in everyone’s minds even if they had actually listened to it a few days beforehand or in some cases had not had a chance to listen to it.

2. Discuss our understanding of the principle (15 mins). This helped us understand how we interpreted the principle, how we understood it to help and where we thought we might disagree with it or see particular challenges in applying it.

3. Discuss how the principles applied to us at Unmade (15 mins). This helped us try and apply the principle to our experiences within our company. We typically discussed examples of where we were using this principle and where we thought it may have helped us overcome problems we faced.

4. Identify changes we want to make as a result of our reflections on the principle (15 mins). We did this to help ensure that this was not an abstract intellectual exercise but one that explicitly impacted our behaviour.

   For example, actions taken in response to our discussions of agile principle number 5, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” included the following:

   • One of our Project Managers, Sarah, ran a session to help the cross-functional team she was leading support one another better and feel more in control of their work. In that session they worked to make each person’s role within the team more explicit and then she got team members to share how they could help each other in their roles which helped break down barriers between the disciplines and gave team members more confidence to offer one another support.
   • I gave a company wide talk about taking authority for decision making to make our adoption of this principle more explicit.

The impact

It has been really inspiring to see how members of the group, from all disciplines, have gained confidence in their understanding of the agile principles and how to apply these principles in their roles and teams. It has also been gratifying to see that we have been finding it easier each meeting to draw upon positive examples of how we have already been applying these principles in our work.

One of our Product Managers, Katie, shared the following about her experience of being part of the study group:

Since starting the study group, I feel we have become far more confident about guiding our customers to rapid and regular delivery of valuable software that meets their needs, rather than more traditional waterfall methods which they might be more used to. For example, we have phased out the concept of ‘UX/UI design reviews’ which are vastly upstreamed from a software development phase, and instead show our customers real working software as soon as possible, which is iteratively improved. This has meant we can reduce delivery risk and time to launch considerably.

Although I was already familiar with the principles it has been very valuable to regularly discuss them with a range of other disciplines in the team, and to collaboratively decide if and how to action any changes as a result. It has helped me understand how other people experience the challenges and opportunities of working in this way and I feel it has noticeably increased the empathy and understanding of agile product development practices across the company.

We’re coming to the end of our study of the 12 agile principles and given how successful it has been we are wondering what to study next.

Thanks to everyone who took part in our agile principles study group and also to Jeffrey Frederick and Douglas Squirrel of Troubleshooting Agile who not only provided us the source material and a suggested format for this study group but also inspired me to set up my first work study group in a previous role.

My first opportunity to do this came about through luck rather than planning.

When I returned to a technology role, as CTO at Unmade in 2018, I committed to make more of an effort to build professional relationships with people outside my organisation. I am not confident in group networking events and far prefer one-to-one conversations. I have been finding opportunities to meet more people (both people I already knew and new people) for coffee or lunch this year.

One such meeting was with Anna, a senior leader in a large engineering team. When we met, Anna was clearly distracted by an issue she was facing at work that day. We ended up just talking about this and I was able to give her some practical advice which she found very helpful. This made us think that it would be valuable to set up a mentoring arrangement.

What did we do?

We started by meeting for an hour to discuss how we would arrange our mentoring relationship. The key points to this were:

• Purpose: Anna shared what she wanted to get from mentoring so that we could work towards a common goal
• Confidentiality: I committed to treating everything Anna told me in the strictest confidence which was essential to enable her to be honest with me
• Commitment: We agreed that if Anna decided on a course of action in one of our sessions, then her only responsibility for carrying it out was to herself
• Limits: We agreed that we would have a limited number of sessions to reduce the risk that, over time, it slowly became less and less useful but continued through inertia or social obligation
• Feedback: We agreed that Anna would give me some simple feedback after every session so that if the sessions stopped being useful we would bring the mentoring arrangement to an early end.

We also agreed on the rough frequency and where and when we would meet for the 5x75 minute mentoring sessions that we had planned.

The time we spent setting expectations was really valuable and we both thought, in retrospect, that it may have been useful for us to have spent a little more time making sure we were clearer on this.

We settled into a routine in these sessions. We started by making tea and coffee and generally chatting about how we were both doing in order to get comfortable with one another again.

Then, usually, Anna would let me know about the impact of our previous session by sharing what had happened as a result of our conversations and the decisions she had made. This was really useful in that it gave me insight into what was working or not working for her and also helped me understand how the situations she was facing were changing.

Finally, we discussed the current challenges that Anna faced. Much of my work here was careful listening, being curious, asking questions, challenging assumptions and reflecting back what I had heard in order to help Anna clarify her thinking and understanding. This is where, in many ways, my not working with Anna felt like an advantage because not knowing her company or colleagues forced me to ask, rather than assume, what was going on. Once we better understood the issues we would discuss potential courses of action for her based on our own experiences.

After each session I wrote some very brief notes for myself so that I would be able to refresh my memory before the next session. I also sent Anna a short questionnaire to reflect on the session and offer feedback within a few days, the key question being “on a scale of 1-5 how valuable a use of your time was the session?”. The advantage of doing this offline were that it slightly reduced the social pressure to respond positively and also gave Anna time to reflect.

How was it valuable for me?

I found the experience of being a mentor really valuable in a number of ways.

Firstly, Anna is very thoughtful and articulate and has her own set of experiences which I felt able to learn from in the course of our discussions. Many of the challenges that she faced in her role as a technical leader mirrored challenges I faced in my own role and our discussions helped clarify my own thinking and spur me into actions in my own job.

Secondly, Anna exposed me to new ideas and situations and gave me insight into to how other people and organisations were tackling the problems that we all face in technical leadership roles. For example, she recommended I read, High Output Management by Andy Grove, which is excellent and I found myself referring back to repeatedly both in our mentoring conversations but also in my wider work.

Finally, as someone who has been privileged to benefit not only from mentoring but also from pretty much all of the available biases in our society, I was grateful for this opportunity to support someone from an under-represented group in technology in their career.

The value of this to me made it easy for my employer to see that this was part of my work at Unmade.

What next?

Perhaps you would like to mentor someone too? If so, I would encourage you to do so, you are likely to learn as much from them as they do from you.

In 2021 I became an Engineering Leadership Coach so if you would like to be mentored and/or coached by then please get in touch.

Thanks to Anna for all that I learned from her and for encouraging me to write this post.

This should give you a clear idea of how continous delivery reduces risk on software projects and make it easier for you to explain the benefits of this approach to your colleagues.

This is part of a series of talks and blog posts reflecting on the practices that we use at in our teams at FutureLearn.

Note: This talk was originally written by Tom Ward as an internal talk at FutureLearn as part of our communications about why we were using continuous delivery.