patkua@work

The intersection of technology and leadership

Page 10 of 53

A Tech Lead Paradox: Consistency vs Improvement

November 17, 2014 / / 3 Comments

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Consistency versus Improvement.

The case for consistency

Code is easier to understand, maintain and modify when it is consistent. It is so important, that there is a wiki page on the topic and the 1999 classic programming book, The Pragmatic Programmer: From Journeyman to Master had a chapter titled, “The Evils of Duplication.” Martin Fowler wrote about similar code smells, calling them “Divergent Change” and “Shotgun Surgery” in his Refactoring book.

Consistency ultimately helps other developers (or even your future-self) change code with less mental burden figuring out of there will be unwanted side-effects.

The case for improvement

Many developers want to use the latest and greatest tool, framework or programming language. Some examples: Java instead of C/C++, Python/Ruby instead of Java, JavaScript (Node) instead of Python/Ruby and then Clojure in place of JavaScript. The newest and latest technologies promise increased productivity, fewer bugs and more effective software development. Something that we all want. They promise the ability to accomplish something with fewer lines of code, or a simpler, clearer way to write something.

The conflict

Software is meant to be soft. Software is meant to be changed. A successful codebase will evolve over time, but the more features and changes a codebase has, the harder it becomes to add something new without making the codebase inconsistent. When a new technology is added to the mix, there is suddenly two ways of accomplishing the same thing. Multiple this over time and number of transitions, and a codebase suddenly has eight different ways of accomplishing

Transitioning everything to a new technology is a function takes time. Making a change to an old part of the system is a gamble. Leaving the codebase as it is makes potentially new change in this area hard. That new change may never happen. Migrating everything over has the risk of introducing unwanted side-effects and taking time that may never be worth it.

To the developer wanting the new technology, the change appears easy. To those who have to follow up with change (i.e. other team members or future team members) it may not be so clear. Making it consistent takes time away from developing functionality. Business stakeholders want (understandably) justification.

Phil Calçado (@pcalcado) tweeted about this paradox:

As a dev, I love going for the shiny language. As a manager, I want a mature ecosystem and heaps of bibliography on how to write decent apps

What does a Tech Lead do?

Tech Leads ride the paradox by encouraging improvement and continually seeking consistency. But how? Below I provide you with a number of possible solutions.

Use Spike Solutions

Spikes are a time-boxed XP activity to provide an answer to a simple question. Tech Leads can encourage spike solutions to explore whether or not a new technology provides the foreseeable benefit.

Improvement spikes are usually written stand-alone – either in a branch or on a separate codebase. They are written with the goal of learning something as fast as possible, without worrying about writing maintainable code. When the spike is over, the spike solution should be thrown away.

Spikes provide many benefits over discussion because a prototype better demonstrates the benefits and problems given a particular codebase and problem domain. The spike solution provides a cheap way to experiment before committing to a particular direction.

Build a shared roadmap

Improvements are easy to make to a small, young codebase. Everything is easily refactored to design a new tool/technology. It’s the larger longer-lived codebases that are more difficult to change because more has been built up on the foundations that must be changed.

A Tech Lead establishes a shared understanding with the team of what “good” looks like. Specifically, which tool/technology should be used for new changes. They keep track of older instances, looking to transition them across where possible (and where it makes sense).

Techniques like the Mikado Method are indispensable for tackling problems that eating away at the bigger problem.

Playback the history

A new developer sees five different ways of doing the same thing. What do they do? A Tech Lead pre-empts this problem by recounting the story of how change was introduced, what was tried when and what the current preferred way of doing things are.

Ideally the Tech Lead avoids having five different ways of accomplishing the same thing, but when not possible, they provide a clear way ahead.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

How do I still write code as a Tech Lead?

November 11, 2014 / / 8 Comments

I have previously suggested that effective Tech Leads spend an ideal minimum of 30% of their time writing code. A common question I hear in the Tech Lead training course I run is:

