How engineers can help deliver software effectively

Photo by SpaceX on Unsplash

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.

Principles of great delivery

As an engineer you should have an idea of what your principals for great delivery are. These are the principles that have stood out to me over the years.

• Move from Scope/Schedule/Cost to consider Value/Quality/Constraints
• You build it you run it — stable long lived teams, continuous delivery, automate everything, focus on the whole product and experience rather than a single feature
• Disband consultant led frameworks — prevents agility, welcome change and experimentation, eliminate “the way we do it here”
• Disband the frozen middle — reduce hand-offs, local decision making
• How do you measure — cycle time, sentiment, outcomes, customer value
• T shaped people — minimal reliance on specialists, minimal reliance on specialist teams, work on whats valuable rather than who’s available
• No waste — keep things simple, don’t over engineer solutions to processes or products, Most meetings aren’t work, — time spent in face to face communication is more valuable than digital, product quality must be high — bugs are — waste
• Focus on your people — develop people, communities of practice, people over process
• Build servant leader culture — trust over control, transparency over secrecy, environment over project — management, psychological safety is crucial, provide strategy and let teams execute
• Every team has a customer — make their lives easier, empathise, get your team close to them, collaborate with — your customer for outcomes, make their lives easier
• Provide a clear direction — have a vision, visualise everything
• Drive portfolio value — build, test, fail loop, smaller projects, ongoing reflection and continuous improvement
• Ensure teams have a process to improve their process, teams develop their own processes, choose their own tools, — teams align with other teams to develop org wide processes

Measuring engineering delivery effectiveness

As a product organisation you should measure success based on outcomes — revenue, customer satisfactions, retention — whatever makes sense for your product. These are a little bit too abstract for an engineering measurement.

For measuring engineering effectiveness I like these metrics from the Accelerate book. These are extremely relevant to engineers on the team. If you get these right you will have more time to work on interesting engineering and less on-call interruptions.

Try to capture these metrics from the start of a project.

• Deployment Frequency — Great is on demand (multiple times per day)
• Lead Time for Changes — Great is less than one hour
• Mean Time to Recovery — Great is less than one hour
• Change Failure Rates — Great is 0–15%

Measuring developer productivity

First thing about measuring developer productivity is that an organisation should have well intentioned reasons for tracking it — “are they working hard?” is not a good reason. “Are they burning out?” is a good reason.

If your delivery manager is tracking some metric around productivity don’t be alarmed unless they use it against someone. If a productivity metric is being used to push your team then you’re in a toxic environment.

What metrics should be used? — It’s always been difficult to measure the productivity of developers. Single metrics like lines of code are known to be rubbish for decades now.

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler have created an interesting framework for measuring productivity across multiple dimensions. A summary of their paper can be found at https://queue.acm.org/detail.cfm?id=3454124.

The framework describes five dimensions

• Satisfaction and well-being
• Performance
• Activity
• Communication and collaboration
• Efficiency and flow.

To use the framework you should choose metrics across at least three different dimensions. This supports the complex nature of dev work e.g. different skill levels in teams, different stages of a project and invisible work. You should also choose at least one metric based on the team’s experience — e.g. a survey.

Important things to remember

• Measure across multiple dimensions to be effective
• Do not measure individuals, measure teams, anonymize individuals
• Be very, very careful about biases in your measurements.
• The team will optimize what you measure

As an engineer on the team you’re in the best position to identify metrics for your project that will indicate how the team is performing against those dimensions.

Don’t hide reality

You should create an adult culture in the team. Engineering teams are not children. Engineers should take ownership of their output and outcomes but this requires empowerment from product and delivery roles (if those exist in your teams). If engineers are told what to build all the time they form a learned-helplessness. Avoid falling into this trap.

A red flag is if engineers expect someone else to create their tickets all the time. Engineers should be able to synthesise the challenges their customers are facing and write their own tickets. Ideally the whole team should come together to write “tickets”.

Of course this is dependent on an engineer’s task maturity. Say in the first year of professional experience an engineer might have tasks/tickets given to them by more senior engineers. But this should stop after a short time.

Engineers should be able to run their own stand-ups, retrospectives and other ceremonies. A delivery manager might have the responsibility to make sure that the ceremonies happen but they should push the implementation back on to the team. You can ask your delivery manager to teach you how to facilitate a meeting but you shouldn’t expect them to run every one.

Make sure everyone on the team understands what they’re empowered to do or to change. Try to get your teams to constantly increase their empowerment. This is nicely described as “Mandate Levels” by John Cutler — https://cutlefish.substack.com/p/tbm-2752-mandate-levels. This is nice because it shows how all the roles and levels are interconnected.

