Depending on the organisation, size and the number of teams, Engineering Managers can code from 0% to even 50% of their work time. In my case, it was 0% - for around 12 months of dealing with two teams having around 6 people each. I probably could find a time to do it, but I usually felt that I’d be doing that from my own fear of getting rusty, instead of this activity being the most impactful one that I could do right now.

However… that caused me to be blind for some of the obvious problems.

The usual situations

As engineering manager, your job is to remove blockers, support your people, hire them, coach them, improve the process and so on. It’s funny that we usually think that we understand the entire process very deeply and there is not that many things that could surprise us. I sometimes ask people to find out if there is something that I cannot see, by asking a simple open-ended quesitons like:

If you would be me, what would you change?

or

What’s not working as it should?

I sometimes get incredible answers - especially from new people - but usually engineers say, that everything is fine! When my boss asks me the same questions, this time it’s different:

• In case of my teams, I can change whatever I want so if there is something that I want to change, what’s stopping me?
• In case of this question, probably I need to look from a higher picture, outside of my teams - here the question makes more sense.

However, just recently we’ve added Backstage to our system, and thanks to that I’ve learned another, great source to open my brain and eyes for problems that people seem to ignore.

Being in the process for a second

In order to add something to Backstage, you need to commit directly to git repository. You can either configure Backstage configuration .yaml files or update documentation, which is automatically synchronized and published in this developer platform. Either way - what’s important, is that you need to literally commit stuff and use your pieplines to change anything.

As a result, in a couple of days I published MR’s to over 20 different repositories that we have (for the first time in 12 months). By doing it, I quickly discovered, that:

• We have a lot of flaky tests which fail even when I’m doing non-braking changes like updating the docs…!
• We have different code style linters across these repos.
• We have inefficient manual deployment queing process which distrubs engineers focus.

The last one was especially shocking to me because nobody told me about this, probably due to learned helplessness. I knew about the others, but I didn’t expect that they are so annoying! If I wouldn’t commit just now, like all engineers do on a daily basis, I wouldn’t notice these obvious problems, or I would notice them far too late.

In Lean this concept was known for years now as Gemba. For some crazy reason we usually think that “with software engineering it’s different”. Maybe we need to work on our own learned helplessness as well!