DEV Community: Tim Knight

Leadership Forums

Tim Knight — Wed, 19 Jul 2023 13:09:38 +0000

I want to talk about one of the Software Delivery Community initiatives we have going on at Opencast, the "Leadership Forum", where it came from, why it exists and the benefits it's having already.

Where it came from?

When I first joined Opencast in 2021, there was an informal fortnightly "Senior Developers coffee call", where we'd drop in, discuss issues we were having, drink coffee and generally get to know everyone and what was going on across the various clients. However without a specific focus and a mission statement for who the call was intended for, it ended up meandering before finally it stopped sometime in 2022.

However, the idea of a more informal support group was something which really spoke to me, and I knew I wanted to do something with that again, but I just needed the time to focus on it. Fast-forward to me accidentally posting in the old Teams group for the Senior Devs call, and seeing a lot of interest spark up, providing the spark to actually make me sit down and hash out a new Forum.

Why the Leadership Forum exists?

My initial starting point before setting up any meetings was to define the Mission Statement of the Forum, why, who, when, what name?

Why?

To provide mentoring and peer support for colleagues who were having challenges when leading teams.
To provide ideas to help colleagues grow into team lead roles in future.
To allow colleagues to find peers who they could privately talk about sensitive topics/issues with.
To reduce the time demands on Senior Leadership and our Practice Leads, by sharing the load over the plethora of knowledgeable Consultants.
To share best practices and Opencast values.
To use Lean Coffee to allow multiple voices and issues to be discussed.

Who?

I wanted to create a forum which would be open to those currently in Leadership positions and those wanting to grow into it.
If people didn't feel comfortable joining directly, they should be able to talk to their PEEP, myself or a Community Lead, who could encourage them to come along. (I believe I said to someone "Yes this is explicitly for you too").
A rising tide raises all boats after all.

When?

Fortnightly to begin with, so it didn't eat lots of time, but we'd have plenty of touchpoints.
I considered Monthly, or a reduction down the line, but it keeps having extremely strong discussions so right now, Fortnightly seems to be working for us.

The Name

I hate the name "Leadership Forum", not going to lie, but finding something better wasn't going to happen.
I like naming things with the Ronseal approach, do what it says on the tin. And this is a Forum for Leaders and Leadership Growth discussions.
So why don't I like "Leadership" as a name, well, we have the concept, as I'm sure many companies do, of "Lead Consultants", "Senior Leadership Teams", who are generally the more senior and management levels. And I wanted a name which was accessible to the audience I'd set out to cater for, "Leadership", "Lead", they have a lot of other connotations.

Now that I had a name, a purpose and an audience, it was time to create a Teams channel, a public calendar and get those meeting invites out!

Boy was I blown away by the support I received for it, we've had excellent turn outs at every Forum, they've run themselves when I've not been around to facilitate, we've covered various difficult topics and empowered our consultants as a result, and we're uncovering new pain points that need to be raised with our other internal teams!

I've had great feedback from my peers, especially Amaal Ali - who is always supportive and kind, along the lines of "I'm glad you brought this back, you're someone I trust to help keep us on track".

Doing it in your company.

You've heard of the Spotify model I'm sure, and other methods people have done to cross-pollinate ideas between teams. This is just one of many ideas out there, but I highly encourage you to look at peer-support networks in your business, they ensure the company culture stays strong as you grow, they provide safe-spaces where people can talk freely with their peers without worry about how it might impact pay/performance, and they allow those peers doing the mentoring to grow a new aspect of themselves!

Define your Mission Statement.

Figure out your Audience.

And watch it fly!

Maintaining a High-Performing Team

Tim Knight — Mon, 05 Jun 2023 15:06:27 +0000

I’ve read lots of blogs on “Creating” a HPT, but few on how to maintain them when you’ve got them.

This blog is just one way of maintaining them, my way.
I’m sure there are other methods people have employed.

What is a High Performing Team?

Let’s define our terminology, so you know what I mean when I say “High Performing Team”. A high performing team is accountable to each other, there is trust, and they are all moving in the same direction. Generally we might summarise this as “High Performing Teams are Psychologically Safe, and as such conflict is creative and work is completed at a fast pace to a gold standard.”


