patkua@work

The intersection of technology and leadership

Category: Coaching (Page 1 of 11)

The Next Experiment? Starting My Own Venture

January 5, 2020 / / 0 Comments

My last post shared some of my reflections about some of the highlights and lessons learned from my last role. In this post, I want to share with you what’s next for me.

What’s most important for you?

During many of my coaching/mentoring sessions, I often start by asking this hard question. It’s hard for a lot of people to answer because it requires looking deep into yourself. It’s a question that no one else but you can answer.

For some people, it’s about having new experiences or growing new skills. For others, it’s about being able to apply their strengths in a way that has a positive outcome. For others, it’s being able to bring their whole self to work collaborating in an environment with people they trust.

To dogfood my own question, I spent a lot of time last year thinking deeply about what this meant for me. Although I know the answers to this question change over time, I believe what is most important to me right now is:

  • Having more time flexibility – I have a goal of spending my time with writing and working on a couple of different projects. Having a full-time role would constrain that more than what I would like right now.
  • Helping others grow – Feedback from participants from my Tech Lead Skills for Developers workshop has been personally very fulfilling. Many come away with the realisation that the Tech Lead role is a role change, not a promotion. Others told me how their personal lives have benefited from the training. Hearing how others have grown, and knowing I’ve had a part in that has been very fulfilling.
  • Having a broader impact – All good leaders continue to review the impact they have had. I’ve had a lot of success growing others leaders within a single company and want to do more.

Got some Ikigai?

The Japanese have a word, Ikigai, that is roughly translated to “the thing you live for” or “reason for being.” It was propelled into the Twittersphere when Marc Winn published this article, “What is your Ikigai?”

Ikigai Venn Diagram
A visualisation of the meaning of Ikigai

Today’s world talks a lot more about mission-driven or purpose-driven companies. Paloma Medina talks about people’s core needs using the BICEPS acronym where two key elements are both seeing Improvement/Progress (e.g. “Progress towards purpose”) and Significance (e.g. “Your work is recognised and appreciated in ways that feel good”).

All of these models resonate with my own personal values of having an impact with the skills and experiences I’ve built over time. I’m grateful I work in an industry (tech) where we have more options to find our Ikigai.

The next experiment?

Now that I understand what is most important for me right now, my next experiment is starting my own venture. I don’t want to label myself as a “founder” and I’m not necessarily interested in starting a product company. Although I’ve learned to “never say never!

Instead my venture is best summarised by the following mission statement: “Accelerating the growth of technical leaders, software delivery and organisations”.

Personal mission statement: Accelerating the growth of technical leaders, software delivery and organisations

Rather than defining everything upfront, I have a couple of ideas and initiatives to fulfill this mission right now.

Offering Tech Lead Development Workshops more widely

My previous role significantly limited how and when I could offer my “Tech Lead Skills for Developers” workshop. I’ve had many requests for running this workshop – both internally for other companies and externally as public workshops as well.

I will be initially offering this to companies who would like to host this internally for their staff. If you’re interested in organising a workshop for your company, then read more here.

If you’re interested in joining a public workshop, I’m in discussions with a couple of training companies and conferences to offer this. Follow me on twitter (@patkua) or connect to me on LinkedIn to watch for updates.

Offering Keynotes and Talks

I’ve had great feedback about the presentations I hold. It’s also an important part of sharing and distributing knowledge more widely and something I enjoy. You’ll still, therefore, see me at various tech conferences (mostly around Europe).

If you’re interested in having me speak at your own internal conference or event, then take a look at some of the talks I offer and you can also get in touch if you’re interested in hiring me for that.

Advising and mentoring

During my own leadership journey, I’ve had a number of people I’ve mentored and advised. I’ve found that many senior leaders (e.g. CTOs, VP Engineering, Directors of Engineering) benefit from having an external perspective who has “been there before.”

I’ll be offering this through a traditional consulting/advisory model so get in touch if you’re interested in that.

Projects in the Pipeline

Offering the services above also gives me significant flexibility to work on a number of projects I haven’t had time for. My newsletter, Level Up is one such project that has had a good reception and I have a number of others I’d like to focus on as well.

Moving to http://patkua.com

As part of this new venture, you’ll see fewer (maybe zero?) updates on this site going forward. Thank you to all those long term RSS subscribers who’ve shared my journey over this website. I plan on keeping http://thekua.com/atwork around as there are many useful resources on it.

