Anyone who has spent any length of time in the Software industry has heard of the “Daily  Standup” and anyone who has participated in a standup is likely familiar the “3 Questions”.  Repeat them with me now:

    1. What did you do yesterday?
    1. What are you doing today?
  1. Do you have any roadblocks?

Over the course of my career I’ve heard those questions thousands of times, I’m guessing you probably have too.  I’ve heard SCRUM coaches, SCRUM trainers, SCRUM Masters, Project Managers, CTO’s and countless developers use those three questions.  What if I told you those were the wrong three questions?  Well, those are the wrong three questions, and that is how most of the industry is doing SCRUM wrong.
Right now, you might be thinking “Why do the questions we ask matter?”.  To answer your question, I want to start by talking about the concept of a SCRUM team.  From the “SCRUM Guide” by the SCRUM Alliance we get this definition for a SCRUM team.
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”
One of the core concepts of a SCRUM team is being “self-organizing”. The team is supposed to work together to determine how the work gets done and how to move forward most effectively. This is a key element to SCRUM that most clients I’ve worked at have overlooked.  Most “teams” are little more than a collection of individuals working on backlog items, and reporting their status to the Scrum Master (SM).  I believe that this is largely because we are asking the wrong three questions. Those three questions largely focus on the individual and the SM.  For a SCRUM team to become a highly effective team they must actually behave and function as a TEAM.  To successfully do this each team member must feel like they:

    1. have a say.
    1. are accountable to the team.
    1. that other members of the team are accountable to them.
    1. that their efforts make a valued contribution.
  1. that the team is a team and not just a bunch of individuals working on the same project.

Let’s step into a daily standup using the three questions above and see if they help the individual members feel those five things:
SM: Welcome to stand up let’s get going, John why don’t you start.
John: Well Mr. SM yesterday I did, A, B, and C.  Today I am going to do Y, Z and am blocked by X.
SM: Great, let’s talk about X after standup.  Ok Jim, you’re up.
Jim: OK SM, yesterday I did Q, and R, today I’m going to do E, F and G.  I don’t have any road blocks
SM: Cool, Joe you want to go next?
Joe: Sure SM, yesterday I did…
Sound familiar? Does John feel like he has a say? Probably, he is deciding what he is doing today so that is fine.  Is John accountable to the team? No. Why?  He is reporting his status to the SM not the team, this implies accountability to the SM.  Is the team accountable to him? Again, no for the same reason, the team is giving a status report to the SM. Does John feel like his efforts matter?  Maybe. Does John feel like a part of a team?  Probably not, he feels like a guy making a status report to a manager for his individual work.
When the standup goes like the that Jim and Joe are usually thinking about what they need to report on while John is talking, and John tunes out as soon as he is done.  As the individuals report to the SM rather than the team the others tune out and it keeps the team from coalescing and creating the accountability to the team as a whole.
How do we change our questions to improve the accountability and unity of the team?  Let’s look at a slightly different standup:
SCRUM Master (SM): Welcome to stand up let’s get going.
John: Hey, I’ll start, I finished everything I  committed to yesterday. Today I am going commit to do Y, Z but am blocked on X.
Jim: Hey John I think I can help with X let’s talk after stand up.  So, I met my commitments, except I didn’t get E done because I got blocked. Joe and SM helped clear the bock, so today I am going to commit to do E, F and G.
Joe: Jim if you need any more help with E let me know, yesterday I finished my commitments…
I hope the first thing you noticed is that the SM got the meeting going and then stayed out of it. After the standup, he can help resolve X but during the standup he needs to remember that he is a chicken, not a pig, and let the team work it out.  I know that has nothing to do with the questions but it’s another common occurrence and making the change will help the team develop.
What are the questions that were used in that standup?

    1. Did I keep my commitments from yesterday? If the answer is No the team needs to know why.
    1. What am I committing to do today?
  1. What help do I need from the team?

Does John feel like he has a say? This doesn’t really change with the questions themselves but as the team becomes more accountable to each other John will feel more empowered to help direct the team.  Is John accountable to the team? Rather than giving a status report to the SM John is telling the team if he kept his commitments, accountability to the team is a natural outcome of making and keeping commitments.  Is the team accountable to him? As they keep the commitments they made, or they help him understand why commitments aren’t met, he will feel like they have skin in the game and his desire to help them meet their commitments will increase.  Does John feel like a part of a team?  Absolutely, as the team works together to solve the problems that come up it will improve team unity immensely.  The SM is the second level roadblock remover, not to say that he shouldn’t be aware of every roadblock, but he should only step in to help remove road blocks that the team can’t remove themselves.
The change in the questions may seem subtle or even trivial at first, but as you try them out you will find that they do help improve the team, and as the team improves the performance of the team will also improve.  Give them a try for a few sprints and let me know what you think.

by Quinn Heiner

Ask most software engineers whether they would prefer an option to work from home, most would say in a heartbeat, yes!  Ask most employers whether they would prefer their engineers to work from home, most would  say no. Below is a breakdown of some of the main pros and cons from both points of view.

