Redesigning Engineering Teams for Expansion - By: Matt Brunsdon

Re-Designing Engineering Teams
for Expansion
By: Matt Brunsdon

About Me
Matt Brunsdon
Transformational technology
manager experienced in
modernising engineering team
structures and system
architectures.
linkedin.com/in/mattbrunsdon/
1 of 19 | Matt Brunsdon - matthew.brunsdon@outlook.com

Talk Overview
This is a talk about my
experiences when
redesigning engineering
teams for expansion,
key sections include:
1. Culture
2. People
3. Structure
4. Process
5. Architecture

Why Transform Teams?
Some things that can
be achieved by
transforming an
engineering team:
 Effectively manage increased
staff headcount
 More feature teams
 More engineers
 1 codebase to many codebases
 Increase software deployment
frequency
 Increase product release
frequency
 Deliver new features more
efficiently and rapidly

What is a monolith?
A monolith is when all
software functions are tied
together, there is no re-use or
separation.
A monolith exists in a software
codebase but can be caused by
the team’s structure. It is
difficult to scale software or
teams with a monolith.
“Micro services is the
modern alternative to
Monolith architecture”

Hierarchy vs Value Structure
Engineering teams maintaining
monolith software are often
organised in a traditional
functional based hierarchy.
Value based teams are made
up of cross functional
members who add value to a
specific output are more suited
to micro services architecture.
Head
Lead
Eng Eng
Lead
Eng
ProductSoftware
Top down
Managers think
Workers do
Multidisciplinary
team
Specific value output
Clearly defined
customer
Self organising
Lead
Engineer
Product
Dev Ops
Data
SME
Functional Based Hierarchy
Value Based Matrix

Scaling Agile Management
Agile management promotes
accountability and trust.
Spotify’s “Squad” model of Agile goes
one step further creates self
organising teams with direct contact
to stakeholders – like a series of small
start-up’s.
Squad is a scalable way to manage
engineering teams of increasing size.
For more information on Spotify’s use of Squad: https://bit.ly/39Euhgs
Scalable Agile Management via “Squad”

1. Cultural Changes
Some cultural changes
required to create a
“high performing”
engineering team:
Encourage a culture of innovation,
introducing accountability and trust.
Obsession with the customer by
monitoring feedback. Reinforcement
through regular review of customer
feedback.
Inspire staff by creating a leadership
culture of mentorship, inspiration, and
learning. Unblock issues, and enable
personal growth.

Technicalability
2. Approach to People
Definition of a “high
performing engineer” needs to
change.
The right attitude is as
important as technical ability.
Engineers with balanced
“T-Shaped skills” are ideal.
Boundary crossing abilities
include:
 Communication
 Resilience to change
 Curiosity
 Positive Energy
 Continuous learning
Boundary crossing ability
For more information on T-Shaped Skills: https://bit.ly/38FAJCM

3. Designing Team Structures
Monolithic team
structures breed
monolithic technology.
Cross functional teams
break down silos, know
who the customer is, and
create micro services.
Designers Developers QA’s PM’s DevOps
*New* Cross Functional Team
Attitudes to foster include:
Autonomy & Accountability
Continuous improvement
Purpose and direction

3. Designing Team Structures
Leaders must advocate
for attitudes that are
desirable.
A way to structure
engineering leadership to
encourage team attitudes
and set clear leadership
goals is:
Product Manager
Purpose & Direction
Technical Lead
Continuous Learning &
Improvement
Engineering Manager
Accountability, Trust,
Autonomy, Self-Organisation

4. Redefining Processes
When measuring success
focus on outcomes over
the method of output.
Set value focused
objectives and allow
engineering teams the
freedom to define
solutions.
 Increase acquisition of
new customers by X%
 Increase conversion of
browsers to buyers by
Y%
 Increase click/open rate
by Z%

