Why did I do this to myself

So let’s get into this weirdness.

I’ve never been a software engineer. I made a couple websites in high school and college and figured out HTML as best I could (and tried to use the “no code” tools of the time like BBEdit, but like our current tools… if you didn’t know how to code it, the tools were only going to get you 80% of the way). And yet, I’ve been in the software engineering world, surrounded by brilliant people writing some of the most used apps and trying to find a way to be helpful to those folks.

It took a lot of time to learn how they operated, and mostly I learned by totally screwing up. I made a lot of assumptions, made a lot of enemies, and often looked like a complete idiot. But that’s part of the journey. And we’ll do a whole deep dive at some point on how time is the best teacher, but for this one, I want to discuss a lesson I learned (through empathy) about software developers.

They need deadlines. And they hate deadlines. Both for the same reason.

When I was first starting out as a project manager, I was woefully naive. Our team was fairly small, only 6 developers, working across 4 different operating systems. So we’re talking about 4 different front end languages, for mobile app development, and right at the beginning of the App Store and Google Play store.

Our team was a bunch of youngish people mostly straight out of college into our company. As a result it was very energetic and chaotic, not just in a “people doing wild shit” way, but in a “we’re all learning to be professionals together” kinda way.

And let’s be clear, I was not a great “professional” influence. I’d been working at Smith Barney prior, and was wearing a suit to work every day, needing to be clean shaven, all that jazz. Now I was at a start up. We wore shorts and sandals to work. I convinced our office manager to buy me a $100 mini basketball hoop with a breakaway rim. I streamed Top Gear episodes on our office wall using a projector that I had lying around. It’s why I can’t watch the show Silicon Valley because it felt too real.

This is all to say, I was one of the people figuring out how to be a professional.

And I wanna talk about one instance that shaped my thinking about how to be a professional and why deadlines are critical to software development, NOT because of the deadline itself, but rather because without a goal, you could write software forever and never release it.

I had a dream dev team.

We were building Bank of America’s mobile applications, which was a marquee client for us, so we got the best of the best doing our work.

I was literally learning as I went. I got hired because I could answer the tech guys mind games in the interviews, while also talking to all the business folks about who I was. I’d been a technology trainer so I was just knowledgable enough to be dangerous but not productive. (I’m probably selling myself short, but I swear I think that my entire interview turned on two stories — 1) ditching work early to wait in line for the first iPhone and 2) buying all sorts of contraptions and wiring my stereo for wireless audio before airplay was just a normal part of life)

So, when I was put in charge of the release of the Mobile Check Deposit feature for Bank of America (their first time putting out this functionality) it was both exciting (because it was cool as hell) and terrifying (holy shit I hope the reason is obvious lol).

I had an iOS lead and an Android lead, we went through this massive business requirements doc, we did requirements reviews with the client, we did backend technical reviews, we looked at everything we could to figure out what it would take to do the work.

After all of that, I assumed we were locked in. We knew what to do, we knew how to do it, we were golden.

And on Android that assumption was validated! My lead was known as a dude who just got shit done and did it FAST, and he delivered. He was early getting it done and already itching for the next thing to do.

But on iOS I ran into a problem… I couldn’t figure out when on earth the work would be done. I would ask the dev multiple times a day for an estimate on when it would be done, thinking that was the right thing to do. I would get the same response every time, “I’m working on it, I don’t have an estimate, but I need to make sure this is done well and in a sustainable way.”

It drove me fucking insane lol. And I acted like it! After about a week, I finally went to our brand new SF office, just to confront the dev and go “what the fuck when is this damn thing gonna be done”. Which, in case you are wondering, is NOT how you should handle this kind of a situation.

He was furious right back at me. We got into a shouting match in the office. I was completely out of line, but had no idea that I was. If I saw that version of myself acting that way today, I would step in and pull myself aside and have a WORD with him about how you treat people. Obviously, I’m still thinking about it today, and still regretting it.

