Category: Teams (Page 2 of 8)

Why you want to give up coding

December 1, 2014 / Patrick / 12 Comments

A background story

A friend of mine worked as a Tech Lead, let’s call them Jo (not their real name) for most of their career. A few years ago, Jo moved into a management role that involved very little coding. They were no longer working full-time as a developer and they stopped playing a Tech Lead role. Jo now leads an organisation with six or seven large development groups.

In the definition of a Tech Lead, I suggested a Tech Lead should write code a minimum of 30% of their time. Jo managed to find some time writing code, but it was inconsistent – about an hour a week. In a 40-hour week, that is less than 3%. Jo missed writing code. Jo was no longer a developer and Jo was no Tech Lead.

What do you control? What do you influence?

Every role comes with a set of responsibilities, and the authority to fulfil those responsibilities. This authority gives you a certain amount of control.

For example, a developer has control over the code and tests that they design and write. Others may have influence over the code. Examples of influencing factors include architectural or product and/or platform constraints, team code standards and code reviews. Ultimately the developer has control over their own code.

Every company has a certain organisational design. Developers (and other employees) work within this structure. The organisational design impacts on how effective software delivery is. Rigidly hierarchical structures with completely different departments (e.g. developers and testers) have difficulty collaborating. An ineffective organisational design is a sore point for many developers because it makes delivering software much harder.

A developer has zero control over organisational design. They might be able to influence it, but it is ultimately controlled by managers. Some developers may try to change this, but most complain. I have heard this from developers in the past:

Who’s brilliant idea was to setup a development [team] like this?

Another example.

I can’t get anything done because I rely on those people to get something done and they sit on another floor.

Developers can complain, which is an ineffective style of influencing, although there are many more effective ways. In the book Influence: The Psychology of Persuasion, the author, Robert Cialdini outlines six key influencing strategies: Reciprocity, Commitment (and Consistency), Social Proof, Liking (a variant of the Halo Effect), Authority, and Scarcity.

Developers only influence their working environment. They do not control it. Note: An exception is, of course, when a company is small enough that the developer also takes on general organisational management responsibilities (e.g. in a startup)

Trading control for influence

Jo, who moved from being a developer to a Tech Lead, and again from a Tech Lead to a general manager shared an interesting insight with me.

You know those things I used to complain about as a developer? Well, now I have the ability to change them.

Programmers see the “non-technical” path as a path with nothing to offer. When programmers step into a leadership role, they inherit both responsibilities and the authority to control more of their work environment. A developer works within these constraints. A Tech Lead has more authority to change those constraints, and a manager even more authority to control and change those constraints.

How does this impact developers who become Tech Leads?

When developers give up their control in trade of influence, their sphere of influence grows. Instead of developing a single feature, they can guide the entire technical solution. The Tech Lead’s influence also grows between the technical and the business side. A Tech Lead has much more influence over how technology can be used to solve business problems, while developers are engaged too late.

I would suggest to Tech Leads never to give up all coding. Instead, it is trading more of the time you would spend crafting code, in exchange for a wider sphere of influence. The wider sphere of influence helps not just you, but also your team write better code in a better work environment.

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 featured image from this post is taken from Flickr under the Creative Commons licence

How do I still write code as a Tech Lead?

November 11, 2014 / Patrick / 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.
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 / Patrick / 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.

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

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.

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.

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 / Patrick / 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

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.

Do we need a Tech Lead?

October 21, 2014 / Patrick / 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.

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.

Top 5 Mistakes for First Time Tech Leads

October 16, 2014 / Patrick / 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.

Talking with Tech Leads

September 25, 2014 / Patrick / 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.

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.

Looking back at 2013

December 20, 2013 / Patrick / 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.

Book Review: Quiet

November 27, 2013 / Patrick / 0 Comments

I have read more books recently with so much more travelling. Susan Cain wrote the book I finished most recently, called Quiet: The power of introverts in a world that can’t stop talking. A provoking title and filled with a good level of research and stories talking about how today’s society views introversion as a negative trait, but can actually provide people and organisations with positive outcomes.

What I liked about the book

Cain provides a different, refreshing perspective about the strengths introverts can offer. She highlights (mostly American) cultural influences that make it difficult for people with introverted tendencies to operate and some practical suggestions along the way on balancing the needs. For example, introverts often need time to digest, prefer to do deep analytical thinking and need time to restore after heavy interaction with many people. Another example is that extroverts tend to take more risk, particularly under stressful conditions, while introverts tend to take more take.

The book made me think about practices like “pair programming” and how agile methods impact introverted people and their need for space. Sidenote: I don’t see agile methods working against introverts but just that necessary balance must be found

I particularly enjoyed the section where Cain discussed how people with different extroversion/introversion tendencies can find a way to live, work and love together. It reminded me of interests based negotiation over positional based negotiation and that if people focused on what their needs were, instead of outcomes, they might find a new, slightly different solution that work for both parties.

What others might struggle with in the book

Although Cain references a lot of research, the contents appear to me more anecdotal. She approaches this early in the book, writing about different definitions of introversion and peppers disclaimers throughout the book that “not all introverts act the same”. She also references studies but warns they are not conclusive because these are in early stages. For some, this may be a killer, but for me, still provided an interesting read.

At times, the guidance can be confusing. In some parts of the book, the message I took was that introverts don’t need to adopt extrovert characteristics. In others, I felt like the guidance changed to sometimes introverts need to adopt extrovert characteristics but they will need to time recharge and it helps to do so in areas you enjoy.

Conclusion
In some part of the book, Cain describes the world being at least thirty to fifty percent being made up of introverts. Some may be better at hiding it. I think everyone should read this book to understand more about a group that will naturally be more quiet and why that is.

Book Review: The Human Side of Agile

June 27, 2013 / Patrick / 1 Comment

A majority of books in the agile space always relate to the practices talked about in various methodologies, if not focusing on the methodologies themselves. With the Agile Manifesto talking about Individuals and interactions over Processes and Tools our community seemed to have missed a bit about how you go about building better interactions between individuals.

Fortunately a community member, Gil Broza wrote a book called The Human Side of Agile: How to Help Your Team Deliver. Gil was kind enough to send me a book a while back, but it was only on this trip to Agile Brazil that I managed to find the time read and reflect upon what I learned in the book.

My first impressions about the book is that it covers a solid range of topics. It addresses the role of leadership, strategies for getting to the ideal “self-empowered team” and useful advice on practical topics such as communication, meeting facilitation and about how to go about constantly improving. These are all topics that are often skipped, assumed easy, and are also the topics many people ask about at conferences. Fortunately Gil has been able to put a lot of practical advice, peppered with some great stories about what impact some of these ideas might have on the team.

The book is laid out in a series of questions, and so I can imagine people finding it particularly useful in a, “What do I do here?” situation. He covers topics some might avoid such as how to deal with behaviour seen as potentially destructive to the interactions of a team as well as dealing with the fact that people change in organisations and advice on how to deal with it.

This book provides a much needed guide to our industry where there was a big gap before. The writing is clear, easy to digest and quite approachable. Definitely one to add to any essential agile reading list.