One of the growing topics in technical authoring over the past few years has been Documentation as Code — a philosophy that “you should be writing documentation with the same tools as code”, rather than it being an awkward, disjoint part of your work.
We wanted to get an idea for how Documentation as Code could be useful within Redgate. Our recent project to make Redgate’s Product Development Progression Framework public gave the perfect opportunity, while also letting us get some hands-on experience with Redgate’s Honeycomb design system and tools.
Which tool to use?
As with anything, there are loads of Documentation as Code…
We’ve already shared what a software engineering career looks like at Redgate, but there’s far more to the modern software organisation than engineering alone.
One area we take special care of at Redgate is how we work together to build and deliver that software. This branch of our career progression framework stems from an engineering background, and must maintain a degree of technical competence, but rather than focusing on the tech it looks far more at how we build and deliver our software, if we’re prioritising the right kinds of work, and how we look after our people.
There’s no “one right way” to build software, and there’s no “one right way” to grow your career in software either. That can make it hard to know what to expect with different companies.
We realised this at Redgate, and spent some time trying to understand what typical career paths look like with us.
Let’s start by looking at our software engineering-centric career path.
We’ve recently shared about Redgate’s new Progression Framework, and how it’s helping folks at Redgate develop their skills and careers.
But we also want to share how we got to pulling that framework together.
It all started by looking at lightning talk attendance…
Back in the mists of time
Our journey started way back in 2018.
Redgate has always prided itself on supporting people in their learning and development (L&D). We run internal sharing and training sessions, have regular lightning talks, host internal open space events, encourage attendance or speaking at conferences, invest in Personal Development Plans (PDPs), and even encourage folks to spend 10% of…
Book clubs are a popular way for groups to work through a book or article together and share their insights.
The obvious way to do that, remote or in-person, is to agree what to read, set a deadline, then get together to discuss your thoughts. But can working remotely bring extra benefits?
Enter hypothes.is.
Hypothes.is is a simple online tool, available for any browser (but far easier to setup with Chrome) to help people asynchronously share their thoughts on any article, paper, or eBook you can find online.
So the Coaches tried exactly that.
How did it work?
Well, here’s what we did:
Working as a team of internal coaches isn’t easy. We do complex work with a wide range of people, across many areas and levels within the company.
A recurring challenge is planning and committing to work. With so many stakeholders, and so many things we could be doing, how do we draw up an effective plan without spending a lot of time on it?
We’ve embraced weekly planning sessions, and we’re edging closer to a system that really works for us.
Step 1: Are We Winning?
Like many teams, we aim to achieve certain objectives and judge progress with some…
Back in July we shared our early experience learning from the “Four Key Metrics” presented in Accelerate.
A key part of our journey was making the metrics available within Redgate, by generating simple charts from existing version control data.
We’re happy to share the code we use to do that. You can check out the RedGate.Metrics repo on Github.
I hope it’s interesting for you, and look forward to sharing more of the lessons we’re learning soon.
There’s been a lot of excitement about the book Accelerate, which summarises research from the past several years of the State of DevOps report (which Redgate sponsors).
Perhaps the most popular topic is the “four measures of software delivery performance”, sometimes called “Accelerate metrics” or simply “four key metrics”.
We’ve started to try track these at Redgate, and we’re learning to use them to drive improvements in how we deliver software.
How to track them?
We trialled manually gathering data, by recording release dates or timestamping index cards. …
Some of our teams at Redgate have adopted a Zero Bugs Policy.
We’ve already shared some of our lessons learnt from this approach, but people have asked about the quantifiable impacts of the change.
So far we’ve seen two.
Impact on the teams
Of our two trial teams, one was effectively taking a Zero Bugs approach already while the other was faced with a significant change in how they work.
The team have already freed up 20 hours of time that would have been spent in various triage meetings.
This time has been spent engaging in better user research, investing in the architecture and…
Some of our teams have been trying out a zero bugs policy, following a simple remit:
If a bug is reported that you feel you should fix, then you fix it right away. If not, you close it.
We wanted to share what we’ve learnt.
Did it help with issue management?
For us, yes.
Our teams have spent less time managing bugs, and more time improving the products they deliver.
Do all teams follow the same process?
Not quite.
One team hasn’t received many issue reports. They can handle each report on a case-by-case basis, without a defined process.
Another team had far more issues reported. This has led to a more detailed…