Where do I find the time to code when I have all these other responsibilities to take care of?

I know that many Tech Leads struggle to find the right amount of code, and also struggle to know what sort of tasks to take on. Here are some useful bits of advice that have helped me and others:

Avoid working on critical path items

Although Gantt charts have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path. A Tech Lead will usually find themselves interrupted and finding a solid block of coding time will be unusual. As a guideline, I advise Tech Leads not to focus on critical path tasks because they will often block progress on those tasks.

If a critical path item requires knowledge or experience, that only the Tech Lead has, it is useful to work with another developer on the task, so that progress continues when the Tech Lead works on responsibilities.

Learn to delegate

Delegating is a skill that Tech Leads must develop, and a skill that developers rarely have an opportunity to build. The Situational Leadership Model clearly explains when to delegate. Effective delegation depends on the skill and motivation of an individual. The model explains four modes: Telling, Selling, Participating, Delegating with the end goal of aiming to delegate as much as possible.

Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task.

A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.

Loosely pair program

I’m not a big believer in full time pair-programming. But finding the right balance between full-time and nothing is hard to achieve. A good arrangement is to work with someone on the approach or design for a particular problem, and then to do regular reviews (or short pair-programming sessions) to see what new information or challenges emerge as code is written.

This style of “co-working” on the design and code works well for a Tech Lead, who will find themselves constantly interrupted.

Avoid unnecessary or poorly run meetings

There is nothing worse for a programmer to sit in a meeting which has no purpose or no outcome. These are frustrating because the time spent in the meeting is waste. Learn how to run effective meetings, to avoid the frustrations of ineffective meetings.

Use the “5 P’s of Effective Meetings” model:

  • Purpose – Is it clear what the meeting is for? Ensure each meeting has one clear purpose. Examples include: Distributing information, gathering information, brainstorming solutions, and seeking agreement or consensus.
  • Product – You can cut a meeting short, when you know what the outcome of that meeting should be. Define success criteria for the meeting (which will be related to purpose) to keep meetings focused and on track.
  • Participants – It is better to cancel/reschedule a meeting than to hold a meeting with the wrong people. This tweet from Esther Derby summarises it very well. Pointless Meetings
  • Probable Issues – What are the concerns or questions that will be raised during the meeting that need to be addressed, or threaten to derail the meeting?
  • Process – Every meeting should be clear about how the meeting will be run, how people are expected to participate, and special rules of what might need to be done. A meeting facilitator should start with clarifying the purpose of the meeting to reset people’s expectations.

Learn to say no

The art of leadership is saying no, not saying yes. It is very easy to say yes. — Tony Blair

As a Tech Lead, you will be pressured to always take on more than you can possibly take on. The more activities you say yes to, the less time a Tech Lead has to code. If coding is really important to you (and it should be), then you need to develop an awareness of what things are really important and those that can be done by others or by non-technical people.

Block out coding time

I know some Tech Leads who block out calendar time in their diary on a regular basis to ensure that they have uninterrupted time to code. Developers know how interruptions break the train of thought and Tech Leads will find themselves even more interrupted in comparison to developers.

Conclusion

It is important a Tech Lead spends time writing code but the other responsibilities demand time away. Keeping the balance right is tricky, but the techniques described above can help you cutting code. Please leave a comment if you have other suggestions.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

The Definition of a Tech Lead

November 3, 2014 / / 22 Comments

There are many names for leadership roles in software development such as Senior Developer, Architect, Technical Lead, Team Lead, and Engineering Manager. These are just a few. To me, the Technical Leader (Tech Lead) plays an unique and essential role that others cannot.

The Definition

The Short: A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.

Tech Lead

The Long: Leading a development team is no easy task. An effective Tech Lead establishes a technical vision with the development team and works with developers to turn it into reality. Along the way, a Tech Lead takes on traits that other roles may have, such as a Team Lead, Architect or Software Engineering Manager but they remain hands-on with code.