The 5 Pros

  • Flexible schedule.  Working from home means you have a much more flexible schedule, since you’re not constrained by a commute or by limitations from the physical worksite.  For the employer, this can also be a benefit if they need to reach an employee outside of the typical 9-5 workday.
  • Cost Savings. For the employee, gas and wear-and-tear on the car is certainly a cost savings, not to mention the sheer fact that time is money.  For the employer, a lot of the fixed costs to “house” an employee (utilities, office space, hardware, etc.) are greatly minimized.
  • Fewer workplace distractions. It’s often said that negativity breeds negativity.  The same can also be said for unproductiveness.  Just about every workplace has a class clown or drama queen who is in constant need of attention and distraction.  Having your own location can shield you from these types of distractions so you can focus more on getting the job done.
  • Physical mobility. In addition to working when you want, working where you want is important.  Some people are simply more productive when they’re working where they want to be working, not just when.  This is especially true of jobs that require a high degree of creativity.
  • More time. Taking away a commute obviously frees up time for the employee.  In addition, a trade-off in working remotely for the employer is that almost always the employee is to be available outside of regular business hours.

The 5 Cons

  • More domestic distractions. Although there may be fewer workplace distractions, the tradeoff for the employee is obviously more distractions at their remote location.  This is greatly amplified for married couples with kids, or people with roommates who are regularly present.  Time at the home office for you sometimes translates to a list of honey-do items and constant attention-seeking quests from others.
  • More self-discipline and trust needed. This is the toughest challenge for an employee who is working remotely.  Since you’re not being monitored, it’s incredibly tempting to slack a little, especially when you’re usually in the same environment that you’re used to relaxing in on the evenings and weekends.  For employers, this is the number one obstacle to overcome when trying to institute a blanket work-from-home policy, since every employee reacts differently to such freedom and flexibility, some for the better, and some for the worse.
  • Communication challenges. A quick side conversation to solve a problem or receive further guidance suddenly becomes an email that takes five times as long to write, not to mention how much communication really is non-verbal at the end of the day. Trying to coordinate and touch base with everyone can be particularly challenging when you’re not in the same physical area.
  • Work relationship challenges. It can be very difficult to forge meaningful and important professional relationships with people without any physical presence.  Team cohesiveness and company culture are difficult to forge when everyone is at separate locations doing their own thing.
  • Environment setup issues, especially security. This is particularly challenging for companies with sensitive data.  When so much of working from home these days involves BYOD (bring your own device), how can a company possibly protect intellectual property, especially when sensitive data is involved?  What if an employee’s local environment is down for hours at a time, when the situation would have never occurred had they just been at the physical worksite?

Fixing the Cons
So is it possible to overcome these cons?  Let’s address each one in turn:

  • CON: More domestic distractions.  ANSWER: lay down the ground rules. From day one, you will need to set the expectation to those living with you that they should treat your working from home the same as though you were at the physical office and that any time lost for a quick errand or other distraction will have to be made up accordingly.
  • CON: More self-discipline and trust needed.  ANSWER: higher accountability, measuring deliverables, not man hours. This is perhaps the biggest road block to employers’ setting a fair policy for all, because it largely depends on the individual employee how productive they will be in a work-from-home environment.  Some employees thrive when working from home, and others struggle with their newly discovered freedom and temptation to slack a bit.  However, having a clear and consistent system of accountability in place (that is fair to all) will not only force self-discipline, but mutual trust will naturally follow as milestones are being met.  In reality, you have to meet or exceed the kind of accountability at the physical worksite. The key is to keep a clear expectation of measurable deliverables, and consistently enforce accountability without micro-managing.
  • CON: Communication challenges. ANSWER: plan regular team meetings.  Set aside regularly scheduled meetings, whether it is through video chat, conference calling, or even a chat room.  Daily SCRUM is a given in order to enforce and guide deliverables and expectations.  It may also be helpful to set aside regular office hours of everyone working remotely in which they should be able to respond to others immediately.
  • CON: Work relationship challenges. ANSWER: plan regular team-building events. There simply is no substitute for mingling with co-workers in person, and the only way to do this is to plan regular company events that’s worth everyone’s time.  A fine balance should be struck between mere socialization with no agenda and forcing team-building activities that nobody finds worthwhile.  The best team-building events I’ve been to are usually paid lunches where the first half is spent socializing and eating, and the last half is spent discussing work-related topics in a town-hall type format.
  • CON: Environment setup issues, including security. ANSWER: provide reliable I.T. support, including VPN access for security. In order to best facilitate working from home, the employer must take the initiative to provide reliable and helpful I.T. support to make sure employees are always up and running.  In terms of security, anything that is not meant for public consumption should be behind a VPN firewall.  For highly sensitive data, company-issued hardware complete with two-factor authentication should be considered, rather than a blanket BYOD policy.

In conclusion, by forging a relationship of trust and accountability, having a consistent and secure environment, and scheduling regular team interactions, both employers and employees can come together to institute a win-win scenario when it comes to allowing employees to work remotely.

