A few months ago I had lunch with a friend who wanted to pick my brain about some frustrations she was having with her company’s software development department. Her company produces specialized machinery for something (actually, I forget what they do), but they also build and sell software products. In her role, she leads up a marketing team in charge of commercialization, PR and marketing of their software.
She started the lunch in a quite civil mood – the food was great, the restaurant was awesome – but once she started talking about their software guys, she got a bit edgy. “I don’t know what they’re doing.” She said, clearly agitated. “We’re supposed to release this new version in 3 weeks, and I’ve never even seen it. I don’t know what new features are actually going into it, and they won’t tell me.”
“Every Time I go to meet with them to get more information, they treat me like I’m an intruder – like I’m some annoying idiot from Marketing invading their turf. All I get is hand-waving and the big brush-off: ‘Nothing to see here pretty lady…’ blah blah blah.”
“I don’t get it. How am I supposed to do my job? We’re supposed to go live in 3 weeks and they won’t even show me!”
My immediate reactions while she was telling me this story were a bit like this: I wanted to go strangle that software team. It was clear that they were badly organized, lacked leadership, they’ll no doubt miss their release target, it will ship with a reduced set of features, and the quality will be poor. I got especially annoyed when she went on to tell me that they were “Agile”. Her comment was, “I know you do Agile too, but I don’t think it works.” That was the clincher.
Agile is all about transparency, it’s about delivering continuous working software, it’s about inviting all stakeholders in to participate in the development of a product. Like anything, there are a lot of pretenders out there using a popular concept to hide their own inability.
So, if you were in my shoes, in that situation, sitting across from her, what would you say she should do?
Should she escalate the issue to higher-ups?
Should she continue to badger them till she got answers?
Maybe she should just know-her place. Bow down to the divine miracle-makers in software. Wait patiently until they’ve completed the magic-of-software-development before asking more tedious marketing questions.
What would you say? (see poll below)
Ultimately, there are so many things wrong with this situation; I struggle to know where to begin. So, I’ll make a quick list of the obvious problems that this represents before diving into any detail:
- There’s a clear misaligned idea of product ‘ownership’. While the product should be owned by the business as a whole, the development team appears to view their role as somehow ‘more entitled’
- There is a dangerous breakdown in Transparency and Communication
- The software team doesn’t know how to ‘ship’ software
A misaligned idea of product ‘ownership’
Clearly many software teams are compelled to believe that what they do – their role in their organization – is to ‘write software’. Which, in some respects, has some functional truth to it; but the greater truth to what technology professionals do is, “Build Market-Driven Products”.
So, okay, maybe that statement makes you want to roll your eyes to the sky … but at the end of the day, we all work for a company that is in the business of doing business. Making money. Whether you’re building commercial or internal software, your company is investing in your time because they believe that it will help them make money. It’s pretty rare that someone will pay you to play with technology. The fact is, they’re paying you to do whatever you can to produce a product that has the maximum market potential and ROI so that they can make money.
The long and short of all that is: the technology team doesn’t ‘own’ the product and they have no right to throw up barriers around that product when other stakeholders with equal ownership need to participate in the product’s success. The product is owned by the business, and the software group’s contribution to that should be a business-driven contribution. NOT a technology-driven contribution.
A Breakdown in Transparency
Software developers have a strong desire to hide in a dark corner and fidget away at their work – their creation – for as long as they can get away with. The goal is to reappear, unveil the masterpiece with a “Ta Da!” and crowds will applaud the genius, the angels will sing and he will have saved the day.
This is likely the most dangerous thing in the world of software.
Ensuring that your team is fully transparent from all aspects of communication, visibility and availability of working product is absolutely fundamental to a successful software project. If you’re getting pushed off with the “Move along, nothing to see here…” attitude from the dev shop, it’s a clear sign that things are not well in that department.
Learn to ShipSoftware
I just had a chat with my friend, and as it turns out, 4 months later, they still haven’t shipped that release. And it’s still not clear to her, or anyone else outside the technology department, what will be released or when.
Writing the code is only one aspect of creating a commercial product that you deliver to happy customers (internal or commercial). The act of shipping that software product is craft that requires practice, experience and a lot of planning. It’s tricky to ship. No question. So, to manage the risk and pitfalls that exist around getting your product to market, best practices tell us to ship all the time. Ship your software as often as you can. Even if it’s only to internal stakeholders – your BA, Product Manager, trusted clients, etc. Ship.
If you are on the outside looking in; and your dev group can’t prove that they can ship the software asset you’re investing in long before the release date – this is another sign that things are not well in that department.