Once all the groundwork is done on your project, you are raring to get cracking on that code.
You research a few organizations, check what their previous customers have to say and finalize one of them to hire the most qualified and efficient developers, ideal for your business.
The Developer interviews are impeccable, and you get the feeling that they are the best bet to get started on your innovative project.
But 3 months down the line you start to realize that this relationship isn’t working as seamlessly as you had imagined. Even after spending a reasonable time with your developers, you don’t feel a bond building. The developers you hired are contributing as per the plan, but there is no spark in their demeanor of working on a pathbreaking idea.
So where did this relationship go wrong? When did the boat start rocking? Did you not bring them flowers on the first release, or you forgot the 1st anniversary of database migration, or are you the one acting paranoid?
Many entrepreneurs at the start of their journey realize that something is wrong. Proceedings aren’t going as per their dream sequence, and things are falling apart in real life. But what they tend to miss out on is introspection - questioning if there was something they are doing wrong along the way.
Delegatophobia
This is a made-up term for a very real phobia. The fear of delegation.
In almost all cases, you the entrepreneur, have the project imprinted in your memory. You know it like the back of your hand. Many features are dear to you, and you have intricate specifications on how it should actualize.
Over perfection can be a major hindrance while delegating modules. The urge to do it all arises and takes over. “Since I know most of the modules so well it is better that I take a crack at it.”
Hidden inside is a very subtle notion of either losing control over the development or losing the tasks you enjoy doing. There are other reasons too, like a lack of faith, a feeling that you can do it better than an external developer or having a bad experience during the earlier outsourcing escapade.
Some entrepreneurs are always in a hurry and nurture an aura of being out of time. “The product that we are developing should have been in the market yesterday.” The project deadlines start to feel like hurdles and hence a failure to delegate.
All these assumptions create a counterproductive outsourcing experience. Gradually you realize that you are not getting the adequate output you imagined from the hired developers.
An easy way out of this is, before initiation, list out all the tasks that you are willing and unwilling to delegate.
For the tasks which you are unwilling – Go over the reasons why it is so. In case the reason is a lack of faith – Find a developer that generates faith within you during the initial interview session.
If the reason is a lack of time, try to find a team who can do it faster.
The guideline here would be to utilize developers for the expertise that you have hired them for and not just get them engaged in trivial tasks while you carry the real burden. Minimize the risk by planning ahead and keep a regular check on the quality and timely delivery of the code.
Micromanaging
A synonym of Micromanagement is Lack of Trust.
This might not be true, in the dictionary, but is very much relevant in manger-developer relationships.
Keeping track of the progress and contribution is one aspect, but governing the way a developer should spend a day would be overdoing it.
If your developers await your go-ahead at every deployment; if you require regular updates from every developer; you are cc’ed in every minor email; you insist on giving detailed instructions on how to execute a task and most of these tasks are completed late awaiting your approval, then you are a Micromanager.
How to stop micromanaging
- Have a chat with your developers and set your expectations straight.
- Set up scheduled updates that are adequate only for your reporting needs
- Step back, be an observer, not an intruder.
- Reassure yourself that people will do the right job when handed responsibility.
- Your personal desire to win should be set aside.
Believing Deadlines
At the end of the day, Developers are creative individuals. Painting a final picture of the project in their head won’t give them an assessment of the timelines required to finish it. Hence, with this rosy picture in mind, they tend to provide you with an overly optimistic deadline for it.
Rest assured their intentions are not to get you into a fix or to fool you. But rarely do developers have to ability to forecast an estimate for the quantity of code that would be required to produce the kind of product you have imagined together.
A bird’s eye view of the project makes it seem doable in a very short span of time. This estimation is often off-track by miles. Make sure you add twice or thrice the amount of time projected by developers before you commit to the stakeholders. Have an administrative or managerial person to align realistic deadlines for you.
Dynamically Changing Requirements
Sitting in a corner, anticipating when the product will be ready you feel like a customer waiting at a restaurant, ready to be served. But this excitement leads to incubating more ideas of how the application should function.
“This minute change in design would be a boon for the customers. This feature will give them new wings” are thoughts that run through your mind, which motivates you to run to the developer’s desk. Feeling that you can throw new ideas to the developer at random and he would be as ecstatic as you are to accommodate these changes is a misunderstanding.
You have spent hours sitting with the Developer, going through the Requirements Definition phase. Sign-offs have been done, and the developer has aligned himself to fulfil them. These additional changes seem like impulses, that an animated mind keeps coming up with.
This will not only disturb the rhythm of development, but also impair your relationship with the Development team, as a manager who works on whims. It projects that you lack clarity and are easily diverted by attractive looking avenues.
An alternative would be to jot down all the amendments that you think of and sit tight till the first working version of the Product is out. Modifications and Additions can be done in further releases when they are examined, and their Feasibility has been judged.
Ignoring Technical Expertise
Most entrepreneurs coming from a technical background tend to believe that they have detailed information regarding the technology being used in the implementation.
Informed individuals tend to cling to obsolete knowledge due to their prior experience, unyielding to an expert’s views on the subject. This tends towards using the older methodologies over and over again without exploring the nuances introduced in the technology.
This sounds like a classic example of the Dunning-Kruger Effect.
It doesn't make sense to hire smart people and tell them what to do; we hire smart people, so they can tell us what to do. - Steve Jobs
When you override an expert’s opinions that would mean that either you have not recruited the right person for the job or you are not ready to deviate from your traditional plan.
This could have adverse effects on the developer as it would induce a feeling of being neglected and a display of distrust in his abilities. This could lead to an aloof employee who operates under the umbrella that whatever the case be, his opinions won’t matter.
Scaling Up Too Fast
As in the influx of funds start increasing all entrepreneurs yearn to expand their company to accommodate more. With this in mind, you start scaling up either by increasing the flow of work or by hiring staff impulsively.
While it seems good that your company is growing, you might end up hiring too many heads, prematurely, without having projections to sustain the inflow of work. To avoid breakdown most startups end up laying off their workforce as their leads start to dry up; which is detrimental for the morale of the rest.
A second scenario would be wherein your entire team turns into workaholics and are seen trying to overcome their workload. This indicates that your staff is spread thin, the process needs a slowdown and a more step by step expansion needs to be planned out.
For startups, to be as lean as possible for as long as possible is the mantra. Grow as the business grows, and accommodating changes with an elaborate plan will avoid you the rush of scaling too fast.
Not Providing Challenging Tasks
Even harder than finding real talent is grooming them and keeping them updated with the latest technologies.
Monetary incentives are at the bottom of Maslow’s ladder as a very rudimentary motivator. Employees grow beyond just monetary benefits as an incentive to be on the top of their skills.
The team’s purpose and the project vision are primary in inspiring their dedication. But in the long run, as the monotony sets in, it is difficult to reignite the same vigour in them.
Hence, it is mandatory to provide developers with tasks that seem challenging, and which would require niche skills and would take the team ahead by leaps and bounds.
Such challenges, on intervals, help them to keep updated as well as endorses a feeling of accomplishment associated with their daily tasks. Motivation is contagious and gradually creates sharp developers, encouraged to find innovative solutions to mundane tasks as well.
How To Keep Your Developers Motivated
1. Reward your High performers
Most developers crave recognition, especially high performers. Developers await getting recognized for their significant contributions. Rewarding high performers not only helps lift their spirits, but also creates a healthy competition amongst teammates to perform better.
2. Treat developers as individuals
It is instinctive for entrepreneurs to treat developers as a temporary hired hand. But each of these developers is a distinct individual with unique traits. It is incorrect to pigeon hole them into one category and expect the same output. Recognizing them as individuals helps to identify their potentials and to allocate appropriate work to each accordingly.
3. Provide them space
Detailed instructions on tasks or constant status updates cramp your developers. Giving them space to experiment will produce more path-breaking ideas and will rid them from fear of causing bugs or breaking the build.
4. Follow latest technology trends
Developers are often eager to work with newer technologies or frameworks. Giving them that opportunity will not only keep them up-to-date and motivated but also keep your systems and applications updated, directly enhancing the services. It also creates room for career growth.
5. Manage the processes not people
When you do not get the outputs that you expect, work on improving the processes involved in delivery, rather than micromanaging or overburdening the developers. Timesheets and effort tracking are distractions for developers, keep them to a nominal amount.
6. Cut down on the reporting
Reporting is considered tedious and monotonous and often reluctantly wrapped up or ignored by developers. Streamlining the reporting to a minimum will not only improve the quality of the documentation but also make management easier. This will leave them with more time for development tasks and research.
The foundation of any long-lasting relationship is trust. Gradually building trust on your teams’ abilities and utilizing them to their right skills is the core of a manager-developer relationship. Though this might not be an overnight task, making your expectations clear and incorporating their productive feedback into your plan, will help you establish a mutual agreement in the beginning. Even though this list comprises the common mistakes that entrepreneurs make, which can be easily avoided; mistakes are inherent to learning. Adapt and learn as you go would be the mantra for startups as you deal with your extended family.
Most organizations that are adopting Agile are moving towards building Agile Teams. An Agile workforce is the future of distributed teams. To know more about agile, here is a Guide For All CEOs on the most common Agile related queries.