Author: Ryan Parrish
As a consultant, often when diving into a large online retailer environment you can expect there to be many pieces of proprietary company knowledge to pick up. Between learning a new API, using Foreign CRM tools, and adapting to the conventions of their business operations and hierarchy expectations, it can be a lot to keep track of. 
In doing so recently at, I was able to help strengthen their business with immediate solutions and leverage my position as a consultant to speak the truth without any political or superior ties. This put me in a great position that harnessed a relationship based on trust and helped push toward the company’s progression in their development. 
Specifically, I was tasked with maintaining a new web series they’ve started called ‘collections’. I came on at week two of their launch and was helping to maintain these weekly releases while a team in Costa Rica was building a tool that automated the process. After producing one collection: I realized that I never wanted to maintain these pages the way that they had in mind. There has to be a better way, I thought. So after a few conversations with some engineers and a couple days passed, I cobbled together a PHP based solution that effectively generated an entire ‘collection’ page just by passing in a set of product SKU arrays. Take that! 
Make the computer do the work. Don’t be a developer doing production work. 
Essentially, I developed a slightly less robust tool than the team in Costa Rica. But you know what? It took a few days and was getting implemented in a real world fashion right out of the gate. 
Not to dog what their team in Costa Rica built (which ended up being pretty amazing in its own right) but I think the multiple job offers speak loud enough.
Author: Ryan Parrish

Author: Quinn Heiner
Without seeing the subtitle to this article, you might try to decipher what “Synergizing the Strategic Alignment of our Initiatives“ really means, only to find that in reality, it means almost nothing.  It’s just a bunch of buzzwords thrown together.  The old adage that words mean something is only sometimes true.  When it comes to buzzwords, they usually have a very vague, shallow definition that doesn’t actually solve problems.
We’ve heard all the talking points and buzzwords in interviews and seen all the keywords we’re looking for in a resume.  But too often we become disappointed when someone looks great on paper and talks a good talk in an interview, only to see them give a mediocre job performance at best when push comes to shove.  In this article, we will discuss what companies really want to see on a tech resume, how to really vet a candidate in both technical/non-technical interview situations, and some practical advice on salary negotiation from both the employee/employer perspective.  Although this article is written with software engineers in mind, many of the topics discussed can apply to other disciplines alike.
The Resume
The purpose of a resume is to list relevant accomplishments that you feel make you a good fit for a company.  It’s also used to land you an interview.  Some general tips:

    • avoid listing unnecessary or irrelevant details
    • keep your resume concise (1-2 pages max)
  • make sure your resume is readable and formatted well (assume it will be screened by software, or if you’re lucky, quickly scanned by someone who won’t be reading every word)

Concerning the actual content of your resume, it’s extremely important to remember one simple fact: actions speak louder than words.  This is especially true for software engineers, where practical experience almost always trumps other credentials, such as education.  Most applicants will already have some form of a college degree and will claim to be proficient with a particular programming language or framework.  So by knowing this upfront, what exactly will separate you from the other candidates?  The answer is specific accomplishments that are rich with action words, not merely buzzwords to satisfy a keyword search.  The following comparison chart below can help drive home this point:

Good Better Best
Significant experience in C# C# development on a large-scale web application for various Department of Defense agencies Senior architect on a $1.2 million dollar, 2-year, enterprise-level C# web application for the Department of Defense. Actively managed 10 developers and regularly coordinated with stakeholders, including extensive end-user trainings and demos. Completed project on time and under-budget.
Senior-level experience in Angular 3 years of front-end development on a C# web application using Angular Active participant in various Angular forums, including several presentations at user conferences and weekly blog posts on a developer blog with over 5,000 weekly views. Received guru badge status on Stack Overflow by answering over 100 Angular-related questions.
Microsoft certified Currently MCSD Certified (Microsoft Certified Solution Developer) Successful completion of the MCSD (Microsoft Certified Solution Developer) Certification, including over 200 hours of studying outside of work for 3 separate exams covering all aspects of the Microsoft .NET framework.

In terms of a general structure for tech resumes, it’s often best to have four distinct sections that offer both a high-level and low-level insight into your accomplishments:

    1. a brief summary of qualifications (no more than a few sentences) that describes your expertise at a high level (i.e. the elevator pitch)
    1. a short list of technical skillsets
    1. professional experience (this is the only place where you will list out extensive details as suggested in the table above)
  1. education and training (including applicable certifications, honors and awards)

In general, having a resume that clearly and concisely communicates exactly why you are a good fit for the job can not only help you land an interview, but will also help to create a better first impression going into the interview.
The Interview
Unfortunately, the people performing an interview sometimes like to make the interview all about them by asking tough questions to make them feel smart.  Or worse, they’ll stick to vague, irrelevant “fluff” questions that don’t really establish whether you’re the right fit for the job (questions such as “what’s your greatest weakness?”, “if you could be any animal, what would it be?”).
The real purpose of an interview is to have a two-way conversation to establish whether you’re right for the company, and whether the company is right for you.  It usually boils down to three questions:

    1. Do you deliver good results?
    1. Do you deliver on time?
  1. Are you easy to get along with?  In other words, are you a team player that will fit in with the company and its culture?

In interviews for a technical position such as a software engineer, you are not only trying to establish whether the candidate has good soft skills, but also whether they meet a certain level of technical skills.  Below are some examples of both types of questions to get a productive dialogue going.
For soft skills:

