Ask Your Managers What They Really Need
If managing technical personnel were an exact science, we would have all been taught how to do it in our management courses and studies. The fact is managing brilliant minds is quite difficult. Frankly, from a software development standpoint, I have only found two people who do technology and organizational management equally well.
While it may seem unfair to say technical folks just cannot manage people and processes, the reality is, most do not want to do it anyway. In Nanonation’s case, it turns out, figuring out how to motivate a team, managing utilization and scheduling and approving time off, is not nearly as interesting as creating software for one of the world’s most recognized shoe brands. Where that leaves us is, we must find individuals who understand the intricacies of technical people and who have the aptitude to at least understand what they are saying. It is actually quite difficult to find that person as well, but when you do, you are set. Solid people management skills and the ability to connect with brilliant minds equals a happy team.
As our organization has been transformed into a very desirable workplace, what we have found is some of our most experienced and technical resources are attracted to advancement but not organizational management. What they desire most in a senior level role is mentorship of junior developers and similar professionals. It tends to fill the career progression need as well as build a strong team. After nearly ten years with the company, one of our most senior developers found light in what was a bit of a slump in his career by increasing the amount of technical mentorship he provided to a team of Windows developers. Today, he is more motivated and happier than ever and not only is it fun to see, the company is benefitting from the transformation.
Smart people can figure out the paths to success in a technical environment, but the best of the best, understand people
Perhaps one of the most important areas to address is a skill that cannot be taught. That is, loving people and thoroughly enjoying getting to know them is a requirement of the technical leadership role. It does not matter if you are managing a wait staff or the most intellectually astute software developer; you must love people and really get to know them at a personal level. Smart people can figure out the paths to success in a technical environment, but the best of the best, understand people.
When I first started working at Nanonation, the most intimidating managerial task was taking on the management of a founder of the company. Talk about an uphill battle. However, there was one secret sauce that made it all work out better than ever expected. I had to understand and really believe in his value to the company. There is not one introduction that goes by where I do not acknowledge his unbelievable talent and service to the company. The reality is, he has a lot more experience inside and outside of the company than I do. The secret is, acknowledgement and taking each piece of his knowledge and learning from it myself. Managers need to manage well, while still learning from the people they lead.
Once you have the people management side down, it is time to talk about the tools and utilization to employ within your team. Over the past four years, Nanonation has been evaluating software production processes. After attending a DevOps conference a few years ago, I quickly realized each organization is unique in its own way and there is not a single way to approach agile or any other process for that matter.
Our environment has evolved from a textbook waterfall organization to agile and now we are somewhere in-between—and that is ok. In fact, I think most organizations need to think more along the lines of what works best for them, rather than the way someone in an article or speaking at a conference tells you to organize. Currently, Nanonation fosters a scrum based environment with sprinkles of our own methodology. We have high delivery expectations, while encouraging a very relaxed and balanced work environment.
Regarding our processes, we recently dropped time logging altogether. While not possible in some services organizations where hourly billing is a must, in a product organization like our own where projects are pre-estimated, it makes complete sense. When we asked ourselves what we were time logging for, the answer was to make sure our estimates were accurate and ensure people were utilized as much as we require. The fact is, estimates are estimates and we trust our people, so time logging just did not make since anymore. Actually, the time it was taking to time log, would have paid for another software developer. We chose the software developer.
A common theme throughout my time at Nanonation and throughout DevOps training is to make sure you are doing things that work for your organization. The implementation of project planning tools you choose are no exception. At Nanonation, we have tried a handful of tools in my tenure and each of them is good and bad in their own ways. The successful way we found to choose our current tool, was to gather a small group of key users and mangers in a room and ask ourselves what we really needed. Our first list was two pages long and what we ended up with was a list of four things: intuitive issue tracking, ability to create estimates, project creation and tracking. After we came to what we really needed, we chose a tool and have not looked back.
Outside of tools and processes and back to people, is the topic of blending teams. Software production includes more than developers. In our case, it includes design, development, quality assurance and project management. Each team consists of employees who are wired slightly differently from one another and have different skill sets. The key to cultivating a team atmosphere is to treat the team like one, while allowing a certain amount of autonomy. Whether you are leading all of the teams or you are managing managers, you must lead and treat the teams as one. Breaking down silos is incredibly difficult if all teams are managed differently and without some consistency in expectations.
In the end, you have to operate the way it makes most sense to you. I suggest you take a closer look at those managing your technical staff and make certain you have the people side in place, which in my opinion, create a significant return in productivity and ultimately delivery of your product or service. As it relates to processes, do not over think it. Take a look at what you have, understand what you really need and adjust frequently. It costs the company money to readjust, but it costs more to keep something in place that does not work.