How founders can drive developers productivity

Stack Overflow released the results of its annual developer survey. It shows the greatest challenges of developers’ productivity, according to developers themselves, are distracting work environments, meetings, not-development work, inadequate workload and lack of support from management.

Clear communication drives understanding and productivity, not clear one — make businesses lost $37 billion a year, according to Holmes report. More than half of the projects fail due to breakdowns in communication: misunderstandings, one-sided decisions, lack of strategic alignment and lack of feedback.

We want to talk to founders and managers without technical knowledge and tell them how they can drive team productivity at the workplace and, at the same time, not to burn out, snap, or book the nearest flight to Malta for a month-long vacation after product release.

We choose developers as a focus, well, partially because we’re an engineering company and we manage developers. The other reason is that the language barrier between developers and non-technical people is huge: you can read about design trends or learn how to write a good email copy, but programming language and that hard skill, in general, require a bit more work. Plus, developers are one of those people who do a lot of work in their hands (yeah, just staring at the computer) and distraction management is vital to them.

Note, that we don’t undermine the necessity of keeping distractions out of the bay for other specialists. The recs that follow will be valuable for managing any team.This article won’t be about methodologies and approaches to management. It will focus on soft skills and on how to improve productivity through interruption management and clear communication.

Prevent disruptions in product development schedule with user research

According to Stack Overflow, only 30.3% of developers have absolutely no schedule or spec and work on what’s more important and more urgent. These people are usually more experienced than those who follow or somewhat follow schedule and/or specifications.

We’ve interviewed our managers for this article and they said that communication with developers becomes more challenging if additional corrections or changes appear often and force them to distract from their tasks.

It’s hard to come back in time if every task is planned beforehand — but startups often prefer moving extremely fast in the process, having to deal with in-the-middle and late-stage corrections. That’s often disturbing and discouraging for a team.

The solution is to predict and research all aspects of the development on the stage of planning, double-check and cross-check everything multiple times — and the closer the prototype/sketch/etc to a future product, the better.

Also, do user-testing before development. It may seem that it’ll be much expensive than development, but it actually won’t: a) user tests will allow you to notice things you’ve missed — elements that are obvious to us, f.i., are often not obvious to other people, b) it will allow you to test your prototype on the market from the start and rethink the concept if it doesn’t fit.

Minimize distractions by planning them

Research shows that in the office environment people can focus on their task solely only for 20 minutes. Then, they're interrupted by noise, conversations, calls, messages, etc. Considering the fact people can be productive for four or six hours per day, the number of actual working hours isn't very promising. So, here’s what to do about it.

• Remote work. An option to choose a place to work, by the way, drives productivity itself — that's why so many companies choose to implement distributed workplace principles.
• Silence in the library. Organize, if possible, “silent rooms,” where people do not talk at all.
• Do not disturb. Allow people to use “Do not disturb” status on Skype/Slack and silent notifications and don't make them feel bad for missing something important.
• Schedule communication. Establish a specific time when teams should be available and report on their progress. Two or three times a day is enough.
• Plan for emergencies. Instead of going hellbent on messengers when you’ve noticed something should be added in the project or something has to be changed, set up a list of prioritized events ranging from “we can live with that” and “superurgent.” Address your team only for superurgent matters.

Don’t double message to multiple channels. If you sent an email or texted to someone on Skype, don’t come to him or her with a question if they’ve received your message. They did, they’re just busy and can’t answer to you right now.

Also, a good idea is to establish a system of signals that will cover specific situations, a period that a situation needs to be handled within, and a channel of communication. Like in this table:

Set up meaningful meetings only

Distractive power of meetings is hard to underestimate, but in meaningful meetings you’re planning on what to do next, receive and choose how to act on feedback and making sure you’re up to date on the project. There are:

• Strategic meetings. Places where decisions are made. If you want your startup to be successful, you need to engage experts in the development of your product. That means, that engineering decisions — what and how to build better — should be taken with the help of tech experts.
• Planning meetings. Meetings where you decide what parts of the project should be developed in the defined period of time.
• Daily standups. We, for instance, running them every morning: developers tell what they've done and what they're planning to do in that working day.
• Feedback sessions. In the team format or in a one-on-one format, these meetings are a must if you want to keep developers engaged and establish a culture of communication.