Good Better Best
What is the time-scope-quality triangle? Why is the time-scope-quality triangle so important in software development? What are some strategies or tactics you’ve employed to keep the time-scope-quality triangle balanced?
What qualities make a great leader? What kind of leadership roles have you taken on in your career? As a senior developer, you’ll likely be helping out some of the juniors on occasion. How do you best deal with other developers that are constantly asking for your help?
How do you resolve conflict? What kinds of conflicts or battles occur during development on a project that you’ve observed, and how do you best deal with them? You and another developer heavily disagree on how to best implement a solution for a given architecture problem. How would you resolve such an implementation battle?
What kinds of technology changes have you seen in the industry in the past few years? How do you adapt to changing technologies? You’ve been assigned to a project using a technology that you’re unfamiliar with. How do you best adapt?
What does the term “rough consensus and working code” mean to you? What are some industry best practices you’ve grown to appreciate in your career as a software developer? How do you best balance principle vs. practice when it comes to writing code?
What is Agile development? How do you think software requirements are best established? So many customers only want to evaluate things in a production-like environment. How can we help to ensure early feedback in a more agile way?
What are your greatest strengths and weaknesses? If I were to call your supervisor from your last job, what would he say about you? What’s your claim to fame from each of your previous jobs?
Why do you want to work for us? What makes you more qualified than the other candidates? How do you think you can transcend your current role?

For technical skills:

Good Better Best
On a scale of 1-10, how would you rate your SQL skills? Our customer needs to set up a very simple order tracking system. Draw for me a basic ER diagram for the backend database that could be used. Here’s an ER diagram of a basic product sales database. Write me a SQL query that shows me the best-selling product by month.
What does SOLID stand for? How have you incorporated SOLID principles in your code? I need to calculate the area of various shapes. Write me some pseudo code of how to best implement calculating each shape’s area, adhering to SOLID principles as much as possible.
What’s the difference between a for loop, a foreach loop, a while loop, and a do-while loop? Write for me a for loop that prints out only odd numbers. Here’s an example of a for loop that is producing incorrect results. Can you identify the bug and fix it?
What technologies are you currently using in your application stack? What would be the ideal technology stack for your application? For each of the technologies in your application stack, describe for me the strengths and weaknesses of each.
What is an abstraction? What is the difference between an abstract base class and an interface? When would you use an abstract base class vs. an interface?
What is dependency injection? Why is dependency injection important? How have you been using dependency injection in your current project, and how has this benefitted you?
What is an N-tier application? Why is important for an application to have many layers? Describe for me the overall architecture of your current application, including what each of the levels are for.
What are design patterns in software? Why are design patterns in software important? Describe for me a few of the software design patterns you use on a day-to-day basis and how this has made your application better.
What is TDD? Why is TDD important? I have a set of requirements here for a screen on adding a new employee to an HR employee management application. Using TDD, walk me through how you would architect some unit tests for this.
What is inheritance? What is prototypal inheritance in Javascript, and how does this differ from classical inheritance in C#? Here are some examples of inheritance in both Javascript and C#. What values will be printed to the screen on line ___ of the code?
What is encapsulation? How is encapsulation implemented in C#? Here is a code example of some classes with poor encapsulation. How would you fix this?

The takeaway from all of this is that rather than merely quizzing an interviewee on concepts or questions that will invoke a very generalized response, it’s best to ask more specific, thought provoking questions that will force candidates to give specific, real-life examples, or (in the case of technical questions), actually demonstrate they understand the concepts in practice.
The Salary
So you want a raise?  Who doesn’t?  How much money a person makes is certainly a sensitive topic, and one that most people would be uncomfortable discussing openly.  However, when it comes to salary negotiation, you must be willing to not only be specific, but also feel justified in your request.
First, it’s important to understand salary from the employer perspective.  Employers have fixed costs well beyond just the salary figure you see on your paycheck, including (but certainly not limited to): benefits, unemployment insurance, taxes, administrative costs, building utilities and maintenance, training resources, reinvestment expenses, etc. It would be a shock to most workers if they were privy to the full sticker price of their employment in an organization.  In addition, companies must remain financially solvent (and, depending on the industry, profitable), in order to stay in business.  These factors certainly place limits on how much a company can actually afford to pay you.
Second, it’s important to understand the true market value for a particular job.  Market value is simply defined as the “going rate” at which most employers in your area are paying their workers given a level of expertise.  Since the tech industry is very much a talent-based industry, software engineers with a high level of expertise (and skillsets that are in high demand) can expect their market value to be significantly higher than an entry-level engineer fresh out of college with limited experience.  The truth of the matter is that offers are all over the map.  It’s hard to pin-point a specific dollar amount for an engineer with x years of experience, because offers vary widely depending on the job location, type of business, needs of the business, and background of the engineer.  In addition, since software engineers are in high demand, job hopping in order to increase salary is a common behavior, with each employee often offering to match or beat what they’re current at salary-wise.  It is for these reasons that market value is always changing, and that only through careful research and knowing where you fit into the overall market scheme can you at least get an idea of what is considered fair compensation.
Third, and probably most important, is the need to understand that a salary is always (or should always, at least) be merit-based.  In other words, what have you accomplished in particular that warrants a salary increase?  How have you added value to the company?  The more valuable the company perceives you, the more they are willing to pay you to keep you around.  Check your ego at the door on this by trying to look at salary from an objective point of view when it comes to what is merited.
Unfortunately, many workers think that circumstance alone justifies a salary increase.  For example, your medical expenses doubled last year.  You just moved into a new house and your mortgage payment is higher.  You just had a new kid, so your cost of living has increased in order to provide for your family.  These are all valid circumstances that one can certainly sympathize with, and for which a raise would definitely help.  Often times there are even more unique circumstances beyond one’s control that can certainly put a financial strain on any family.  Certainly, there are companies out there who are willing to work with their employees to make sure their basic needs are met, and, at times, can increase salary according to those needs.  Often times, however, one must first merit a raise by adding value to the company in a measurable way.
When it comes to software engineering, what kinds of things can you do to merit a raise?  The best place to start is to have an open dialogue with your manager about specific performance expectations or actions that one can do to merit such an increase.  Sometimes that means getting certified in a particular technology. Other times that can mean taking on extra projects that will save the company money or increase revenue.  The specifics vary widely depending on the needs of the employer.  Having an agreement in place with objective, measurable benchmarks can help to ensure that both the employer and employee’s expectations are being met.  The bottom line is to practice clear, concise, and constant communication with your employer about where you feel you’re at and where you’d like to be.  Before you try and job hop to gain a few bucks, talk about it with your employer first.  You may be surprised at how much they are willing to work with you, especially as you become a strong asset for the organization.
In conclusion, resumes, interviews, and salary negotiation can be tough nuts to crack, but one theme certainly prevails among all three, and that is that actions speak louder than words.  So drop the buzzwords and start listing real accomplishments on your resume.  Anticipate more thought-provoking questions in interviews that will demonstrate a practical understanding of a concept or principle, rather than just sticking to talking points that sound rehearsed and overly general.  And when it comes to salary negotiation, understand the employer’s perspective, your market value, and what merits you personally bring to the table in order to start a successful dialogue.
Author: Quinn Heiner