You can now follow me on http://patkua.com (same as my twitter handle) and the writing will continue at http://patkua.com/blog.

Goodbye CTO, Hello Chief Scientist

March 10, 2019 / / 10 Comments

What was the Challenge?

Hypergrowth land is fun. Things change all the time. My challenge as a CTO was to shake-up the early-stage startup “snowglobe.” It was to transform “start-up” habits into a “scale-up” culture. It was to prepare and launch into hypergrowth. I took on this challenge because I saw the kernel of engineering talent that I could nurture and support.

What Changed?

Looking back at the time I’ve been there (it feels like ages in startup time!), so many things have improved. It’s hard to count all changes as the company constantly evolves. Here are some of the changes I’m proud to have influenced:

  • Clear priorities – It’s easy to fall into reactionary mode and want to switch gears all the time. As the old saying goes, “If everyone is a priority, then nothing is a priority.” Engineering is always the bottleneck. Ideas are cheap. Ideas are easy. You have 5 ideas. I have 5 ideas. Engineers have 5 ideas. To maximise our opportunity, we needed to be clearer about where to focus attention. We now have a better planning process that enables clearer trade-offs and decisions.
  • Almost 4x tech growth – When I first started, I looked around asking, “Where are all the engineers?” Our ratio of tech to non-tech was way off! We worked hard with the People team to change our recruiting strategy. We improved our onboarding process. I spent a lot of personal time writing articles and speaking on our engineering culture. The result? Tech is almost 4x the people compared to when I started. We also managed this while continually delivering value to customers too.
  • A clear Target Operating Model – Change is hard. What helps is a shared picture of how we wanted to scale Product & Tech. You can’t have more people working on the same problem. You need to create a clear focus. You need to encourage high cohesion and low coupling across people and teams. We established a shared Product & Tech Target Operating Model. This model visualises and explains new structures, processes and how they fit together. Each iteration aims to addresses organisational smells and maximise Autonomy and Alignment. We’re working on our 3rd iteration of this now.
  • Product versus Portfolio Management – We have individual product area priorities. We also have cross-cutting projects. We now can focus on ensuring the bottleneck or critical path has full support and attention. We can manage both product and portfolio priorities well.
  • Fuller life cycle ownership in teams – When I arrived, we already had cross-functional teams. Not all teams were responsible for the full “life cycle” of a product. Sometimes back-office or operational processes belonged to a different team. The separation lead to queues and bottlenecks. Our teams are on a journey of integrating more responsibilities. They continue to extend the definition of done to remove hand-overs. We build security and quality in from the start. Teams can better respond to customer issues, incidents and build new or on existing products.
  • Technical governance practices that scale – As we grow, we also focus on alignment where it makes sense. Organisations can only support a certain amount of variation or entropy. Alignment helps. We adopted a lightweight RFC process and iterated on our internal Tech Radar. We built decentralised support structures like Technical Working Groups and an Architecture guild. These work without relying on the same individuals to make decisions.
  • Three Product and Technology Hubs around the world – We’ve moved from being completely centralised in Berlin to operating three successful P&T hubs in Barcelona, New York City and Berlin. We transitioned major product ownership to one office as it grew. The team evolved and released completely new features and services in record time. We’ve maintained speed and throughput, and quality remains high.
  • Rapid growth of individuals – As a I leader I invest in people I work with. I’ve mentored, coached and trained many individually personally. It’s wonderful to see how it’s accelerated people’s growth. People have better ways to deal with imposter syndrome. Engineers have more impact and influence through stronger leadership skills. Better yet, I know they have done this with an explicit support.
  • Diversity, inclusion and culture – I remember one big change I first made was removing a degree requirement for engineers. I created the #diversity slack channel. I sponsored the celebrations for International Women’s Day. This lead to a wonderful support of CSD in Berlin. Watch this amazing video! I know we’re not perfect but we are improving. Our gender ratio in tech can still improve. We have, however, built an inclusive culture where everyone in Product & Tech can express ideas in safety.

What’s next?

The CTO is one of the most confusing roles. Some call it a chameleon role. Companies have different requirements of the role. It changes rapidly in the same company (particularly one going through hypergrowth). There are just many different explanations. As our company grows, the needs of the CTO role grow and change.

