Let us discuss software development.
I’d like to take a moment of your time to explain software development in terms you can understand.
I have provided the kitten above to help draw your attention and included additional kittens below to help retain it. I understand you are quite busy, so here’s a list of salient points.
I know you think I’m annoying when I ask questions. I see your face when I ask for details. I’m doing this because I need to fully understand what you’re asking for.
I need to “get” it and document it, and this documentation needs to be crystal-clear, clear to the point that I can give it to a developer, who can then make a computer do something.
And that computer? It only understands ones and zeros.
Maybe you get annoyed because I ask about things you don’t have answers for, but you know what? That’s totally ok. I understand that you may not know exactly what you need.
In fact, it’s more likely that you won’t know what you need until you see what you don’t need. And that’s also ok.
We have a process for that, where you get a chance to try out our handiwork and let us know if we got it right. I understand that you’re often too busy to come to meetings, but please consider that we have nothing to hide, and we truly want to include you.
Next time we invite you to a planning or review meeting, please come, and maybe it will alleviate some of the frustration you’re feeling.
When I say that a software development team must work together to make something happen, I’m not just talking about collaboration, or consensus, or, you know, “being on the same page.”
I’m talking about working together to understand a business problem and finding a solution that will work.
And when I say work, I don’t just mean “work” in that it doesn’t crash, but work so that it makes you, our management, and our customers want to use the software. And finding that sweet spot takes time and a helluva lot of talking and Skyping and drawing and trying.
On your team, you’re lucky enough to have folks with shared skill sets who can easily absorb each other’s extra work. On my team, not only do we have to rely on each other to get everything done, but each member of the team has a special role in the process.
We can’t move the work around as easily, although my .NET guys are getting better at PHP by the day.
The mention of our expanding skills leads me to discuss tenacity. A former developer (no, not that one, the other one who quit this summer) once said that software developers have to draw upon the same tenacity, the same drive, that we did in college — just to make it though the day.
So if you ever wonder why we’re all typing in a Google search box, or scrolling through code samples, or reading comments on Stack Overflow, it’s not because we’re bored.
We’re learning. We’re questioning. And we’re digging for answers because things can break and we need to learn how to fix them.
It’s also because even if our code needs to change, the deadline usually can’t.
Oh, deadlines. I’ve seen your raised eyebrow when we discuss deadlines, and you’ve probably also seen mine.
Software development teams love deadlines, but deadlines that are set before we’ve had a chance to understand the scope of a project, or figure out how much work it’ll take, are pretty scary.
You once advised me to “be softer” about deadlines and to “find a way to make up for late work” because, as we both know, we’re not a dedicated software shop.
It’s important to understand that on a software team, we often can’t make up for late work on our own. This isn’t just a result of the dedicated skill sets I mentioned above — sometimes, it’s a matter of security.
We do a fair amount of business through our eCommerce site (the new product images look great, BTW).
In order to keep doing that business, we have to play by lots of rules. Some of the most serious rules surround the collection and transfer of personal credit card data. Perhaps you’ve heard us mention PCI compliance during a scrum or two.
These rules dictate which members of a team can have access to secure information, including passwords to the servers that store it.
As a manager, I have access in a limited capacity, but my developers sure as hell don’t.
So, when a deadline is missed before something gets to us, we can’t just make up for it by turning around a fast job on our end. We have to talk to the folks at the gate and convince them to turn the key. I don’t enjoy doing this in a rush, and I also don’t enjoy having to explain why it’s in a rush.
When I can’t set the deadlines, I still want to make plans to meet them. I also want to set up ground rules for re-planning when things are late.
This way, if a deadline is missed early in the project, we can adjust accordingly, and I can let the gatekeepers know to expect my knock on their door.
But to do that, my friends, we need to understand that we’re in each other’s sandbox, and we may have different needs. You bring the buckets and water, we’ll bring the shovels and sifters, and we’ll build something new. Something better.
Thanks for listening.
PS: I know you’re not interested in talking about social media strategy with anyone outside your team, but I was reviewing some data and noticed that my tweet about cardboard Jar Jar nearly got more interactions than your last targeted email had click-throughs. Just let me know if you’d ever like to discuss ideas.
PPS: Need more kittens? Here you go! http://emergencykitten.com/
All kitten images: www.emergencykitten.com.
This essay was originally posted on Medium on October 14, 2013, and has been backdated accordingly.