Well fuck that was a downer Scott, I thought we were talking about deadlines lol.

WE ARE, TRUST ME, WE’RE ALMOST THERE.

The important thing to remember when you screw up, is that the screw up doesn’t mean YOU are a screw up. It’s just in that moment you screwed up. Your next step can be to continue being that person, or it can be to learn and grow and become the person you want/expect yourself to be.

Luckily, I had incredibly kind and respectful people around me, in addition to being brilliant engineers. And they were not shy about telling me what I got wrong in that situation. And the thing I got wrong? You guessed it… I didn’t have empathy for the guys on the team.

My Android dev was young, hungry, smart, and probably TOO good at what he was doing. I could just let him be and he’d deliver earlier than anyone expected partially because he was that good, and partially because he just didn’t want to get stuck doing one thing for too long. He was a wanderer who needed to find new opportunities to feel engaged and like he was having an impact.

My iOS dev was experienced. And with experience comes pain and understanding of everything that could possibly go wrong. And so he wanted to be more thoughtful and purposeful especially with a feature that’s net new not just to our team but to the market. With that, he needed to do extra research, and that is what took the extra time, not the actual development (hands on keyboard time was the same, it was all the things that go WITH hands on keyboards that was different!).

The thing I didn’t realize is that both of these approaches are valid and reasonable. And when you’re talking to someone in either of these modes, you have to talk to them differently. I could ask my Android dev “how long do you need” and he would answer directly because he was thinking about his time on the keyboard. He knew the tasks he had to finish and that was that. But when I asked my iOS dev “how long do you need” he heard “how fast can you do this”. Which to be fair, is exactly what I was asking.

But in his head you couldn’t just do this quickly! You had to put in the work! So me asking him “how long do you need” was insinuating that he wasn’t doing real work. Which was totally my intention at the time — and that sucks.

What I learned from that though was incredibly important. Developers need guard rails. Especially when they’re both experienced and talented. Because engineers think about all the things that can go wrong. They have the scars from their previous screw ups. And they don’t want them to happen again!

And that’s a GREAT perspective to have! You should want your people to be that dedicated and caring that they don’t want to just put out slop because you are paying them to do it. They should have pride of ownership. But you have to cultivate that. And what I was doing, was stifling it instead.

So I shifted my focus. Instead of asking for timelines I would give timelines. I would say “we need this done in 4 weeks, can it be done in 4 weeks”. That’s a clear ask and answer, and I’m not making it personal by asking can YOU do it in 4 weeks, but rather just asking “can it be done in 4 weeks”.

This mindset shift allowed me to then fully embrace some of the agile ways of working. If you think about it, agile is just a different way of committing to work. Waterfall approaches were long tedious projects with all the detail written out and you had to just hope that everything was right and nothing changed, and your time horizons were large enough that you could fit what you needed to in them.

Agile just shifts it so that the timelines are shorter. Instead of 9 months we’re looking at 2 weeks. And you’re asking people to commit to work during those 2 weeks.

Those deadlines and guard rails are invaluable because it gives the scope of work a barrier for the development team. They can see all the things that are coming but we’re not asking them to look at those yet, we’re asking to look at what’s right in front of them. It’s a focusing exercise. And that’s what deadlines and timelines do for software development. They create focus. They create intention. If I need my specific task done in 2 weeks, and I’m told it’s longer than that, we break the task down until it’s doable in that 2 week timeframe. That way we’re looking at accomplishable goals!

I know that for many of you, you’re like “duh Scott that’s just how we all work”. But it’s important to me to understand WHY we work that way and more importantly why that way of working works! (what a gross sentence lol)

I probably would have bought into agile regardless, but that experience of getting my interaction with my developers so wrong radicalized me. It made me see (even if it took longer than it should have) the value in doing things like a developer. It made me see the value of deadlines and expectation setting. It made me want to be a better communicator at work.

And the only reason I was able to look at my failures and turn them into successes is because I chose to give myself, as well as my team, a little empathy.