To make the most effective choices and to maintain trust and empathy with developers, a Tech Lead must code. In “The Geek’s Guide to Leading Teams” presentation, I talked about an ideal minimum time of about 30%.

Effective Tech Leads Code
An extract from the The Geek’s Guide to Leading Teams presentation

Not just a Team Lead

Early in my career, I worked on a team that had both a Tech Lead and a Team Lead. The Team Lead didn’t have much of a technical background and had a strong focus on the people side and tracking of tasks. They would have 1-to-1s with people on the team, and co-ordinate with outside stakeholders to schedule meetings that didn’t interrupt development time where possible.

The Team and Tech Lead

While the Team Lead focused on general team issues, the Tech Lead focused on technical matters that affected more than just one developer. They stepped in on heated technical debates, and worked with outside stakeholders to define technical options and agree on solutions for future streams of work. They wrote code with the other developers and sometimes called for development “huddles” to agree on a direction.

More hands-on than an Engineering Manager

You manage things, you lead people – Grace Hopper

Any reasonably-sized IT organisation has an Engineering Manager. They are responsible for more than one development, and have tasks that include:

  • Maintaining a productive working environment for development teams.
  • Acquiring appropriate budget for development to support business goals.
  • Representing the technology perspective on a management or board level.
  • Establishes and/or co-ordinates programmes of work (delivered through development).
  • Responsible for overall IT headcount.

Engineering Manager

Depending on the size of an organisation, an Engineering Manager may also be called a Chief Technical Officer (CTO) or Chief Information Officer (CIO) or Head of Software Development.

Although an Engineering Manager represents technology, they are often very far-removed from a development team and rarely code. In contrast, a Tech Lead sits with developers, very much focused on moving them towards their goal. They work to resolve technical disputes, and are watchful of technical decisions that have long-term consequences. A Tech Lead works closely with the Engineering Manager to build an ideal work environment.

A good Architect looks like a Tech Lead

The Architect role ensures overall application architecture suitably fits the business problem, for now and for the future. In some organisations, Architects work with the team to establish and validate their understanding of architecture. A suitable amount of standardisation helps productivity. Too much standardisation kills innovation.

Some organisations have the “Ivory Tower Architect” who swoops in to consult, standardise and document. They float from team-to-team, start new software projects, and rarely follow up to see the result of their initial architectural vision.

An effective Architect looks like a good Tech Lead. They establish a common understanding of what the team is aiming for, and make adjustments as the team learns more about the problem and the technology chosen to solve it.

What is a Tech Lead responsible for?

You may ask yourselves, what exactly does a Tech Lead do, or what are they accountable and responsible for? I’ve actually already addressed that in this article about the Tech Lead’s Circles of Responsibilities.

What is a Tech lead again?

A successful Tech Lead takes on responsibilities that sit with roles such as the Team Lead, the Architect and the Engineering Manager. They bring a unique blend of leadership and management skills applied in a technical context with a team of developers. The Tech Lead steers a team towards a common technical vision, writing code at least 30% of the time.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Update from Sep 2018: Short definition from “A Tech Lead is a developer who is responsible for leading a development team” to “A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.”

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

On Leadership and Being a Lead

October 27, 2014 / / 0 Comments

Henry, the “Developer”

I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.

Although Henry was just a “Developer”, he lead the team in a number of ways.

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

You don’t need to be a “Lead”

My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.

A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:

Thinking and doing something for the benefit of the team without being told to do so.

There are, of course, many other attributes to being a leader, but that is a separate post.

A Lead without leadership

You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.

Great leaders encourage leadership

Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.

Action is not the same as a title

Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.

If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

The featured image is shared from Flickr under the Creative Commons licence.

