Ability to deliver working software within an agreed timeframe is one of the defining characteristics of a Senior Engineer. Understanding WHAT you are building, WHY is it being built and WHEN it needs to be delivered is obligatory. And, just like any other skill, it requires knowledge and constant practice. This article will provide you with HOWs, but practicing part is on you!
Background
A mere coincidence. That’s what it was. I found myself on a two-day on-site meeting in Italy.
Not only was I youngest, but I also happened to be the lowest ranked person there. It was a meeting organized by CTO with all Heads and VPs, arriving from Europe and USA in order to spend two full days discussing plans and goals for the upcoming year.
And I? I was just a lucky person to end up there. I happened to be in charge of a rather important Platform development project and they wanted me to share couple of words on the topic.
These two days proved to be incredibly valuable for plethora of reasons, but most important one, for me at least, was an opportunity to see how stuff works on upper levels. I happened to learn that these people aren’t exactly devils in suits, as I used to picture them, but rather ordinary people struggling with pretty much exact same issues and problems as regular engineer does; multiplied by ten, due to sheer span of power they have.
Random thing that happened, which couple of months later proved to be an inspiration for this article, was an accidental chit-chat I had. I went for breakfast a bit earlier, and happened to stumble upon one of the VPs who had quite an early flight back home.
- VP: So, how are you doing in your new role?
- Me: Well, it’s challenging. I love the power and influence, but, honestly speaking, I think I’m just an engineer deep down in my heart.
- VP: I understand. I’ve been in the same spot – programming for most of my life, before moving to management.
- Me: Really? I had no clue! That’s amazing! But how did you manage to get yourself “away” from coding and focus fully on people?
- VP: Well, to tell you the truth, all these years later and I’m still struggling. But, from time to time, I’d create a task knowing that there’s nobody else to work on it, so I’d roll my sleeves on and do some coding for the sake of doing it.
- Me: Haha! Love the idea. But anyway, tell me, how are you satisfied with your team, new hires and especially ones located in Serbia?
- VP: They are amazing group! Smart, energetic, focused, passionate and heavily educated! I love working with them! The only thing that I’m currently working on is teaching them how to deliver stuff.
- Me: What do you mean?
- VP: Well, they all have rather solid theoretical base and pretty good coding skills, which is amazing. But they didn’t have much experience in the industry before, and they aren’t used to DELIVERING stuff. They love exploring, presenting and building, but I have to teach them HOW TO DELIVER.
- Me: That’s interesting. In over a decade of experience, I never really thought about that.
And behold, the idea for this article being born!
We love to BUILD, but hate to DELIVER
I mean, let’s get real. Most of us go into software engineering because we enjoy PLAYING and BUILDING things. Combine those two, sprinkle it with some money on top and you’ve got a perfect working environment … in theory, at least.
Sadly, as some might know – by telling your kids that they HAVE TO play with something usually makes them lose their interest rather fast.
- “Sally, you see we have guests here? Go and play with your dolls!”
- “Brian, go play with your trucks, now!”
You don’t even have to be a parent to know how the kids would feel, right? It’s like humans 101 – tell us that we have to do something and no matter how much we love doing it, we’ll immediately lose the interest.
For example, I love reading books, but force me to go and read and, hell, there won’t be any actual reading happening any time soon!
This is the exact reason why we lose the FUN and PLAYFUL part of our work. Because, occasionally, we are TOLD that we have to do something, instead of willingly choosing to do so. And what do we have left? We lost one ingredient – playfulness, and what we are left with is the second thing we enjoy at core – building stuff! Because, let me repeat again – the primary reason MOST OF engineers go into software engineering is due to ability to BUILD stuff; with their hands (and, occasionally, brains as well)!
Occasionally, some people would discover alternative ways of having fun and that’s why you see so many engineers doing carpentry, playing with car mechanics or making artistry in kitchen. Or, they simply go and build side projects for the sake of rediscovering that missing piece – PLAYFULNESS.
But I digress now as this topic was about work. So, most of us lose that playfulness and we are down to a single thing – BUILDING stuff. And here’s another interesting thing and I’ll try to share some examples that you might relate with.
Have you ever finished reading a book and felt just EMPTY afterwards? Feeling just sorry that the story came to an end? Or watched a TV show that you hoped will never come to an end (Friends, anyone?). Occasionally you might keep rereading and rewatching the stuff just for the sake of reliving that experience (I’m looking at you, Back to the Future!).
There are times when we enjoy things so much to a point that we are AFRAID of having them come to an end!
We are afraid of feeling EMPTY afterwards, feeling unsure what to do next.
And you know what? That feeling is totally legit! Because, and this is one of those situations where you’d expect me to say BUT, but there’s NO BUT. It’s true. It’s a fact. This fear is totally justified!
Because, yes, the future IS uncertain! And yes, uncertainty IS scary! And yes, that SHOULD make you scared.
BUT, and here comes the BUT — BUT, that’s ok! That’s how it should be! Uncertain future is scary but instead of being paralyzed by it, you should embrace that uncertainty and be happy about the new possibility, which is something that we forget that we enjoy – EXPLORING NEW THINGS! Exploring all the possibilities and options that opened as a result of CLOSING some chapter. Or, shall I say – as a result of DELIVERY? 🙂
FTM Theorem
Let’s make sure we are clear, again. We, the engineers enjoy BUILDING and PLAYING; to the point that we don’t even see a difference any more.
However, concept of WORK is made up of an idea that we invest our TIME (you know, the only ever-shrinking resource you have) and ENGINEERING SKILLS in favor of being told WHAT needs to be done, while being given MONEY in exchange.
And yes, we usually lose the PLAYFULNESS part because we are pretty much playing somebody else’s game. Someone else wants to have fun BUILDING something, but since they have no skills (or time) for doing so, they usually have to invest their MONEY in exchange for getting it built. And we agreed on calling these people “owners” and/or “bosses” (among other names).
At the end of the day, it’s really like a CAP theorem that, in short says that in the presence of network partitioning (i.e. your network going kaputt) out of Consistency, Availability and Partitioning, you can only have two out of three at the same time (e.g. C & A or C & P). if you are having all three – your network is NOT kaputt.
It’s the same with FUN, TIME and MONEY (FTM theorem, anyone?). You can always choose two, but never have all three. If you choose to have FUN at work while having enough TIME off work, chances are high that you are working in academia and not having too much MONEY. If you choose FUN and MONEY, chances are high that you are investing tons of TIME at your work because if it’s fun and pays a lot, it usually means you are working on the cutting-edge stuff that puts a lot of time pressure (I’d imagine SpaceX or self-autonomous cars being such a topic). If you choose TIME and MONEY, chances are high you want to go and become a Senior Expert at a huge corporation – nobody will bother you because you are an EXPERT and you can have tons of TIME because you can always choose not to do anything for HOURS … but this comes at cost of having zero FUN at work.
Now, where do the problems come from? Well, let me put it bluntly:
The problem arises when we forget that we are being PAID not to BUILD but to DELIVER stuff.
The whole idea of a BUSINESS is that you are creating a VALUE that somebody else finds to be cheaper than if they had it built inhouse, and as such – they pay you money for it. Hence, no matter how much we dislike it, we are paid to build stuff ASAP, so that it can be sold ASAP, so that more money can be poured in towards creating more value. That’s like business 101.
Furthermore, business entity that owns a product gets paid for, believe it or not – a WORKING product. It might come as a surprise, I know, but sometimes we forget that the money we are paid is actually a result of a FEATURE that somebody was able to SELL. And they sold it because someone else assumed it will solve THEIR problem.
So, how do we deliver?
Learning to Deliver
I lied. Well, a bit, at least.
I lied when I said that the issue is that we forget that we are paid to deliver a working feature. It’s more complex than that. Like, way more complex. And I dedicated a whole article to it – Art of Finishing Things.
In a nutshell, there’s plethora of emotions and beliefs, both rational and irrational, involved in the process of “finishing” stuff. Some of the common ones being:
- “It just needs some more polishing”,
- “I just need couple more tests”, and
- “I have to refactor this part so that future maintenance is easier
Usually, the root cause is found along the lines of perfectionism, insecurity and general anxiety. But again, I’ve dedicated a whole article to it, so go check that one out if you want to go into full analysis.
Question is — how do we learn to deliver? And yes, it’s a skill and just like any other skill – it requires constant practice. The more you do it the better you become.
Before I go into some tools & tricks that you can use, I’d like to do a quick digression. Well, two digressions. Bear with me.
Digression #1: Have you ever heard of Ballmer Peak? It’s a fun and yet somehow true phenomenon where given right amount of alcohol in your blood you can go into a state of hyper-productivity. Or, in human-understandable language, it pretty much says that if you get yourself drunk just enough, you are likely to experience a peak of your productivity and start coding like there’s no tomorrow.
Digression #2: You know that feeling when your boss or your boss’ boss comes to you and gives you approval to “do whatever it takes to get this project” done? Usually, as a result, you go into a similar state as with Ballmer Peak — you write code like there’s no tomorrow.
What’s the point of me digressing? Well, the point is that given a verbal approval of a superior, you go into a state where you deliver code way faster. Probably not the perfect code but likely good enough. And why is it so? Because all of a sudden it becomes somebody else’s responsibility; and if anything goes wrong, you can always say “they told me to do so”. And you know what’s funny? Rarely it does! It’s a typical “it’s never as scary as you imagined it” phenomenon!
This should, hopefully, give you some food for thought. Why do you deliver way faster when somebody tells you that it’s URGENT or “do whatever it takes to get it out”? I’d urge you to take some time and think about that 😉
Anyway, back to the original topic – what are some tools & techniques that we can use to practice delivery? Here is what I see:
- Understanding that you are building a product — probably one of the most underrated “techniques”. First and foremost, you have to understand that this is a constant process. You have to keep reminding yourself WHY you are building what you are building, because, as time goes by and as more and more crap piles up, we tend to turn towards negatives, eventually forgetting why we are doing what we are doing in the first place.
Your job is to be aware that YOUR JOB is to know the WHY, and if and when it becomes blurry – you need to refresh that memory by approaching your manager. There’s simply no other way. - Having clear deadlines — one of the ABSOLUTE BEST ways to do anything. Period. And yes, I’m the one who HATES them, but just like vegetables (oof!), they seem to be a necessary evil.
Deadline is what induces the positive stress needed in order to focus on actually DELIVERING stuff. You can play for all you want, but as the deadline approaches, you simply have to go into a “game’s over, we have to focus on delivery now” mode. And yes, I wrote a full article about it as well. - Understand the “Project Management Triangle” — if the image below is not familiar, now’s some learning time:
It pretty much says is that, as an “owner” of a project, you have three levers to work with, in order to maintain a project quality.
Here’s an example – let’s say that you are being told that you need to deliver Project X in 6 months. And it’s non-negotiable. That means that TIME is fixed, which leaves you to work with COST and SCOPE. Now, most of the time, COST is also more or less fixed (i.e. you usually have fixed resources to work with), which pretty much means that, in order to maintain quality, you need to work with SCOPE lever. And this is what most of people don’t get — SCOPE is ALWAYS negotiable. ALWAYS. And whenever somebody says NO, I’ll claim that they mean “I don’t know how to reduce it”.
I could agree, to a point, that this lever thing is manager’s job, but your job as a Senior Engineer or a Tech Lead should be to at least be familiar with it. So if anyone tells you that Deadline is fixed and Resources are limited, you simply pull up the “Project Management Triangle” concept and answer with – “OK, then let’s see what the scope of the project is”. - Good is GOOD ENOUGH — There’s a famous quote by Winston Churchill: “Perfection is the enemy of progress”.
It’s what happens when your manager tells you to do whatever it takes to deliver. You don’t feel the pressure of “oh, it has to be perfect” any more, and you start focusing on writing code that works (and hopefully has tests along with it!) and shipping it as soon as possible.
I know this is a direct attack to what you deeply believe in. I understand. I’d get attacked as well. But, go and weigh pros and cons, understand your product, understand WHY the deadlines are there and armed with that knowledge, rethink this advice. - Reviewing past stuff — we are faulty. Well, our brains are faulty. They tend to focus on thing that push you forward and ensure that you survive. Keeping memory of all the accomplishments you made in the past is not even a tertiary function.
You need to intentionally remind yourself of your past achievements. What was delivered. How it turned out. How you felt about it, …
By doing so, you will willingly remind yourself that 9 out of 10 times, that “good enough” code proved to be perfect.
And that’d be about it. Apply it wisely and you should be good to go!
Appendix: Can we have all three – Fun, Time and Money?
I went too harsh when I said that you can choose two out of three. Yes, there are instances where people claim they DO have all three – tons of fun and piles of money while still having enough time to spend with their friends and family.
BUT! And there’s this horrible BUT.
BUT, this is more of an exception than a rule. Really. You might occasionally end up in a company where your skill and past experiences are in high demand to a point that no one will even question what you are doing. And this seems to currently be the case, if you are lucky enough, in well-funded crypto startups. But, I’d still claim this is more of an exception than a rule, and as such – I’d rather not focus on it.
Useful Resources
- “Speed solves a lot of problems” Reddit post on /r/ExperiencedDevs — really cool Reddit post discussing how at FAANG (referring to tech giants – FB, Amazon, Apple, Netflix, Google) it’s all about speed of deliver; sometimes even crazier than at startups.
- “Fire and Motion” article by Joel Spolsky (ex-CEO of Stackoverflow) — another amazing blog post discussing how on a battlefield, your main goal is to constantly move forward. You never want to stop and rethink stuff because you lose your advantage pretty much. Highly suggested to read!
- Project Management Triangle at Wikipedia — leverage and lever concept. Pretty much says that every project has THREE levers that you can work with – TIME, SCOPE and COSTS. And you manage quality by pulling each one of these.
- “The Mythical Man-Month” book by Frederick P. Brooks Jr. — I haven’t read this one (yet!) but my manager swears by it, and I’ve heard really great comments about it. Should be worth checking out!
- “Extreme Ownership” by Jocko Willink and Leif Babin — great book to teach you on power of “owning” things and seeing them go from beginning to end.
- “Clean Agile” book by Uncle Bob — another great book by Uncle Bob. Goes in details of how Agile came to be and what it means for developers. I personally loved it!
- “High Output Management” book by Andrew S. Grove — this is a bit more of a management book, but nevertheless a great book. Written by former Intel CEO, it goes in-depth about project management and pulling the management levers around.