A hot topic in HR and Management I’ve encountered a number of times is “employee engagement”. In fact, according to Delloite’s Global Human Capital Trends 2015 survey, the most important problem and trend in HR is “Culture and Engagement”. The problem of lack of engagement isn’t new. The surveys related to employee engagement exist since the late 1800s and were even used by Frederick Taylor to study people’s attitude. So called “soldiering” phenomenon Taylor observed in his studies is that monotonous work had negative effects on motivation and engagement.
Today, many employees still see work as something that has to be done without caring too much about it. When I mention “You should have fun at work and enjoy it at least as much as weekends and vacations” I’m usually replied with cynicism. According to a Gallup’s survey, only 13% of employees are “engaged”, while others spend their valuable energy and time on e.g. Facebook during the work. More seriously: 64% is not engaged and additional 24% is actively disengaged.
Leadership is often given as the answer with the believe that it has a positive effect on engagement. There is, in fact, no significant research that proves this. Cesario Ramos explains in his blogpost these misconceptions, backed by several scientific sources.
There is a tendency to overemphasize the importance of leadership and overlook more important systemic problems in environment people work.
What effect does LeSS have on employee engagement?
The meaning of “engage” isn’t clear and engaging itself shouldn’t be the goal. Instead to create exciting, fulfilling, meaningful, and fun environment. Organizational structure in LeSS supports creating such environment:
Customer Centric and Whole Product Focus principles create purpose
Refocusing employees engaged in product development toward whole product and actual customer instead of local part or a local activity helps in making work purposeful. It answers the question: “Do I contribute to a whole product and therefore customer value?”. This is particularly important in large product development, where it is common to feel lost or irrelevant.
Some people are satisfied with their work without having a whole-product focus. How? They optimize what is in their control and this often leads to local optimization.
For example, the system architect tries to manage all complexity but has this nagging feeling: Did my contribution really work out?
Even more present is constant tension with other people involved in same product development. It looks as if there are many separate goals, instead of delivery of a single product.
People want to see an own contribution to have a positive effect for someone else, the customer. One needs to see this effect as frequent and clear as possible in order to get out of bed for more than only a salary and possible bonus.
This sense of purpose can be achieved by having a clear product definition and product vision. All team members are involved in this. This is usually during a workshop such as Product Vision Board, Product Vision Box, User Story mapping.
From there, the constant reminding of the product vision happens during Product Backlog Refinement where team members engage directly with users, customer, and other stakeholders. No matter the size of the product. When we compare LeSS to Scrum, LeSS ensures strong collaboration between teams and customer / stakeholders by having one PO for a whole product. Not one PO for each team as then the PO often stands in between users and the teams.
Therefore, teams see the achieved value via the quick and direct feedback received from customer / stakeholders. No “translator” such as BA, Product Owner, (Project) Manager, Architect in between.
Developer’s job enriched
Great developers today do not stare at their screen and avoid people. Not much of these jobs are left, and it is unlikely to improve in the future.
Working alone implies a lack of sharing and lack of shared responsibility. The effect is that code and (automated) tests tend to become unreadable for others.
The job is exciting and powerful (“I’m important to others”) in the beginning until it goes into production and everyone wants something from this single developer. This creates stress and frustration since there is no one to help out.
The job of a developer isn’t just writing code. Not even just writing quality code. The job of a developer includes continuous integration and test automation. But that is not it. Even requirements are part of a modern developers job. A big chunk of the time developer collaborates with customer, stakeholders and other developers.
“We hate meetings. Period!”
Meetings are passionately hated. They are dreadful, long time-slots, stolen from a developer by someone “more important”. And they always come too late. The goal of most meetings is unclear and people boast while you wonder “why am I here?”.
Despite this passion, the problem is usually not meetings in general, but the lack of involvement and empowerment to influence and decide what happens in the meetings. LeSS supports effective collaboration and meetings help achieve this. The people who hate meetings do get together, share, discuss, and make decisions…together. In other words, they do meet but don’t call them meetings.
Most developers I meet do not like large product developments (except salary part :-)). Why? It isn’t because they are large. Not because their products are insignificant as they are often important products with nice challenges and impact. But it is because there are so many wasteful activities between own work and creating value that effect of own work is much less visible.
Luckily, in my experience, there is hope! In a LeSS organization, the job becomes more meaningful, powerful, and circle of influence is significantly larger. And meetings become fun! They become places where creativity happens, complex problems are solved and continuous learning nurtured.
In a product group adopting LeSS, a developer can influence not only what happens within the boundary of her own team, but also cross-team and whole product. This is what creates a fulfilling work environment.
Manager’s job enriched
Managers often ask the question, “If I’m not supposed to decide what people should be doing, how they execute their work, then there is not much left for me to do. In the best case, I don’t really know how to do my job without this.”
Why would managers think this?
Organizations have often pushed the manager into a position where the manager is the one who makes things happen by defining what needs to be done, how the work is done and supervision. There is also a tendency to look up to e.g. Steve Jobs or Elon Musk as role models. But they misinterpret their importance. Despite all leadership or what I call “humbleness” training, if you as a manager are the one accountable and responsible for everything that happens on your team you will be skeptical about self-management.
Most managers involved in LeSS adoption find the change positive. The reason for this is found in their actual job before the change. Ironically, in strongly hierarchical organizations middle managers tend to be very busy doing not so inspiring work. E.g. yearly performance reviews, budgets, objectives, KPIs, reporting, hiring and firing people, salaries, and bonuses. In fact, such managers tend to make long hours especially during the last months of the year, and beginning of the next one.
The more satisfying part of their job tends to be rather a minor part. The fun part of being a manager (besides a good salary and status :-)) is that manager supports, helps and teaches teams with their knowledge and experience. Managers should also create spacetime where people can learn, grow and excel.
LeSS principles, rules, guides, and practices help to simplify or completely remove many of the annoying practices. This creates more time for the manager to be meaningful to her teams. Instead of continuously and under pressure deciding what people should work on and how they should work, a manager is very visible and contributes by resolving impediments, pairing with team members, personal coaching, organizing events, open spaces, etc. A manager is also a matchmaker between people across departments and other groups of people. Therefore, in LeSS, the role of middle management is capability building.
Also, self-managing teams do not happen overnight. It takes time and effort to achieve this. Managers play a crucial role in the creation of this mindset by very actively delegating responsibilities to teams.
In some cases although not recommended, managers become ScrumMasters, and sometimes go back to development and become valuable team members while still retaining all benefits.
However it turns out for each of them, I never met a manager who was not pleased how the job changed after transformation, although the ride towards this point can be quite difficult.
Customer’s experience with IT people enriched
In large product development, customer satisfaction is often a sanity check. Customer dissatisfaction is a symptom of organizational dysfunction. Any improvement is not sustainable if it is not reflected in some way in customer satisfaction. In case there is a lack of it, a never-ending blame game between customer and IT guys is played. Unfortunately, this blame game becomes de facto standard after being played for years. It results usually in a complex contract game where situation stabilizes and the problem is covered up. The blame continues and nothing has really improved.
Although “Customer collaboration over contract negotiation” is embraced in Agile practices, it is often not reflected in the reality of large product development.
For a customer, one of the promises of Agile development is close collaboration with a team that is able to fulfill a need in an iterative and incremental manner. We are talking here obviously about a real customer need, and not so-called technical need.
But, although teams on are so-called Agile teams, you can’t really talk directly to any of them.
Why not? None of the teams is able to deliver your wish on their own, and their focus is one application. In other words, part of the puzzle. They are component teams. A common example is corporate banking products that usually translate into a chain of many separate applications that need to be changed. Each of them is managed by a separate “Agile team”. A complaint from an internal customer I’ve heard a number of times: “I don’t even know who do I need to talk to about this”.
From the customer point of view, it becomes frustrating and impossible to be bold, try something soon, experiment cheaply, collaborate directly with developers. At that point, the customer tends to be cynical about the whole Agile thing.
In LeSS, this complex corporate banking need is the product or part of a product. Teams are organized around such a product definition, and since they are feature teams, each has the capability of making changes across many applications. The customer interacts directly with a feature team that is able to fulfill a need completely.
Collaboration in this context could mean:
- Discussions about idea and possibilities
- Doing experiments for one sprint and getting direct feedback on daily basis if needed
- Finding out how difficult would be to get product / feature delivered, and whether it could create value at the end.
- Delivering product iteratively, within few weeks or faster after having it prioritized by Product Owner.
This reduction of organizational complexity translates into the removal of the wall with IT people where blame game is reduced and contract game not needed anymore.
Conclusion
Therefore, LeSS has positive influence on engagement by:
Improving sense of purpose in large product development through principles of customer centricity and whole product focus
Broadening developer’s circle of influence through decentralized decision-making and closeness to the customer.
Enabling to take more meaningful work for people with role “manager”
Seeing more satisfied customer.
RSS feed