Author: Dave Thresher
When I started writing software in the ‘80s, most companies had just phased out keypunch operators, or were in the process of doing so.  To replace the vital process of entering massive amounts of data through a keyboard, programmers were tasked with creating terminal software that would replace the keypunch machines.
This is when I learned about “Head Down” data entry.  I was writing this kind of program for people who knew how to type at astonishing rates and carry on a conversation at the same time.  It was if they had two separate brains, one that used the eyes and fingers, and another that used their vocal cords and mouth.  In any case, they needed to be able to fix their eyes on the data source and almost never look at the screen.  Of course, there was no mouse involved either.
So it went: Tab, type, tab, tab, type, tab, type, tab, type etc.  In a very short time, they would have memorized the current data form they were using and simply go to town.
Years later, I was talking to a friend who worked for a casino, entering data from the pit.  You know, the kind of data that casinos use to calculate the comps for the players.  She was complaining that it used to be very easy to enter the data as it was in a DOS format, and the data entry was exactly like entering data on a mainframe using tabs and typing.
The new Window app was causing her a lot of problems, because the tab order wasn’t the same as before, and the software trainer had instructed her to use the mouse to navigate between fields.  I asked her to show me and sat with her for a few minutes while she worked.  I noticed that the programmer may have missed some of the tab orders, but did include the alt+key shortcuts.  I showed her how that worked and she could then nearly match her previous productivity.
Ironically, the casino hired the trainer a few weeks later.  They were in the same office and my friend was busily entering data, but she noticed the trainer kept giving her strange looks.  When she asked, the trainer said she couldn’t figure out how she was doing her job so fast.
So, the moral of the story is to pay attention to the way data can be entered into your application.  If it can’t be done from the keyboard alone, it’s not complete.
Author: Dave Thresher

Author: Chick Lignell
staff augmentation for IT servicesRunning a successful business, keeping up with and beating the competition, meeting the needs of your customers and growing your business.  It’s overwhelming what it takes to run a successful business.  There are so many departments that need your attention and one of the most vital parts of any company is its IT department.
IT takes its fair share of the budget and it seems that IT and technical people are changing jobs more often than the people do who are in your other departments.  And the sheer volume of options available to you when it comes to technologies; what is right for your company and do you have the right people to make those technology succeed.
One of the options available in today’s market is staff augmentation.  In years past, staff augmentation was reserved mostly for human resources and sales departments but with the explosion of technologies there is a wealth of talented people who are available to companies that need that specialized skill.  The problem is, with technology changing so quickly, you may only need that person for less than a year.  Hiring someone that you know will not have a job in a year unless he or she learns a whole new skillset is an expensive way to run your business.  Staff augmentation can solve this issue.
There are many reputable companies that hire skilled technical people to work for them as consultants, working with and aiding their clients.  There are five major advantages to using the staff augmentation model.

  • Cost and time management
  • Flexibility in scale management
  • Access to distinctive skilled manpower
  • Reduction in overhead costs (insurance, perks, benefits, PTO, etc.)
  • Stability in organizational structure a

