Skip to main content

SDM Insights: Own the Failures - Yours and The Team

SDM Insights: Own the Failures - Yours and The Team

In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list here.

About 6 months into my time as SDM, I had to kill a major project, one that had seen three developers invest many months, an entire year for the Senior Dev on the project. The project was the baby / brainchild of my predecessor, and everyone assured me that it was almost complete, just a little more time and effort would get it over the top.

SDMs are not always in the position to green-light or kill significant client-facing projects, but as we made our strategic plans for the coming year for Development, it became obvious that we had higher priorities and more lucrative opportunities to pursue, ones that we would miss if we continued to pursue this overdue, over-budget, over-complicated project. So it was terminated, and I reassigned the three Devs to other projects.

The post-mortem of the project identified several issues that could have been early-warning signs: it was over-architected for a million concurrent users before knowing if we would have any users; its technology choices introduced several elements that were new to the whole team and no one understood well, including me; the senior developer was not ready to be a team lead; the Product team did not have a coherent set of use cases, and so on. Lots of blame to go around.

But ultimately, as the SDM, I needed to own a significant share of the failure. In hindsight I was too slow to get up to speed on the project and especially its architecture and technology. I relied too much on inherited evaluations of the skill level on the team and the senior developer, rather than trusting my own judgement. I could have pushed for clearer Use Cases or a more-articulated Business Case for the project.

Road Closed

The SDM did not cause the failure of this project, or at least not alone. But the SDM needs to take on the responsibility. It gives higher Leadership a place to focus their attention (see the related Protect the Team post). It would not do, for example, to have fired the lead developer. But it should and did spark more honest evaluation, discussions, assignments and professional development of the individuals, the team and the processes in place.

Owning the failure does not mean being the sacrificial lamb, or a heaping of self-flagellation. But it does mean digging into it, understanding the many complex factors that led to the failure - design, architecture, product, timelines, commitments, abilities, team size, composition and more - and working on a plan to address the weaknesses for better success next time.

Part of the SDM role is to juggle and balance all those complex factors. When they don't work out, the SDM needs to shoulder more than just "their share" of the blame - they had responsibilities both up and down the chain.

Taking responsibility for your own mistakes and failures is a mark of character and integrity.

Taking responsibility for those of your team is a step toward addressing those failures and weaknesses, and building your team into one that is stronger, more resilient, more talented and more able to succeed the next time.



Labels:

Popular posts from this blog

How to do Git Rebase in Eclipse

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here : One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like: The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon). Check out this extreme-case history:  http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time. Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit. Git Rebase offers us 2 benefits over Git Merge: First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For this
Read more

Java 8: Rewrite For-loops using Stream API

Java 8 Tip: Anytime you write a Java For-loop, ask yourself if you can rewrite it with the Streams API. Now that I have moved to Java 8 in my work and home development, whenever I want to use a For-loop, I write it and then see if I can rewrite it using the Stream API. For example: I have an object called myThing, some Collection-like data structure which contains an arbitrary number of Fields. Something has happened, and I want to set all of the fields to some common state, in my case "Hidden"
Read more

Git Reset in Eclipse

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.
Read more

Code Coverage in C#.NET Unit Tests - Setting up OpenCover

The purpose of this post is to be a brain-dump for how we set up and used OpenCover and ReportGenerator command-line tools for code coverage analysis and reporting in our projects. The documentation made some assumptions that took some digging to fully understand, so to save my (and maybe others') time and effort in the future, here are my notes. Our project, which I will call CEP for short, includes a handful of sub-projects within the same solution. They are a mix of Web APIs, ASP MVC applications and Class libraries. For Unit Tests, we chose to write them using the MSTest framework, along with the Moq mocking framework. As the various sub-projects evolved, we needed to know more about the coverage of our automated tests. What classes, methods and instructions had tests exercising them, and what ones did not? Code Coverage tools are conveniently built-in for Visual Studio 2017 Enterprise Edition, but not for our Professional Edition installations. Much less for any Commun
Read more

Scala Collections: A Group of groupBy() Examples

Scala provides a rich Collections API. Let's look at the useful groupBy() function. What does groupBy() do? It takes a collection, assesses each item in that collection against a discriminator function, and returns a Map data structure. Each key in the returned map is a distinct result of the discriminator function, and the key's corresponding value is another collection which contains all elements of the original one that evaluate the same way against the discriminator function. So, for example, here is a collection of Strings: val sports = Seq ("baseball", "ice hockey", "football", "basketball", "110m hurdles", "field hockey") Running it through the Scala interpreter produces this output showing our value's definition: sports: Seq[String] = List(baseball, ice hockey, football, basketball, 110m hurdles, field hockey) We can group those sports names by, say, their first letter. To do so, we need a disc
Read more