How to Productively Work With Developers without Micromanaging

How to Productively Work With Developers without Micromanaging

I’ve seen it work by working with Volker and Dominic (see case study). They got it right. No micromanaging, and at the same time the team’s output was high. What did they do right?

But it’s not straightforward. I’ve seen utter failures where I myself pushed a developer back and forth. It was a mess. Output stalled as he was working on too many things at the same time.

(BTW: This article appeared on our blog over at Pairing.dev already)

If you are anything like me, you fear the same: paying a developer thousands of dollars every month, just to see that nothing got done in the end of the month.

Could it be that the developer was just bad? Or did your management (or your manager?) just screw it up? Most of the time, there’s only one to blame: you (or the manager you hired)

It could be so easy: you specify stuff, then developer works on it, and then you get your finished product. Spoiler alert: Success is not a straight line, but this is definitely possible - with the right tools, which we show in this post.

These tools will also help you weed out bad developers. This is especially true for micromanaging: bad developers respond well to micromanaging. Those people will eat away your performance, and then still charge you - because the hours have been put in.

Are you managing or owning a software product? Have you struggled with this previously? Then let’s look at what you might have been doing wrong all along.

Developers are creative people who need time to focus. Only through deep focus time, good things happen. Deep focus means: working on one thing at a time, uninterrupted.

When everything is important then nothing is important \

Leeor Engel, a PM with a lot of experience (read his blog). His credo is to limit the focus, even of a whole team, to not more than 2 work streams. We have seen this working with teams using graphql in a bigger client application: one pair is working frontend, one is backend. And inside these pairs there’s only one main focus.

True: Only through deep focus time, good things happen.

Now: how do we get a developer to focus on one thing, for a longer time frame? Let’s unroll the three steps to get there.

Have them buy into your vision

I reached out to Dieter, a great PM I worked with a couple of years ago. I asked for his comment while writing this post.

If you define all expectations and show the mission [...], then people get intrinsically motivated, solve problems by themselves, and give you heads-up when problems occur.

I do agree to that. In my 15+ years of professional software development experience I have seen this a couple of times: people like to stick to projects with a clear path to success. However, it’s a bit counterintuitive.

It’s not so much about the vision of your company, it’s about the vision of them inside the company.

• How much are they going to learn?
• How much are they going to earn?
• How will it feel for them, once your app gets traction and has users?

This is counterintuitive, I know. But this is the most important thing about leadership. People only do things that they think brings value to them. And this is the value YOU provide.

Ask yourself these things first. And then, ask these questions to the people working with you:

• Is your product interesting?
• Are you using an interesting technology?
• Are there people in your team they can learn from?

What if my product is boring, and the tech behind it even more boring?

Then you make it interesting. Ask the developer: if you could make decisions here, what would you do differently to make this product faster/better/higher quality? That’s when they will tell you.

You don’t necessarily need all of these 3 points. Just one reason is enough to have the developer buy into your vision.

Do the preparations (= show them that you care)

In 2015 I was working with a developer from Russia, and I had this idea of scraping a lot of websites and selling the data. The project was a complete failure. In retrospect I could have done much more to support the developer.

Let’s use this as an example. Imagine you’d be in the position to direct a developer to write a scraper for websites to aggregate data. Need some ideas? Here’s a list of things most people don’t do. Use some (or all of them), in order to give a kickstart to the developer:

• Make a good landing page and send some traffic on it. Figure out what features people click on. This will give you a priority list of what’s most important.
• Write down the whole flow. Every interaction the user has with the software.
• Research the heck out of your market. What other software is there, and how usable are those products?
• Hire a UX person to take your specification and put it into nice UX wireframes.
• Print out these wireframes, put them on a table, and see if they still make sense.
• Got APIs? Look into them, try to understand what data you can get out of them.
• Got multiple roles? Make a spreadsheet of all actions possible and state what role can do what.
• Got background processes? Write down in a timeline what triggers the process and what happens, when.
• Got mobile apps? Think about all kinds of devices this should run on. What are the screen sizes? What happens when the connection is not available?
• Speed and accessibility. Do you have any constraint on who operates the app? Do users have special requirements or situations when using your software?
• Training: how do you onboard users who haven’t use the software before?
• If a bug happens: who is responding to the support request? How do you take support requests in the first place?

Most people don’t do these things. Many think they can figure those things out along the way. That’s a fallacy, because taking those preparation steps cost way less than changes later on in the development phase.

“I got told that Agile is the way to go. You build, I comment, and we change course” – Yes, true. Agile is not a bad way to go - but it can go bad if there’s no clear deadline and too little specification. See how to ship software within budget for reference.

You might say “But I have a UX designer.”

Yes, a good UX should take care of all the edge cases and ask you the right questions. However, this is over relying on one person. What if that UX designer forgets about a use case? Or they assume something that you should know better?

Taking these measures before you write any code can be magic. You might even find out that you don’t need to write a software at all.

Don’t change course a lot

If you do decide to stop something else then all momentum on it is lost; along with a potential hit to team morale. It’s a lose-lose situation.

Joel Spolsky describes how context switches are harmful. This is definitly true on a micro-level. Once you zoom out a bit and look at a project, the same physics apply.

The problem is this: developers can switch tasks and do something completely different. This is not a problem in itself. It spawns 2 sub problems.

Sub-problem 1: the planning of the feature might not encompass the changes. The developer then needs to change the architecture - and thus loses time. See the title of this essay. We want to increase developer productivity. And this starts with good planning, and then finishing things.

Sub-problem 2: changing course and/or changing definitions of features as you go along is bad for the developer mindset. Developers cannot get into the “finishing culture” - which is exactly what we want here: finishing things and being productive.

If you change features, the developer doesn’t experience the sense of accomplishment - and thus will have less motivation to start the next thing.

--> But what should you do if you really find a case you haven’t thought about?

Then, think about finishing the current specifications. Let the developer experience his win. And then you make a new ticket/story and describe the extension of this functionality.

That way the team feels accomplished and you can still change course later. It might sound like you are overspending here, but it’ll pay off later through better team morale.

Conclusion

Having developer productivity - of course - starts with great people to work with. If you work with an inexperienced developer, those 3 items discussed still help you with your project. But it won’t make an inexperienced developer into a pro overnight.

However, if you work with great devs, then use these three points religiously to get the most out of them. I have seen this over and over again in my work. If you ever want to discuss any of these points, please reach out to me and let’s have a chat!