[Tech] Engineering Effectiveness - the Automation Engineers edition

Question#

How do you better enable developers in their capacity by enabling the right automation and process solutions and without damaging culture / productivity as a side effect

Proposal#

We allow software engineers to focus on what’s important by automating and/or eliminating unnecessary blockers that are slowing teams down.

This incorporates people, process and tech with this goal of reducing barriers, provide better value, increase velocity while still promoting a culture of empathy, accountability and transparency

Vision#

Engineering Effectiveness is a force multiplier that covers analysing, developing, empowering and socialising tools, process and Infrastructure to allow an organisation to better perform their engineering capabilities and providing a frictionless E2E experience

Re-positioning of technology from being a cost centre to being a return on investment Automation is a major component of EE

The intersection between the tooling, the right people and the right mindset (best tools in an ideal environment)

The Problem#

At first glance, the term engineering efficiency is easy to understand: a higher efficiency means doing the same engineering task faster than before and thus with lower costs. However different skill levels, abilities, learning rates, management structure are all likely to affect efficiency

Ee Moto

Velocity, Quality, Gaiety

Twitter Model

E is the total effectiveness of an org where eng is the total number of engineers, ee is the number of engineers devoted to an Engineering Effectiveness style team, b is the boost the first EE engineer gives to the remaining engineers’ effectiveness, and s represents how each additional EE engineer scales the total productivity boost. If s was one then each EE engineer would add a boost of b. If it’s less than one, as seems likely, then each new EE engineer has a smaller effect than the previous one.

Under 10 engineering an EE role is perhaps not worth it as the engineers will most likely automate things that are annoying them However for 100 engineers if you have 2 EE then essentially you free up 1 engineers worth of work

Developer Productivity Gains#

5 mins per day for a 1% productivity increase (depending on the current state, bigger savings the more messy if is)

Delivery

The gap between code complete and deployment SDLC ‘Time to value’ going from idea to working product

Segmentation of responsibilities makes each segment efficient in their channels but can slow down the E2E process and produce silos.

But having different people doing different roles can lead to communication overhead and can slow the feedback loop

Devops Principles : “Operate What You Build”

Teams that feel operational pain are empowered to remediate it Deployment issues, performance bugs, capacity planning, alerts, notifications etc are owned by the development team, partner support

The Importance of Flow

15 mins to get into flow and an instant to get out of it. Looking to fix/change those things that are getting you out of flow After an interruption it can take up to 23 mins to return to the same point in the original task Meetings On average there is 15 per week Of those: 73% admit to doing other work during meetings 90% report daydreaming 65% say meetings prevent work and deep thinking

Flow books Steven Kotler Rise of superman Stealing Fire

Skills

Providing effective training at the right time How skills impact new product experiences A challenge skills ratio thats 4% greater than your skill level compounds over time

Tech Debt

It compounds over time, as you scale the worse it gets

Hiring / Employment

Turnover rate of 13% with an average to 2 years employment Estimated costs of hiring a software engineer: • Internal recruitment: $22,000 • Agency recruitment: $32,000 • Lost productivity while hiring for open position: \$60,000

Here are the top four reasons people leave their jobs: Lack of opportunities for advancement (45%) Unhappy with leadership (41%) Unhappy with the work environment (36%) Desire for more challenging work (36%)

Quick response teams Having snr engineers be able to ‘drop’ in and provide resource, guidance or assistance to teams for a short period to increase productivity gains

Measurements Competency model (where a team is at and where it would likely to be)

Level

Area Design / Planning Quality D&I Dec Release / alerts Reliability Cloud Infra Performance Master Desired

Expert

Proficient Current

Competent

Novice

Then define initiatives based on the above results (ultimately the areas that there is the biggest gap). Do this exercise at least quarterly Accountability / ownership You Built It/You Own It

Human factor considerations Reducing cognitive load Increased feedback loops Good team attributes: Deeply curious Ruthlessly realistic Highly empathetic

Summary#

• Effectiveness varies between teams
• We are in a software driven economy
• Progress is the key to success
• Small and frequent releases

References:

http://www.gigamonkeys.com/flowers/ https://www.infoq.com/podcasts/caitie-mccaffrey/