Tag: Leadership
In today’s tech-neutral age, talent is the key differentiator between companies, with employees a key source of competitive advantage. Top app developers are in high demand to ride the mobility wave, and enterprises scramble to retain developers from being poached.
Developers are by and large content with their current jobs, but three out of four developers are open to new opportunities, and would readily change to a job that offers them better working conditions. Even developers not actively seeking out jobs do spend around an hour per week checking on potential jobs. This is in addition to the time they spend with other developers and potential recruits on communities such as Stack Overflow. In such a state of affairs, employers need to remain on their toes always, to retain developers.
Here are some tips to retain top talent in your enterprise, without allowing competitors to lure them away.
Provide Opportunities to Grow
Most programmers are knowledge workers who value their skills and strive to keep themselves updated. One in every three programmers contribute to open source projects, and a whopping 81% of developers program as a hobby as well. These programmers are neither beholden to any organization, nor dependent on any corporate training program for their skill enhancement. They remain with their organization as long as it is worth their while, and simply move elsewhere if the organization get in the way of their development. Their loyalty is to themselves first and to any organization second. Organizations would do well to understand this fact and provide employees opportunities to grow and develop their skills.
A good salary and fringe benefits are now a basic requirement, rather than any special motivators to ensure employees stay. Rather, if an employee feels the enterprise offers them opportunities to enhance their skill-set, valuable exposure, time to spend in creative pursuits, and more, they are more likely to stay.
Get the Leadership Right
Very often how the employee is treated in an enterprise determines whether he or she sticks on or leaves. As a rule of thumb, an authoritative leadership style is a sure-fire way to doom for the enterprise, and a servant leadership style, where the focus is to serve the employee, by facilitating them to do their thing, works wonders.
Having said this, a charismatic leader, who can lead from the front and motivate employees by dint of authority can also work wonders, no matter the leadership style. A good case in point is Steve Jobs, who would yell and publicly shame his teammates when dissatisfied with their work, and yet made Macintosh engineers believe they could achieve the impossible.
Keep Employees Motivated
The most effective retention trick is to facilitate the employee harness their creativity in tasks that matter to them. Abraham Maslow’s time-tested need-hierarchy theory lists out five levels of needs or motivation that satisfied an employee, starting from the basic psychological and safety needs, a moving on progressively to need for affiliation, esteem, and self-actualization. Most developers, by dint of being “knowledge workers”, have already accomplished their basic needs, and look primarily at higher level needs such as esteem and self-actualisation.
The onus is on the enterprise, especially HR to craft retention strategies, keeping in mind what exactly motivates an employee, and would prompt them to stay. Challenging work assignments, rewarding projects that would enable them to gain the esteem of their co-workers and peers, a sense of satisfaction on having accomplished a project that is really useful, and more are some ways to retain the employee’s interest to stay.
Pamper the employee
Motivating the employee into staying is of no use unless the basic systems are in place. Developers being highly skilled “knowledge workers.” The onus is on the enterprise to facilitate a congenial working atmosphere to do their thing.
Facilitating the employee means pampering to their needs, and a flex-and-fun time, combined with work-from-home options lead the list of facilities sought after by most developers. About 64% of developers already work remotely at least one day each month, and 11% of developers work remotely on a full-time basis, as of now. Nevertheless, much more is required to keep developers happy, and facilitate their creativity. While 57% of developers valued the ability to work from home on vacation days most, 53% of employees valued vacation days, 47% of employees valued health benefits, 40% of employees valued work hours, and 40% of employees valued the equipment they use.
Autonomy and Career path
At times, retention of talent may have more to do with a dysfunctional enterprise than any other factor. A rigid and hierarchical enterprise, with a culture of deferring to authority, and where information is kept on a tight light is hardly congenial for developers, who value creativity and openness. Most talents seek to leave enterprises where talent and merit are not valued, where promotions are a matter of tenure and not merit, and where there are no mentors to guide them.
Programmers value autonomy and empowerment. Empowering them to take crucial decisions regarding their projects, entrusting them to engage with clients directly, drawing deadlines through a collaborative process rather than imposing one from the top, are all steps that make employees feel valued, appeal to their self-esteem, and go a long way in retaining them for the enterprise.
Also, enterprises that fail to chalk out a clear career path for their top talent risk them leaving. Not all developers make competent managers, and many of them do not even seek a managerial position. The onus is on enterprises to ensure progress in roles and responsibilities that suit them. A technical path, parallel to a managerial or supervisory role, may work best for technocrats who may not find managing people their cup of tea.
Top programmers seek continuous value. They seek out highly challenging projects and seek to leave when they perceive the projects they work on are futile or destined to failure.
Getting and retaining top app developers is not easy. However, we offer an effective alternative. We already have a team of highly talented, resourceful, and experienced app developers, with a track record of having delivered several intuitive mobility and other projects, for customers cutting across industries. When you hire us, you are free of all your human resources related worries. Retaining the top talent, pampering them, and preventing others from poaching the best talent becomes our headache, leaving you free to focus on your business.
Last spring, we found ourselves working with a global media giant, to understand why their new high tech enterprise information sharing IT system was not being used by employees. As we plowed through the usual rigors of analyzing feedback from front-line staff, department managers and BU heads, we discovered something puzzling. While the new state-of-the-art system was hardly being used by anybody, few departments and teams used alternate custom-built IT systems to automate their processes. Most of these custom-built systems were rudimentary and offered poor user experience, and yet, every team member had adopted and used their system every day! Digging deeper, we discovered something even more surprising – The development and deployment of these systems were managed by the Line Manager (s) of these departments, who had little to no knowledge of IT or Software Development!
Sure, deploying a new, large, complex, and organization-wide system across different locations is fraught with enormous technical challenges, but the real answer to these questions lies elsewhere.
The IT department, was attempting to solve a technology problem. However, none of the users had a technology problem. They had business problems.
Problems about information availability, sharing and communication in the context of how they got work done. Divisional, middle and operational managers, i.e. the Line Manager was in a much better position to understand these problems, since he knows the people in his teams and how they get work done. Direct involvement of the Line Manager enabled the building of IT tools which solved business problems that his/her teams faced.
In hindsight, the centralized top-down approach of IT system deployment was a mistake. The IT department never stood a chance.
Understanding the processes, practices, people and nuances of every team in a 6000 person global organization was an unrealistic expectation, especially under a tight budget and timeline. A decentralized approach to technology development and deployment, where the Line Manager was empowered to take technology decisions for his or her team, would have yielded better results.
Decentralization, as a management concept, has been around for a while. William B. Given Jr.’s book Bottom-Up Management, 1949 was probably the first to talk about Decentralization, while Drucker’s works over the last 50 years have often made the case for giving front-line managers greater control. However, it is only in the last decade that we saw an increased devolution of formerly centralized responsibilities (like human resource management, risk management, and strategic planning) to the Line Manager.
In this context, the decentralization of IT decisions is a natural step forward. Looking at our own portfolio of projects at Fingent, we see a steady increase in Line Managers successfully creating, customizing and deploying technology solutions for their departments. I believe that there are three key reasons why the Line Manager is successful in independently managing core information technology needs of his/her teams:
- Line Managers, especially those who are hands-on, are able to derive a good understanding of information architecture requirements
- A Line Manager understands of how the team gets work done, and
- A Line Manager’s ability to lead and manage changes to the ways of working.
The right information, at the right time
In relatively flat, multi-functional organizations, workers at every level have decision-making responsibilities. For such a knowledge worker, the ability to assimilate, interpret, arrange, sift and process relevant information is critical for the successful execution of day to day tasks.
Take the case of the failed digital-information IT system; asked to identify the single most important cause of failure, users across departments answered that the information necessary for work was either unavailable in the system, or was not available at the right time or in the right format. Each of the smaller systems that they were using daily was tailored to meet the specific needs of the team, providing different roles in these teams with the information they required to operate efficiently and effectively. Information was shared in the context of the tasks and stage of work, ensuring that it was available to the right person at the right time. These systems thus organized and structured information in a manner best suited to the team’s objectives. Or in other words, they had good information architectures.
Different departments/teams adding value to the organization in different ways need radically different information architectures. Information required for software developers to execute their day to day tasks is usually different from information necessary for a hardware engineer, HR personnel or Sales personnel. The IT department, which led the deployment of the failed solution, tried to create a system of compromises, and in doing so, compromised the critical needs of almost every department. This flawed approach resulted in a significant wastage of money and time.
A good information architecture secures that the right information is available to users; enabling a good technology system to use this information architecture for delivering the right information to the employee at the right time.Creating a good information architecture requires: the allocation of the right resources, interfacing with supplier and customer teams ( internal or external), a good understanding of current and desired processes, and a good understanding of the strategic and tactical objectives of the department. The Line Manager for the team/department is in the best position to take ownership of this activity and to use his resources to drive the creation of a good information architecture for his team or department.
There is one specific aspect of the information architecture where the Manager must be hands-on; performance measurement. Early measurement systems were top down, with KPIs being set by Senior Executives cascading down to the teams. However, with the greater empowerment of teams, we now see teams, designing their own measurement systems, in line with corporate strategy and measurement systems, to gauge own progress. The manager of a team is often responsible for the KPIs, its methodology and also the measurement. He should determine the level of access that different roles in his team, have to these measures.
Providing the right information, to the right person at the right time often provides the base for realizing the value added by technology. This “right information” is realized using the Information Architecture used by a team. Technology can then be deployed to use this Information Architecture to deliver information to employees in the context of their day to day work. The Line manager is in the best position to drive the creation of the information architecture for his team, while securing that it is aligned with organizational strategic goals and the team’s tactical objectives.
Processes and Practice: A Line Manager knows the difference between theory and application
In addition to a good information architecture, technology must also be aligned to systems used by the department, to add value to the organization. These systems are deployed via processes, and these days almost all self-respecting departments and teams of knowledge workers have documented processes. Whether the documented process meets practice is another story entirely. In the case of knowledge work, especially work that requires moderate to high degree of autonomous and creative thinking, tacit knowledge and improvisation trumps documented processes in practice.
When automating the change management system for the pharma enterprise, we discovered that different project coordinators had different approaches, planning, reporting, risk management and interdepartmental cooperation, which often resulted in significant deviations from the documented processes. For such a department to realize the benefits of automation, documented processes alone are insufficient. It is vital to consider the entire system as practiced and applied by the users, and in doing so, prioritizing the creation of tools to automate the desirable aspects of the system. It is the promise of predictability and stability in the way things get done using a system that often determines the effectiveness of deploying the software application. The Line Manager of the Department has a good view of the overall picture, people and the operational details; all of which are critical inputs to good decisions about balancing process and practice to achieve a stable system.
In the case of the pharma company, the Line/Department Manager was able to obtain the necessary strategic, operational and tactical perspective to determine specific processes and practices which were important to automate. Only he had sufficient authority and responsibility to ratify and take responsibility for these decisions. The IT department, or a 3rd party consultant, or even most people in his team would not be able to provide the unique perspective necessary to take these decisions.
The software solution we deployed for this department not only provides the benefits of automation, but also helps the team identify process deviations, enabling good decisions about the acceptance and mitigation of these deviations in day to day operations.
Often, the development of new tools and technologies is a trigger for teams to introspect and overhaul their existing systems. One of our clients, a property acquisition department at a national property management firm, re-architected their processes to take advantage of the benefits that a custom-built software application could provide. Their old system was built around the tools of pen-paper and a commodity desktop solution available then. During our early stages of pre-development analysis discussions, they realized that a custom software application, could free the department from the constraints of the commodity software, and open the doors to add value in new and innovative ways. Through mobile devices, real-time updates, and improved reporting, they could realize benefits that were not accessible to them before. They reinvented their property acquisition processes, providing significantly greater value and increasing the department’s strategic value to the organization. Such successful change was possible because the Line Manager was able to allocate a good team to work with the core process changes and technology upgrade, while he also worked with his peers and governance board, to plan and manage the delivery of business benefits.
Providing change leadership: Who better than the Line Manager?
IT deployment often makes some previously subjective measures objective and visible to all. Employees may be nervous to reveal more information than they used to do before. Then there is inertia, the reluctance to shift from comfortable routines and practices to a different way of working.
Supporting the team to see the change brought about by technology deployment is a leadership challenge. The Line Manager is in the best position to take up this challenge.
Leading such a change requires the active, consistent and continuous engagement of all employees who will ultimately be impacted by the change. It requires the creation of trust, so issues and concerns can be discussed and evaluated freely, together with the perceptions of value and benefits of the new system. This is an undertaking that requires significant effort, often at an interpersonal level. The Line Manager is the ideal candidate to lead such an effort. As organizations become flatter, the manager is a coach and a mentor to the individuals in his/her team. Alongside tactical directives, a Line Manager can use one-to-one meetings, coffee machine conversations and other informal discussions to evangelize the need for the new system and reinforce the benefits: a better work profile, reduced workload, skill upgrades and much more.
Leading such an effort also means assembling the right people, from the very start of the technology development initiative. These are people with the right skill set, organizational credibility and influence. Assembling such a team, and providing them with purpose, while leveraging their strengths and abilities at the right time can make a big difference to the progress and the success of a technology deployment project. Some team members may be good with early phase visioning, while others may be simulated by the challenges of training and change management. Choosing the right people for the right task, and giving them the ownership of creating and deploying the new system can increase interest levels in the entire team. This also leads to greater participation, and mitigating resistance during deployment. The Line Manager knows the strengths and weaknesses, the goals and aspirations of the individuals in his team. This enables him or her to make good decisions about mobilizing the right people for the project.
Leading this change, requires the management of day to day operations, while resources are devoted to the deployment of the new system, and while the department migrates from the old way of working to the new system. The Line Manager can secure minimal impact on ongoing operations, by allocating the necessary time (and backups) for those involved. And also providing the necessary time and support for the entire team to learn and use the new system. He can use his resources and forums to identify potential deployment blockers and mitigate such risks early. For example, staff meetings provide good opportunities to build cohesion and agreement about the new system and the deployment plan. It is also an effective way to source ideas and motivate volunteers for beta testing.
Conclusion
The choice of tools to execute a task requires combination of strategic, operational and tactical knowledge to make informed choices. The IT department in an organization, which services many lines, sections and departments, cannot be expected to have such an in-depth understanding.
The Line Manager is best positioned to have such an intimate understanding of the business and its operations. The Line Manager understands the formal and the informal processes, which gets the work done within his team. He/She knows the measures and indicators on his department’s scorecard, the data required for these and the processes which define these. He/She knows and often owns the processes that detail how his team interacts with other teams, within and outside the organization. The Line Manager understands a team’s suppliers and customers. And most importantly, the Line Manager understands the team today – the people who work for him today, their capability, their skillset and he/she understands the team required for business tomorrow – the capabilities and skill set required to keep up with a changing business environment. From an organizational perspective, giving ownership of technology to the people who will use it, empowers them with greater control and responsibility towards the outcomes expected from them.