As a leader, I found myself asking others (and myself), “How does this scale?” I’m constantly looking at ways to scale myself too. To scale with the growing set of responsibilities, we are splitting this role.

The CTO for our company, in our stage, demands a more operational, management and inward focus. I will step into a new role called, “Chief Scientist.” This new role takes a more outward focus and still guides the technical direction and growth of the tech team.

Our “Chief Scientist” role focuses on three areas:

  1. Representing the external face of technology
  2. Supporting and enriching technical decisions
  3. Accelerating the growth of people in our technical team

I’m look forward to refocusing my attention and energy. These areas not only bring significant value to the company, but also play to my strengths. Here’s to embracing constant change, evolution and experimentation!

Sekt on a mountain

PS. If you’re interested in joining me on building the bank the world loves to use, check out our open opportunities.

More with LeSS

Learning about More with LeSS

January 6, 2019 / / 0 Comments

Background

I took part in a three day course before Christmas to better understand Large Scale Scrum (LeSS). LeSS’ tagline is “More with LeSS”. I’m pessimistic about most “Scaling Agile Frameworks.” Many give organisations an excuse to relabel their existing practices as “agile.” Not to fundamentally change them. Bas Vodde (one of the founders of LeSS’) invited me to take part in a course just before Christmas. I took him up on the offer to hear it “From the horse’s mouth.”

This article summarises my notes, learnings and reflections from the three day course. There may be errors and would encourage you to read about it yourself on their LeSS website, or post a comment at the end of this article.

About the Trainer

I met Bas Vodde about a decade ago. We met at one of the Retrospective Facilitator’s gathering. He is someone who, I believe, lives the agile values and principles and has been in the community for a long time. He still writes code, pair programming with teams he works with. He has had a long and successful coaching history with many companies. He worked with huge organisations where many people build a single product together. Think of a telecommunications product, for example. Through his shared experiences with his co-founder, Craig Larman, they distilled these ideas into what is now called LeSS.

What I understood about LeSS?

LeSS evolved from using basic Scrum in a context with many many teams. I took away there are three common uses of the term LeSS.

  • LeSS (The Complete Picture) – The overview of LeSS including the experimental mindset, guides, rules/framework, and principles. See the the main website, Less.
  • LeSS (The Rules/Framework) – The specifics of how you operate LeSS. See LeSS Rules (April 2018).
  • LeSS (for 2-8 teams) – Basic LeSS is abbreviated to LeSS and is optimised for 2-8 teams. They have LeSS Huge for 8+ teams, and modifications to the rules. See LeSS Huge.

Practices & Rituals in LeSS

LeSS has a number of practices and rituals as part of its starting set of rules. Some of these include:

  • A single prioritised Backlog – All teams share a single backlog with a priority managed by the Product Owner.
  • Sprint Planning 1 – At the end of this, teams have picked which Backlog Items they work on during a sprint.
  • Sprint Planning 2 – All teams do this separately. Like in Scrum, Sprint Planning 2 focuses on the design and creation of tasks for their Sprint.
  • Daily Scrum – Each team runs their own Daily scrum as per standard Scrum.
  • Backlog Refinement – Teams clarify what customers/stakeholders need. Good outcomes include Backlog Items refined into sizes where teams can take 4/5 into a Sprint. LeSS encourages groups, made up of different team members, to refine Backlog Items. This maximises knowledge sharing, learning and opportunities to collaborate.
  • Sprint Review – Teams showcase their work to customers/stakeholders for feedback. The Product Owner works to gather feedback and reflect this in the overall Backlog. Sprint Reviews should not be treated as an approval gate. It’s about getting more input or ideas.
  • Sprint Retrospective – Each team runs their own retrospective. As per standard Scrum.
  • Overall Retrospective – Members from every team plus management hold a retrospective. This retrospective focuses on the system and improving the overall system.
  • Shared Definition of Done – All teams share an overall Definition of Done, which they can also update. Teams can build on the basis of the shared Definition of Done.
  • Sprint – There is only one sprint in LeSS, so by definition all teams synchronise on the same sprint cadence.

Roles in LeSS

  • Scrum Master – Like in Scrum, LeSS has the Scrum Master whose goal is to coach, enable and help LeSS run effectively. The Scrum Master is a full time role up of up to 3 teams.
  • Product Owner – The Product Owner is the role responsibility for the overall Backlog prioritisation
  • Area Product Owner – In LeSS (Huge), Area Product Owners manage the priority of a subsection of the Backlog. They also align with the Product Owner on overall priorities.
  • Team – There are no explicit specialist roles in LeSS, other than the team (and its members).

