Technical Leadership

In my new position, I've spent a large amount of time helping morph my development team's process into something that is a little more effective than what existed when I showed up. What we used to do was have a bunch of developers furiously coding on what they thought was important without actually getting feedback from the business. This led us to an interesting situation where we where spending hundreds of hours developing things that nobody really wanted (sound familiar?)

We've since spent quite a bit of time honing our skills and process to make sure we're working on things that the business (folks who pay us at least) think are important. This work has been rewarding, but not very technical in nature. I've finally gotten some time to play around with really technical stuff again and now remember why I got into this business.

The fortunate thing I'm finally realizing is how EXTREMELY rare it is to find folks who can be effective at both managing development teams, as well as keeping abreast of the technical issues. In addition, I'm finding exactly how bad many techhies are at figuring out what things are important to their business partners (or users). More importantly, I'm seeing how a HIGHLY technical manager can actually be a very serious liability if they do not have the ability to realize that their output is measured by their team's output, not their own personal accomplishments.

Comments

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image