Staff augmentation gives you the ability to keep a stable IT organization that can expand and retract as your business and the market demands.  Giving you the option of picking from numerous resources to find the ones that have the exact skills that you need for the time you need them.  This gives you a leg up over the competition which is trying to meet the demands of the market with those they already have on staff or those who spend the weeks and sometimes months finding someone they can hire to do the work.
And the cost of staff augmentation is not as great as you might assume.  When you consider the real costs of an employee, with all the benefits and the time it takes to manage that individual, you will find that staff augmentation is an affordable way to stay ahead of the competition.
Contact your STG Account Manager to find out if staff augmentation could help solve any issues you might have and if STG is the right fit for you.
Author: Chick Lignell

Author: Greg Gerber

Having spent the better part of 20 years driving talent acquisition strategies within global organizations and small start-ups, I’ve had many opportunities to see and hear how organizations are evolving in the constant fight to attract and retain top talent.
In today’s aggressive battle over top talent, there are so many more tools available to help organizations than when I first stepped into the profession in the mid 90’s; however, the workforce is so much different than it was back then, and it is evolving at lightning speed. Organizations who understand how to adapt to the way professionals wish to practice their trade, and put this understanding to practice, will have the best chance at winning the war on talent.
Finding top talent is easy, attracting top talent is more challenging, but retaining top talent is the hardest proposition of all. So let’s focus our conversation today on the latter two, because it is there that we can impact the organization the most.
To attract and retain employees today, we first need to understand them. Below is a diagram from Chess Media Group that clearly outlines the evolution of the worker:
Evolution of the Employee
“Based on the above evolution these are the key things to pay attention to…
Create work and work environments that are truly flexible
The first two items above along with ‘focusing on outputs’ comprise this idea of flexible work, that is working anytime, anywhere, and being evaluated not by how many hours you sit in a chair but by what you produce. There is no longer a need for most employees to work from an office or to work 9-5. Unilever is doing a great job of this where they are rolling out this concept of (what they call) ‘agile work’ to their 175,000+ employees around the world. Aetna and American Express are among other organizations leading the way for flexible work. The future employee will only work in this way.
Use any device
We’re already starting to see this with BYOD, but gone are the days of company sanctioned phones and computers. Instead, the future employee will be able to use any device they chose to get their jobs done. Companies like Ford, IBM, and Intel have been among those leading the way in allowing their employees to use many personally-owned devices for work.
The death of the ‘ladder’ and customized work
When you start working for a new company, usually you start off at the bottom of the proverbial totem pole. In other words you begin as a sales coordinator, then a sales manager, senior sales manager, sales director, and so on and so forth. You have to climb the ladder for a few years in the hopes that one day you will reach a position that you are happy with. However, with the freelancer economy, collaboration platforms, and new management approaches; employees are now starting to shape their own career paths and how they actually work. Companies like Deloitte offer something called the Mass Career Customization Program which allows employees to change their work preferences twice a year, changes include things such as making a lateral move within the company or selecting how much time an employee wants to spend traveling. Other organizations like Valve or Treehouse allow employees to completely pick the projects they work on or who they work with!
Sharing and collaboration
Employees used to hoard information and keep it to themselves. There was no incentive, scalable way, or reason for employees to share what they know with others. Knowledge is power and if employees keep their ideas to themselves then they have the power. Employees were also not encouraged to share or think creatively, their job was merely to show up to work and perform their tasks…that’s it! For the future employee the exact opposite is true. Collaboration platforms are making it easy for employees to share information and organizations are creating incentives to do this ranging from internal incubators to intrapreneuer programs to open innovation programs. Internally, email is also shifting from being the primary form of communication to being the secondary form of communication.
Going forward any employee can have an idea that can turn into a new product, service, or opportunity. Shell with their GameChanger program and Whirlpool with their ‘Winning Workplace’ program are just two examples of organizations that are shifting their culture from hoarding to sharing.
Anyone can be a leader
As mentioned above employees were thought of as being expendable cogs which meant they had no voice within the organization. Once again, collaboration technologies play a crucial role as they give any employee within an organization the chance to be a recognized leader by sharing their ideas, thoughts, concepts, etc. Any employee that is able to build a following with the content they share internally is capable of being a leader; something which was not possible before especially not at the scale that collaboration platforms allow today. Think of how many people have become leaders as a result of social platforms such as Twitter, Instagram, or Facebook, now employees can do the same inside of their companies.
Knowledge vs adaptive learning
Knowledge is now nothing more than a commodity. To be the world’s smartest person all you need to do is pull out your cell phone where you have access to anything you need to get answers to. This means that for the future employee it’s not knowledge that is the most important but the employee’s ability to learn new things and apply those learnings to new situations and scenarios that come up. In other words, always being able to learn how to learn and stay adaptable. This is far more important and valuable than what you ‘know.’
Everyone is a teacher and a student
In most organizations today if you want to learn something you have to sign up for and attend a class that may be a few days or a few weeks away. Today (again thanks to collaboration platforms) any employee can take out their cell phone and record a ‘how-to’ for anything ranging from setting up a modem to programming something on excel. Simply being able to connect employees to each other provides a way for democratized learning and teaching in ways that were never before possible. Thanks to sites such as Udemy, Coursera, and Khan Academy we have the ability to learn what we want to learn and teach what we are uniquely qualified to offer to others.” *
With all of this being said, the philosophy should never be, “Build it and they will come”. There will always be a spot in any organization for truly talented “Talent Acquisition” professionals, who know how to find top talent, understand how to attract top talent, and who can also influence the long term retention of top talent. Attracting top talent is only the initial battle in attracting and retaining today’s workforce. Today’s organizations will need to both adapt and evolve to a more nimble, adaptive, and flexible workforce based on the principles outlined here, or suffer a stagnation and eventual atrophy in business.
*Footnote: Excerpt taken from Forbes article LEADERSHIP 9/02/2014
Author: Greg Gerber