Principles of LeSS

A key part of LeSS is the principles that guide decisions and behaviours in the organisation. People can make better decisions when taking these principles into account. You can read more about LeSS’ principles here. Like many other agile ways of working, Transparency is a key principle. Unlike other agile methods, LeSS calls upon both System Thinking and Queuing Theory as principles. Both are useful bodies of knowledge that create more effective organisations.

Another explicit difference is the principle of the Whole Product Focus. This reminds me very much of Lean Software Development’s Optimise the Whole principle. I also like very much the description of More with LeSS principle. This principle challenges adding more roles, rules and artefacts. So think carefully about these!

Overall observations

  • In LeSS, having LeSS specialisations is a good thing. This encourages more distributed knowledge sharing.
  • LeSS explicitly priorities feature teams over component teams to maximise the delivery of end to end value. Both have trade-offs.
  • LeSS doesn’t explicitly include technical practices in it’s rules. It assumes organisations adopt modern engineering practices. To quote their website, “Organizational Agility is constrained by Technical Agility.”
  • A lot of LeSS has big implications about organisational design. Agile teams showed how cross-functional teams reduce waste by removing hand-off. LeSS will be even more demanding on organisations and their structure.

LeSS Huge

The creators of LeSS made LeSS Huge because they found a Product Owner was often a constraint. Since Product Owner’s focus on prioritisation, it’s hard to keep an overview and manage the priority of 100+ Backlog Items. (Note that teams still do the clarification, not the Product Owner). With 8+ teams, they found even good Product Owners could not keep on top of the ~100+ refined Backlog Items (which normally covers the next 3+ sprints).

LeSS Huge addresses this by introducing Categories (aka an Area). Each Backlog Item has its own category, and each category then has an Area Product Owner to manage the overview and prioritisation of Backlog Items in that category.

Guidelines for creating an area:

  • This should be purely customer centric
  • Often grouped by stakeholder, or certain processes
  • Could be organised by a certain market or product variant
  • No area in LeSS Huge should have less than 4 teams

Conclusions

After taking the course, I have a much stronger understanding of LeSS’ origins and how it works. After the course, it feels much LeSS complex than when I first read about it on their website. It includes many principles which I run software teams by. I can also see many parallels to what I have done with larger organisations and LeSS. I can also see how LeSS is a challenging framework for many organisations. I would definitely recommend larger product organisations draw inspiration from LeSS. I know I will after this course.

Thanks Jerry Weinberg

August 11, 2018 /

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind. 

Starting as CTO at N26

September 18, 2017 /

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? 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.

Reflecting on the Tech Lead Skills for Developers Course in Brazil

February 26, 2017 / / 0 Comments

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.

The Well Rounded Architect

The Well Rounded Architect

November 27, 2016 / / 6 Comments

In this blog post, I explore the six different dimensions I covered in my recent talk at the O’Reilly Software Architecture conference in London called “The Well Rounded Architect.”

The elements of the well-rounded architect

The Well Rounded Architect

Acting as a Leader

Good software architects understand that their role as a leader is not necessarily telling developers what to do. Rather, good architects act like a guide, shepherding a team of developers towards the same technical vision drawing upon leadership skills such as story-telling, influencing, navigating conflict and building trust with individuals to turn their architectural vision into reality.

A good leader, and thus, a good architect, will listen carefully to the opinions of each contributor, fine-tuning their vision with feedback from the team. This leads well onto the next point.

Being a developer

Making good architectural choices is a function of balancing an ideal target architectural state with the current state of a software system. As an example, there is no sense in adding a document database to a system if the problem domain is better suited for a relational database, even if that’s boring. An architect may feel tempted to impose technologies or architectural choices without considering the fit for the problem space – AKA behaviours of the “ivory tower architect.”

The best way an architect can mitigate this is by spending time with developers and time in the code. Understanding how the system has been built up, and the constraints of the system as it stands today will give the architect more information about the right choices for today’s environment.

Having a systems focus

