The Future of Engineering at Redgate — A futurespective empathy map approach

One of the thing I love the most about working at Redgate is that we constantly challenge the status quo and we are open to reflects on how we can become an even better software company.

Last week, I facilitated an experiment with Jeff Foster with the goal of imagining the Redgate Engineering function of the future through the eyes of a future new starter.

We decided to build an futurspective empathy map all together.

We started by showing the description of a future persona.

Future Redgater

We then split in three groups and each group individually built an empathy map trying to answering the following four questions:

• What are Gina’s main activities?
• What does Gina think?
• What does Gina feel?
• What does Gina say?

Follow an write-up of all the individual answers.

What are Gina’s main activities?

• Asks the quality coaches for help and guidance
• Write good, clean code by following the example in the existing codebase
• Reviews colleagues’s code + has useful feedback to give
• Shares her previous experience and how some things could still be improved
• Constantly explores the work she produces without leaving it until the time to ship it
• Gets involved in retrospectives, open spaces, etc.
• Pairs with everyone
• Release in one click because the process is automated
• Learn/Explore new things on 10% time
• Involved with customers & research at an early stage
• Holds her team accountable for quality of their work
• Checks out all source code and it builds first time
• Finds a central resource with all up-to-date information
• Able to work on items she is interested in
• Pairs on the bug fix with a more established team member
• Can get code to customers really quickly and get feedback
• Ship on a martini in a hammock on a beach in Bermuda whist remotely working with her colleagues in Prague
• Write a test first to reproduce the bug
• Shiny web-tech
• Shiny not-web tech ;)
• Pair with other developers because everyone does it!
• Use TDD whenever possible and make sure all new code she writes is tested
• Browse internal sites…
• Write code without all the overhead
• Find out about how other products fit together towards a company goal
• Participate in learn & share activities with the team regularly
• Participate to many team discussions on how to make the code base even better
• Share knowledge & experiences

What does Gina think?

• How can it be possible to get feedback on her code so quickly
• Our codebases live up to the standards we preach
• Being effective is the new being productive
• Is Raygun broken? Why users don’t report crashes?
• Hears “How could that be simpler?”
• Open space was amazing so much learning + excitement!
• Can’t believe NCrunch works so well
• The roadmap for my product looks exciting
• I can do this!
• The code is really easy to understand
• Can ask anyone anything at anytime
• Knows how what they are working on contributes to the wider picture
• There is a clear division of responsibility between codebases
• All key metrics are visible and people act on it
• A red build is taken seriously around here
• Constructive criticism is going to help me grow
• Oh, people write clean code here. Hope I am good enough.
• It was the right move.
• All the support and personal development opportunities are fantastic!
• Mmm… free food
• Our products solve hard problems

What does Gina feel?

• Proud of the products & everyday work
• That she can make a difference in week 2
• Her new colleagues support her
• Confident to change code. Confident in tests
• She can ask coaches about different testing processes, skills and techniques
• Feels able to experiment and make mistakes in safety
• Impressed by the high coverage of the code
• Opportunity cost is taken into account when deciding what to do (not to do)
• Confident that joining Redgate was a great move
• I want to understand the problem space
• There is a good test safety net
• There are no dark corners which people have given up on
• There is good and frequent feedback
• Feels confident making changes
• Feels welcomed by her team and involved with the work
• Freedom to revisit and improve old code
• Feels she knows what the team is working towards for a sustained period of time
• Feels she is learning
• Pressure but not unreasable pressure
• We are working together
• Feels limited by the boundaris of the problem space rather than tech debt + creaking infrastructure
• Great to have extremely fast PCs and many monitors. Hardware is cool!
• Comfortable to challenge
• Proactive
• Learning lots
• Overwhelming code-base
• Colleagues are here to help
• Supported but stretched
• Secure sharing difficulties
• No barries
• Colleagues are friends
• Wind in hair (while using Nigel’s slide)
• Redgate understand its customers

What does Gina say?

• To all her connections out there how enjoyable working with simple and testable code is
• She’s happy with her equipment and tools
• Can’t believe people are using my code only fixed it yesterday!
• I am so glad you don’t use %obsolete-tech% here
• It’s great you are using C# 12 already!
• It’s great to understand how the product works and how is using it
• The code is easy to understand
• No repetitive manual work because all these is automated — Great!
• This code is amazing
• How do I reproduce this bug?
• Wow! Code coverage is so high and tests run so quickly!
• Redgate is a great place to grow
• Redgate is an awesome place to work
• Where do I find… ?
• I fixed my first bug!
• Understands how her work contributes to the company success
• Can I ask you about…?
• How can I be even better?

Open Discussions

The open discussion was the most interesting and engaging part of the workshop and a lot more people joined the discussions up until 5pm.

This is remarkable on a Friday when people tend to leave earlier :)

We spent a solid hour talking and trying to understand how we can close the gap between the current Redgate and the future reality we pictured together.

How can we close the gap?

• Identify where are the biggest gaps
• Everyone attend soft skills and UX training
• Consider the Dreyfus model before pairing
• Remove/Fix all flaky tests
• Create a list of all training available
• Stop doing planning during retrospectives
• Each team has a clear list of what they currently trying to improve (code and processes)
• Resolve fantastic beast confusion.
• Create a survey for new starters to fill x weeks after they join (example question: what are the top 2 things that can be improved)
• Every build increase code coverage (break the build if goes down!)
• Organise a product division retrospective on engineering
• Quantify in money the tech dept we have (regularly)
• Each team has an operational risk board
• Use “Fix day” where all product teams improve their codebase
• Product team engineering award at Duxford Conf
• How can we celebrate good code more?
• Identify what are external/shadow pressure that prevent us to improve code
• Swap developers beween projects more often
• Identify which products were created in house vs acquired
• Add positive feedback section during exploratory testing
• Call out what you like in code reviews
• Track tech debt, make it visible, set a threshold that should never be crossed (The SQL Release team did it for 2 years so every team can!)

Conclusion

The experiment was very successful and generated a lot of new ideas.

If you want to find ways to improve your company, I would definitely give it a go.

The most important step is obviously act on some of these feedback and continue to organise activities to learn together and make our organisation an even better place to do great work.

If you are interested in working at Redgate, check out our current opportunities. We are always looking for new people with an open mindset that want to make a difference!

Andrea Angella
Microsoft MVP | .NET Community Lead | Senior .NET Engineer
www.productivecsharp.com