Year: 2019

Software developer asking his boss why it takes ages to receive feedback

The Cost of Waiting for Feedback in Software Development

October 3, 2019 / / 2 Comments

[In the series ‘Explain this to me like I’m a manager’]

Let’s imagine you are paid to write emails.

The company you work for has a policy that all public emails from an executive should be written by someone with a clear head and proper training. That someone is you.

It works like this:

  1. You receive an in-person briefing from the executive of what the email is about.
  2. You go back to your office to work on the email. In case a question arises, you phone the executive and usually get an answer right away.
  3. When finished, you present your email and edit it together until you’re both satisfied with the result.

The whole process takes about half an hour up to several hours.
This seems OK. It might even be kind of fun, right?

Now, imagine a different way of working

The only difference is that you’re not sure when you’ll get feedback or approval. It might be right away, or it might take several weeks.

Since you don’t know how long it’ll take, you start working on the next task. Instead of having 1 email “in progress,” you might have 20, 30 or a whole lot more.

This the exact same job, with the same input, but it seems much more cumbersome and a lot less fun, or not?

Well, unfortunately, this is the way most developers are working

In this example, we’re assuming there is no middleman (PM, analyst…) through whom all communication passes, introducing his or her own ideas, obfuscating the message in the process.

As a developer, I have often found it very frustrating when it takes ages to get feedback or answers.

You start working on something. You get stuck, you need feedback. Because you don’t know when you’ll get answers, you put the task on hold and start working on the next one.

But wait, the client has the exact same frustration!

Yes, I’ve been there: for several years, I worked on the other side, steering contractors/freelancers to develop custom software for our organization.

It is just as annoying to give extensive feedback to a developer, only to get additional questions 2 weeks later. These questions are usually ones that could have easily been answered if asked right away, but 2 weeks later, I can hardly remember what it was all about!

Surely, there are better ways to waste my time!

What is the engineer’s solution?

Let’s use a tool to manage all this “work in progress”, with statuses, flags, due dates, source integration, custom fields, assigned persons, reports, milestones and all that jazz.

This is an often unnecessary over-complication that is regarded as standard practice.

“That’s how it’s done!”

There are indeed situations that demand this way of working.

But, most of the software projects out there are actually quite straightforward and don’t benefit from these “solutions.”

The root cause is still there: it takes too long to receive feedback. As humans, we can’t temporarily store our built-up understanding—our “grasp”—somewhere until we need it again.

So, what’s the alternative?

We are all busy and we can’t just drop what we’re working on whenever someone demands our attention. But what if we could?

What if we could work on 2-3 tasks at the same time?
What if we didn’t need tools (except for a basic to-do list) to manage the progress of all our tasks?
What if we could work intensely with the client on a few tasks from beginning to end? And not start a new task until these were actually completely finished?

Why am I asking these questions? Because it would save time, money and frustration!

This is one of the core elements of several task/project management frameworks that suggest focusing on a limited number of tasks during so-called “sprints,” or that impose a limit on the “work in progress” (a WIP limit).

Often advocated. Seldom practiced.

And really, no one is asking you to drop everything at every question; just don’t let things slide forever.

Do we really waste that much time waiting for feedback?

There was a study, conducted at Palm in California, the makers of the first PDAs. This study measured how much longer it takes a developer to fix a bug detected 3 weeks later instead of on the same day.

Now, how much longer do you think it takes?

About twenty-four times as much, no matter if the task is big or small.

Did you also fall off your chair? My initial guess was 5-10 times, which should be enough to inspire anyone to give this some additional thought.

But waiting endlessly for feedback isn’t the only cause of WIP explosion!

It’s also:

  • The delay between analysis and development
  • The delay between development and testing (if you use testers)
  • The delay between a developer reading the tester’s feedback and acting upon it
  • Waiting for approval or a sign-off on something
  • …

Now, how do we fix this?

Well, it’s not that hard… to write about! 🙂

Here are my suggestions, which should work no matter what role you’re in:

  • Try to get everyone on board. Send them the link to this article. Or send them this excerpt from The Scrum Book; the author is just a bit more known than me, so it might work better! 😉
  • Lead by example: give feedback and answer questions on the same day or at least within 24 hours.
  • Explicitly state that you try to give feedback asap. Actively request the same from everyone you work with, including clients and managers. Follow up if necessary. A lot of people let things slide until they notice you’re consistently following up.

And, if your role allows:

  • Try to get everyone (necessary/needed) working on roughly the same task(s) at the same time.
  • Try to limit the number of tasks and the “work in progress.” Impose a WIP limit.
  • Cut the number of in-between-persons. They often serve no real purpose, except to consolidate or translate information. Developers often communicate too technically. I still make this mistake myself. But I also believe you can learn to communicate on a more non-tech human level. Listen to what is really being said, and try to respond at the same level using the same words.

I think it’s always better to have direct communication lines because it improves the possibility of learning from each other.

But I’m a developer. I can’t just demand my client’s attention!

You’re not demanding immediate attention; you’re asking not to wait for ages to get a reply.

I know this is not the standard way of working for a lot of developers: being proactive instead of reactive, reaching out instead of tackling that next user story or bug. I don’t mean to be condescending. I speak from my own practice, from the mistakes I’ve made, from experiences with failed as well as successful projects.