Seasoned developers know that code is only one aspect to working software. To make code run, a seasoned developer understands there are other important quality attributes necessary for code to run well in its production environment. They consider aspects like deployment processes, automated testing, performance, security, and supportability. Where developers may approach these quality attributes ad hoc, an architect will focus on understanding not just the code but also the quality attributes necessary to meet the many needs of different stakeholders such as support, security, and operations staff.

The good architect focuses on finding solutions that can satisfy as many of these different stakeholder needs instead of choosing a tool or approach optimised for the preferences or style of a single contributor.

Thinking like an entrepreneur

All technology choices have costs and benefits, and a good architect will consider new technology choices from both perspectives. Successful entrepreneurs are willing to take risks, but seek ways to learn quickly and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short- and long-term costs and the likely benefits they will realise.

A good example is when the architect avoids committing to a new tool based on reading a new article, or having heard about it at a conference. Instead they seek to understand how relevant the tool is in their environment by running an architectural spike to gather more information. They don’t pick a tool based on how good the sales pitch is, but what value it offers, given what they need for their system. They also look for the hidden costs of tools such as how well is a tool supported (e.g. level of documentation, community adoption), how much lock-in the tool brings or the extra risks it introduces over the long-term.

Balancing strategic with tactical thinking

A lot of teams build their software reactively with individual developers choosing tools and technologies that they are most comfortable with, or have the most experience with.

The good architect keeps an eye out for what newer technologies, tools or approaches might be useful but does not necessarily draw upon them immediately. Technology adoption requires a considered approach looking at a long-term horizon. Architects will seek for a good balance between agility (allowing the team to move fast) and alignment (keeping enough consistency) at both a team and organisational level.

An exercise like the Build your own Tech Radar is a useful tool to explore technologies with strategy in mind.

Communicating well

Architects know that effective communication is a key skill for building trust and influencing people outside of the team. They know that different groups of people use different vocabulary and that using the technical terms and descriptions with business people makes communication more difficult. Instead of talking about patterns, tools and programming concepts, the architect uses words their audience will be familiar with. Communicating technical choices to business people with words like risk, return, costs, and benefits will serve an architect better than the words they use with their development team.

An architect also realises that communicating within the team is just as important as outside, and will use diagrams and group discussions to establish and refine the technical vision, and use a written log like an Architectural Decision Log or a wiki to provide a historical trail for future generations.

Conclusion

Doing the job of a well-rounded architect is not easy. There are so many elements to focus us, each drawing upon many skills that a developer often doesn’t focus on practicing. What is most important is not necessarily the ability an architect has, but that they have enough expertise in each of these different areas to be effective. An architect who is skillful in only one of these six areas described above will not be as effective as an architect who has a good level of expertise in all of them.

Making Change Stick

January 15, 2016 / / 0 Comments

A gym instructor told me yesterday that it was the day that most people statistically give up their new year’s resolution. Whether or not it is true, it got me thinking about what works when changing behaviours, whether individually or in an organizational context. What follows are some of my favourite approaches to making change stick.

1. Keep it small

In my experience, the bigger the change is, the more likely it is to fail because old habits come back, or the change hits too many barriers. A more significant change means less chance of success because it requires more time, energy and motivation to accomplish – all of which can easily run out.

Five years ago I was unsure about whether I could be a full-time vegetarian. Rather than commit to being full-time vegetarian, I kept it small by deciding to trial it for an entire month. In this time, I made myself experience as many activities I enjoy in the trial period (eating out, traveling) to work out being full-time would not suit me. In the end, I decided a 2-day per week vegetarian habit would work instead.

If you want to make a change, find smaller steps towards the end goal.

2. Build on an existing habit

I have a friend who gave up smoking but took up a running habit instead. After talking to him, I realised a lot of his success was described in the book, “The Power of Habit.” In this book, they describe how we often build responses to stimulus as rewards, which eventually becomes a habit. Our first approach to change is to simply stop the response but habits make that difficult because they are automatic.

The book explains that stopping the habitual response hard. However replacing the response with a different response can be a lot easier.

3. Keep it social

One of the many reasons fitness websites like Runkeeper want to connect you with your friends it that social pressure and acknowledgement from family and friends is a really powerful mechanism for instituting change. Websites like Runkeeper fail because they treat every connection the same, even though we have different types of relationships with people. Acts such as making a commitment to a group of close friends, or training regularly with the same group of people is great motivation to maintain a new change.