Author: Tim Collinson
It is common to read articles and posts which say that the issues that organizations face when developing software are bigger than ever before. However, in many ways we face many of the same issues now as those that were common in 1975 when Fred Brooks wrote his famous essay on issues facing software development companies, “The Mythical Man Month”.
The issues discussed in “The Mythical Man Month” have not so much changed as the options for fixing those issues have grown and morphed into better solutions. Every business is different and they all have their own sets of challenges. We can categorize issues that businesses face by the size of the organization. Large businesses have more employees, harder to handle communications, and more strenuous processes that must be followed. With that in mind let’s explore five issues, and their solutions, that large organizations face as they try to find success with IT.
Big Design Up Front
Large organizations have a number of challenges which often seem as though they can be solved by the concept of big design up front. Executives want to know when they will be able to see a return on their investment. Marketing and sales teams want clear deadlines so that they can begin to share information with customers about new features. Engineering management want to be able to plan what will be developed with project management groups. Operations teams need to be able to plan and purchase needed hardware to support these new products.
It is exactly these pressures which cause companies to attempt to design every facet of their software as early in the process as possible. Big design up front is the process of trying to architect and plan everything in a project before ever writing a line of code. Often big design up front will lead to long schedules filled with development tasks which take a product down the wrong path and do not leave room for an organization to learn from their customers as development proceeds. Big design up front may alleviate the initial pressures of development by creating schedules, but it will also often lead to product failure.
Obviously companies can not just ignore these initial project pressures. The solution to these pressures is to adopt a goal to deploy to real users early in the development process and often after an initial release. At Hewlett Packard, on a consumer facing project, we made a goal to release to a small set of customers in the first week, and weekly after that. By doing so, everyone in the organization could plan and prepare for constant customer interaction. Additionally, the company was able to receive customer feedback early and pivot quickly as it saw areas of innovation. This sort of goal, as opposed to big design up front, leads to quick and consistent success.
Not Quite Agile
Many organizations I work with call themselves agile. However when pressed to discuss what agile methods they follow companies will stammer out an explanation that we in the Agile community call “Scrum But”. “We are scrum but we don’t have stand ups,” “… but we don’t write user stories,” “… but we don’t demo to stakeholders”. This list can get quite long and before long the organization is not so agile at all.
Large organizations need to understand the agile mindset now more than ever before. Agile states that an organization should value:

  • individuals and interactions over process and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan

Large businesses know that agile is important but they fall into the pit of “Scrum But” when they forget the real tenets of agile. Companies need to remember that agile is not scrum. But the rules of scrum, as well as extreme programming, lean, kanban, and many other so called “Agile Methodologies,” if adhered to, will help an organization to follow the four truly agile principles.
Too Many Meetings Not Enough Action
Large organizations often complain of communications issues. With dozens of levels of employee and management between the software producers and the executive teams it is easy to see how communications can become problematic. Most people within organizations have an honest desire to communicate status, changes, and issues to both their supervisors and their subordinates. However this honest desire to communicate generally leads to a crippling number of meetings. These meetings often hamper the amount of work a team can complete.
Organizations in recent years have turned to agile practices in an attempt to alleviate these meeting needs while still keeping communication channels open. This is a good tactic as long as it is kept in check. All too often companies allow agile to become a reason for more meetings. Daily stand ups turn into multiple hour status sessions. Sprint planning can turn into multiple day marathons. When agile methods are not kept in check they are not agile at all.
When agile is used correctly it can reduce the meetings and increase communication. An organization must work to have an effective backlog and to make sure all of the stakeholders in an organization have access to the list. A prioritized backlog can tell stakeholders, even at the executive levels, more in a few minutes about development efforts than weeks worth of meetings. Additionally companies must be diligent in keeping their agile meetings agile. Stand ups must be kept to 15 minutes of less. Sprint planning should be under an hour. Other meetings should be kept to a minimum or eliminated. By keeping a prioritized backlog and keeping agile meetings agile, organizations will see engineers complete more software development and meet less.
A Lack of DevOps and Automation
Whenever I start a new engagement I always ask how the company deploys its software. Often the company will complain of the long and arduous process of moving their code from environment to environment. The process usually involves a myriad of manual steps and is quite error prone. The longer and more error prone the process is, the longer the organization will wait between releases. This is not good for the development process nor for an organizations bottom line.
This is why DevOps and automation is so important. DevOps is the intersection between development and operations teams. Before the DevOps movement engineers working on products would complete features and then “toss” the code over to operations for deployment. Operations would then try to replicate a development like environment on production hardware, deploy the code, and debug any production issues. This method of deployment is ineffective and expensive.
By implementing a DevOps strategy which includes the automation of both the server configuration as well as software deployment organizations can speed up the deployment of their software. Product engineers must help in the process of automating these steps. Companies can no longer tolerate an internal atmosphere where product engineers create software in a vacuum and then toss the results over the fence to operations. As product engineers plan their development activities they must add tasks to automate and test deployment strategies.
Rebuild Or Hand On Too Hard
Large organizations can on occasion fall prey to their own success. Unlike bootstrapped or venture backed start ups, large organizations often have the capital needed to invest in very large software projects. These projects do occasionally go awry. When that happens companies will either decide to rebuild or hang on and keep trudging forward with their software development. Depending on the circumstances these scenarios can be detrimental to the company and the development teams.
When a large software project starts to have huge problems is may seem like the best plan is to rebuild the project from scratch. This stems from the nearly universal good feelings that come at the beginning of a project. Tasks complete quickly and progress often is fast in the early project stages. But if there is a problem in an initial project it will be exacerbated in a rebuild project.
Similarly, companies in distress will sometimes try to hang on to a failing project. They do not want to lose the perceived value, and cash, they have already put into a project so they trudge forward hoping things will get better. Again when a project has issues this desire to trudge forward, throwing good money after bad, will exacerbate the issues.
The answer to these issues is not to rebuild from scratch or trudge forward blindly but to find the underlying issue in the project and eliminate it. Often the project is having issues because of ill defined requirements. At other times simple processes are being made overly complex. It is also not uncommon for a project to no longer be of value to the organization. It is better to understand the underlying needs and address them than to blindly rebuild or hang on.
Where Do We Go From Here?
Large organizations are obviously not immune to issues when it comes to IT. Unlike smaller businesses, large organizations have a huge number of employees, levels of management, high budgets and budget constraints, and rules and regulations to follow. When we look over these issues that have been presented, it can be seen that they creep in because of the unique environment that are within these large organizations. However, by following good principles such as true agile methodologies, keeping communications in check, automating, and making solid businesses decisions when issues arise, we can overcome problems within our large organization IT departments.
If things get too overwhelming, contact STG Consulting, it’s what we’re here for.
Author: Tim Collinson

