The K Unit

Tag: management

Process and Structure

by kelvin.kang on Nov.07, 2009, under People-Engineering, This-and-That

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Leave a Comment :, , more...

Sucking down

by kelvin.kang on Oct.12, 2009, under People-Engineering, This-and-That

This is a re-post of one of the first blogs I ever wrote. As I started the People Engineering category, I thought it was a good time to re-publish it again.
Guy Kawasaki is one of my favourite blog writers. I don’t know that much about him outside of the short blurb that is written on Wikipedia. I enjoy his blog because his topics cover a gamut of areas such as ethics, enteprenuerism, business smarts and even social smarts. In many ways, they all link together but it’s nice to see someone link these concepts together and how they are relevant to be successful in today’s world.
 
The second paragraph of his most recent blog entitled “The Art of Sucking Down” caught my eye. The entry talks about why it’s important to treat people without the big titles with respect because they are the ones that make the world run. So often we get frustrated with customer service reps or front-line staff when things go wrong. We wish that they would just “do their jobs.” Maybe they are and that’s the problem. What we really want them to do is to go above and beyond the call of duty but how do we do motivate complete strangers with no relationships with us outside of the fact that we are a customer of their employer. Guy goes on to outline 9 simple but relevant concepts that makes sense by going through the lifecycle of persuading someone who is not a celebrity/upper management/CXO type to do something for you.
 
This story from the Blackout of 2003 comes to mind when I think of this topic. It was on a Friday afternoon when someone alerted me that most of the East Coast of the North America had been completely blacked out. I had been in the San Francisco area for almost a month without coming home at that point and was anxious to get home. So all of us from my Toronto team – Jay Helmer, Jonathan Kwan (JK for short - he’ll be the main character of my story), Sarbjit Bath, Keith Tran and myself – decided to chance it to go home that Friday afternoon. When we got to the AC counter, we were automatically told that we wouldn’t be let on. JK in typical JK fashion went through his usual tirade when he doesn’t get what he wants. It’s typically pretty entertaining in general and definitely worth the show :) But ultimately, it didn’t really help our cause that day. It didn’t help at that time that not one of us had status at AC but luckily we had previously purchased Keith and Sarbjit business class tickets and we were able to pack them onto a plane to get home. That just left Helmer, JK and myself to deal with. We were able to hook up with Livia, Eddie and Deepika as well who were at the same client but different project. Fortunately, Livia had status. She gave us her number to use. So while we couldn’t get to Toronto on Friday night, we were able to get ourselves a little closer – we had found our way to Chicago on a flight the next morning. At least when we got to Chicago we would have a number of options. One of them would be to drive home if absolutely necessary. It would have been extremely expensive but at this point the problem stopped being cost; it was a race agaisnt time because all of us would have to be back on a plane that Sunday night on the way back to San Francisco.
 
When we got to Chicago, we had to go through the same ordeal. All the people who had flown earlier that day were now stuck in Chicago trying to fight their was back to Toronto. So as usual, we sent JK back into the fray to negotiate a seat for the three of us – you’d think we would have learned our lesson ;) . However, JK used a different tactic this time around; maybe because this ticket agent was a female, maybe because he had decided a softer approach for different results but the end result was that we had ourselves booked on a flight that would get us back into Toronto late Saturday night. As a gift for the ticket agent after completing the transaction, he bought her a bunch of chocolate because he recognized that she hadn’t eaten the entire time we were there. The entire ordeal took over 6 hours. I thought it was nice of him to do that. The story doesn’t end there. Livia and Eddie were booked to go on an earlier flight but that wouldn’t leave for another couple of hours so we decided to have a quick bite to eat because we were all exhausted. By the time we were done eating and gotten back to the waiting area long before the supposed departure time of Eddie’s and Livia’s flight, Eddie’s and Livia’s plane had already left! You can imagine the dismay and anger of Livia and Eddie. Missing a plane that day was like shooting yourself in the head. We had no idea when they would be able to fly back again. So once again, we sent JK back into the fray. JK went back to the ticket agent to negotiate on Livia’s and Eddie’s behalf and miraculously they were on the same flight as us. While I don’t think the stewardess thought that she owed JK something for the bag of chocolates, I’m pretty sure that his kind consideration stuck out in her mind and it was in some ways a way of bonding through human understanding between them.
 