Encourage engineering comms

It feels somewhat redundant mentioning this these days, but it’s important to have an engineering channel where the team can discuss the work, the impact the work is having on the product and on their world.

I like the mnemonic DIRECT from freistil for describing the topics that should be encouraged in this channel

• Decisions: Did you make a choice that will affect others on the team?
• Insights: Have you learned something new?
• Results: Did you reach an important objective?
• Emotions: Is there something that’s making you happy? Sad?
• Contacts: Did you get in touch with someone who could influence our product?
• Troubles: Do you have an issue you could use some help with?

If you don’t have this channel for the team/product/project you should create it.

Coaching for valuable retrospectives

Retrospectives are one of the most important team ceremonies. But they have to be run well. Don’t stop at just listing everyone’s positive and negative items. There needs to be action items produced at the end.

Each retrospective should be unique because it’s based on the previous period but here are some general things you should look out for in every retro.

1. Is there a normalization of deviance for the team? — Where they have to do one thing (or say they are doing one thing) so they can say they are sticking to the process, but they actually do something entirely different to get the job done.
2. Is the way the team is working helping them and the rest of the organization meet goals? If not, what needs to change?
3. Is your understanding of the customer (or whatever system you’re trying to improve) correct or are you basing your decisions on the wrong assumptions?
4. Do you have a clear picture of what you want to achieve and how that is aligned with the goals of the organization?

Mitigating risk

You should ensure the team has identified any risky parts of the solution. You should take extra care around these.

Work with the rest of the team to write down a risk assessment for these special areas

• Describe the code components in contracts
• Document any assumptions you’re making
• Document the implications of error
• Enforce guarantees of contracts and assumptions
• Write tests for critical flows
• Test potential plays and responses
• Develop POCs for new integrations

Keep a risk register for the team that isn’t specifically engineering problems — e.g. software components, infrastructure, key personnel.

Incidents and postmortems

If there’s an incident you should have a practised procedure to handle it. At a minimum there should be

• A single incident channel for all comms (channel as in communication medium)
• Incident lead — holds all unassigned roles, communicates outwards and is point of contact to protect the team, longer term planning — ordering food
• Operations (team) — only people who can investigate and change the system
• Log how the system has been modified so it can be reverted later
• A report after resolution e.g. https://landing.google.com/sre/sre-book/chapters/incident-document/

You should have some criteria in place that triggers a post mortem after severe incidents. Not all incidents will need a written postmortem. The severity measures will depend on your team, org and product.

The team will need time to decompress before asking for the post mortem. The purpose of the document should be to confirm resolution and identify corrective action, it’s not about blame. It has to be blameless.

If you’re writing this document or if you’re reviewing it you should ensure it is comprehensive and meets the goals of a postmortem for your organisation before publishing it.

• Was key incident data collected for posterity?
• Are the impact assessments complete?
• Was the root cause sufficiently deep?
• Is the action plan appropriate and are resulting bug fixes at appropriate priority?
• Did you share the outcome with relevant stakeholders?

Making a change

To change anything you have to be

• Responsible for the outcome
• Empowered to initiate the change
• Knowledgeable about the issue

If you only have one or two of these you should seek out the others who can fill in your gaps.

Be aware of Wadge’s law of meetings — “Before every formal meeting there’s a smaller, more exclusive, less formal meeting where all the important decisions are made.”

You’ve probably been part of the smaller meeting at some time or another. So you know there is truth in this. If you haven’t been part of the smaller meeting then there’s likely some context you’re missing.

Reverse this to have more successful meetings yourself. Pre-prepare for meetings by understanding and empathising with the stakeholders for whatever you’re working on. Chat to them and figure out what they’re thinking.

Complexity and doing the simplest thing

I’m forever thankful to an old colleague who recommended this video from Rich Hickey — https://www.youtube.com/watch?v=SxdOUGdseq4. Rich is an amazing engineer but also a great teacher.

He describes that we should always try to fight against complexity. We should always do the simplest thing. But it’s important to remember that simple != EASY! Do not do the easy thing.

You should help the team to push past the easy route, focus on simplicity instead.

Summary

When we do an amazing job we often work ourselves out of a role because the output of our work is so effective it reduces the need for our input.

Delivering software is no different. You should be training the team to take care of delivering software successfully themselves. Use your expertise to guide the approaches and culture they use but don’t handhold them too much!

Let me know on Twitter if there’s something you think is missing here. I’m always looking for new things to learn!

Originally published at https://www.darraghoriordan.com.