by Lenny LaCour

Building a High Performing Team

I’m not going to go into this in detail here, I’ll link some good blogs on the matter, in short, give clarity to the team on what everyone’s role is, collaboratively agree on your goals and what is important to you, iterate on these through several cycles until you are in a good place.


Also known as Forming, Storming, Norming, Performing from "Framework for assessing of high-performing teams"

Maintaining a High Performing Team

Okay, so you’ve built your HPT and everything is going well, your team is happy and cracking through the backlog.

How do you maintain this state? (spoiler: you don’t)

If we think of the Team as a Car, then there are lots of ways we can envisage how to do maintainence the High Performance nature.

Firstly, we can perform regular check-ups, are we well oiled as a team, are there any warning lights coming on? This is where your Retrospectives come to play; ensure you occasionally mix up your retros (or change every time), to ensure you don’t fall into the same patterns and miss the blind spots those patterns have. If you’re always asking “What Went Well” and “What Didn’t?”, you miss out on things which were fine, or might go wrong, but just haven’t yet.

Secondly, flag your warning lights to a trusted colleague. Your team should be psychologically safe, therefore if something is annoying you, check in with someone else on the side, if they’re also struggling then the two of you can work together to raise or solve it, if the problem doesn’t frustrate them, they maybe able to see why something is happening and help you to resolve it. AKA find or be a Rubber Duck.

Making space for the Team

"Okay Tim, I’m doing all of this and my team is rocketing through the backlog, we’re just about to deliver another Feature the customer wants and everything is a-ok."
"Is it though?"

On the surface this looks great, this is your High Performing Team doing HPT things, you have a feature rich ecosystem and your retrospectives are all producing small actionable items and the team is happy.

But what if you’ve been going like this for a Quarter/Half year?

Is your team on the edge of burnout?
Do you have capacity to react?

Back to the Car analogy;

| If I am in the highest gear and at the top of my speed, I’ve got nowhere to go. If something suddenly pulls out, I can’t accelerate round it, my choice is slam on the brakes or crash, neither of which is going to do my car good in the long term (or in the case of crashing, the short term). |

We need to take our foot off the gas.

Rather than wait for something to force us back into “Norming” or in anyway break that High Performing flow, we can choose to stop High Performance.

I’ve done this in several ways with different teams, at different companies, it all depends on the setup, demands, etc. You may not be able to do this with the whole team at once but maybe you can do this in a split 50:50, 25:75?

Post-Feature cooldown: you’ve just shipped MvP, or V2 of a feature, it’s with the customer and you know you’ll soon get feedback. You almost certainly built up some tech-debt in feature dev, if you don’t think you did… ask your Developers, because, let’s be real, you have tech-debt, everyone does. If you use a week/sprint to tackle the tech-debt from that feature, then it’s a molehill, if you leave it, it’ll become a mountain. By the time you’ve tidied up, you’ll either be ready for the next feature, or you’ll have feedback for your next iteration/bug-fixes.
Firebreak: We’re trying this right now on my current project. Taking a week out of normal sprint activity, to recharge those batteries, get on some learning (which will inevitably pay off for our upcoming work), catch up on admin (issue management etc) and write some blogs (this one here). For teams without common Features, or other clean breaks, the idea is that every N sprints or weeks, you take time out to catch up on tech-debt etc.
Onboarding: if you’re onboarding someone new, a good way to ensure they don’t get left behind is to slow down, work on those tech-debts and use it as a way to give them a great overview across the system.

You’re deliberately choosing to drop out of high-performing, so that it’s a lot easier for you to step back into it; the engine is still well oiled, the gears are smooth, you can hit that pedal and get the acceleration.

If you leave it until something broke, you’d almost certainly have to fully rebuild the High Performing team, which would take a lot longer and be more mentally taxing.

Go slower Now, to Go faster Later.

My Career Journey

Tim Knight — Mon, 26 Apr 2021 08:22:19 +0000

