Geek Culture
Published in

Geek Culture

TL;DR Encourage your team to do what they want. Let them Level-Up!

TL;DR

In the last few years, I’ve seen a few companies from the inside and spoke with a few more about “how to find the right balance between tech debt, strategic thinking, personal contribution and regular product-driven deliverables”. Unfortunately, none of these companies knew how to bite the topic and implement something that will work for engineers and the business at the same time. They tried, but with mixed results. From my experience, it usually all boils down to one thing — non-engineering decision-makers don’t understand the value of letting programmers (or other creatives) drive the change and work on something non-product led. This post focuses on the “personal contributions” as they are the essential driver of engineering excellence, happiness, and efficiency across teams.

So, why should we allow teams to do what they want?

And why technology leadership should do more to support such initiatives.

  • People are much happier when they have a chance to work on what they genuinely enjoy and believe in.
  • It’s a way to get people more efficient and more committed.
  • Teams feel their work is valued in the company, and they can make a personal impact.
  • It gives an opportunity to write code, learn new skills and grow the team in new directions.
  • Finally address problems that existed for a long time, and nobody ever had time to work on them (codebase, projects and processes).
  • A chance you will learn about challenges nobody ever mentioned before! That’s an eye-opener, and you can help your team.
  • Expect increased engagement within and outside of the Level-Up workload.
  • You can’t afford not to do it. It’s a small sacrifice for great benefits.

If you are interested in how I approached the Level-Up Time, why it is important, and my experience implementing it in three different places… keep reading.

Why do companies have such problems working on technical debt and letting engineers decide?

  • Product-driven engineering teams.
  • Lack of understanding of the importance.
  • No trust in people doing the job.

If these answers resonate with you, that means you have more significant challenges in your company than level-up stuff.

It usually doesn’t work for different reasons, but from my experience, the most common is the lack of understanding of the importance of such work and the company’s obsession with delivering yet another feature or piece of functionality. As a solution to this challenge, some companies implement 20% of engineering time towards technical improvements. But, unfortunately, it’s only a dream as most of the time, the product and delivery teams do not allow it to happen (with various excuses).

When technical leadership fails to explain the purpose and get the business’ buy-in, it all ends as another empty promise and disappointment. All that happens when we, engineering leaders, suck at our work. We shouldn’t blame others, but first, look at ourselves and think about educating people outside of our group to show the value. We can do better, and we should!

The most destructive part of it is not lack of support and understanding, but the absence of inspiration and structure. It is a death of promise and hope that engineers can finally move technology improvements off the ground and do the right thing. If we fail our teams again, it will erode trust and convert our talented and motivated engineering team into robots who care only about their salary and free food. It would be better not to introduce initiatives like that if teams are not empowered to enforce them.

Occasional hackathons are a different way of approaching innovation. They are often not very ambitious or interesting with the result in mind like “deliver value for customers but primarily $$$ for the company”. It sometimes feels like engineers are asked to do the product team’s job rather than feel inspired the next big thing. That doesn’t mean we cannot make it better. Always worth trying.

What is Level-Up Time?

It’s a dedicated amount of time towards self-improvement and work on exciting projects. It could be anything. From fixing the constantly crashing application, writing unit tests, learning new languages, working on soft skills, getting involved with projects outside of the team, working on performance improvements, and fixing these crashing release pipelines. Really, it could be anything, as long as it brings value to the company and makes us better. When we put faith in our teams, we will be rarely disappointed. See how their ideas help to fix the technical debt and how you can address the long long-term tech improvement strategy driven by your team. It’s a win for everybody, especially if you can have people working on projects they like and care about.

Now, let’s be clear. It doesn’t mean the team will decide 100% of their time (maybe in the future?), but instead, we can allocate 20% for Level-Up Time. That should be enough to start with and review later if that works.

Why?

I said a lot about this in the TL;DR section (scroll up and reread it), but I just want to add a few more words…

Level Up Time is how we build excitement and trust. It will be a 20% investment from the company, but we will get so much more back. It’s hard to put a price on innovation and happiness. The team will feel that the organisation cares about their input and gives them the opportunity to come up with new ideas. We will also learn more about the people we work with and what they genuinely care about. That might have a future impact on how the team will grow and what their natural strengths are.

It also helps to avoid “the boring”. Sometimes engineers get bored on a project. It happens. When it’s too much, and they would like to do something else for a short time, that’s where we can use level-up work to motivate them.