I saw this most recently when a bunch of friends and I signed up for a Tough Mudder. Before the event, a friend of mine didn’t regularly train. They knew the event would be a challenge so hired a personal trainer and went regularly several times a week. In the course of six months until the event, they built up the fitness, strength and skills required by Tough Mudder and finished it brilliantly.

4. Visualise the end state

One of the wonders of our human mind is our ability to influence the future simply through belief (or what’s commonly known as the Placebo Effect). In organisations and in personal coaching, I find the Futurespectives activities of the most powerful practices because it helps people imagine what the future state could be like.

All too often people fail at change because they focus too much on what is blocking them rather than focusing on what they can do to move towards this end state. An exercise I know used by a few friends is the Letter from the Future to visualise their desired end states.

5. Celebrate, celebrate, celebrate

With my experiences using appreciative inquiry, I have found that celebrating the small achievements for what is working is often a more powerful motivating factor than focusing on what didn’t work. It leads into a positively reinforcing loop that can establish new habits and make lasting change as pictured in the diagram below.

Cycle of celebration improving motivation

Conclusion

There are many other opportunities to make change stick I find that these five steps are the techniques and practices I draw upon the most. Books I have found useful on this topic include

What do you do to make change stick?

Book Review: Difficult Conversations

August 3, 2015 / / 1 Comment

Conflict, negotiation and difficult conversations are hard, but there are plenty of good books help. I often recommend Crucial Confrontations, Getting to Yes and Getting Past No. Someone recommended Difficult Conversations, a book that I recently finished reading.

Difficult Conversations

Difficult Conversations

Where the other books I read tended to take a more mechanistic view of steering the conversation, I really appreciated the slightly different take with this book, which I felt more humanistic because it acknowledged the emotional side to difficult conversations. The authors suggest that when we have a difficult conversation, we experience three simultaneous conversations:

  1. The “What Happened” Conversation
  2. The Feelings Conversation
  3. The Identity Conversation

The “What Happened” Conversation

We often assume we know what happened, because we know what we know (Our Story). The authors (rightly) point out, that our story may be completely different from the other person (Their Story). A good practical tip is to focus on building the Third Story as a way of building a shared awareness and appreciation of other data that may make a difference to the conversation

The Feelings Conversation

As much as we like to think we are logical, we are highly emotional and biased people. It’s what makes us human. We manifest this by saying things based on how we are feeling. Sometimes we don’t even know this is happening. The book helps us understand and gives us strategies for uncovering the feelings that we may be experiencing during the conversation. They also suggest building empathy with the other person by walking through the Feelings Conversation the other person will be having as well.

The Identity Conversation

I think this was the first time that I had thought about when we struggle to communicate, or agree on something, we may be doing so because have difficulty accepting something we may not like, or something that threatens our identity. This is what the authors call out as the Identity Conversation and is a natural part of successfully navigating a difficult conversation.

Conclusion

I found Difficult Conversations a really enjoyable read that added a few new perspectives to my toolkit. I appreciate their practical advice such as stepping through each of the three conversations from both your and the other person’s perspective and avoiding speaking in different modes. I like the fact that they address the emotional side to difficult conversations and give concrete ways of understanding and coping with them, instead of ignoring them or pushing them aside.

5 Tips for Accelerated Learning

July 16, 2015 / / 1 Comment

I spent all of last year in Berlin, where I focused on learning the German language. After years learning different programming languages like Java, C#, Javascript and Ruby (not to mention all the tools, frameworks and libraries) and several years training and teaching I figured I could “eat my own dog food” and apply what I learnt about learning to a real language.

Enter to Learn stone sign

Stone sign: Enter to Learn. Image take from flikr under the Creative Commons licence.

Since that year, I talked to numerous people impressed that I can speak fluent German after living in Berlin. They often ask me, how did I found my experience. This post is a good summary of what I found myself repeating. Firstly, if you really, really want to learn German, Berlin is probably not the best place since there are so many foreigners living there and the level of spoken English is ridiculously high. You can easily fall into hanging out with the English-speaking crowd, enjoy the city, and fail to pick up more than rudimentary German.

Although I have very specific tips for learning the German language, this is more focused on what helped me learn the most that I think applies to any subject.

1. Find different teachers

At the start of the year, I spent the first three months doing an immersive language course at the Goethe Institute. Over the two classes, I experienced four different teachers, each with their own style and emphasis on what is important to learn. Although I wished that I had spent less time with one of the teachers, I found their point of view was sometimes useful. Each teacher focused on different aspects and it made my learning all that richer.