Hello, my name is Tim and I am non-binary. My pronouns are They/Them and I am gay. I joined UKTV’s Tech and Ops team at the end of February and want to say a big virtual hello to the entire team. This is the second job I’ve started during a lockdown period after finishing a contract with School of Code, an educational software bootcamp. I’d like to share a bit more about my unique journey from studying rock formations to a career in the virtual cloud.

It’s safe to say I’ve come into the tech industry in an unorthodox way. I know there have been sessions around the idea of 'squiggly' careers of late, so I’ll set the scene with my own squiggle (is that the right word? Who knows, I’m using it though).

I did my university degree in Geoscience, specialising in Geophysics and Volcanology, with a master's degree focused down on modelling convection within the upper mantle and how that impacts volcanism in places you wouldn’t normally expect a volcano. From there I attempted a PhD but after falling down a bit of a pit I decided to move on and bounced around a few temp admin jobs at the university, before landing my first tech role with Ikon Science. They tested me for logical capacity on the basis that it was easier to teach me, a geologist, to code than it was to do it the other way around. I was able to use my scientific knowledge to directly help the development teams and had some fun working with the on-staff doctors to implement their theories in the software.

I used that opportunity to make the move fully into tech and away from my degree subject. I ended up working in Birmingham and specialised in AWS (Amazon Web Services) and the flights Industry. I still have a ridiculous amount of air transport codes in my head, but I hope they’ll go away soon and I can use that space for something more interesting.

In June last year, with everything related to furlough and the pandemic I decided to move in a different direction to really stretch myself. I joined the School of Code, helping the CEO develop his junior development staff as well as running a bootcamp for apprentices. I’ve learnt a lot about coaching in that time and now I hope to bring some of that knowledge and energy to UKTV alongside my tech skills.

I hope my career story inspires you to try something new, and know that wherever your path takes you, you can still end up somewhere great and respected in your field (I type hoping the team agrees).

Tim with Poppy, their cat they adopted in 2020

await Promise.all: not just for async functions

Tim Knight — Thu, 21 Mar 2019 15:25:54 +0000

In our code we end up making a lot of asynchronous, independent calls to 3rd party and internal REST APIs in order to build up among other things, currency conversion rates, Airport IATA Code -> Name mapping and getting a result set for a user's Flights search.

This led to a lot of head-scratching about how to improve speed, we needed all these calls to resolve before we could continue, but because they were all independent did we need to wait for each Promise to resolve before we could invoke another?

In short: no, we could use Promise.all to invoke all our independent asynchronous calls at once, and await them all to have resolved, not worrying about which resolves first:

const [
 conversionRates,
 airports,
 flights,
] = await Promise.all([
 getConversionRates(),
 getAirports(),
 getFlights()
]);

Brilliant! We're waiting once, for the longest process to resolve and gathering all out data in one go.

But we still have some synchronous calls later one which again, are independent, non-mutating functional code. Could we do the same thing there?

Yes was the answer, with a bit of fore-thought about grouping functions together and making sure our code was fully functional in design, we are able to use Promise.all to await the results of multiple functions regardless of whether they are defined as async or not.

Write functional, independent synchronous and asynchronous Javascript functions
Run groups of them simultaneously using Promise.all
Await for all the functions to resolve, rather than one at a time
???
Profit

Agile: Optimising our Workflows

Tim Knight — Wed, 20 Feb 2019 16:38:36 +0000

Or why we stopped caring about "Effort" and strict Agile.

No two people, no two teams, will agree on what “Agile” means.

I should say before I get into the main thrust of this blog post, that just because this works for us, it won’t necessarily work for your team. Though you may want to read this, bring it up in your team, and decide what “Agile” means to you and what workflows you are doing because they’ve always been done, if you’re not using that data within the team, or could be using that data more effectively.

“Agile” as Guidelines

‘They’re more what you’d call “guidelines” than actual rules’

Our Agile process should adapt to the team’s needs, rather than hinder their growth or efficiency by constraining them with a fixed set of rules.

