Lead dev 2022 London: Day 2, part 1

• Constructing a Framework for a Differentiated Customer Experience
• Why we are writing a monolith, not a microservice
• Navigating the minefield of changing working relationships when stepping into leadership ❤️
• A Commune in the Ivory Tower? - A New Approach to Architecture Decisions
• Sorry… you go ahead. The art of making space and claiming space in meetings
• Development setup: how an important part of your toolset is often overlooked
• Success isn’t repeatable

Constructing a Framework for a Differentiated Customer Experience

Jasmine James (@gojasmineee), Engineering Manager, Engineering Effectiveness Twitter

There is no question that the needs of customers, of every type, have evolved over the years. Individuals have adjusted what they value throughout generational changes and external occurrences, such as the pandemic. With so many options for consumers of products and services, the associated experiences have become the key differentiator and deciding factor for individuals. The question most leaders face today is, “How can I continuously ensure that the experiences created are competitive and keep customers wanting more?” This talk will examine key ways personas such as a leader serving external customers, internal customers and a team can establish processes, tools and capabilities that unlock a next level experience leading to more impactful customer strategies, a better employee experience and improved team velocity, to name a few.

Customer emotion: how they feel about their experience with a company? They will remember how they felt about your product (but not the specifics). This is not the same as cutomer satisfaction. Here we need to fulfill their deep, unspoken needs.

This framework is just a starting point. Align all the DUCC (Discoveraability, Usability, Capability, Credibility) together :)

Personal note: the analogy developer/customer was quite unsetteling to me

1. Discoverability

How easy is it to find the path to complete their task? The fundamental motivation is to have a sense of freedom.

Talk to your users, use analytics to learn what they need.

Developers need:

• single sourcing guidance
• universal search
• centralized support

Measure results:

• onboarding / time to productivity
• tool usage
• NPS

(cf thesis from Gutherberg)

2. Usability

The fundamental motivation is to have a sense of freedom.

• learnability (on 1st they encounter on something)
• efficiency (when they already know the task)
• memorability
• errors (how much, how they recover from it)
• satisfaction

Do:

• usability testing (observe someone doing some task)
• define golden path: clear line to accomplish common goal
• automation as much as possible: automate, automate, automate!
• errors prevention (poka yoke) with linting

Measure results:

• tasks success rate: aim 100%
• time based efficiency: should remain the same or become lower

3. Capability

Do you address all personas within your customer base?

Fundamental motivation: feel a sense of belonging, being part of a group

Do:

• journey mapping, including their interraction with all workflows, for all personas
• surveys, real time feedback

Measure results: NPS

–> Book: Developer Relations: How to Build and Grow a Successful Developer Program, Caroline Lewko & James Parton

4. Credibility

How reliable is your product at delivering what it promises?

Fundamental motivation: feel secure.

Do:

• focus group (talk to people in a controled environment): what/how confidence was reduced?
• incident management data
• post mortems

Measure results:

• tool uptime
• mean time between outages

Why we are writing a monolith, not a microservice

Supriya Srivatsa (@SupriyaSrivatsa), Software Engineer Atlassian

While microservices take the industry by a storm, we chose to decompose our age old monolith into (no, not microservices!) a new monolith! A modular monolith. Join me to understand why we at Atlassian, decided to break down our mammoth monolith, why we chose to not go down the microservice route, and the what and whys of the new, shiny modular monolith we are working on!

10 min talk

Monolith have a bad reputation, as sad codebase to interract with. But:

• Abstractions, but it doesn’t have to be over the network.
• Boundaries: are to define, but not set in stone. Give them space to evolve
• Conway’s law: should your codebases mimic your organisation structure? Business priorities change, team organisation change, code and services change less. Give the ownsership of a domain to a team.

-> build a modular monolith, with domains that represent abstractions of the business domains. Interaction within well defined interfaces only. A good monolith needs a good code structure, with boundaries as best we know today.

Build for today, envison for tomorrow.

Navigating the minefield of changing working relationships when stepping into leadership

Humayra Hanif (@HumayraHanif), Senior Software Engineer, accuRx

This talk includes recommendations in order to succeed as a new leader and emphasise the importance of collecting feedback from your team, and understanding more about their motivations.

Becoming an engineering leader within a team is a difficult move: tech lead, engineering manager…

Book: the first 90 days, Micheal D. Watkins

Role chages from being a contributor to a multiplier, boost the outcomes of our teams. A tech lead becomes an advocate of the technical solutions that were choosen. It’s about vector alignment.

5 stages by Bruce Tuckman:

1. forming: get to know each other
2. storming
3. norming
4. performing: what we are looking for
5. adjourning: end ot the project

Need to maximize team’s morale and effectiveness. This will require a lot af small incremental steps. Focus on the people, start with something small. Treat the team with respect, everyone whould feel listened to.

