I came to Redgate over a year ago now. As part of the induction process, the leadership of the Product Division talked about a few of the books that have informed their approach to management.
Both books I was reasonable familiar with but it did emphasise the close values alignment between myself and my new employers; they were, Drive by Dan Pink, and Turn The Ship Around by L. David Marquet.
The Promised Land
When I first moved to Cambridge, over ten years ago now, I worked for a company that happened to be opposite Redgate; both geographically (just across the road) and culturally.
As you walked along the top floor landing above the Atrium during your timed toilet-break (I’m only partially joking), the Redgate building across the road looked like the Promised Land; where staff shared tea and coffee casually in the atrium, set off the smoke alarms with toasters, and had juggling lessons on the grass outside.
As a great analogy, I’m told at one point after I left, Redgate took pity on the staff opposite during a fire alarm whilst it was raining heavily, and let them in to the Atrium.
But it had got to the point where I assumed that I would never work for Redgate, due to an accident of technology, many years before; Redgate had always been focussed on SQL Server and the Microsoft stack, I had years of experience in Javaland as well as how to go about delivering value from software as early as possible and make sure you are delivering the right thing.
And it is, frankly, all too tribal.
When I mentioned I was becoming available, and someone at Redgate suggested I apply to join as a Technical Lead, I was quite happy to — indeed it was nice to be wanted. And it seems I sailed through the interview process; I was still nervous waiting for the final call though, I thought I’d fluffed up a question.
Being a Tech Lead
The Tech Lead role at Redgate is an All-Action-Hero role. It is both Leading and Line-managing a team of developers alongside a Designer and Product Manager. Any hands-on development is a bonus, especially to begin with.
The blend of skills required does make hiring for the role feel like searching for Unicorns. Quite a few have stepped in to the role, but stepped back again
I have no problem with understanding the syntax and language of C#. It’s the difference in (some say lack of) build-tools, the subtleties between Dot.Net Framework, Dot.Net Core and Dot.Net Standard, versions 2.2 and 3 of one of them, versions 4.6.4, 4.7.2 and 5 of another, and version 7.0, 7.1, 7.2, 7.3 and 8 of yet another. And how they all interact. Or don’t. That’s what makes me feel queasy.
It felt simpler in Javaland (it’s more recently it’s got more complicated, with a new JDK every 6 months), or have I Stockholm Syndrome? I told you it was Tribal.
On top of this, the team has dived straight into Electron* and Typescript which I haven’t had the chance to pick up with everything else that’s going on.
*= One of my team, Mark, appears to be writing The leading blogpost series on the subject!
Giving the conflicting pull on my time, I do get time to be hands on technical but it’s so disparate that it’s hard to pick up a task and take it completion (in one go); a few times, I’ve got a change together, but then not had a chance to turn it into a Pull Request and get it on master.
This is where Mob Programming really helps; something I’ve helped Redgate adopt a lot more widely whilst I’ve been here. The week before last I joined in a session with my team and we thrashed out how to solve a problem we had, I was able to contribute, do some hands-on ‘Driving’, understand the problems the team were working on, before being dragged away to the next thing I needed to do.
Living ‘Turning The Ship Around’
Thinking back, I’ve been living Turning The Ship Around.
With a deep knowledge of one set of technology, I’ve dived into the context of a different technology — in this case software stacks, not submarines.
I’m lucky to be heading up a great set of developers, and all I’ve needed to do is keep a focus on what we’re trying to achieve, have identified the shortest path to it, alongside what we might like to do to embellish when we get there, but also make sure we get it out the door at every opportunity we have to get it in front of a customer so that we get feedback.
In terms of Intent-based leadership, as part of the Team Charter that we put together when the team was coming together, I signaled my intent for the team to be as close to Continuous Delivery as possible.
I have also encouraged the team to live by “No Surprises”, which on reflection is another way of expressing being Intent-Based. Former Redgater Elizabeth Ayer blogged on this subject very eloquently — “Don’t ask forgiveness, radiate intent”.
I’ve been able to challenge the team on how we go about doing things, how we present our code, (see … something on Code as Content), how we go about logging, dependency injection, testing, architecture and design, but have been able to trust them to write the best software we can.
Just with the occasional nudge.
Leading not Micro-managing
I’ve also been careful not to assign work to a specific person, but to describe something that needs doing, or more often facilitate the team to decide what needs doing, ask for a volunteer, and make sure they’re supported to success.
There have been exceptions to this, and I’ve sounded people out, but they’ve come from requirements of having (experienced) representation from across the Division, or they are a suitable activity to answer a specific Personal Development area, or indeed they are responsibilities that need to rotate round the team.
Examples include presenting the teams progress to the division or company, making sure everyone can do a demo of the product, being primary contact for a customer within out Early Access Program, or leading a customer call.
Living your Values
Through these approaches I feel I have given the team members Autonomy, Purpose and Mastery as well as Intent-based Leadership. Not that the Ship really needed Turning Around in the first place, but it did need starting and keeping on course.