A real-life example of sticking to the Rules:
In an old job, we did “strict” SCRUM, recording effort, estimating complexity and time, performing repeated retrospectives to hone the team to know exactly how hard things were and how long they would take. From that, we could plot velocity and plan SCRUM from that. However, this ate a lot of time, and we probably didn’t need to be so strict, EXCEPT in that team we had an external client we updated every 2–3 weeks on progress and had to show concrete data to them to prove our workflow and explain any delays.
On the flipside, we could artificially inflate or change our velocity with easy tasks to buy ourselves time to complete larger tasks we deliberately underestimated. That didn’t help the team at all because we couldn’t trust our own estimates, but it was needed to keep the client happy, which in turn reduced pressure on the team.

Now back to my current team at ClickTravel;
I’ve spent a lot of time this week thinking about the “software” side of Team leading, how to make the lives easier of my team not through any code or automated pipeline, but simply by changing our internal practices.

Changing how we use JIRA and Asana

My Product Owner and I spent a whole afternoon talking through our use of JIRA/Asana, how we felt each should be used and then going through and actioning those changes to JIRA.

This resulted in clearing down our JIRA backlog of over half the tasks and tying a lot of the weeks/months old Technical tasks or Improvements which we hadn’t had time to do, in with upcoming Asana cards. In future allowing us to deliver new Product Features whilst simultaneously tidying up tech-debt or implementing other improvements, we’ve spotted within the codebase.

After discussion with the team, we collectively agreed that our JIRA dashboard should contain only work in focus, or expedites, and anything planned but not in focus would sit on the Flights Backlog. As a team we can then organise the backlog in Priority order, meaning if anyone is off on a planning day, or someone finishes focus work early, the team can look at the backlog and simply pop some tasks off and into the dashboard. Our snippets meetings then become times we can sit down, run through what we’ve done, and looking at the ordered backlog and simply deciding how many tasks we think we can pop off onto the Dashboard.

Our dashboard has become much cleaner and obvious what needs working on that week, and our backlog similarly can become a team product to keep clean and ordered, so when work is to be done, the team knows they can simply take off the top of the backlog.

‘Gotta go Fast’

Stopping caring about “Effort”

Cycling back round to the first point, during our discussion about using JIRA within our Kanban cycle; I raised that during the week, people should move cards to “LIVE” with Effort recorded, but not move to DONE, as that is something we’d review as a team during Snippets and use to inform our weekly achievements.

Which has the added side benefit that we don’t have to remember what we’ve achieved, anything we have achieved is in “LIVE” waiting to be moved to “DONE” at the end of the week.

But with “Effort” I was asked, “Why?”, at which point we paused.

“Why do we record Effort?”

Well in Agile theory to measure our velocity against our estimates.

“But we don’t do any estimation of story size, as story points, within our Kanban flow, nor do we measure our velocity.”

So what was the point in having to record effort, or more importantly, having to remember to record effort, or someone explicitly having to spend time asking people to record effort days after the fact?

Within our team, the answer was a resounding: None.

So we stopped caring and removed it from our JIRA cards (we set up a team-specific ‘screen’ in JIRA because there were some fields we wanted adding just for us, therefore it was relatively trivial for me to remove the ‘Effort’ field from our ‘screen’).

That’s not to say recording “Effort” is a bad thing if you are using the data you collect within your team to inform your planning.

Nor is any of this to say that our Kanban flow, JIRA and Asana use are the one true way, quite the opposite.

There is no One True Way; Agile should work for you, rather than you working for it.

If sticking to a tried and tested flow works and improves your team’s efficiency, rather than not, then don’t change just because I wrote a blog post, that’d be the worst outcome I’d want!

Simply think about what you use your Issue-tracking tools for (such as JIRA/Asana) for;

How you use them and is there anything you’re doing because they’ve always been done?
Is there anything you could change or remove which would actually save you time in the long run?
Or do you want to add in processes such as Estimation because measuring velocity will help you plan your project timescales more effectively? There’s nothing to say we won’t change our minds down the line and add in processes we’ve removed or some other “Agile” process.

‘There is no one Agile Methodology to rule them all’

Tim Knight
Flights - Tech Lead
Click Travel