Features of Leadership

Since speaking at Atlassian Summit (of which I'll be writing and sharing more about in the coming weeks), I've been following up by reading more and more about the topics that I covered. Here are a few articles I've come across that deal with leading a technical team and the issues and decisions those leaders must face.

On technical debt, complexity and opportunity cost

This article isn't just about technical debt, it's offering advice on how to approach technical debt. What to do about keeping it, or removing it. The idea that when developing a new feature that integrates with older features, keeping that older feature still requires time and effort.

it’s worth challeging the idea that every old feature is going to have more business value than the new features they are competing with.

He also goes into thinking about the cost of a feature as not just the time it takes to complete it, but rather, when it's finished, the truth time it will take to support is only just beginning.

When you release a feature it’s not the end of the job, it’s just the beginning!

Something I've always encouraged and pushed for is the idea a criteria for the success of a project. But I like the idea of pushing for criteria for the success of a feature. Is a specific feature worth keeping?

it’s important to define success criteria upfront. If the feature doesn’t meet the measure of success you’ve defined, remove it. And if it does, we know the debt is worth taking on.

The one cost engineers and product managers don't consider

This is an excellent read by someone who has taken the time to be fairly introspective in his craft. It's fairly clear when he states the reason for discussing what he does.

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. The answer seems obvious now: The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product [Emphasis mine]

He also goes on to make the point that even features that have no impact to the quality of the product are still negatively impacting the complexity of the software.

If you methodically test the impact of each change you make, you can discard those that are negative, but equally relevant to complexity cost, also discard those that are neutral. A change that doesn't hurt the key performance indicators still hurts the product because it adds complexity debt that must be paid on all future projects. [Emphasis mine]

Without even realizing it, he comes up with a couple of simple rules that, if you understand, can lead to better software, and as a result, allow you to build better products.

• Train your entire engineering department to understand complexity cost and to use data to keep it down.
• Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built.

There are no small changes

I enjoyed this article because it took us through an example of how a simple requirement can lead to a lot of extra work. The idea of now limiting a product review to 140 characters.

Sandwiching this story are two keep points:

• There are no small changes when you’re committed to delivering quality software.
• Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.

What CTOs fear most

I think all software developers would do well to strive to be good CTOs, whether they are CTOs or not. A CTO does more than worry about the technology. It's a balance of meeting the needs of the business with building good software. Allen Rohner said,

if the technical solution is 100% stable and not being strained at all, it probably means we’ve spent too much time on it.

He also says with something I wish more software developers would strive for:

What’s different about being a CTO vs something like a lead engineer? Understanding the business model. Making technical choices that shift the business.

The software architect in me cringes at this disregard for software that was obviously well crafted, but the CTO in me understands the point. And that supports the authors opening point in the article:CTOs are worried about how to be great leaders.

After all, being a great leader means not only making that decision to not spend as much time on that technical solution despite knowing it's not 100% perfect, but also making sure the software architects understand that you aren't blindly asking them to accrue technical debt.

It's really interesting to read all the challenges and thoughts that go into being a CTO. It's not just a fancy 3-letter title. It has meaning.

These four articles cover a lot of information, and I plan on pulling from them key quotes for use later on (some of which I've done above). You should definitely spend some time reading through them.