ELK and Elasticsearch

Distributed Architecture with Cloud Computing

As the number of applications designed to run in the cloud increases, the distributed architecture has become more main stream. Instead of a monolithic application that scales vertically, more applications are built to scale horizontally and many are even aware of the cloud environment they are in.  These applications are deployed with clusters of components over a network of compute nodes, each specialized for its specific goal. These components constantly communicate with each other as they carry out the business functions for the application.

This distributed design allowed the component to be monitored through infrastructure monitoring tools typically used by Ops team. The nature of distributed architecture means there are now many more processes to watch, logs to collect. The value of single pane of glass to see what is going on at the overall application level has never been greater.

As the information collected at the infrastructure level reveals deeper insight of the running application, the activity between Devs an Ops are now more intertwined. Ops team need to work closely with Devs to help understand the production status through the collected information, and Devs need to be able to put the information from different processes together to interpret the result. Those who can adapt to the new working dynamics can build successful product in the cloud era.

Devs and Ops together need a tool that is horizontally scalable, powerful enough to process all the data efficiently without sacrificing the user experience, a UI that is flexible and easy to use. More importantly, with the explosion of data the cost of total ownership needs to be easily understood and estimated.

ELK stack appeals to the team who are proficient enough with deployment and self-monitoring service. Its built on top of a production tested lucene. Elasticsearch and Marvel both have the smooth out-of-box experience. The decoupling among logstash, elasticsearc, kibana and Marvel provides the most flexibility for deployment, something that always holds the highest value among Ops teams. Elasticsearch has the capability of scale without sacrificing the power of search. Its REST API is a must-have for the cloud era. 

Developer-centric team, often found in early stage startups, might end up spending more time than they deem necessary to work out the details of the ELK deployment that does not come out of the box. The examples are:

• Tougher out-of-box experience for logstash agent than that with elastic search server, even though both are supposed to be a service
• The programming experience during the configuration of logstash
• User still need to dig around the internet to find the right grok patterns for common platform components
• No out-of-box security, requires the knowledge or research on setting up reverse proxy.

Comparing to SaaS like Loggly, ELK stack still comes with the cost of hosting and maintenance. For example, Some teams probably will need choose to use a monitoring-as-a-service to avoid the monitoring inception problem and ensure a much higher SLA needed for the ELK stack. 

Log analysis has been a challenging problem to solve, and it has become harder than ever with the explosion of processes in Cloud Computing industry. The Devs and Ops see their goal as solving the production issues and keep systems running. They will build and tinker with tools if necessary but it is not considered as the primary job function. These users see a product like ELK be the essential part of their toolset, and are willing to put high value on services that will enable them to spend less time doing the chores and more time following the insights. With the ever growing community behind elastic search and log stash, Elasticsearch can become the thought leader in the community, drive discussion and foster innovation that leverages ELK stack. In addition to support license and monitoring license, there can also be revenue from training and consulting.

At the same time, this is already a competitive market in big data archive, search and analysis on machine generated data. Since Lucene is of Apache Software License, there is not a barrier of entry for using the technology. The Apache Solr is one of the examples (a two-year old feature comparison can be found here). As Cloud Computing market continues to grow, the need for a log/eventing system will as well. Other factors like the cost of compute, disk, or UI development will continue moving to lower the barrier of entry to form a new end-to-end solution, encouraging new entrants to enter the market by attacking the problem from another angle. For example, there will always be the appeal of logging-as-a-service type of product like Loggly, which has the pay-as-you-go model and maintenance free for the users. By nature, the early adopters of ELK will always seek for better alternatives. 

In summary, with the community behind ELK stack, teams formed organically from the main contributors to the open source projects and a clear go-to-market strategy, Elasticsearch as a company does have the wind behind its back to grow user base, increase adoption and usages of the ever popular ELK stack.

Beyond ELK and Democratize the Google Search
Given the existing user experience of ELK, designed to appear to the Devs and Ops, and the fact that the technology behind Lucene is for a more general purpose, it might be worth asking the question of what other customer Elasticsearch might be able to serve.

Google is known for its simplicity to use.  There are many teams willing to push their email data to Google, sometimes violating company policy, because it is much easier to find related email and get their job done than Outlook or Exchange server. There will always be a need to search at local level with a limited scope and yet there is no clear winner in this category like what Google has for the internet search. 

Can there be a product with the vision of "Democratizing the Google Search" to "Search UI to every company,  organization and maybe even home"? How big would that market be?

