The New Frontier CIO

Organizational Change, Taming the Beast!

Get ready to strap on your armor, mount your faithful steed, and … open your arms for a hug. If you’re going to effectively tackle organization change, you’re going to need to be resilient to attacks, fast moving, and have no small amount of empathy for the people around you. I say “effectively” because there are certainly many ways to implement change – some with horrendous consequences. However, with a deft hand, a good leader can reshape an organization like melting butter. Ok, that butter thing is probably a bad metaphor but you get the idea!

Read the full article on LinkedIn:

https://www.linkedin.com/pulse/organizational-change-taming-beast-mark-w-bennett

 

The Secret To Innovation And The Lost City of Atlantis

Controlling weather, pacifying volcanic eruptions, channeling energy from time and space? If you believe the stories, these and other unbelievable technologies forever disappeared from the face of the Earth when Atlantis sunk below the roiling ocean. Real or not, if the founders of Atlantis ever existed they were certainly incredible innovators. The good news for us is that their purported powers of innovation are not an unfathomable secret.

So, where does disruptive and transformative innovation really come from?

 Read more on my LinkedIn post:

https://www.linkedin.com/pulse/secret-innovation-lost-city-atlantis-mark-w-bennett

Asking why vs how? David Hussman's "Dude's Law".

http://www.hanoulle.be/2011/04/why-over-how-my-look-at-dudes-law/

The above is a worthwhile blog entry to read even if you aren't directly involved in an Agile software development project. It discusses a mindset that I have always found useful even if it does get me into trouble on occasion — turn over enough rocks and eventually you'll find a snake. At the root of this is the philosophy of asking "why" are you doing something before you dig too far into "how" you do it. I'm often heard telling people who want to collect lots of metrics or other data, "Why do we want that data? What decision are we really going to make with it?". The same concept applies to implementing new processes, SLDCs, management tools and virtually everything in my life, which doesn't always endear me to my wife when she's asking me to do something I really don't want to do :) Anyway, my point is that challenging things that don't make sense to you by asking "why" is a good philosophy and is something I encourage all of you to do — just be positive and constructive in the way you approach asking the questions.

Measuring a Software Developer's Performance

Conducting performance evaluations on individual software developers can prove a daunting challenge for even the most experienced manager. Unless you’re working in some sort of Utopian organization where you have perfect processes and perfect requirements, measuring the performance of your development staff is likely to be very subjective. A key stumbling block is the fact that the success of a software developer is often dependent on many variables outside of their control. Som

Image via Wikipedia

e of those variables include things like the quality of the software requirements; the level of collaboration from the business sponsor; the availability effective development environment; etc. Yet, every sizable software development shop seems to both their star players and those that seem to fall short.

So, how do you measure their performance? There is no single answer and one of the first things you should do is stop by your friendly Human Resources department for some advice. If you don’t have an HR group, do a little research and reading

online. You’ll find that there is no shortage of opinions on this matter, from folks that want to measure the number of lines of code per hour to those who claim it can’t be adequately measured.

Here are a few of my own thoughts on the matter:

• Subjectivity is part of the equation – If you were hoping for a purely objective way of measuring a developer’s performance, forget it! Programming is both science and art, and it’s the artistic quality that will always be subjective. That’s ok! If you’re a manager, you should understand that agreement is not necessarily part of the equation. However, you do need to be able to express what you like and don’t like about their work in a way that will allow them to take corrective action.

• There are things you can measure – It’s not all art! For example, if you set an expectation that developers will unit test their code, that’s a pretty black & white measure. They either did it or they didn’t. As to the adequacy and quality of their testing, well, that’s a different story – subjectivity again. Did they complete any required documentation (e.g., design docs)? Hard deliverables, such as documentation are easy things to measure.

• Setting clear expectations is critical – If you require your developers to do unit testing or prepare certain documentation, then tell them! Better yet, put it down on paper and share your expectations with the entire team. Make sure your team understands exactly what and how you are going to be measuring their performance.

• Provide near real-time feedback and document – When an employee performance well, tell them! When they don’t perform well, tell them! Simple, huh? I suggest, particularly when correcting negative performance, that you document things using e-mail or some other written mechanism. If you have an individual with chronic performance issues, having written documentation is essential if you every reach the point where you are making a termination decision. I also can’t stress enough how important the “real-time feedback” aspect is in this process. If you wait more than about 24 hours to provide feedback, the effectiveness is greatly reduced.

•  In the end, measuring whether a developer is able to consistently deliver quality work on time is essential.  The trick is how do you hold a developer accountable for what is essentially an estimated level of effort? It’s an “estimate” after all?!  It’s a tough problem and the key is to break things down to the point where most of the variables are in the control of the developer. If you’re measuring a developer on completion of tasks estimated to take more than about two or three days, you’re going to run into problems. Generally, the longer the duration the more uncontrollable variables that come into play – everything from dependencies on other developers to shifting requirements. One of the things I like about most of the Agile development methodologies is the way the team breaks down the work to be done in really small chunks, typically measured in days or hours. If a developer says they are going to finish implementing class XYX by tomorrow, that’s something I can measure them on and I can reasonably expect the outcome to be in their control. True, there are things that can still go wrong that isn’t their fault, but they are generally easy to identify and understand (e.g., their workstation crashed).

If you’ve have some success stories or challenges you want to share related to measuring software developer performance, I’d love to hear from you! It’s a tough subject, with no shortage of opinions!