Note, that what’s above isn’t an obligatory list. You can digitize feedback sessions or daily standups. The thing you need to worry about most is to make sure you’re connected to what’s going on in your development team and they are, on other hand, are talking to each other.

You can’t for instance, allow a developer to change something without a) letting people who work on the same project know, b) adding the feature or change in the documentation.

Make non-development work aligned with programming

It’s known that small teams ship faster — but only if all members of the team are committed both to high-performative work and to, well, your product development strategy. Which means — people need to understand how what they’re doing will impact the overall state of things; even developers.However, Stack Overflow survey show that non-development work is third in the list of productivity affecting things.

Non-development work was not specified in the report, but we think it has to do with high-level communication.

For instance, if you want to improve click-through-rate on your landing page, you can go to a developer and ask just that. In other words, you’re coming to a developer with a business problem.

Now, we’ve already written that it’s better to have at least one senior specialist in your team: senior developers usually have no problem with “translating” high-level “I want more people to leave their emails on Demo page” to low-level “We need to talk to research/marketing department and see what are best landing page practices and then, make a pop-up appear only after N seconds a user spent on the page.”

If you don’t have senior developers, things are going to be more complicated: developers may be upset that you want something that is out of their expertise and you will be upset because people don’t want to think about customers.

What to do about it?

Choose very high-level communication when developers are free to listen to you: “People don’t leave their emails and we don’t get to make more customers. Do you know how to fix that?” (No “CTR”, “CPC”, and “Retaining” terms, these are just as specific as “API”.)

That is clear communication which doesn’t make anyone feel underestimated or misunderstood. To get there, you need to drive “putting yourself in other’s shoes” culture — a culture where no one (including you) feels dumb because he or she doesn’t understand what’s going on — and everyone is empathetic and interested in establishing clarity and explaining complicated things. Because work gets better if it’s like that.

Small teams ship better if there’s a sensible workload

Let’s take a look at the startup postmortems:

“Not the right team” is on third place of reasons of startup failure (we know you’re sick of this numbers, but still.)

While the right team requires people with soft skills — because clear communication and ability to get things done without making everyone feel bad also require soft skills; a conflict management and product strategy — the unrealistic mess instead of sensible delivery estimates can kill it.

What are we talking about? Deadlines.

You need to ship faster and outrun the competitors (that point is in the fourth place. Scary.)

You need to deliver. ASAP.

But even if you hire flexible people that can adapt to every crisis, troubleshoot, and still be in time for their tea — you’re at risk.

Because these people will get the job done — and then they’ll burn out and you’ll need to look for new people.

So. Let the developers estimate. And then, research data of delivering such products, and aline their estimates with this data. And then, ask tech expert to evaluate estimates.

Why so much? People tend to overestimate their ability to deliver something in time. You need to draw out your expectations both from what people say and from others, not so interested, parties.

Also, align these estimates with other departments. Marketing specialists, for instance. When will you have a communication strategy? If you going to ask for funding, are you looking for investors or other sources of it right now? Align estimates of different parts of product development and product marketing.

Of course, there are cases where the product is so great and the team is so good that developers (and other specialists) agree to work day and night to release it and be awesome. That’s still living on the edge of falling apart, though. People can’t work under stress all the time — and stress actually affects performance negatively (which again means — distractions.)

Make all work visible and everyone’s input appreciated

Most of the developers’ work is invisible. Everything’s working but the user usually doesn’t want to know how if it is.

It’s important to let them understand their work matter. That user satisfaction consists of the reactions to an app, to the value an app deliver — including its performance. That your profits are connected to user satisfaction and they’re people who’re partially driving them.

Distraction management, by the way, and following the culture of clear communication is a way to show the entire team that its time, knowledge, and efforts are valuable. No one likes micromanagement.

So — create an environment where people will be understood. Gather feedback often and act on it. The feedback that is acquired but not put into action is rather disappointing, meaningless, and demotivating. Praise others’ work, if it’s good, and if it’s bad — explain why, in a language that’s understandable for them.

Companies, where leaders are good in communication, got 47% more total ROI to investors, according to the same Holmes report than those who neglect the necessity to learn how to talk clearly.

Rules of effective communication, in general, are rather simple: don’t be dismissive; there are no “obvious” things in work; be empathetic and make sure people understand what you’re talking about and how to put it in action; listen. Always have time to communicate.

Most of what you’re doing is done through people — how can it be done if you don’t have time for them?