If we consider a license and support fee on average $50 per person in work force, given the latest number of 150 million working population from Bureau of Labor Statistics, the total market value can be estimated at 150 million * $50 = $7.5 billion.

Assuming one third would use a SaaS solution, charged based on volume, and assuming on average each person will have 10 GB charged by $0.20/GB/month, the total market value can be estimated at $3 billion.  To clarify, this is different from the online storage like Box, Dropbox. The product is more like a search plugin for Yahoo! or Outlook.com, where the user can search at ease just like the Gmail users.

What we have achieved at DevOps GTD

I drafted the following response to an internal employee. As I finishing and going through it with my lead on the mentioned GTD pod, I cannot help but feel proud of what we have been able to achieve in the past year. I feel fortunately to be the manager of such a great team that pulled through the tough times. (Names have been swapped)

Tony, we can help you get that $400 expensed as part of DevOps budget, and let¹s work together on what you are trying to achieve as a joined effort. I talked to Andy and he will reach out to you and coordinate. It probably will appear to take longer but it will have much better chance of organizational adoption and being sustainable.

We at DevOps share your desire to change the status quo and make things suck less if not being phenomenal. These inefficiencies were easier to deal with when we were smaller, but it starts killing our productivity as we scale up. This is especially true for someone like you with a lot of knowledge and experience. Almost everything passes through has something tangible yet you know from history that almost nothing will be retained with our current setting. The valuable institutional knowledge remains in people¹s head rather than in a media that is easily accessible and searchable.

The great thing working at Guidewire is that we have amazing persistence from the members of this community. People always strive to find a tool or process to make things better. When something sucks, people go beyond the call of duty to try something new, make some change for the better. Sometimes things work out great. After a bit of fumbling period, we have got production quality system like Jenkins, Confluence, GitHub, Nexus, upgraded JIRA system. Something staggered or failed. Open Q&A was out of commission with hardly anyone noticing. ReviewBoard is still on life support. But either way, the spirit of innovation goes on.

Ideally, DevOps GTD pod would like to make that process smoother and better by providing our full attention to these initiatives and help along the innovation process. In the past year, it has been very difficult to break away from the daily grind with only one person (Adam) focusing on these with me help on the side. Even so, we (mostly Andy) were able to put certain systems in production operations, upgraded JIRA system, and keeping up with understanding and documenting the needs and desire of the teams even in the case where we couldn¹t address them, especially like this one.

To follow your format, why this email?

First, I hope I have credibly acknowledged your frustration and desire to make things better. You are not alone on this. No one should be. This is the job of GTD pod, a pod with a peculiar name because we care nothing but help you to Get Things Done.

Second, in the past 12 months, we have been able to secure two open position to get us above the water, and we were able to fill those position before we suffocate along the way. With Ryan and Mandy joining in this year, we have finally got ground cover on JIRA initiatives and the Guidewire product release process. We can now stick our head out and are ready to be more involved with these initiatives.

For the rest included in this thread, we would like to reiterate what we have been posting in DevOps regular updates (PLEASE read them and let us know what you think), please send your request to Dev Helpdesk so that we can gauge the demand for requests like this one and consolidate the effort in making things better. By aggregating the demand data, we will be able to align our long term initiatives and back them up with investment on people, tools, and process from the company.

Job Posting

Job posting has been nothing short of an art these days. You want to attract the talent by describing the job as challenging and the environment as fun. Of course, it always helps if it is really the case.

Fortunately for me, this is the case for Development Operations team at Guidewire. And fortunately for me, I got a lead who cares deeply about attracting the talent, and he drafted the following posting by himself.

Development Operations Engineer

Foster City, CA, United States

How we hire
We’re looking for someone who’s good for the role, good for Guidewire and good at lots of things.
Things move quickly around here. That means we have to be nimble, both in how we work and how we hire. We look for people who are great at lots of things, love big challenges and welcome big changes. We can’t have too many specialists in just one particular area. We’re looking for people who are good for Guidewire—and not just for right now, but for the long term.

How we interview
We’re looking for smart, team-oriented people who can get things done. When you interview at Guidewire, you’ll likely interview with four or five team members. They’re looking for four things:

Leadership
We’ll want to know how you’ve flexed different muscles in different situations in order to mobilize a team. This might be by asserting a leadership role at work or with an organization, or by helping a team succeed when you weren’t officially appointed as the leader.