While the topic of “sucking down” is definitely appropriate for selling and negotiating, I can’t help but think about how relevant this topic is to leadership as a manager. As a team lead, you still have a lot of direct influence over any paticular problem or situation that you could be facing with. You could physically do the work in order to get something accomplished. As a manager, you start to have even less. You could at best keep an eye of a paticular issue but as a director, you now have multiple issues that need your attention as much as the next. The reality is that you are extremely dependent on the people who report to you. So here’s how I would “twist” Guy’s article to how I would relate it to my working experience:
 
1. Understand the dynamic. Guy talks about appreciating the fact that while the person you are facing is a “lowly” ticket agent, they are in charge of your fate right now. This is no different than facing an escalation at work. While the person across the phone or across from you may be a “lowly” developer, this is the person who will ultimately control the fate of your issue. As much as you as an individual may have the capability of coding your way out of the mess, that will come at an extremely high cost because your eye needs to be on multiple balls at the same time. Empower your team, build their confidence and let them know that you trust them – then get out of the way. Ultimately you really have no choice.
 
2. Understand their needs. The key goal here for Guy is to emphatize with the person whom you need to help you. In the IT world, I would look at this for someone in a management or senior management role as clearing the roadblocks. Assuming that your team is going to do what it takes to get it done, you have to make sure that you understand what they need you to do. These are usually things like getting direct access to environments, ensuring that are direct escalation paths to third-party vendors or key client personnel and access to required expertise within the firm. This is probably the single largest value that you can bring to an escalated situation.
 
3. Be important. Guy describes the importance of building equity with a vendor in this section of his entry. Conceptually, this is no different for a manager or director. You are important in title and your title will only carry you until your first “battle.” After that, you have to prove that you are worthy of the title that you carry. A couple of things come to mind in this area. It’s part of understanding the needs of the team – in an escalation, what the team needs is to be focused. So being “important” here means that you shield them from the heat that is coming from the client, upper management and/or business counterpart. Get the team what they need and get it to them quickly. Usually if you do your job well, the team should never hear it directly from you. This is one key way of building equity with your team; this is how you earn their respect. Another important lesson I learned from JK on this project was understanding the visibility of your role. When I step into a situation where it’s teetering between being escalated or not, it is automatically escalated by my sheer presence. What goes through tme mind of the client is why else would I be there if the situation doesn’t warrant my attention? Another side repercussion is that it takes away any confidence or credibility of your team lead because you are now the focal point. Let the issue be the team lead’s show and come in at a time when you and your team lead decide you can bring direct value to the situation (or when the client demands it which is usually bad :) ). Another key point here is that constant communication is always important. Ultimately, it’s your ass or your boss’ ass on the line. And trust me, when it’s your boss’ ass on the line – it’s STILL your ass on the line. That’s part of what being important is about.
 
4. Make them smile. The all important ice-breaker, the first impression with someone who could open the door to a plethora of opportunities. From a team leadership perspective, it is slightly different here. Yes, the first impression is key. For me this is usually a losing battle since I look like I’m 18 half the time and it scares the heck out of the team :) So the key here in my mind is really not make them smile but keep them smiling. It is the act of building an ongoing relationship. It’s tough to do with everyone. My tactic was to build that concept with my regional managers and team leads, and then hope that they would then share that concept with the rest of the team.  Fear shouldn’t be the default motivator for your team. Joke with them, laugh with them. Remember that you are going to need them to walk on hot coals and sleep on a bed of nails. You have to motivate them to do this for you for the best results. I’m personally not a big fan of the motivation by fear. The result that you get from bringing a person from scared to more scared is minimal compared to the amount of effort that it takes them to get to that state in the first place.
 
5. Don’t try to buy your way in. When I read Guy’s section on this topic, it speaks to me of devaluing the person by quantifying their worth. It is always a losing battle because you can never get that amount right without an established relationship. What may be important or valuable for one person will be completely different for another. The other issue I have with this approach to leadership is that this also establishes a  precedent of “reward me before I produce an outcome” type of thinking.
 
