Coming from a development background, I understand the disdain that comes from the words – process and structure. Often times, most processes and structures hinder rather than help people to do their jobs. In my observation, one of the reasons why this is has to do with the fact that processes are created reactively in large organizations. They are often written to stop certain actions or behaviours. Most people who move from large organizations to small organizations often understandably cringe at the thought of having process and structure created. However, the lack of process and structure is still process and structure; just very bad ones. Over the years, my career has evolved from being a developer to focus more on management and the creation of IT organizations. I’ve found structures and processes to be very powerful “people engineering” tools. The key thing about making these two tools work is to use them for what they are best at.
The best execution of the lifecycle of a process in my career was the first one I had the privilege to help create. Much of the principles on which I use to create processes from stem from that experience. The project was the second Application Development, Maintenance and Support (ADMS) project that Deloitte had won for this particular client. The second project was to build a support team that was global in nature – we had support teams comprised of over 70 team members that would be situated in Japan, Singapore, India and Canada. My team would be made up of 48 of those team members. I had been part of the first project and executing the process as part of the support team was extremely frustrating. The process had a lot of flaws and the tool that was chosen to execute the process was implemented inadequately. It’s not uncommon for processes to start like that. What made it extremely difficult was how difficult it was to make recommendation for changes that would benefit both the client and the support team. When I was asked to help setup the second project, I requested to be involved in the creation of all the processes that would impact the support teams. The process development team was more than happy to take the input and together we developed the process for the second project. Here is what drove the process development.
- Understand the business problem and ensure that the process solves the business problem
This really is not very different from developing a technology solution for any business. Like all solutions, they need to resolve a business problems. In this particular case, there were multiple stakeholders and each of their needs were different. The stakeholders comprised of the client’s business management team, the client’s technology management team, Deloitte’s management team and the Deloitte’s support team. The client’s business management team required to receive adequate support in a timely and consistent manner. They had a business to run and their own clients to support. The client’s technology management team required to be able to justify that outsourcing was a viable solution to provide similar levels of support to the business while drastically cutting their ongoing technology costs. The Deloitte management team required to be able to report the support team’s ability to meet the agreed to Service Level Agreement by quantifying quality, identify issues and react to them accordingly. The Deloitte support team required to be able to do their job without being caught up in the process. The process should be a by-product of the support process and should not take up more than 10% of a support resources total day.
- Involve the people who are going to participate in the process
This often sounds simple but it often isn’t done well because it is time consuming. We had the luxury of developing and implementing the process in about 3 months. This was reasonable and acceptable to all stakeholders because this was a major change for the client. There was a lot of negotiation between the client business, technical and Deloitte teams to come to a process that was acceptable to all. The solution was compromise for all parties but the reality, like most development projects, is that most good solutions is a result of compromise. What makes them good solutions is that is the solution is acceptable by all parties albeit grudgingly. I had a Project Manager who once taught me that a sign of a good negotiation is when all parties come out as though they have given up more than they should. It means true compromised has happened.
- Make conscious effort to improve the process
Knowing that my team was going to find any kind of process burdensome, I entrusted the ownership of improving any processes back to the team. It gave them ownership of something that they found cumbersome but they were also the ones that would be the group that would most likely be able to suggest relevant improvements. Doing this indicated to the team that the promise made at the start of the project that we would be making process improvements more than just lip service. My role in improving these processes was to understand the change, ensure they met the business objectives and then negotiate the changes with the rest of the stakeholders. The key was to make this a living process. The process had to be relevant to all stakeholders.
- Accept that documented processes are best used as a communications tool not a problem solving tool.
It is useful to help communicate to new members joining a team what is typically expected of them. It is also useful to communicate expectations of when and where other parties are interacting within the same workflow. I’m a big believer that processes should not solve all problems; they should provide the general guide and not meant to resolve every question or issue that the team will face. You have to trust that the team you have is talented and intelligent and the process has to be flexible enough to allow team members to make appropriate decisions to resolve issues creatively without ignoring the process.. It is much better to replace a resources that isn’t performing than to try modify a process to deal with a small number of members that aren’t performing.
- Keep the process simple
The reality of complex processes is that they will fail. Complex processes are cumbersome and are difficult to maintain. A process should enable the team, not restrict them. Complex processes are generally very restrictive.
The most difficult responsibility that any manager has is his orher people. Structures are meant as another enabler to team members. Inexperienced people managers are often a big fan of a flat structure. On the surface, it makes sense. Everyone in an organization should be considered equals. The problem with traditional structures is that the structures are more bureaucratic and less functional. The bureaucracy often creates a layer that does not help the team. The organizational model that I think that is most efficient is the consulting organization at the delivery level. Levels are driven more by experience and capability more so than responsibility at the firm level. You are more likely to have certain roles based on your level. However, those roles are determined by your function within the project. One of best examples of the effectiveness of this kind of concept is that I had the uncomfortable responsibility of sending stern emails to a manager who was two-levels above me at the firm level but we were peers at the project level. While this was an individual I deeply respected, we didn’t see eye-to-eye on the execution of a particular work item but it was in my realm of responsibility. He apologized publicly and we moved on from the issue. No egos were bruised because it was the right thing to do. Every organization I’ve built all have had different elements in them because the business needs were different and the team needs were different. However, they share some common elements.
- It’s difficult to properly handle the growth of more than 8 individuals
This is speaking mostly from personal experience. It’s hard to help mature and grow the talents, skill and professional maturity of any individual. Each individual requires an investment of certain amount of time and energy in order to do it well. And all this has to be done in conjunction to the other responsibilities that you have as a manager. My magic number is 8. This number is derived from me taking about an hour of the morning or afternoon for each individual. 4 days a week allows me to focus on 8 resources leaving Friday to catch up with my own needs or issues.
- Democracy is ineffective in team management
Democracy is great in politics but has no place in technology management. I’m personally a believer in hiring the right team and that often means hiring a lot of smart people. The biggest benefit of having a really smart team is that they are going to have a lot of great ideas. The biggest detriment of having a really smart team is that they are going to have really good ideas that are going to contradict each others and chaos typically ensues in a flat structure. Technology decisions should be driven by purpose. You need someone to make the decision that aligns to the technology vision of the company otherwise the result is a fragmented solution that becomes difficult to support and extend over a period of time.
- Nobody is an expert in everything
Beyond accountability, there also is the issue of expertise. You want to pick the best solution/technology for the problem on hand. When developers are stuck on an issue, they have the tendency to not want to go for help. Creating functional responsibilities around areas of expertise helps you as a manager. You need to have go-to individuals for expertise when you have to make a decision. The team is no different. The team should have go-to people to accelerate the solution of certain problems.
- Roles and Responsibilities are the minimum requirements for individuals
Most people look at formalized roles and responsibilities as limits to what they can do. In most consulting organizations, fulfilling your prescribed roles and responsibilities guarantees that you don’t get fired only in the good years. In lean years, most consulting organizations will look at individual performers and keep anyone who is performing above and beyond what is expected of them. Roles and responsibilities should be used as the MINIMUM requirement for any individual. To be eligible for additional reward, you have to perform above and beyond what is expected of you.
- Responsibilities is not a reflection of value
A manager has different responsibility from a developer but it doesn’t in any way reflect the developer is more valuable than the manager. A good manager cultivates that culture by fostering the growth and mutual respect for every member of the team regardless of responsibility and title. In certain organizations, I’ve created lead responsibilities within a team that are meant to rotate from member to member. I’ve also created special teams where in those projects I would function as a business analyst reporting to team members who would otherwise be reporting to me in the overall project.
Like most engineering tools, it’s up to the individual to decide when, where and how these tools are used. People engineering is not different in that perspective. Process and structures has the right uses for them. The key thing is to understand the purpose, strength and failures of these tools. Used in the correct fashion, it is an effective means to run an organization otherwise it will grind your organization to a painful and grinding halt.