Role-Related Knowledge
We’re looking for people who have a variety of strengths and passions, not just isolated skill sets. We also want to make sure that you have the experience and the background that will set you up for success in your role. For engineering candidates in particular, we’ll be looking to check out your coding skills and technical areas of expertise.

How You Think
We’re less concerned about grades and transcripts and more interested in how you think. We’re likely to ask you some role-related questions that provide insight into how you solve problems. Show us how you would tackle the problem presented--don’t get hung up on nailing the “right” answer.

Fit at Guidewire
We want to get a feel for what makes you, well, you. We also want to make sure this is a place you’ll thrive, so we’ll be looking for signs around your comfort with ambiguity, your bias to action and your collaborative nature.

The Position

The area: Development Operations
Development Operations provides a solid infrastructure to enable our development team to quickly and efficiently develop new products. This critical team combines software development, software administration, and product management expertise to support our Guidewire development team. As the primary infrastructure team at Guidewire we have the ability and responsibility to make decisions that will benefit Guidewire in the long term.  We provide an infrastructure on which Guidewire can cost-effectively scale.  Every member of our team is expected to provide new ideas, while we work as a team to prioritize and accomplish the work that gives us the most bang for the buck.  We can't do it all ourselves, so our job is to communicate with those outside of DevOps to establish healthy working relationships needed to support work of Product Development and by extension our own work.  Our job is to educate our users to prevent fires from happening.  We can't prevent them all, but we can identify risk areas ahead of time and build an infrastructure on which we can quickly respond.  We hire creative engineers and technology enthusiasts who enjoy being challenged by organizational problems, with a strong desire to make services better for users.  Our teams come from diverse backgrounds, and we are actively seeking new team members to bring fresh perspective to solving problems, along with the technical and soft skills needed to keep Guidewire's services growing and reliable.
The role: Development Operations EngineerYour job is to understand the daily activities of our development teams and constantly think about ways to make them more efficient.  This includes:

• Listening to individuals across development, understanding their activities, and constantly thinking about ways to make it more efficient
• Searching for suitable software and tools
• Making recommendations
• Purchasing software
• Install, configure and administrate tools with support from our Information Technology and Systems department
• Giving presentations about the software tools
• Documenting your work
• Finding ways to provide training materials
• Being the software system administrator and expert for JIRA, including:
  
  • Designing and implementing workflows
  • Building custom plugins
  • Identifying and deploying 3rd party plugins
  • System administrator systems like Confluence, Mediawiki, GitHub, Perforce, Nexus
  • Lead projects across Development, Information Technology, and Information Systems
• You will scale your job by encouraging organizational learning and self-sufficient teams
• You will encounter challenging, novel situations every day, and work with just about every other engineering team and department at Guidewire
• You will be looked upon as an expert and advocate to fellow engineers

The ideal candidateWhat drives your work?

• More than a paycheck, you love your work and want to maximize your positive impact on the people in an organization.
  

Minimum Requirements

• BA/BS in Computer Science, Computer Information Systems or related technical field. (In lieu of degree, 4 years relevant work experience).
  
• Strong written and spoken English language skills
  
• Solid communication skills
  
• 1 year of experience at a small startup company or a startup-type team
  
• 1 year of software system administration experience
  
• 1 year leading a project to accomplish a goal
  
• Do it yourself experience with Linux and Windows
  
• You have served as an expert in 1 or more areas at a company
  

Additional Requirements
You should meet about 8 of the following 12 requirements:

• 1 year in project lead or similar role
  
• 1 year in tech support or similar role
  
• 1 year in quality assurance or similar role
  
• 1 year coding software using object-oriented techniques (in order of preference, Java, .Net, C++, Python, other)
  
• 1 year hosting software as a service
  
• 1 year as a doc writer, or otherwise extensively documenting your work
  
• Experience troubleshooting web browser experiences: Internet Explorer, Google Chrome, Mozilla Firefox
  
• Experience with Linux and Windows as an administrator
  
• Experience with Linux systems requiring the use of scripting languages like Python, Perl, or Shell
  
• Experience with Windows and Mac/Linux as desktops
  
• Experience with Kanban or Scrum as a user
  
• You have built your own product or service which is/was used by 10 or more people.  This could be internal or external
  

Example Profile
We don't expect someone to match this exactly, but the ideal candidate will have this kind of breadth of experience:

• 2 years of experience running and building a 2-3 person technical support organization
  
