Receiving timely relevant feedback is an important element of how people grow. Sports coaches do not wait until the new year starts to start giving feedback to sportspeople, so why should people working in organisations wait until their annual review to receive feedback? Leaders are responsible for creating the right atmosphere for feedback, and to ensure that individuals receive useful feedback that helps them amplify their effectiveness.
However today, I want to share some brilliant work from some colleagues of mine, Karen Willis and Sara Michelazzo (@saramichelazzo) who have put together a printable guide to help people collect feedback and to help structure witting effective feedback for others.
The booklet is intended to be printed in an A4 format, and I personally love the hand-drawn style. You can download the current version of the booklet here. Use this booklet to collect effective feedback more often, and share this booklet to help others benefit too.
A challenge with many leaders is creating the right environment to allow dissent. I draw upon Retrospectives as a useful tool and here are some tips if you are a leader looking to use it effectively.
Be clear about your motives – I can see some types of leaders who want to use retrospectives as a way to get to blame (which is definitely not the point). It helps to be explicit upfront about what you expect from people and to let people know if there will be consequences. If people feel like retrospectives are being used to “find dirt” or for blame, people will refuse to actively participate in future sessions or simply lie.
Find an independent facilitator – I address a number of the trade-offs of an independent facilitator in The Retrospective Handbook and when you’re a leader running a session, there will be times you will want to participate. Playing dual roles (participant + facilitator) can be really confusing for those simply participating, so I recommend at least starting retrospectives with an independent facilitator.
Allows others to talk first – Leaders often come with a level of explicit or implicit level of authority. Different cultures treat authority differently and it pays for a leader to be aware of the significance that is automatically added to your words by holding back and allowing others to speak. Focus on listening first and foremost, and ask clarifying questions rather than being the first to put your opinion on the table.
Pick a topic that affects all participants – When choosing participants, make sure that the topic is relevant and that everyone can contribute different perspectives for. Although outside opinions about a particular topic are often welcomed, retrospectives are best when people can share their experiences. If, as a leader, you are gathering a group of people who don’t regularly work together around a common topic, reconsider if a focused retrospective is a good solution.
Keep an open mind – There is no point in gathering a group of people if the leader is going to follow through on an action they thought of previously to a retrospective. Consider scheduling a retrospective early on, very focused on information gathering and generating insights as a first part, and then a second part with a smaller, focused group on the next steps. By having time to digest the new information, you may find you end up with very different solutions than what you first had in mind.
When used well, retrospectives can create a safe space to invite people to dissent and create an ongoing culture of challenging the status quo.
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)
This article hits home about the reality of a population gaming a metric and what is leading to a shift in cultural values through their actions. The short story, if you don’t read the article is that it is apparently seen as more economical to pay for someone’s death, than for their healthcare overall combined with a low chance of apparently being caught for murder. Due to the economic cost, it has apparently become acceptable, or at least, very common for someone to finish someone off, rather than pay for what medical aid they made need.
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.
Where the other books I read tended to take a more mechanistic view of steering the conversation, I really appreciated the slightly different take with this book, which I felt more humanistic because it acknowledged the emotional side to difficult conversations. The authors suggest that when we have a difficult conversation, we experience three simultaneous conversations:
The “What Happened” Conversation
The Feelings Conversation
The Identity Conversation
The “What Happened” Conversation
We often assume we know what happened, because we know what we know (Our Story). The authors (rightly) point out, that our story may be completely different from the other person (Their Story). A good practical tip is to focus on building the Third Story as a way of building a shared awareness and appreciation of other data that may make a difference to the conversation
The Feelings Conversation
As much as we like to think we are logical, we are highly emotional and biased people. It’s what makes us human. We manifest this by saying things based on how we are feeling. Sometimes we don’t even know this is happening. The book helps us understand and gives us strategies for uncovering the feelings that we may be experiencing during the conversation. They also suggest building empathy with the other person by walking through the Feelings Conversation the other person will be having as well.
The Identity Conversation
I think this was the first time that I had thought about when we struggle to communicate, or agree on something, we may be doing so because have difficulty accepting something we may not like, or something that threatens our identity. This is what the authors call out as the Identity Conversation and is a natural part of successfully navigating a difficult conversation.
I found Difficult Conversations a really enjoyable read that added a few new perspectives to my toolkit. I appreciate their practical advice such as stepping through each of the three conversations from both your and the other person’s perspective and avoiding speaking in different modes. I like the fact that they address the emotional side to difficult conversations and give concrete ways of understanding and coping with them, instead of ignoring them or pushing them aside.
The title is a clever take on working in software development and Rands shares his experiences working as a technical manager in various companies through his very unique perspective and writing style. If you follow his blog, you can see it shine through in the way that he tells stories, the way that he creates names around stereotypes and situations you might find yourself in the role of a Technical Manager.
He offers lots of useful advice that covers a wide variety of topics such as tips for interviewing, resigning, making meetings more effective, dealing with specific types of characters that are useful regardless of whether or not you are a Technical Manager or not.
He also covers a wider breath of topics such as handling conflict, tips for hiring, motivation and managing upwards (the last particularly necessary in large corporations). I felt like some of the topics felt outside the topic of “Managing Humans” and the intended target audience of a Technical Manager such as tips for resigning (yourself, not handling it from your team) and joining a start up.
His stories describe the people he has worked with and situations he has worked in. A lot of it will probably resonate very well with you if you have worked, or work in large software development firm or a “Borland” of our time.
The book is easy to digest in chunks, and with clear titles, is easy to pick up at different intervals or going back for future reference. The book is less about a single message, than a series of essays that offer another valuable insight into working with people in the software industry.
There are so many definitions of what leadership is so I’m not about to add another one. A nice simple one that I like from the Oxford dictionary is:
The action of leading a group of people or an organisation, or the ability to do this.
Many people assume that playing a role with a title that has “Leader” in it automatically makes them a leader – although this is not always the case. In fact, I have found that sometimes people who pursue roles simply because they have a more senior association with them are not really prepared to lead a group of people.
In my consulting life, I have worked in many teams in many different roles and I have seen many acts of leadership demonstrated by people who don’t have this role.
Example 1: On one of my first projects in the UK that I lead, a developer on the team was passionate about user experience design. He decided to do some ad-hoc user testing on the User Interface (UI) we had written, found someone willing to act as a test subject. He observed what they were doing and reported back to the team his findings. His initiative convinced us that setting aside more time to focus on usability would be a good thing to do. He demonstrated (at least to me) an act of leadership.
Example 2: During one of the Tech Lead courses I gave, I split the class into smaller groups for a number of exercises. I remember one particular group that had a large number of opinionated developers, all trying to get their view across. There was a female developer, who I noticed, listened quietly to all the opinions, waited for a pause before summarising what she heard and asking the group if that was correct. When she reflected back what she heard, she had summarised the different approached, integrated all the opinions and provided a cohesive story that everyone agreed with. She established a clear path that allowed the team to move forward. She demonstrated an act of leadership.
Example 3: On a particular client, there was the traditional divide between the development organisation and the operations organisation (sitting on a different floor). I remember during one of our planning sessions, a developer on the team who had met someone from operations decided to, unexpectedly, invite the operations person to the planning meeting. Although it was a surprise to us, we saw the appreciation from the operations person being involved earlier and probably changed the outcome of what we would have planned without them. He was passionate about the DevOps culture and demonstrated an act of leadership.
I do a lot of speaking and writing on leadership in our industry and what I like about these examples are acts of leadership that come without the authority of a title. Taking initiative, driving people towards a common goal, even in small incremental steps are acts of leadership that mean that everyone can be a leader.