Managing The Unmanageable And Behind Closed Doors

Whoops. I started working on this blog post all the way back in mid-February and it’s now mid-April. Life has been busy. Work is busy. Being a dad to a 9-month old is filled with busyness. My wife & I are in the middle of selling our home and buying a home (which is something I do not want to go through again…). Anyhow, let’s see if I can wrap up this little blog post…

I recently read through a couple of books on software management–“Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams” & “Behind Closed Doors: Secrets of Great Management”. Here are my key takeaways from these 2 books.

• Keep up with technology. The longer I’ve been in my VP of Technology role, the more difficult it’s gotten for me to get my hands dirty with writing code. In the first few months of taking on my new role, I was able to spend at least a few hours a week writing code at the office; however, that number has been slowly creeping down. I’ve had to be intentional about writing code and I’ve had to make some really strong efforts at carving out time to write code. There have been weeks where I didn’t write a single line of code while at the office. I guess this is somewhat understandable in that I now have a lot of demands that I didn’t have before and I only have so much time and energy. Writing code is no longer my most important responsibility as an employee at Cappex. However, I simply cannot allow myself to get to a point where I’m a rusty coder & am clueless about current trends in software development. In order for me to be an effective technical manager, I need to continue to be a trusted technical resource to those I manage and to the rest of the company.

• Money is a demotivating factor for developers. Money is not a primary motivating factor for most developers. Pay developers well enough so that the issue of money is off the table and I shouldn’t think that I can keep developers happy in the long run simply by paying them a lot. Remember that developers are motivated by their ability to create software that makes a difference in the world. The type of work they do, the culture in which they work in, who they work with–all of these things are more important than money (as long as they’re getting compensated fairly). Using money as a bait to get developers to work harder will end up demotivating them.

• Stack rank salaries by performance. I would like to think that if everyone on my team somehow discovered how much everyone else on the team is making (including my own salary), no one would be shocked. I’d like to keep things that way.

• Importance of hiring the right people. I will willingly admit that I do not enjoy hiring. It’s an incredibly time-intensive & a highly disruptive process. Good candidates are very difficult to come by, especially in the current tech climate in Chicago. I’ve been looking for a developer for several weeks now and haven’t found the right person after TWENTY phone screens. But as difficult as hiring is, I can’t allow my standards to dip when it comes to hiring. I need to remember that hiring the right people is perhaps the most important thing I do in my role. Work hard at hiring the right people and once they’re hired, work hard at keeping them happy as long as they’re doing a good job.

• Part ways with poor performers ASAP. I’ve found that poor performers are cancerous to a small team like mine. I’ve noticed the following pattern with poor performers: They struggle with getting things past the finish line. They don’t ask the right questions. They’re sloppy and not detailed enough. They’re quick to blame everyone and everything but themselves. They don’t learn from their mistakes. I need to remember to identify poor performers and find ways to part ways with them ASAP.

• Work on building and maintaining list of consultants and contractors. In “Managing the Unmanageable”, it talks about the importance of maintaining a list of consultants you can rely on during times of need. I can certainly see the value of this and will think about what it’d take for me to develop my own list of consultants I can count on when I have a sudden need to tackle development projects. This is something I hadn’t thought of prior to reading this book.

• Think about inviting consultants and vendors to provide technical presentations. This is something that’s mentioned in “Managing the Unmanageable” and I certainly see value in this. While there are a lot of interesting technologies out there that could potentially be very helpful for my team and the company, I’m usually pretty weary of asking vendors to do a demo with me because they tend to get pushy & clingy real fast but… maybe that’s something I just need to deal with.

• 2023 2
• 2021 6
• 2019 1
• 2018 5
• 2017 9
• 2016 25
• 2015 6
• 2014 6
• 2013 15
• 2012 16
• 2011 8
• 2010 13