How to implement Level-Up strategy?

  • Start small in one team as cultural differences will impact how the best rollout strategy within your company. Modify the idea where needed and then spread it across all other groups. Lead by example and don’t force anybody.
  • Make sure the team understands that Level-Up stuff is as important as any other project. You can’t have the product team saying, “this is not bringing $$$”, and blocking the work.
  • Talk to engineering and other business leaders to establish expectations and get buy-in. You all have to be on the same page and understand the importance.
  • Ask the team to come up with a list of things they would like to work on. Whatever they want, as long as it brings value to the company. Leave it open to learn what they truly care about.
  • Encourage to bring up small projects that can remove obstacles, make the team’s day to day work easier, improve something they were always annoyed about (code or process).
  • Agree with each team member on what they will work and make officially part of their quarterly goals. It will make you accountable too.
  • Each person should create more detailed tickets in a dedicated swim lane to be pulled in during planning throughout a quarter.
  • You know your team’s output (if you don’t, that means you have some work to do first), so ensure they move towards Level-Up Goals during every development cycle.
  • If you skip this type of work during one sprint, make up for it during the next planning.
  • Each team member will have around 13 days of work in a quarter (2.5 working weeks). That’s a lot of time to deliver value, especially when you consider the whole team.
  • At the end of the quarter, review what you achieved and spread the good word. Make sure this work is visible and recognised outside of the team.
  • Commit!

People will be genuinely happy when they see it is all REAL, not just another corporate bullshit with no real impact. All in your hands to make it happen! The most important thing — if you want this to succeed, Trust Your Team. If you don’t… Well, that’s something you should work on first.

If the team did not have time to work on their Level up Goals and failed to deliver, that means you failed as their leader, harsh truth.

What I’ve learnt from bringing some structure around tech improvements, technical debt and non-company driven projects?

I was lucky enough to work in companies where the majority of my workload I generated myself. In some cases, that was over 75% of my time which I could invest in building new architecture, new release pipelines and other exciting things. So how awesome would it be if other people in my team could do the same?

Initially, my experiments started with an introduction around how to deal with technical debt and general improvements. Often it just ended up by setting up a small dedicated team for a short period or re-focusing the whole team for two weeks to clean up stuff. But that’s far away from pleasurable. It is simply a chore.

The next step was to allocate 20% of teams’ time to work on debt, but that requires a lot of top to bottom oversight and a constant battle with product commitments. Far away from perfect, actually, it was inefficient and time-consuming. But, unfortunately, this is where most companies end — the endless struggle of priorities and lack of faith they will be able to find a solution to this challenge.

I was lucky enough to work in companies where the majority of my workload I generated myself. In some cases, that was over 75% of my time which I could invest in building new architecture, new release pipelines and other exciting things. So how awesome would it be if other people in my team could do the same?

Initially, my experiments started with an introduction around how to deal with technical debt and general improvements. Often it just ended up by setting up a small dedicated team for a short period or re-focusing the whole team for two weeks to clean up stuff. But that’s far away from pleasurable. It is simply a chore.

The next step was to allocate 20% of teams’ time to work on debt, but that requires a lot of top to bottom oversight and a constant battle with product commitments. Far away from perfect, actually, it was inefficient and time-consuming. But, unfortunately, this is where most companies end — the endless struggle of priorities and lack of faith they will be able to find a solution to this challenge.

The Level-Up name came from an android manager who worked in my team in the past. I felt that this is what I was looking for, the perfect name. It better reflects what 20% is about, makes it more flexible, give people the power to decide what they want to do and how they want to contribute to the company’s success. We’ve been running the Level Up in this form for a while and works great! To make it interesting, we already have new ideas how to improve it, especially around adoption in inflexible or hesitant teams.

Try it and tell me how that worked out for you.

The latest form of the Level-Up works very well in my current team (the best!), and that’s why I decided to share it with you.

It’s now your turn to try and once you do, let me know if this worked out for you, what obstacles you found, what didn’t work for you, and how you improved it even further. Maybe someone tried to implement it in a non-software-engineering team? That would be interesting and likely beneficial. I would love to hear from you.

I’m sure it won’t work in every workplace.
Not every team will like to do it this way.
You will get a lot of pushback.
But if you don’t try, you won’t learn.

--

--

--

A new tech publication by Start it up (https://medium.com/swlh).

Recommended from Medium

HTML File Structure: A Learning Journey to Web Development

Implementation gRPC to Domain Microservices

Writing clean code

10 features where Coda is 10X better than Notion in 2022

Let’s have a look at how AWS names their products…*eye twitch*

Develop and Deploy C#/.Net Core applications for AWS LAMDA

Benchmarking Different Web Frameworks

How to create a cprofile decorator class and save stats in Docker Container— Python

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrew Winnicki

Andrew Winnicki

Software Engineering Changemaker. Driving digital transformation and sharing experiences and thoughts from my journey. 20 years and counting…

More from Medium

My Goal is to Ship

Four Crucial Criteria for Delivering Software in the Digital Age

Four aces.

Things I’ve Learned While Onboarding Remotely as a Tech Team Leader.

Don’t be a hero manager