6. But do express your gratitude on the way out. A little gratitude goes a long way. And gratitude comes in many forms. Sometimes it can be a form of recognition by sending an email out to your boss, along with the entire team. Sometimes it’s just giving them what’s reasonable like a little time off after working for 72 hours straight. I’m personally a big fan of the sliding scale of reward because each individual is different but it does introduce the complexity of how do you make each reward equal. Personally, I haven’t been in a situation where we haven’t been able to deal with it yet although it has come up from time to time. But it goes back to the point – express your gratitude for a job well done. It puts a deposit into that emotional bank account that as a manager or director. Always remember that you are going to withdraw from that bank frequently.
 
7. Never complain. Summarily, Guy’s point is that it is really pointless to complain. It is quite unlikely that one person’s complain is going to get the person fired at that point in time. If the person is incompetent, he or she may eventually get fired but it really doesn’t help you at this paticular moment. From a leadership perspective, it’s tough to complain because who do you ultimately compain to when things go wrong? You are a manager for a reason. Don’t complain – reflect, evaluate, seek feedback and then act. If something goes wrong, in all likelihood something needs to change and it’s your job to figure that out. Suck it up! :)
 
8. Rack up the karmic points. This is probably one of my favourite of Guy’s points because it really talks about the concept of doing good for the sake of doing good. I identify with the concept of “karmic points”. Here’s also another way of looking at this – we tend to attract people with our behaviour. In general, if we are generous, kind but wise about it, people are more likely to reciprocate. If we do it often, more people see that side of us and there is a stronger likelihood of having it being reciprocated. I personally believe that we tend to attract people of like characteristics. If you think most of your friends are asses – take a good look in the mirror and ask yourself why is that (LOL).
 
9. Accept what cannot be changed. I also liked Guy’s point on this.  One of my favourite terms that I’ve learned over the past few years is – it is what it is. You can’t re-index a 20 GB database server in 20 minutes no matter how hard you try or how many bodies you throw onto the issue. Sometimes your client is going to be an ass no matter what you do :) Sometimes you just have to accept things for they are, do what you can and move on. There are other battles to fight that day :) .
 
So that really summarizes my last few years of managing and leading a team. While I’d like to take complete credit (bad or good) for my thoughts, much of the credit goes to observing my senior managers at that time do the very same things for me. It was easy to reciprocate to the team leads and regional managers what I was already receiving and learning from my superior. And of course, it goes without saying that I also had the opportunity to learn from my team as well. People like JK taught me a lot over the duration of those years.
 
Back to Guy, between his article of “The Art of Sucking Up” and “The Art of Sucking Down,” the moral of the story is really be good to who you meet. The Golden Rule still applies today although it feels as though it isn’t being practiced much.

Leave a Comment :, more...

Paper over Programming

by kelvin.kang on Apr.27, 2009, under This-and-That

I'll be the first to admit that being a developer in my previous life, I have the tendency to pick or build an application as my first reaction to solving any problem. Often times, the best solution is the simplest one. One of my greatest challenges when I came to Zoocasa was to figure out how to effectively and efficiently manage my new team. When I started, the team had only recently implemented Scrum. We had stickies printed with stories and we put them on the wall for stories that were checked out. The major benefit was that we could always tell what features that were being developed. However, as an individual and manager, I'm someone who loves data. I always describe myself as a data monkey at heart. I like to have quantitative data to tell me where the current sprint is and how we are improving from sprint to sprint. In that method, we lost a lot of key management data.

We decided to use an application called Pivotal Tracker. We saw one of our vendors use it and I thought it could work. Within a week, I started to realize that this wasn't going to work. Not because the product was bad but it wasn't the nature of the team. This team consisted of people who were development focused outside of 2 members on my team. It was not first and foremost in their minds to update a project management tool. More importantly, we lost the ability to literally see what was going on during the sprint.

Working Wall

So we've moved back to our board and added a whole series of boards as well. Our current board process is significantly more comprehensive then our previous iteration and it is also more efficient than even our application process in terms of tactical management. Today it is easier to see if we're on track. One downside is that historical capture of data is manually I'll go into more details for the purpose of each board in a future post.

Technorati Tags: , , ,

Leave a Comment :, , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...

Archives

All entries, chronologically...