4. Redefining Processes
Using Jira and other agile
software in stand-ups can
make visibility more difficult.
Manually creating and
moving cards on a physical
board refreshes focus and
energy during meetings.
Backlog In Progress Testing Complete
Physical Board in Team’s Area =
Increased visibility

5. Refreshing Architecture
Moving to cloud hosting
such as AWS, Azure, or
Google Cloud reduces
procurement barriers to
increased server capacity
and facilities access to
emerging technologies.
 Move from CAPEX to OPEX
 Reduce overall cost
 Lower barriers to new
technologies
 Scale server capacity with
demand

Implementing a reverse proxy
server and dual hosts is a strategy
to migrate to the cloud over time
without downtime.
Migrate functions (apps,
databases, services, ect..) over
piece by piece, and only use the
new architecture with new
features.
Reverse Proxy
Data centre Cloud
1. Direct traffic
to old or new
hosting
Function
2. Migrate
functions over
time
*New*
Functions
3. Any new functions
only use new
architecture
Function
Function

Database
To give teams
ownership over part of
the solution migrate
away from monolith
code bases towards a
micro services
architecture.
User Interface
Middleware
Database
User Interface
Middleware Middleware Middleware
Database Database
User Interface User Interface
Monolithic Architecture
Micro services Architecture
One big system makes
ownership
difficult…
System broken up
into smaller parts
with specific functions
makes ownership
possible…

A strategy to migrate to an
event driven micro services
architecture (eg: Apache
Kafka) over time is “dual write”.
Move old services over piece
by piece, and only use the new
architecture with new features.
Database
*New* Event
Stream
Data Producers
1. Add dual
write
Data
Consumers
2. Migrate
reads over
time
*New*
Consumers
3. New apps
only use new
architecture
16 of 19 | Matt Brunsdon - matthew.brunsdon@outlook.com More information on migrating to Apache Kafka: https://bit.ly/2PPgtb0

Key Points in Transformation
Cross Functional
Teams
T-shaped skills
Continuous learning
Clear Purpose
Autonomy
Ownership and
accountability
Coaching by servant
leaders
Innovation culture
Self-organising

Support from the business decision makers is
essential to engineering team transformation.
Buy-in and understanding from all levels of an
organisation is needed to make change work.
Key Points in Transformation

Please let me know if you have any questions?
I am happy to share my experiences.
Cheers,
Matt Brunsdon.
Questions?
19 of 19 | Matt Brunsdon - matthew.brunsdon@outlook.com linkedin.com/in/mattbrunsdon/

• Spotify Engineering Culture
– https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• How to Build Your Own “Spotify Model”
– https://medium.com/the-ready/how-to-build-your-own-spotify-model-dce98025d32f
• Hosting Legacy Apps in the Cloud: Is It Possible?
– https://cloud.netapp.com/blog/cloud-insights-legacy-apps-cloud-possible-cis-blg
• Migrating to an Event-Driven System
– https://t.co/0pPvutDjim?amp=1
• Why Engineers Need To Develop T-Shaped Skills
– https://www.ptc.com/en/product-lifecycle-report/why-engineers-need-to-develop-t-shaped-skills
• Monolithic vs. Microservices Architecture
– https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
• Microservices Reference Architecture
– https://www.nginx.com/resources/library/microservices-reference-architecture/?utm_campaign=nx-apac-anz-aw-kywd-
microservices&utm_source=adwords&utm_medium=cpc&utm_content=eb-
microservices_reference_architecture&gclid=EAIaIQobChMIke-WpeiM6AIVFIyPCh2vVQBMEAAYASAAEgKRuvD_BwE
References

Redesigning Engineering Teams for Expansion - By: Matt Brunsdon

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Redesigning Engineering Teams for Expansion - By: Matt Brunsdon

Similar to Redesigning Engineering Teams for Expansion - By: Matt Brunsdon (20)

Recently uploaded

Recently uploaded (20)

Redesigning Engineering Teams for Expansion - By: Matt Brunsdon