This might be one step (of many) to becoming a “10x engineer” and to show that you’re on top of things and care about the project.

Remember, all those non-tech people you’re working with really don’t know much about software development.

There’s nothing wrong with steering and educating them on how to optimize the process and save time and money. Who could be against that? (Unless, of course, your time is billed by the hour 😉

… And what if you get feedback from multiple sources, contradicting each other, even contradicting your own opinion?

Tackling “Design by Committee” is another story. Sign up here and stay informed.


This image shows Nessie, Bigfoot and a 10X engineer and asks if they are 'fact or fiction'

Those are not 10x engineers you’re talking about

August 22, 2019 / / 0 Comments

There’s been a lot of discussion on Twitter recently about so-called 10X engineers. Here’s the tweet that started it all:  

Just to make sure you’re on the same page: a 10x engineer supposedly provides extraordinary value to their team and organization.

Now, this has resulted in dozens of jokes, memes, people wondering if these engineers also incur 10x technical debt and so on.

The general idea is, you don’t want to work with someone like that. 

But these are not 10x engineers.

These are exactly as described: toxic jerks. And there’s a huge difference between the two of them.

Sure, toxic jerks might self-promote their way to being perceived as a 10x engineer, but I doubt they will ever provide 10x value to their team or organization.

In what kind of organization would that behavior ever provide a 10x value? What kind of organization even enables such people to thrive? (Politics, maybe? ;-))

I do understand that if you’ve never worked with a 10x engineer, or if you believe they don’t exist, you may mistake this person as one.

And yes, I’ve worked with these toxic jerks and of course, I agree that you want to avoid them. They can provide value in some edge cases, but I’d rather not have them around.

Fortunately, I’ve also worked with what I regard as true 10x engineers.

And I’m not the only one.

(show full thread)

Whether they provide “10x” value is another discussion. Let’s assume for now that they are very valuable to their team and organization.

And how do they do that? Well, these engineers have a combination of the following traits:

  • Better-than-average tech skills and knowledge in a wide area. (OK, this one was obvious.)
  • Eager to improve how they work and how the team works.
  • Assisting other people, taking new people under their wings.
  • Giving credit where credit is due. 
  • Good communicators, good listeners.
  • Not too cocky to change their mind or admit they were wrong.
  • Eager to learn, on a wide area of topics.
  • Accumulating domain knowledge, if active in a specific field.
  • Dedicated to their job and everything related.
  • Emphatic; trying to understand the customer, colleagues, their manager, …
  • Last but not least: ideas of 10X value (or way more), because of a combination of the above!

This is by no means a complete list; it only contains what I remember from the “10x” people I’ve worked with. Just to be honest, none of them possess all those traits and some can be a bit of a jerk from time to time but never in a major toxic way. Like most of us, right?

Note: there are a lot of soft skills in this list, but they are still engineers, and their excellent tech skills remain their biggest asset. 

The 10x value isn’t all originating from the engineer, though.

The culture of the organization and the environment they’re working in play a major role too.

Can they work uninterrupted if necessary?
Do you promote a culture of helping and sharing? 
Do you facilitate good documentation, provide the necessary tools and training?
Do you often reflect on your way of working (a so-called retrospective)?
Is there a constructive, no-blame culture?

Going from a noisy open-plan office to having a couple of distraction-free hours a day might already “2x” your entire team. Unfortunately, I’ve seldom met a non-tech manager who believes strongly enough to actually take action.

You know, those engineers you see with their headphones on? It’s not because they like music so much; it’s because the music is less distracting than the office noise.

Bossy guy complaining to someone else: "They can't be that busy, they're all listening to music". There is also an "engineer" working concentrated in front of his 3 monitors, wearing headphones.

Now, how do you recognize these 10x engineers?

Well, in my experience, the direct colleagues and managers know, but the rest of the organization usually doesn’t.

It has taken me weeks or even months to realize a person I’ve been working with belongs in this category. It’s not that they fly under the radar or keep a low profile, but self-promotion isn’t on top of their list. It’s also possible I’m a bit slow at recognizing such things.

Sometimes, I have suspected people to be 10x much sooner… in a matter of days or even hours. But these have almost always turned out to be self-promoters of the toxic jerk variety.

So no, there are no rules or tricks. It’s the same as finding out if you like working or living with someone. Maybe you’ve got a gut-feeling, but it will take some time and going through tough and stressful situations together before you know for sure.

Would it be possible to nurture engineers to 10x level?

Well, I’m sure you can, up to a certain level and with proper coaching.

What I’d do is provide a “10x nest” with an optimal culture and environment to attract, nurture and retain 10x engineers. 

Yes, I know that sounds mushy, but there’s a shortage of good engineers. Instead of hiring additional ones, what if you tried to optimize for the ones you’ve got?

Providing a good environment and culture might attract more talent if needed, as 10x engineers often have other 10x engineers among their friends. Birds of a feather flock together, so why not let them flock to your 10x nest?

But be careful that you don’t end up with a toxic clique!

Have you worked with 10x engineers?
Or do you only know toxic jerks impersonating as such?
Don’t hesitate to reach out on Twitter or by email!