Content is King, Context is Queen.

A Commune in the Ivory Tower? - A New Approach to Architecture Decisions

Andrew Harmel-Law (@al94781), Technical Principal, Thoughtworks

This session will introduce you to a mindset and an associated set of practices which do away with the traditional idea of “Architects” while bringing the practice of “Architecture” to the fore.

Buliding software changed a lot. Hard things became easy, expensive stuff became cheap.

Architects present themselves as “hand-on architects”. How to decentralize architural decisions to make it non-blocking?

The Advice Process: anyone can make any decision, but then need to seek advice (not authorization) from people with expertise.

Use lightweith ADR (Architectural Decision Report) for decision report: help you know you made what decision, with who was consulted. Put real effort in filling the Context part of an ADR. ADRs have to live in the dev tooling, not in an"architect place".

ADR:

• title
• status
• decision
• context (needs a real effort)
• consequences (for the others)
• advice (comments from all advisers)

This process could be very slow: how to optimise this? (follow Martin Fowler’s advice)

Implement an Architural Advice Forum: a weekly informal meeting where the whole point is to seek advice, with representatives from all teams. Will help you improve the process.

In short:

1. Advice Process
2. Lightweight ADR
3. Architural Advice Forum

see also Ruth Malan’s article: Software Architects: Do We Need ’em?

How to fail?

1. “Bad” decisions: everybody will think this decision is bad. Step back, let off control. Celebrate good decisions, turn bad decision into learning opportunities
2. Old guard is the new guard: people are the same as before the process changed. Make space for new people
3. Off-the-grid decisions: people not following the process but are making decisions. Get the team to write an ADR and introspect to find out why they didn’t want to share their findings
4. No trust

It’s an “anybody” approach to architecture.

Tips on adoption patterns: start following the advice to yourself

See whole article on martinfowler.com: Scaling the Practice of Architecture, Conversationally

Sorry… you go ahead. The art of making space and claiming space in meetings

Jemma Bolland (@jemolova), COO The Scale Factory

In this talk Jemma will talk through the things you can do, whether you are running or participating in a meeting, to balance things out and make space for more perspectives and ideas.

10 min talk

Good meeting facilitation is like leading a whole orchestra. In truth, this doen’t happen, someone is always blasting in your face.

It’s all about awareness about how much space you’re taking up. A lot of people don’t feel they are able to interact at all. Being heard is about privilege (gender, ranking…).

Some people talk to think, some people think before they talk.

Running an inclusive meeting:

• make sure everyone knows you’d like them to contribute
• outline protocols (how to signal they’d like to talk)
• ask anyone if they are opposing opinions
• silence: leave space before moving to the next point
• be an ally, make space for others

Development setup: how an important part of your toolset is often overlooked

Gus Fune (@GusFune), CTO Div Brands

In this talk, you’ll follow the story of three different developers and how their preferred setup was causing them to struggle in delivering.

10 min talk

Managers mostly assume engineers know their tools.

Think about DX (dev xp, like UX).

Success isn’t repeatable

Hywel Carver (@h_carver), CEO • Skiller Whale

Leaders are responsible for meeting their organisation’s goals by ensuring their team has the capabilities it needs to succeed. Managers are responsible for ensuring their reports continue to develop and improve. But how?

(How to gain wisdom instead)

When a good practice becomes a bad practice ?

As in winning at board games, success isn’t repeatable in leadership.

Learning matters a lot in technology. A lot of new technologies appears all the time (docker was first released in 2013, less than 10 years ago).

We need to enable learning for “non tradictional devs” (here for the job, not just a hobby).

Two frameworks : Bloom & ICAP

Bloom: measure levels of outcome:

1. know, understand
2. apply, analyse
3. evaluate, create

This model doen’t say how to progress in the learning

ICAP is about the inputs for learning to maximise the outcomes:

• Interactive beats
  • Constructive beats
    • Active beats
      • Passive

Learning style (visual, auditary, reading) is a tenacious Myth. Boredom is the enemy of learning (affective context model, attaching feelings/emotion to the learning experience).

New model: knowledge / skills / wisdom

• knowledge: data, facts
• skills: doing things, ability
• wisdom: contextual judgment

(me fait penser à Shu/Ha/Ri)

Back to Bloom (outcomes) and ICAP (inputs):

• know, understand -> knowledge -> passive
• apply, analyse -> skills -> constructive
• evaluate, create -> wisdom

Wisdom is hard to pass on, knowledge is easy to pass on. Wisdom can be mis-applied, as context matters. Success is contextual.

The wisdom feedback loop: Try, Fail, Reflect. This takes time, but you can accelerate it:

• Accelerate experience with peer learning
• Accelerate without experience with simulation (ex: training)

How much are you exploring new alternatives?