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.
I’m proud that many people are actively addresing diversity issues. Research shows that diversity leads to better problem solving and often, more creative solutions. Unfortunately the results of history lead us to where we are today, but we can always do better. I’m proud to be part of ThoughtWorks, where we are also trying to do our part to address diversity issues, and our work was recently recognised as a great company for Women in Tech. And yes, I do realise that diversity goes beyond just gender diversity.
As a fairly regular conference speaker this year, I have been disappointed by some of the actions of both conference organisers and speakers that have been, in my opinion, rather unhelpful.
At a conference speaker’s dinner earlier in the year, the topic of diversity came up where someone calculated that only 4 out of almost 60 speakers were women. I was truly disappointed when one of the conference organisers responded with, “That’s just the industry ratio isn’t it? It’s just too hard to find women speakers.” Of course not all conference organisers have this attitude, such as The Lead Dev conference which ended up with 50% women:men speaker ratio or like Flowcon which achieved a >40% ratio women:men as well. Jez Humblewrites about his experiences achieving this goal (recommended reading for conference organisers).
At another conference, I saw a slide tweeted from a talk that looked like this below (Note: I’ve found the original and applied my own label to the slide)
My first thoughts went something like: “Why do all the developers look like men and why do all the testers look like women?” I was glad to see some other tweets mention this, which I’m hoping that the speaker saw.
We all have responsibilities when we speak
I believe that if you hold talks at a conference, you have a responsibility to stop reinforcing stereotypes, and start doing something, even if it’s a little thing like removing gendered stereotypes. Be aware of the imagery that you use, and avoid words that might reinforce minority groups feeling even more like a minority in tech. If you don’t know where to start, think about taking some training about what the key issues are.
What you can do if you’re a speaker
As a speaker you can:
Review your slides for stereotypes and see if you can use alternative imagery to get your message across.
Find someone who can give you feedback on words you say (I am still trying to train myself out of using the “guys” word when I mean people and everyone).
Give your time (mentoring, advice and encouragement) to people who stand out as different so they can act like role models in the future.
Give feedback to conferences and other speakers when you see something that’s inappropriate. More likely than not, people are more unaware of what other message people might see/hear, and a good presenter will care about getting their real message across more effectively.
What to do if you’re a conference organiser
I’ve seen many great practices that conferences use to support diversity. These include:
Having a code of conduct.
Look actively for more diverse communities and encourage them to apply for talks.
Consider removing names from submissions to prevent gender bias during reivews.
Provide sponsorships, discounts or special diversity tickets to encourage people from minority groups to attend.
One thing that I have yet to experience, but would like as a speaker is a review service where I could send some version of slides/notes (there is always tweaking) and get some feedback about whether the imagery/words or message I intend to use might make the minorities feel even more like a minority.
Brain Rules: 12 Principles for Surviving and Thriving at Work, Home and School by John Medina – A description of rules with how our brain works and how we learn. Our visual senses tend to trump our sense of smell. We need sleep to restore our energy and to help us concentrate. Spaced repetition is important, but assigning meaning to new words and concepts are also important to learning. Since I’m fascinated with learning and how the brain works, I’ll add this to my reading list.
Getting Things Done: The Art of Stress-free Productivity by
David Allen – Although I never read the book, I felt like I follow a similarly described organisation system. The GTD method is almost like a cult, but requires a lot of discipline for it. Unlike keeping a single list of things to do, they have a systemised variant for keeping long-lived projects and ways of managing tasks to help you focus on getting through actions. Probably a good book if you want to focus more on breaking things done into smaller steps.
The Checklist Manifesto: How to Get Things Right by Atul Gawande – With lots of examples from the healthcare industry, a reminder that useful checklists can help us avoid making simple mistakes. For me, the idea of standardised work (a lean concept) already covers this. I agree with this idea in principle, but I’m not so sure the book covers the negative side effects of checklists as well (people getting lazy) or alternatives to checklist (automation and designing against error/failure demand to be begin with).
Start With Why: How Great Leaders Inspire Everyone To Take Action by Simon Sinek – A nice summary of leadership styles and rather than focusing on how something should be done, and the what, is starting with the why. I liked the explanation of the Golden Circle with three concentric circles draw within each other, with the Why being the starting point that leads to the How that ends in the What. It’s a good reminder about effective delegation and how powerful the Why motivator can be. I’ve added this book to my reading list to.
I recently moderated a panel in our London ThoughtWorks office aimed at developers leading technnical teams as a follow up from the Lead Developer conference.
Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.
This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.
Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.
The panelists shared their experiences around situations like:
Having a tough conversation with a team member or customer;
Sharing how they have dealt with overtime (weekends, later work);
How they resolved a technical disagreement within a team; and
Handling a particularly aggressive person, or being aggressively threatened;
The audience also threw in a few questions like:
Dealing with office politics;
Finding access to key influencers/stakeholders;
Where you draw the line with a person on a team; and
Dealing with a technical stakeholder who is too involved, because they seem to have too much time;
We also had some great sound bites in relation to the topics being discussed.
I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.
Earlier this week, I ran a workshop at the first ever Agile Europe conference organised by the Agile Alliance in Gdansk, Poland. As described in the abstract:
Architects and architecture are often considered dirty words in the agile world, yet the Architect role and architectural thinking are essential amplifiers for technical excellence, which enable software agility.
In this workshop, we will explore different ways that teams achieve Technical Excellence and explore different tools and approaches that Architects use to successfully influence Technical Excellence.
During the workshop, the participants explored:
What are some examples of Technical Excellence?
How does one define Technical Excellence?
Explored the role of the Architect in agile environments
Understood the broader responsibilities of an Architect working in agile environments
Focused on specific behaviours and responsibilities of an Architect that help/hinder Technical Excellence
What follows are the results of the collective experiences of the workshop participants during Agile Europe 2016.
A set of coding conventions & standards that are shared, discussed, abided by by the team
Introducing more formal code reviews worked wonders, code quality enabled by code reviews, user testing and coding standards, Peer code review process
Software modeling with UML
First time we’ve used in memory search index to solve severe performance RDBMS problems
If scrum is used, a good technical Definition of Done (DoD) is visible and applied
Shared APIs for internal and external consumers
Introducing ‘no estimates’ approach and delivering software/features well enough to be allowed to continue with it
Microservice architecture with docker
Listening to others (not! my idea is the best)
Keeping a project/software alive and used in prod through excellence customer support (most exclusively)
“The art must not suffer” as attitude in the team
Dev engineering into requirements
Problems clearly and explicitly reported (e.g. Toyota)
Using most recent libraries and ability to upgrade
Right tools for the job
Frequent availability of “something” working (like a daily build that may be incomplete functionality, but in principle works)
Specification by example
Setting up technical environment for new software, new team members quickly introduced to the project (clean, straightforward set up)
Conscious pursuit of Technical Excellence by the team through this being discussed in retros and elsewhere
Driver for a device executed on the device
Continuous learning (discover new tech), methodologies
Automatic deployment, DevOps tools use CI, CD, UT with TDD methodology, First implementation of CD in 2011 in the project I worked on, Multi-layered CI grid, CI env for all services, Continuous Integration and Delivery (daily use tools to support them), Continuous Integration, great CI
Measure quality (static analysis, test coverage), static code analysis integrated into IDE
Fail fast approach, feedback loop
Shader stats (statistical approach to compiler efficiency)
Lock less multithreaded scheduling algorithm
Heuristic algorithm for multi threaded attributes deduction
It is easy to extend the product without modifying everything, modularity of codebase
Learn how to use something complex (in depth)
Reuse over reinvention/reengineering
Ability to predict how a given solution will work/consequences
Good work with small effort (efficiency)
Simple design over all in one, it’s simple to understand what that technology really does, architecture of the product fits on whiteboard 🙂
Systems’ architecture matches team/org structure
Ideally separated tests, Automated performance testing, automatic front end functional testing with selenium, unit testing done for the first time 10 years ago, constructing new performance testing cases takes minutes, after refactoring unit tests are passing (majority of them – hopefully all!)
Constant curiosity for new technologies/approaches
Good knowledge of software patterns (when to use and when not)
Learn from mistakes
Definition of Technical Excellence
(Technical) Excellence is an attitude to be better than yesterday
Technical Excellence is the holy grail that inspires teams to stay on the path of continued improvement
Technical Excellence is a process that continuously improves product design and the development team. Examples: Automation, knowledge sharing, culture. Synonyms: Dream
Technical Excellence is an ability to consciously apply tools and practices to solve and continuously improve over complex problems in a sustainable way and within constraints (e.g. time and money). Examples: Continuous Delivery
Activities of an architect
Able to choose the right solution amongst many possibilities (awareness of consequences and limitations)
Being able to justify technical decisions made
Thinking (find time to think about the product, structure, technologies used, etc)
Helps resolve interdependencies, helps to identify/minimise external noise (i.e. technical dependency change with negative impact), co-ordination of integration with other teams working on the same project
Start and moderate discussions on design, longer term consequences of decisions, etc
Requirements definition, making sure ‘nothing’ is omitted during analysis/design
Questions decisions to encourage thinking about wider picture amongst developers, asks questions (non obvious especially), Asking difficult questions about work being done
Listens to others
Encourage people to bring ideas, encourage idea sharing
Setup backlog for achieving technical excellence
Challenge old decisions
Business decision support (IT, 3rd party)
Make sure we don’t bite more than we can chew – incrementally/iterative
Ensure architecture is visible, understood and accessible to the team, keep the technical cohesion, helps team consider the bigger picture and interdependencies, helps team define the system and diagram it
Detailed knowledge of technologies/protocols used
Proposes solutions to complex problems
Wide view of situation/projects, look what other teams are building for things to reuse or interface to
“Main” test scenarios definition
Definition of components structure and interactions
Guard technical vision (dialogue with stakeholders)
Focus on project goal
Verification of current design vs planned use
Ad hoc just in time consulting to feature teams when things get complex
Teaching teams, sharing technical knowledge (and expertise) with the team
Coaches team. Gets buy-in from the team for change they are about to trigger, coaches dev team
Identifies technical skillset gaps in the team
Mitigates the risks
Out of box ideas
Research for solution, helps team identify areas for experimenting, exploring new territories
Creating proof of concept (POC)
Learns new things, research and try new tools, ideas, technologies, etc
Gains an in-depth understanding of a system before attempting to change it
Reviews teams’ system design, performs code reviews and coding standard support, reviews code
Behaviours that support Technical Excellence
Gives team rapid and timely feedback
Patiently explaining all the tiny details responding to simple questions
Be there whenever needed
be the safety net whenever devs need you
Set communication for knowledge sharing
Explain the reasons behind the design
Raising the visibility of good developers
Do pair programming, works with the team
Explain technical excellence value for business
Encourage team to think and work towards Technical Excellence
Growing people, mentoring developers to improve tech skills, training the team, educate actively – organise coding dojos, etc
Set up backlog for achieving Technical Excellence
Raising the team spirit and motivation
Waking up with 3am to connect with a team on a daily basis (for a distributed team)
Discussing discovered problems with the team
Sat down with the team to teach and record architecture training for future use
Keeping an eye on new things on the market and bringing them to the team
Staying current in technologies, tools, concepts, etc.
Being a visible role model in terms of pursuing Technical Excellence
Support team in collaboration with other teams
Helps team identify blindspots
ability to change contexts between projects
Lets the team make decisions
Take a step back and make room for technical advancements of the whole team
Not doing stuff from actively discourage column
Team makes decisions
Behaviours that discourage Technical Excellence
Dictatorship, have to do it my way, will to control (every small detail)
Blaming and shaming
Making arbitrary decisions, especially without explaining the reasoning behind it
Rejecting too complex C++ code
Using ambiguous, complex, uncertain English vocabulary
Shutting down emergent ideas from the team
Discouraging ideas “I couldn’t care less about your sophisticated C++ SPT initialisation”
Created ugly prototype for a demo and forced team to clean up afterwards
Imposing BDUF (Big Design Up Front) over the development team
Created non-viable design (i.e. could not be implemented with current constraints)
Enforcing old known technologies, etc out of inertia/ignorance, sticking to the “old ways”
Doing too many activities to follow through – not focused on any (and no time to encourage Technical Excellence)
I’ve been at ThoughtWorks for 12 years. Who would have imagined? Instead of writing about my reflections on the past year, I thought I would do something different and post twelve key learnings and observations looking back over my career. I have chosen twelve, not because there are only twelve, but because it fits well with the theme of twelve years.
1. Tools don’t replace thinking
In my years of consulting and working with many organisations and managers I have seen a common approach to fixing problems, where a manager believes a tool will “solve” the given problem. This can be successful where a problem area is very well understood, unlikely to have many exceptions and everyone acts in the same manner. Unfortunately this doesn’t reflect many real-world problems.
Too many times I have witnessed managers implement an organisational-wide tool that is locked down to a specific way of working. The tool fails to solve the problem, and actually blocks real work from getting done. Tools should be there to aid, to help prevent known errors and to help us remember repeated tasks, not to replace thinking.
2. Agile “transformations” rarely work unless the management group understand its values
Many managers make the mistake that only the people close to the work need to “adopt agile” when other parts of the organisation need to change at the same time. Co-ordinating this in enterprises takes a lot of time and skill with a focus on synchronising change at different levels of the organisation.
Organisations who adopt agile in only one part of their organisation face a real threat. As the old saying goes, “Change your organisation, or change your organisation.”
3. Safety is required for learning
Learning necessitates the making of mistakes. In the Dreyfus model, this means that particularly people in an Advanced Beginner stage, need to make mistakes in order to learn. People won’t risk making mistakes if they feel they will do a bad job, lose respect from their colleagues or potentially hurt other people in that process.
As a person passionate about teaching and learning, I find ways to create a safe space for people to fail, and in doing so, make the essential mistakes they need to properly learn.
4. Everyone can be a leader
I have written about this topic before, but it is such an important observation. I see a common mental model trap where people feel the need to be given the role of a leader, in order to act like a leader. People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it.
5. Architects make the best decisions when they code
In the Tech Lead courses I run, I advocate for Tech Leads to spend at least 30% of their time coding. Spending time with the code helps build trust, respect and a current understanding of the system. Making architectural decisions without regard for the constraints of the current system are often bad decisions.
6. Courage is required for change
I miss people talking about the XP values, one of which includes Courage. Courage is required for acts of leadership, taking on the risk to fail and the risk/reward of attempting something new. Where there is no risk, there is often little reward.
7. Congruence is essential for building trust
Beware of the old age maxim, “Do as I say, not as a I do.” In reality, regardless of what you say, people will remember how you act, first and foremost. Acting congruently is making sure that your actions follow your words. Acting incongruently destroys trust. Saying “no” or “not now” is better than promising to do something by a certain time, only to not deliver it.
8. Successful pair programming correlates with good collaboration
Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict.
I consider (navigable) conflict a healthy sign of collaborative teams. Deferring feedback, such as is the case with code reviews on long-lived branches tends to lead to more resentment because it is delivered so late.
9. Multi model thinking leads to more powerful outcomes
One of my favourite subjects at University, was Introduction to Philosophy where we spent each week in the semester studying a different philosopher. Over the course of my career, I have come to appreciate the value of diversity, and to see a problem through multiple lenses. Systems thinking also recognises that facts can be interpreted in different ways, leading to newer ideas or solutions which may be combined for greater effect.
10. Appreciate that everyone has different strengths
Everyone is unique, each with their own set of strengths and weaknesses. Although we tend to seek like-minded people, teams are better off with a broader set of strengths. A strength in one area may be a weakness in a certain context, and teams are stronger when they have a broader set of strengths. Differences in strengths can lead to conflict but healthy teams appreciate the differences that people bring, rather than resent people for them.
11. Learning is a lifelong skill
The world constantly changes around us and there are always opportunities to learn some new skill, technique or tool. We can even learn to get better at learning and there are many books like Apprenticeship Patterns and The First 20 Hours which can give you techniques to get better at this.
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.
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
It’s the end of yet another year and a great time to reflect and put your Personal Retrospective hats on. I mention using Personal Retrospectives in my book, “The Retrospective Handbook: A guide for agile teams” because I find them powerful tools to celebrate the past year and to establish new goals for a new year.
This year, instead of simply stepping through questions on paper or on the computer, I decided to use sticky notes and activities I would use with a larger group. In order to keep flow, I wanted to prepare appropriately. This meant I:
Made a plan for the exercises I wanted to run;
Prepared the activities in advance so I could focus on gathering data/generating insights and reflecting instead of thinking about the process;
Had a set of questions prepared in case I got stuck;
Had water and coffee ready so I didn’t need to leave the room.
Here are the activities I used this year and that you might find useful for your own Personal Retrospective.
A year in tweets
Using very small stickies to simulate the 140 character limit (I’m guessing I had ~50) trying to generate a number of small tweets about how I felt about 2015.
Generating a timeline of events
I find the timeline a very powerful way to reflect on the year’s events, and to celebrate their significance. I first brainstormed memorable events before I attempted to nest them into the timeline. I the checked my personal and work calendars, realising that the human memory (or maybe it’s just mine!) is quite bad at remembering the order of events.
Constructing the timeline took the most time of all exercises. Partly because there were lots of significant events for me, and I wanted to appreciate how much had occurred in this year.
4 L’s (Liked, Loved, Lacked, Longed For
I don’t normally use the 4 L’s exercise but figured I would give it a go. It seemed to work well in terms of framing insights but I found I needed to reflect deeper in some of the initial ideas I wrote up. Having an independent coach/facilitator would have been useful but I had to play this role myself.
Goals for 2016
After looking back at the timeline, and reflecting on how the events made me feel and what impact they had, I brainstormed some goals for this year. My focus for this first round was to generate all possible goals I might have, even though these long term goals would not meet the SMART criteria.
In the second round, I went through each of the different goals, generating some concrete next steps to move me towards each of those goals. My intention is to revisit the goals throughout the year and to take other actions to progress them further. The orange-coloured stickies in the picture below represet these next steps linked to the relevant goals (in green).
I also spent the time digitising the outputs into a A3 Personal Retrospective report and have made the template available here if you want to print it instead.
Have you set aside time to reflect on 2015? How did you run your Personal Retrospective? Leave a comment and let me know.
With a one-time only opportunity this year, I am running a course for Architects and Tech Leads on 22-23 October at the ThoughtWorks Sydney offices. After interviewing over 35 Tech Leads for the Talking with Tech Leads book, I recognised there is a gap about teaching developers the special leadership skills a successful Architect and Tech Lead demands. The class size is really limited, so reserve yourself a place while you can.
In this very hands-on and discussion-based course, participants will cover a wide breadth of topics including understanding what a Tech Lead is responsible for, the technical aspects a developers rarely experiences and is not accountable for, and the difficult people-oriented side to the role including influencing, relationship building and tools for better understanding your team.
This is a two-day course that will quickly pay back dividends in accelerating you on your path or further developing your Tech Lead skills as developers. Register here on eventbrite for the course 22-23 October.
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.
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:
Find different teachers
Have a goal, and keep focused on it
Vary your learning activities
Accept you’ll never be perfect
What other learning strategies do you find work for you?