Manage by Example

Over my career, I have worked at several software companies and some software departments. Some companies sell their software directly, other companies make money other ways, but require custom solutions. One thing that is common, the managers of the software teams don't know the software or how to use it. I found this odd because the whole teams existence revolves around that software. Luckily for me, one of those jobs did not work that way. I had a boss who was part of the team and helped build the software we worked on. He showed me that managers can participate in the software development process.

This was a small company with 30 to 50 total employees. The software development team had to be between a dozen or two dozen people. Before I joined they decided to rewrite the product for some valid reasons. This meant I was joining a greenfield project. It was fresh start for design and code. My boss was also the architect. People wore many hats at this small company. The boss started the project with his expertise. Then he let the developer take on the big futures needed to replace older products. He did not just sit back and manage after that. He took on tasks, and fix bugs and worked with other teams. You could see the application running on his computer screen. He was just as involved as us.

One of my favorite examples of this was when our user facing UI was becoming inconsistent across all the screens. That is what happens when you got multiple developers building out new features at the same time. The boss did something clever. He took a screenshot of all the screens. Then printed them all, and then began posting them on the wall. He caught everyone's attention. When he was done, he was able to explain by showing everyone the inconsistency. With some effort from the team, the UI became more consistent after that.

Another example of being a manager by doing. There was an issues in production that took down a server. The boss knew the team was busy building the new release so he took it on. It was a customer uploading an CSV much larger than we expected. For this customers, large CSV files were common. He took the task on to fix it by refactoring the code to stream the file instead of load it into memory. It was really cool to see the final solution. I was impressed and learned something new.

Looking back at this, I'm glad I got to experience it. The best part about was, you got a manager who knows and is working with you. When you talk about the product, you don't get any confused looks when you mention a fact about the software beyond the basics. You get relatable advice and guidance they direct you to specific code examples. They also know which parts of the software are the hardest. They have a better idea of estimates and effort required. Most importantly they are able to understand and relate to your work.

I cannot say the same for other places. I have had manager just drop me off at my desk and not see them until it's review time. When there is an issue, usually I just get routed to another team member. I could have done that myself. Compared to my experience at a retail store when I was much younger, managers did not do this. Maybe it's the office and it's effect on work. Who knows.

Moral of my story, be a team player and get in there. Know how to use your product. Know your code. Feel the pain everyone else has. You might have fun and you'll gain some big respect.