• 2 years of being the only QA for a 4 person development team
  
• 3 years of experience on a 2 person team hosting software as a service for 80+ customers
  
• 4 years of experience building a customer facing product from scratch, deploying it to 20 customers, and supporting it.
  
• 4 years of platform development using object-oriented techniques in VB.Net and VBscript
  
• 1 year of experience writing an 80 page user guide to be used by over 300 customers.
  
• 1 years of experience building a test infrastructure to automate deployment and running of automated tests
  
• 1 years of experience leading a team of two to run those tests automatically across a large swath of servers.
  
• 1 year of experience preparing a merge of a QA department into a Development (Coding) department.
  
• 7 years of experience serving as an expert on JIRA, even though it wasn't your job.
  
• 2 years building and supporting a tool that is used by 200 developers.  The tool is part of a customer facing solution, which you built the first fully functional version of.
  
• 4 years of experience doing platform level JAVA Enterprise development

Leadership Trio - from the Beginning

(All names here are fictional, and I recommend the readers not to think if they are based on any real characters. The point here is to tell a story about an idea that can be very interesting)

"You should write this down." Andy told me, "The result of your effort is the change in us three leads.We are very happy with how you have coached us and provided clear opportunity for growth. But others in the company might not see it that way. They will see the three of us getting things done and nothing from you. And they will find reasons that they can believe for things that they don't understand. You need to communicate about your work, maybe in the form of blog."

I brushed it off initially, thinking with my work during the day and school during the night, the last thing I want to do is to keep a blog about what I am doing at work. But that idea grew on me. After all, we should only brush off ideas because they are not good, not because we are too busy. Doing so would lead to the possibility that we might be spending effort on less worthy ideas right now and might be wasting our lives.

So here I am, backtracking the footsteps of this most rewarding journey that I have stumbled upon as someone who is searching for the leadership style that fits me as a team member, a manager, and in the future, as a leader of a business unit or organization.

Prelude

The form of trio was the result of nothing more than pure luck. As I am getting to know the team and the operations after moving over one year ago, I slowly realize that I have been blessed with three capable leads. Believe it or not, it takes some training to be able to reach that realization. Andy, Vitaliy and Bernard are the leads who are ready for further career coaching. I have now established a good relationship with them. At the same time, I took the "Total Leadership" class in Wharton MBA that involves putting myself through a leadership coaching process. While still in the training myself, I can see the power of the coach framework. By the time that my training required me to design experiments that served the interests of my stakeholders and achieve four-way wins in the area of work, community, family and self, the idea came to mind to apply the same coach framework to the leads.

The format of my training made it pretty easy for me to write down essential elements for the experiments. I discussed them with my coaches (TA, Alumni coach and my coach trio) and received positive feedback and strong encouragement.

I talked to the leads, confirmed their desire to be responsible and accountable for all aspect of their teams. I also got their agreement to form a trio as part of their training process.

Leadership Trio

Originally, I called this "Management Trio". However, the term "manager" has raised more eyebrows than I anticipated or wanted to deal with, because of its association with the HR policies and legal implications. Whatever the term is, the idea is to let the team also understand the non-technical side of the team operations. The purpose is to let members with technical background be involved with major decision-making and have a taste of life outside their normal realm. It serves as a natural career path for those who have the potential to become full-time manager, which is extremely valuable yet hard in a technical startup. It can also serve as a valuable education ground for those who decides to remain technical. The extra knowledge will make them more valuable because they can support the managers better.

The trio structure provides quite a few benefits. It provides the check and balances it needs while supporting the coaching style management. It provides a good self-learning foundation, which is more valuable in a process where the main purpose is to promote learning to build a functional team. By leveraging the existing core competency and resources, the trio can effectively work through the challenges. By providing supporting structure for real-life learning, the trio structure can be easily duplicated elsewhere and can lead to grassroots movement.

From the manager's standpoint, this structure is aligned with the change of management style in fast companies. The people with the best information are making decisions. The job of the managers is to communicate and coach the team so that the objectives and incentives are aligned and the teams are making the right decisions. Our company has recently grown from a start-up to a publicly traded company. As tit has grown, I have witnessed many cases where people turn to a manager to make decision for them or the manager steps in to head decision-making process. These behaviors have been pulling us away from the goal of always searching for innovation in organization structure and team governance. We should be mindful of the example set by companies such as GE, Semco who have maintained a culture of innovation despite their tremendous growth. We must make sure we don't lose the innovative culture we have built here.