Over the rest of the year, I found other avenues to teach me, guide me and give the feedback I needed to grow. If I had stuck with a single teacher, I would have missed out on a number of other valuable perspectives.

2. Have a goal, and keep focused on it

Unlike many European people, I was never bilingual as a child. Moving to England from Australia, I came to appreciate how useful a second language was by meeting many other bilingual people. Although I learned Japanese in school, I believe it is more important to have the ability to use it.As they say:

Use it, or lose it.

A whole year to learn a language was a once in a lifetime opportunity and my goal was to be fluent by the end of the year. I had a whole bunch of other personal reasons to learn German, but figured many things came into alignment and I would make the most of this opportunity.

I reminded myself throughout the year about my goal, and why it was important to me, and it helped me keep focus on the learning. It helped me in particular when the going got tough, and it will get tough!

3. Celebrate progress

After a year passed by, I met with some of my colleagues again who were impressed that I could now speak with them fluently in their native tongue. Although it’s easy to celebrate that final result, there were many times along the way that I wanted to give up because it was hard, and I felt frustrated that I felt like I wasn’t learning as fast I wanted to.

I was sharing a flat with a German, who knew that I was wanting to speak fluent German. Although he could speak English very well, he spoke only to me in German even if it would have been easier for him to communicate in English. I remember coming home one day, exasperatedly asking, “Can we just speak in English?!” His answer, “Nein!” (No, in German).

Although there were bad days, there were also good days and I made sure to sit back and acknowledge these small milestones, such as watching my first film in German with subtitles (and understanding most of it), completing my first German novel, and going to the Town Hall to register myself without speaking a word of English!

Each small step moves you towards your final goal, and celebrating progress will help you overcome the learning hurdles you experience along the way.

4. Vary your learning activities

One problem with a long-term learning goal, is that you will get bored and distracted. At the start of my year, I was naturally doing a lot of grammatical textbook exercises which was useful for the classroom. However I couldn’t see myself continuing to do just these exercises for the rest of the year. I wanted other ways to learn but would help me keep engaged. Therefore I combined learning German with other activities that I enjoyed, such as meeting with people (the German Stammtisch the language school organised was a good one), watching movies and reading books I liked in German (thanks library!), meeting with a tandem partner, and listening to the radio.

A friend gave me the book, “111 Orte in Berlin, die man gesehen haben muss” which roughly translates to, “111 must see places in Berlin.” The book has two pages for each place, one with a short description and the other with a picture and was perfect for dipping in and out. I could read about a place I wanted to visit, and because I lived in Berlin, could go and see what it was talking about. At the same time, it helped me deepen my vocabulary and help me experience the unique experiences Berlin had of offer.

Later in the year, I spent some time traveling around in Germany, where I did a number of tours in German. Each of these experiences kept the learning alive for me and I never grew bored about “learning German” because I was doing it at the same time as I was doing other activities I was enjoying.

5. Accept you’ll never be perfect

Early on in my career, I discovered the idea of the Beginner’s Mind (Shoshin). For me, part of this accepts that I do not, and cannot know everything and that means there are new things to learn. In learning German, I found that my vocabulary will never be as rich as it is in English because there are situations I have never found myself in.

A good example of this was talking to a friend of mine when we first worked in a German-speaking office. She told me this story:

Although I studied German at school and was very fluent, I was shocked the first time that I was running a project kickoff for a German-speaking client. Not only was I learning new German words for the domain (transportation) but I was also learning new German words for technology terms I had taken for granted.

Our experiences shape who we are, and we cannot possibly be experts at everything, and that’s perfectly fine. I found it was more productive to focus on getting better than worrying about how close to mastery I was.

Conclusion

After years of coaching, teaching and training technology, I have many techniques that I consider useful as learning strategies. I found last year was a great opportunity to try applying some of them to a completely different skill and see how far I could go. Happily, it seemed to have worked.

I hope you found this article useful and that you will find these tips above useful. In summary, try to:

  1. Find different teachers
  2. Have a goal, and keep focused on it
  3. Celebrate progress
  4. Vary your learning activities
  5. Accept you’ll never be perfect

What other learning strategies do you find work for you?

« Older posts

© 2024 patkua@work

Theme by Anders Noren — Up ↑