From Flickr (https://www.flickr.com/photos/susivinh/7019888809) under the CC licence

Book Recommendations for a Tech Lead

October 24, 2014 / / 3 Comments

I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.

Dealing with people

Tech Leads are leaders for an engineering/development team and will need to learn the right skills to deal with the unusual world of people. People are different, unique and have their own styles which may or may not align with your own.

Leading Snowflakes Leading Snowflakes is a good e-book, aimed at Engineering Managers who need to deal with different situations. Although it goes beyond just the people aspects, it is still a good book that focuses more on the people side.

Managing Humans Managing Humans (3rd Edition) is written by Rands & Repose author, Michael Lopp. It’s a humuour collection of stories describing the weird and wonderful world an Engineering Manager may find themselves facing. Most, although not all, of the stories will be relevant for Tech Leads. Thanks to Alex for this book recommendation.

Turn the ship aroundTurn the Ship Around is a great leadership story that talks about how leaders should be enabling other leaders using an example story of how a certain leadership style turned around one of the world performing US navy ships into one of the best. Thanks to Joe for this book recommendation.

Negotiation

A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.

Getting To YesGetting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation. Thanks to Jo for this book reommendation.

Getting Past NoGetting Past No (Fisher) is the sequel to the book above that describes getting through more difficult conversations. Jason Yip recommended this book.

Crucial ConversationsCrucial Conversations is a great book talking about how to have conversations when the stakes are high. They also have another great book called Crucical Confrontations that shows you how to have those difficult conversations that matter. Thanks to Clay for this book recommendation.

Facilitation

Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.

The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.

The Skilled FaciliatorThe Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.

Facilitator's Guide to Participatory Decision MakingFacilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.

Collaboration ExplainedCollaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.

http://amzn.to/1wzIYHDSecrets of Facilitation (Wilkinson) is a book recommended by Jason Yip.

Risk Management

With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.

Waltzing with BearsWaltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.

The Failure Of Risk Management
The Failure of Risk Management (Hubbard) is another book recommendation from Jason Yip. Now added to my reading list as it’s one I haven’t yet read.

Not just for Tech Leads

Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Do we need a Tech Lead?

October 21, 2014 / / 5 Comments

A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.

Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.

Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.

Tabs Spaces
Image take from Emacswiki

The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.

Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.

When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Top 5 Mistakes for First Time Tech Leads

October 16, 2014 / / 3 Comments

1. Spending too much time writing code

Old habits die hard. When a developer suddenly steps into the Tech Lead role, it is not immediately clear what to do differently. Instead of taking on the Tech Lead responsibilities, they stay heads-down writing code. The more code they write, the better they feel that they are still contributing to the team. Other Tech Lead responsibilities are neglected in favour of writing code, even though they must still be fulfilled. A Tech Lead must spend enough time on non-coding responsibilities. They must ensure a Technical Vision exists, and the development team are working together towards the same goal. Both of these activities require more than just code-writing.

2. Not spending enough time writing code

The “Tech” in the Tech Lead role is there for a reason. It is too easy for a Tech Lead to sit in endless meetings instead of spending time with the team. They lose awareness of how the code is evolving and which patterns or anti-patterns emerge. Without an up-to-date awareness of the system and its technical constraints, a Tech Lead cannot effectively lead the team. A Tech Lead who codes has a better understanding of technical problems or opportunities whilst building and maintaining trust with developers. Writing code keeps the “Post Technical” label away.

3. Making all the technical decisions

The first time Tech Lead may feel compelled to make all decisions. To compensate for writing less code, or to demonstrate their new role, they give input to any and all decisions. Unfortunately this behaviour discourages the team from making contributions. It sends the message to the team they should do what they are told, or not think, even though a team member has the better solution to a particular problem. An effective Tech Lead knows when to give input, knows when to make decisions and when to step back and allow the team to take more ownership.

4. Talking only Tech

A Tech Lead interacts with many people who sit outside of the development team such as people from marketing, finance or a product division. These people usually have very limited technical knowledge. Talking to them in terms of frameworks, libraries and tools adds confusion, frustration and simultaneously signals a lack of empathy. A Tech Lead must find a way to communicate ideas in ways non-technical people can understand such as using analogies and using terms others can easily relate to.

5. Constantly reacting

A new Tech Lead will find themselves juggling several activities at once. The bane of a developer, interruptions, becomes an everyday occurrence. A first time Tech Lead can simply react to the loudest or most alarming situation, even if it is not the most important. Over time, the Tech Lead develops better time and task management skills in order to manage the many demands.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Talking with Tech Leads

September 25, 2014 / / 1 Comment

I am proud to announce the release of my latest book, “Talking with Tech Leads” that is now available on Leanpub.

I started this book project over a couple of years ago when I discovered a lack of resources for helping developers transition into a role which demanded more than good development skills.

Talking with Tech Leads

Book Description: A book for Tech Leads, from Tech Leads. Discover how more than 35 Tech Leads find the delicate balance between the technical and non-technical worlds. Discover the challenges a Tech Lead faces and how to overcome them. You may be surprised by the lessons they have to share.

Buy it here on Leanpub.

Booklist from the Retrospective Facilitators Gathering 2014

May 19, 2014 / / 0 Comments

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

Looking back at 2013

December 20, 2013 / / 0 Comments

Although we have a bit of time left in 2013, my work for the year is almost done. Next year brings a completely different adventure. First though, are some reflections for this year.

A bit of a blur

My year was punctuated with many short engagements and events. I definitely did not have a regular schedule, but I did have a good amount of restorative time. My consulting engagements came dotted through speaking engagements, the latter which I had tried to reduce to a good level compared to 2012. The short consulting engagements often involved navigating a new organisation, collecting enough information to provide advice most suitable for their context.

I appreciated these engagements as it often meant working with really experienced people I don’t normally get to work with during other engagements, and I really enjoyed the debates about what might be the “next steps” that organisation could take to address their problem effectively. At the same time, I less enjoyed building relationships with a lot of new people for such short periods because I found it really drains me (and my memory for names seems to get worse and worse). It makes it worthwhile though, if I know that their environment could improve for the better.

Lots of travel

Naturally with so many different shifts both for clients and for conferences, I found myself travelling a lot this year. One week I remember being in London, Manchester, Hamburg and Rome before returning to London. With another client, it was three cities across three weeks back to back. I found myself returning to Dublin for a client, only to be impressed by how much more “continental” the city felt but you are still guaranteed an Irish pub around the corner.

I also found myself in Brazil for the first time (twice!), a beautiful country but one where the lack of public infrastructure is staggering. Fortunately the reliance on taxis for transportation was definitely made up by the friendliness of the Brazilian people.

The Retrospective Handbook in Print

I have been very happy with the reception to the book, “The Retrospective Handbook”, I published last year. People told me how it’s really helped and improved their retrospectives. Totally worth the time.

I spend time making the electronic copies available as print, and I can now physically give away copies (or you can buy them here on amazon!) There’s still time to gift it to someone before the new year 😉

Keynote for Agile Brazil

I also felt very humbled to give the opening keynote to Agile Brazil, a 1000+ person conference this year held in the country’s capital city Brasilia. It warms my heart to see the ideas prospering around the world. I wrote a new talk, “Agile: Unlocking our human potential” with the goal of inspiring people to engage for the rest of the conference.

The video was recently published online too:

Unlocking the human potential – Patrick Kua from Agile Brazil on Vimeo.

Plans for next year: Berlin in 2014

As I hinted previously, 2014 will be completely different from previous years. I intend on taking a break from work, partly because of a (generous) 12 week sabbatical period ThoughtWorks offers employees after a long tenure. My plans are to move to Berlin for year, with my only goal being to speak/write German fluently. I depart British shores early next year where I will start with an intensive language course involving at least 30 hours a week of study.

For people who I know in Berlin (Hallo!) but I hope to avoid speaking too much English for the first part of the year.

Dafür wir können uns treffen wenn wir nur auf Deutsch sprachen.

I intend to write less on this blog, and to spend more time (deliberate practice!) on a German one I have set up here.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