Leads

It is still hard to say what kind of people are suitable candidates for this trio. For that I consider to be extremely lucky because I didn't have to go through the interview process. The most thinking that I have done was to look at my current three leads to decide if this serves their interest, and if they are ready for something like this.

Vitaliy brings his understanding, voice of reason, and good communication to the trio. Eager to learn and eager to help, Vitaliy has been the natural leader of his team. Vitaliy has a good way of communicating externally as well as internally, especially in contentious situation. I have learned much just by observing his interactions with others. Vitaliy provides good understanding and voice of reason which generates trust in the trio.

Andy brings his capability of strategic thinking under fire to the trio. Andy has been operating in a challenging environment for a year. He survived and delivered a major internal system upgrade single handedly, which is no small feat. While others like me always have the tendency to jump into any request and help people out, Andy has established a good practice of looking at the requests based on the urgency and impact, possibility of user error, so that he can address those who really need his help, and push the rest to learn to be self sufficient. There is always a contention with this model, and he has walked the fine line for over a year, and survived. This gives him the time and energy not only to survive, but also to think strategically about what we really need. This is how he was able to recognize the need to research and implement the solution ahead of anyone else in the department. Examples are the service level of certain servers, the disaster recovery readiness, the cost and benefit analysis for the medium term projects in the next two years.

Bernard brings in his style of Charisma to the trio. That statement is not as tangible as the two above, and that is because he has been in the shadow of the former leader until recently. There are a lot of signs showing that he has the capacity to lead and he has made it clear that it is his career interest. He has been watching the operations of Vitaliy, understand its value and want to learn the art of adopting it to his team. He has been learning about our build system and wants to migrate the system to fit more into that model. I have sat in quite a few user meetings and they all went very well. Bernard is confidence in voicing his opinions, while still take others input into consideration.

All three leads are smart people with good grasp of concepts and understanding the importance of business operations in additional to the pure product development. They learned the elements of operations on the job and acquired practical skills to succeed as a leader. At the same time, learning in a resource restrained environment has made it difficult to slow down enough time to look at the business as a whole and think about strategic plans, especially where there is no guidance or training about how to do that. All three leads are known for their capability of listening to people and making good judgment calls in terms of functionality and urgency.

Each lead also has his own areas for improvement. I am not comfortable listing them here, yet, as it is highly personal. I do plan to invite them to be the writer of this blog to see if we can fill the missing information here.

Preparation

The only preparation is to make sure the leads are ready. Being a lead is a rewarding and challenging journey, and it is certainly not in the interest of every software engineer. During the one-on-one meetings, I talked with the team leads about their strengths as well as areas for improvement. Instead of simple praise or passing of critical judgment, I focused more on the future of the team. What do they want to do achieve for the team and for themselves, and what is preventing them from doing it? Through that conversation, I brought up the trio framework and they all signed up immediately. That was definitely a good moment because I was off to a good start.

Session I - Kick Off

The first session is the kick off session. I want to bring the coaching dynamics in the one-on-one to the trio. To do that, each lead needs to learn more about each other and be aware of the desire and strength of each other. There will be time for them to learn about the area where each other needs help with but that will come later.

We went around the circle asking the question: What is your goal? What would you like to achieve for the team and for yourself? The answers were interesting such that they are on different level: relationship with customers that we are serving, the value we are bringing to the company, and the technical innovations that we can foster within the team. This is another sign that the trio is a versatile group.

The second round of question was: Identify one thing that you can bring to the group that others don't necessarily know about. I don't have the notes on the answers but I remember we got good laughs. My goal of building rapport among the trio was definitely achieved.

After that round of exercise, it is the experiment framing stage.

"This is an experiment that will benefit Guidewire as well as us individually. By experiment I meant that it can fail, even though the chance of success is high. This is an idea that I have thought through, and have got feedbacks from others. As of now, you three are part of a trio for learning about team and organizational management. You will practice and learn how to coordinate on behalf of your team. You will learn how to reach non-political agreement."

Then I open the floor to let the trio talk. The topic was mostly focused on how much this is needed at this stage of personal growth and company growth. I think we also touched on my role in this and my answer was that I will assume the coach role and I expect them to reach decisions through peer discussions. The lead could and should look for me for advice and I would still focus on talking through the issues and help the leads reach decisions.

