The QCon Plus conference ran over three weeks in November, 2020. On Wednesday 11 November, Randy Shoup hosted the Non-Technical Skills for Technical Folks track, aimed at technical leaders and focused on some of the important people skills needed for effective communication and collaboration in and outside teams.
The first talk was by Lena Reinhard, vice president of product engineering at CircleCI. Titled What Engineering Teams Need from Leaders Right Now, the talk was about sharing key lessons that she has learned from leading organisations through times of change, uncertainty and fast growth.
She started by reflecting on the current state of the world, how people are coping with all the challenges of 2020, and the impact that the lack of control is having on our effectiveness. She presented ideas about looking at and working across different leadership horizons. As leaders we need to be able to operate across the different operating horizons (foundations, short, medium and long-term) and move our focus between them deliberately.
On the foundational aspects, she said that an important starting point for any leader is the ability to manage oneself first and foremost. This includes managing our thoughts with deep self-reflection, managing our energy to know what energises and what drains you and managing our time through ruthless prioritisation and self-organisation. We also need to manage our operational horizons, making time for strategic thinking and working on things that are beyond the current moment.
She presented the BICEPS model of human core needs:
- Belonging
- Improvement
- Choice
- Equality
- Predictability
- Significance
Our job as leaders is to understand how these show up in our teams and create environments where they can show up effectively. She linked these core needs to research into what enables high performing teams and how factors such as psychological safety, dependability, structure, meaning and impact align with human core needs.
Teams need leaders who understand their needs. The most important tools for leaders is the ability to ask good questions with genuine curiosity to truly understand the team’s needs.
Teams need strong relationships. Create environments where people can get to know their colleagues and share ideas. She gave examples of remote pair-programming, regular fireside chats, book clubs, department-wide meetings and mentoring programs.
Shifting to the big picture (strategy, vision, the higher level context which guides all the work we do) she said that one of the most important leadership tasks is to encourage leadership in their teams.
She contrasted management (coping with complexity) with leadership (coping with ambiguity) and emphasised that the skills of leadership need to be applied at every level. This requires different behaviours:
- Lead through context rather than control, help people understand what impact their work has, and empowering people to do the right thing
- Focus on values, principles and outcomes rather than activities and tasks, using techniques such as OKRs
- Distribute ownership and remove bottlenecks and dependencies in the flow of work
She then shifted to talking about working in the present and how leaders need to ensure alignment across the organisation by:
- Creating communication patterns so people know what to expect in different channels
- Assuming that people don’t know, and that you need to communicate repeatedly to ensure your message gets heard
- Relentlessly communicating vision and strategy
- Tailoring the communication to the people receiving it
- Showing clear feedbaths
- Being a dolphin - surface and communicate in small bursts frequently, rather than trying to communicate lots at once
She spoke about ways that leaders can create an environment of continuous learning using techniques such as small experiments, blameless incident reviews and retrospectives. Resilience is another important characteristic that leaders can nurture in teams; she pointed to the Bridges Transition Model as one tool to help people discover, accept and embrace a new situation.
She ended by asking the audience:
How are you going to show up for your team as a leader right now?
Track host Randy Shoup, VP engineering and chief architect at eBay, gave the second talk, Communicating Effectively with Your Business Partners. This talk covered the mindset and techniques engineers need to effectively listen, understand and communicate with non-engineers.
He started by laying the groundwork around the importance of trust in any communication and explored the three aspects that lead to trust:
- Motivation - are we motivated by the right things?
- Integrity - openness, honesty, transparency
- Competence - do we have the capability to do what we say?
Addressing motivation, he made the point that we need to focus on outcomes over output. Value is in the benefit the customer and the organisation gets from the work we do, not the volume of quantity of that work. To achieve this we need to understand the business metrics we are aiming to achieve and why they are important to the organisation. We also need to have a clear understanding of the customer metrics that will contribute to the business metrics. He pointed out that there are key engineering metrics that lead into the customer and business metrics (referring to the Accelerate book). He pointed out the importance of tracking some engineering outputs but not managing to them.
He said that the most important question for an engineer to ask is:
What problem are we trying to solve?
He pointed out that engineers are trained in disciplined problem solving and this is a skillset we can bring to the conversations we have with non-engineering folks who do not necessarily have skills in this area. It is our job to bring this approach to help clarify and refine customer and business problems.
He pointed out that:
Discussing integrity, he emphasised the importance of open, transparent communication: tell it like it is. Share both good and bad news, don’t hide or obfuscate the real situation. We need to share the engineering context and clarify the situation for non-engineers in order to create a shared context. He pointed out the need to disagree and commit when we cannot achieve consensus.
Another key aspect of integrity is the value of a regular cadence of structured communication, up, down and laterally. This communication should be consistent, not just when things are going badly. He quoted Steve McConnell:
The half-life of trust is six weeks
He pointed out that transparency builds credibility and respect.
On competency he made the point that we need to be consistently doing our main job, solving customer problems and showing a consistent trajectory of incremental value. He explored the danger of too much parallel work and large batches, and pointed out that frequent delivery of value enables adaptation to changing priorities and maintaining credibility with business partners.
Another aspect of competency is estimation. Estimation is a common stress point for engineers and between engineers and business/product partners. He made the point that estimation is necessary and honoring a request for an estimate is important because there are business dependencies which need to be planned for across other areas of the organisation. When estimating we need to be clear about the uncertainty level in the estimation process, use ranges rather than single point figures to indicate that uncertainty and refine the estimates based on learning as we do the work.
He then explained how these three aspects are applied using common situations that engineering managers will find themselves communicating with business/product people about:
- Pressure to go faster
- Technical debt
- Site incidents
He ended by quoting Martin Fowler:
If you can’t change your organisation, change your organisation.
The third talk in the track was by David Van Couvering of Optimizely, titled Lean and Accelerate: Delivering Value as an Engineering Leader. He explored the lean principles and explained why they work and how they can be applied in practice in software engineering.
He used two sources to identify the key aspects of the topics, The Principles of Product Development Flow by Donald G. Reinertsen and Accelerate by Nicole Forsgren PhD, Jez Humble and Gene Kim.
Talking about the Accelerate book, he pointed out that the deep research which underlies the book shows definitively that the practices they explore result in better outcomes in terms of meeting business goals as well as team morale and engagement. The authors call out lean management and development practices as a key contributor to achieving high performance.
Referring to Reinertsen's work, he called out the deep mathematics which is in the book and how an important concept which is often neglected when prioritising features in software development is the cost of delay. Value can be significantly degraded by delays when releasing the product.
He explained the concept of value streams and how value is only realisable when all of the steps in the development process have been completed, and how queues cause delay and waste in the process. He pointed out that in software delivery queues are generally invisible, which means they are often not exposed and addressed. He then introduced Little’s Law as a way to calculate cycle time, and the resultant queue length. Cumulative flow diagrams are a useful tool to visualise the processing time and queue length.
He showed how queueing theory means that a busier team means exponentially longer cycle time because of the resultant wait times. This is counter-intuitive and means that managers need to avoid loading teams to full capacity - they need slack capacity to enable more effective throughput. Many managers take the opposite approach - he cited a study by Reinertsen survey showing that over 10 years managers run teams at 98.5% capacity, resulting in very high queues and reduced throughput. Once teams are in such a high queue state it is very difficult to move out of that state and get into a low queue state.
He then presented some ideas about how to reduce queue length and improve throughput rates.
The first idea is to reduce the batch size - small batches have additional advantages, including:
- Faster feedback
- More efficient use of resources
- Avoids system overwhelm
- Reduces variability and improves predictability
- Reduces waste and rewrite (errors are caught sooner)
- Reduces management overhead
- Improves motivation and engagement
He pointed out that the optimal batch size has to be calculated based on the context of the system under investigation.
The second approach is to limit work in progress (WIP). Setting a cap on the number of items an individual or team can work on at one time, allowing them to focus on completing one piece of work rather than being interrupted and needing to switch to a different task, with the resultant context switch. He then introduced a technique to help sequence work in a queue, weighted shortest job first.
He explained that being able to limit WIP requires leadership support to succeed. The idea is counter-intuitive and it is important to explain how WIP limits.
