I’ve received 1:1 messages from engineers asking if they can go into our project management tool and enter in a task. Of course, I say “yes” and also remind them to enter tasks in immediately if it’ll help them unblock their work. This is one way we can empower engineering teams to perform autonomously.
As a Dev Manager, Scrum Master, Product Manager & CTO (I know, there are a few more roles I’m missing) actively practicing ways to build trust and confidence in your engineers is crucial to the health of your team as well as the product.
Having someone breathing down your neck asking for updates on a specific task is no fun. I’m sure many of us have felt this whether we’re engineers or not - that feeling of trying to focus but being interrupted by a manager or a coworker for progress and etas.
I will say practicing the act of trusting and letting go can be hard. Autonomy is usually pre-determined by a companies culture, your company either has it or not. Personally, there’s no reason why you as a manager can’t start making space for autonomous work to flourish. By providing autonomy you’re saying “I trust you to do your job” and that is huge. Engineers should have the ability to work on their weekly workload with little nagging. Get your questions in front of the engineering team early during something like a Backlog Grooming meeting or a 1:1 to avoid hourly check-ins on progress.
Give your team autonomy. Let them do good work. Keep a pulse by using stand-ups or checking progress via your project management tool.
Giving The What and Why, Not The How
I’ve struggled with this before. I even still catch myself writing out let’s build “X and Y to deliver Z” and I have to remind myself to take a step back. As we know, engineers are on the team because they’re the people who can provide solutions to problems for the product, for security concerns and even usability issues. Because of that, it’s better if we pull back on providing solutions for engineers. They really need the “What” and the “Why” but not always the “How”.
You may be asking, “Hmm…but engineers don’t know the product as well as I do?”. Unless you’re deep in the backend code and understand the logic and system design behind the whole product, engineers may actually know more about the product than you - and that’s okay.
Now, how can you work to attain the “Why?” So, my approach for this is when you’re faced with a feature request from a user or from sales get to the bottom of why that feature is useful and when the user found themselves missing it. From that point hop on a call with a developer and collaborate in writing a story or multiple stories to attack that problem. You may have ideas on solutions and feel free to discuss them but please don’t enter a story with a request and the solution written in for an engineer to just do it. We want the engineers to feel confident and creative and by providing them with the solutions we may be undermining their skills.
Involve Early in Discovery or User Interviews
When you are running continuous discovery or whichever method your team prefers make sure to include engineering. That exploratory usability call you’re having with Maria (a frequent user of your app) is a perfect time to invite one of your engineers. When engineers are able to have a touch point with a real person using what they’re building it creates an opening for better work. Engineers will also see how meaningful their work was to folks outside of CX or Sales.
Freedom to Write Stories or Technical Tasks
I remember when I was in Customer Support and I would see my manager writing in bug tickets and I wasn’t yet allowed to for whatever reason. That made me feel less than.
One way to make the team cohesive and really get into the nitty-gritty is to allow engineers to create tasks in your project management tool. Us PMs or Dev Managers are frequently entering tasks in and I soon came to realize that surprise - I’m not a developer, I don’t necessarily know the technical lift behind a feature delivery or a bug fix. So please please please, allow your dev team to place in the tasks they need to keep moving on their workload. If they need a task to spin up a new dev environment, let them do it. Don’t require them to come to you and get permission first. This all causes delay when we could be moving and taking steps towards release.
Make That Change Today
I’ve worked for companies on two opposite extremes - one extreme was engineers who felt no freedom to move the needle forward and on the other hand a team who grew into feeling empowered to run. Let me tell you, having a team who can run autonomously and collaborate with one another is a dream. Given the right communication, specs and involvement with users can really take your engineering team to new heights.