The next two questions are based on the feedback I got from my coaches. How would the trio reach agreement on decision? At what point would we know that this is not working?

For the first question, the agreement was to talk about it through open conversation. Later, we moved this to an online chat room, so that the conversation can keep going even as we are busy with other tasks, and even when we are remote.

For the second question, the answer was that when things are being dropped, that would be the sign. I agreed to keep sending feedback whenever I want the confirmation that things are not being dropped.

The meeting then adjourned, marking the start of trio.

Bonus System

A bonus system is to be designed with the idea that it is a motivation tool. Its purpose is to maximizing the desire of the members to do better. While there is certainly some benefit of paying attention to only a small number of elites in the organization, the effectiveness of a bonus system  can reach to majority of the community, including those who don't receive the bonus.
There are many articles, case studies, blogs, videos and theories around motivation and reward system. When it comes to bonus system, it helps to think from two perspectives: equity and expectancy. They can be applied to understand the motivation oriented compensation. To reach a solid structure for a particular company, other factors like the history, recent events, and members also play a big part.

Equity Perspective

One way or another, individuals will compare their job inputs and outcomes with those of others and then respond to eliminate any inequities. People have strong psychological reactions to fairness in how they are paid and these need to be managed carefully. Given the uncertainty of bonus for each year, this psychological need is especially strong during the payout period. A effective bonus system can present enough degree of fairness and continue motivate even those who don't receive them. When not managed carefully, a bonus system can generate anger for the under-rewarded, guilt for the over-rewarded, and confusion across the organization, thus defeats the purpose of the bonus system as a motivation tool.

When inequity is perceived, the result can be damaging. Some will lower their input; some will change their outcome (e.g. increased units produced at lower quality); some will distort perception of self; some will distort perception of others; some will choose a different reference for comparison; and mostly commonly in silicon valley, some will leave the field or the company.

The key element here is an individual's perception of justice. While the differences of opinions make it hard to manage, the subjective element suggests that the most important piece is the perceived fairness of the process used to determine the distributed rewards. For employees to see a process as fair, they need to feel they have some control over the outcome and feel they were given an adequate explanation. It is important for the manages to be consistent, unbiased, make decision on accurate information and is open to appeals. This is why it is important for managers to provide early feedback as well as frequent feedback to detect inconsistency and gather more information base on the reaction from the employees. This interaction is more important in the case of bonus, because there is an implicit reset after each year. At the beginning of the year, the employees and the manager start the process again by providing the employee an opportunity to present his or her point of view about the desired outcome to decision makers.

Expectancy Perspective

The following picture illustrates the expectancy theory (source: Wharton MGMT 621 class material)

In practical term, employees will be motivated to exert a high level of effort when they believe that effort will lead to a good performance appraisal; that a good appraisal will lead to organizational rewards such as bonus, a salary increase, a promotion, or a public recognition; and that the reward will satisfy the employees personal goals.

This is particular applicable to bonus because of the one time nature of the rewarding system. The reward only applies to the past review period, thus giving managers and employees a common ground to repeat the motivation process on annual basis. Among others, bonus remains as a desired outcome for most employees because it is always extra money that is in proportion of the regular income. In this case, an effective manager will be able to build the shared connection between performance to outcome, and from effort to performance.

Performance to Outcome: While it is easy to define outcome (bonus rewards) and performance (annual appraisal), it is harder to build the connection from performance to outcome in an organization where there are different teams and roles. The perspective of equity mentioned above goes a long way to design a process that can be perceived as fair.

Effort to Performance: In the context of bonus system, the manager can set goal ahead of the time, and use it for performance appraisal. When the right goals are set, the employees can see a strong connection between their effort and the performance rating they will get. The most effective goals are difficult but not impossible, specific, and have to be accepted by the employee. Another way to describe the criteria of a good goal is SMART: specific, measurable, attainable, relevant, and time-bound. These criteria, especially time-bound, fit very well in the bonus system.

In Conclusion

It is always a challenge to design a reward system in a corporate setting. That challenge applies to the bonus system as well. When it comes to bonus system, however, one can gain deep insight by being informed and continue thinking in the perspective of equity and expectancy.

Blog of the day

Interesting article because it relates exactly to what we are going through.  I am only wondering about the stage we are in

Top 10 Reasons for Slow Velocity

http://www.svpg.com/top-10-reasons-for-slow-velocity/

My current challenge at work is to capture velocity reliably, but I am sure this post will come handy sometime down the road.