Author: Ray Hunter
In my 15 years of IT experience, including IT consulting, I’ve set up and monitored many blogs for various companies. I’ve also spent a lot of my time helping companies identify the wrong reasons for having a blog, from technology to social. Companies tend to focus on generating traffic and SEO rankings, forgetting their audience and providing boring and general content.
When asked to write this blog post, I thought a lot about what has been successful with the blogs that I read on a regular basis and where I see our blog taking us in the near future. I wanted to find 4 reasons why our company must have a blog and how that would be beneficial to our company.
So what are the right reasons for having a company blog?
Let me share my top 4 reasons.


blogging shows a company's skills - reasons your company needs a blog1. builds confidence, credibility and trust with customers

Blogs are an essential way for a company’s top employees to demonstrate their skills and share their expertise and knowledge with current and future customers. In the IT industry, we call top employees “gurus”: engineers who promote trust and confidence among their peers and strive constantly to help other engineers through collaboration and mentoring.

As you share experiences, trust grows. As customers read your blog, their confidence in what you are sharing increases. This confidence is the foundation of a relationship. As they come to trust you, they are more likely to do business with you.

A blog is the focal point of a company - reasons your company needs a blog2. is the focal point of your brand, vision and marketing

With all the buzz around social media (Facebook, Twitter, Instagram, etc.), it’s important to recognize that a blog is the primary driving force behind those social outlets. Your blog keeps you focused on your marketing strategy, sharing your vision and helping you pinpoint the content necessary to promote your brand.

Most social media outlets are superficial. Only a blog lets you share deep insight into your company, your culture, your amazing employees, and your fantastic ideas. By creating and maintaining a blog, you must define who you are and consistently think about the content that will best promote your brand.

accelerate communication in your company - reasons your company needs a blog3. accelerates communication

Blogging is not just a one-way street! Blog comments enable instant communication with customers. They’re a way for the reader to become part of the experience, to share their thoughts and ideas with you. Encouraging comments on blogs is a way to see different points of view and share your own.

Replies and interaction provide a voice for the company, a persona if you will. Readers want to hear about new services, technologies or products as they come to recognize your brand and relate to it.

strengthen your team with a blog - reasons your company needs a blog4. strengthens your team

I love delicious and amazing foods from many different cultures. I invite friends and colleagues to lunch whenever I can. We talk, share experiences, tell stories or just get things off our chest.

Your company blog can have the same impact! As employees become part of the blogging experience, they feel like part of the team. Sharing their expertise increases their confidence and trust with customers and fellow employees. Contributing to a public blog encourages them to stay ahead of the curve on technologies and skills. Writing regular posts improves employees’ communication skills and personal knowledge base to benefit the company and customers alike.

Most people might think that blogging is a cool thing to do for SEO. There is way more to it than the SEO benefits. A company blog can provide so much more to the company, customers and employees alike.
Before you head off and get moving on your blog, what are some of your reasons for a company blog?
How has commenting on a company’s blog helped or not helped you communicate with that company?
How has a company’s blog helped you gain trust in their skills and expertise?
Please leave your thoughts in our comments below! And if you need consulting on your blog, then be sure to contact us today at STG Consulting.
Author: Ray Hunter