Battle of the Smartwatches: Sony vs Pebble

I used to be one of those people that collected wristwatches when I was younger. A nice wristwatch can make a great fashion statement. Unfortunately, the greatest strength of the wristwatch, was also its greatest weakness. It only told time. Yes, you had some that had a timer function, a stopwatch function, and even a calculator, but those devices were incredibly ugly. With the introduction of cell phones, wearing a wristwatch became redundant. It’s for this reason I stopped wearing them. That is, until recently. In the last few years, several companies have been working on new wristwatches called “smartwatches”. These watches do everything from displaying your text messages and email to showing local traffic camera footage. Today we’re going to take a look at two of what I think are the most affordable and good-looking smartwatches currently on the market: the Sony SmartWatch and the Pebble SmartWatch.

The Pebblepebble
The Pebble started out as a Kickstarter project and actually set a Kickstarter funding record. 85,000 people backed the development of the Pebble and over 250,000 of these things have been sold. Having these kinds of numbers, my expectations were probably too high for this device to meet. I was very aware of this fact going into this review.

Here’s what I liked about the Pebble.

•  The 144x168 pixel display is always on due to a new low-energy technology known as e-paper.
•  It’s the classiest-looking SmartWatch I’ve seen other than the Samsung Galaxy Gear (not reviewed here because it only works with Samsung smartphones).
•  It’s waterproof! You can go diving with this thing!
•  Battery life is rated at 5 to 7 days. In fact, I never charged it the entire week I was testing the device. 
•  It has an open software development kit so you could develop your own software for it if you were so inclined. Other users have already begun doing this at

So what didn’t I like about the device?

•  Unfortunately, the device is only black and white because of its e-paper display.
•  It doesn’t use a standard cable for charging. No Micro-USB cables here. 
•  Not many applications can be installed on the device. During testing, I could only install 8 applications at any one time. 
•  All the “good” applications have to be side-loaded from a third-party website.
•  It’s not a touchscreen device. It uses four buttons on the side of the watch to navigate it.

Out of the box, the Pebble comes with a lot of different watch face applications to change its appearance.  From the Pebble application on your smartphone, you can download more watch faces. You can download other third-party applications for the device here. The Pebble is currently $150 as of this writing.

The Sony SmartWatch sony
My first smartwatch was the Sony Ericsson LiveView, the predecessor to the Sony SmartWatch. When Sony released the Sony SmartWatch, it was better in every way. It’s the first color smartwatch I’ve gotten my hands on and the applications for it are pretty amazing.

Here’s what I liked about the Sony SmartWatch.

•  It has a color screen. The 128x128 pixel 65,000 color screen is very pretty to look at.
•  It’s a touchscreen device. To navigate on the watch, use a combination of swiping or tapping an onscreen button just as you would on a smartphone.
•  Finding and installing applications on the watch is easy. To install an application on the device, just start the Google Play Store on your smartphone and search “Sony SmartWatch”. 
•  It has many good applications. This is where the Sony SmartWatch shines in my opinion. It has applications for local traffic cameras, instant messengers, remote recording applications, and even a web browser. 
•  It has 7 colorful and swappable watchbands via the clip (all sold separately).

So what didn’t I like about the Sony SmartWatch?

•  Ugh, the watchband clip. While I like the colorful bands, I would rather they have implemented this without adding additional height to the watch. This really makes it rise off your wrist too far for your shirt sleeve to cover it. 
•  It’s not waterproof, it’s splashproof. You can get water on it, but I wouldn’t go diving with it on.
•  This watch also has a non-standard charging cable. If you lose it, you’ll need to order it specifically from Sony. 
•  The battery life on the device is about the same as that of your smartphone. You are going to have to charge this thing every day after use. Sony’s website says you’ll get 3 to 4 day’s typical usage and up to 14 days standby. In their dreams.
•  It doesn’t send email notifications without installing a third-party application. While I understand why this wasn’t included, the Pebble seems to do this flawlessly and out of the box. There are a slew of really good third-party applications that do this for free and are easy to install.

With the Sony SmartWatch, it has just a few notifications installed and enabled right out of the box. To get the real functionality out of this device, you’ll need to download a variety of third-party applications. The good news is that most of these applications are free and all of them are easy to install and find. The Sony SmartWatch is $129.99 as of this writing.

Other good smartwatches on the market right now are the Samsung Galaxy Gear, I’m Watch, and Sony SmartWatch 2. Unfortunately, the Samsung only works with Samsung phones, the I’m Watch is fashionably horrible, and the Sony SmartWatch 2 was only just released so I have not yet reviewed this device.

When I started writing this blog, I had originally intended to pick a winner between these two devices. However, they both serve their purposes in a different way. While I love the battery life and always-on display of the Pebble, it just didn’t have any “killer” applications and you can only install 8 apps on it. And while I did get a lot more “cool watch bro’s” from the Sony SmartWatch and its list of apps is stellar, the battery life is terrible and it’s not waterproof.

So maybe the answer is the perfect smartwatch doesn’t exist yet and maybe never will. However, with new devices from Apple, Samsung, and Sony in the works, I’m confident we are just a few years away from everyone talking on their “watchphones” while trying to eat a cheeseburger next to you in a restaurant. One day, that will be a good problem to have.

About the Author: 

 Legend Wilcox is a Senior Systems Engineer for MATRIX who has been working in the IT field for over 15 years. He’s an avid technology gadget collector and total geek.

Posted in: 

Want Job Security? Be Underpaid

For as long as anyone can remember, there has been one primary driving force in every career: money.Job Security

I’ve been in the staffing industry for over 20 years. During that time, I have helped thousands of candidates seek their next position and hundreds of companies secure top talent for their organization. My observation over that span probably won’t surprise you - salary is always one of the, if not the, top criteria candidates consider before taking a job. And why not? The amount of money you make (or don’t make) can have a dramatic impact on how you live. For most of us, the calculus is simple: more money = more security = better life.

As if the “better life” argument isn’t compelling enough, the ubiquity of technology (smartphones with corporate mail, VPN, SaaS-based systems), has blurred the line between personal and work time – like our devices, we’re now expected to be “always on”. Maximizing income isn’t just smart, it’s fair . . . right?

Unfortunately, it’s all too easy to lose perspective on the real driver behind compensation. People typically aren’t paid more simply because they have new skills, longer tenures or more experience. Instead, they are paid more because those skills, tenure and experience bring greater value to their employers.

Which leads me to my point:  Be underpaid.

This probably sounds strange coming from a career headhunter, since we get paid based on what you get paid. But, I passionately believe that if you over-deliver… or are underpaid, there will always be a seat for you at the table. Now, I don’t believe you should be taken advantage of in this worker/company relationship – rather that you should be delivering more real value to the company than what they are paying you. Relationships are based on mutual need and mutual benefit. You need a job and the associated money - and companies need your skills, abilities and experience.

Think about the top NFL quarterbacks today and their sky high salaries. The value they bring to the organization must still be greater than what they are paid, or there won’t be a spot on the team for them. Sure, the money paid to Tom Brady, Aaron Rodgers and Tony Romo is almost too much to wrap your head around. But, clearly the value they bring to their respective organizations is greater than the millions they receive in salary. You see it all the time. As soon as their value to the team drops below the millions they are paid, they are cut or traded.

Whether you’re a top NFL quarterback, IT developer, finance manager or marketing guru – to keep your seat at the table – always strive to over deliver for your employer. I know it sounds counterintuitive, but I suggest that you feel just a little underpaid for your contributions. Keep in mind that your career is more than just your current job. If you approach your selected profession as a marathon and not a “what’s in it for me – show me the money” sprint, the long term gains you’ll enjoy will give you not only the income you desire, but job satisfaction and security for many years to come.

About the Author: 

Jon Davis is Executive Vice President of National Sales for MATRIX Resources. He has over 20 years of experience in leading sales teams and corporate recruiting efforts in all verticals ranging from startup companies, mid-market organizations and the Fortune 100. Follow Jon on Twitter for more career tips: @JonDavis12.

Posted in: 
Job Seeker

Distributed Agile Teams: The ART of the START

I’ve been sharing about agile methods for over ten years at conferences and workshops. One of the top three questions I always receive from attendees is:

Does agile work with distributed teams?Distributed Agile Teams

And sometimes the question is phrased another way:

The notion of co-located teams is nice in theory, but in real life we have team members all over the world. We need to cobble together teams based on our business needs from wherever they are. Does agile support that level of high distribution?

Photo credit: Flathead Beacon

I often smile at the repetitiveness of the question. It indicates clearly that enterprise level software development is often distributed. It also indicates that outsourcing is still alive and well. I’ll try to provide some answers to these questions by sharing two stories of distributed teams I have experienced.

A Tale of Two Distributed Teams

The “Good”

I was lucky enough to be invited to do an agile jump-start for a new client. They are a rather large firm that builds hardware and software devices supporting mechanical control systems. They were kicking off several projects that encompassed many teams, some of them offshore and many distributed. They were looking to leverage Scrum as the method for starting these projects, and they invited me in to do some training and get the teams sprinting in this new style of product development.

When I arrived at my first class session, I learned that they had invited four complete Scrum teams to attend. In fact, one of the teams was based in India, and they had flown the entire team in for several weeks. The first week was for our Scrum boot camp, and the next few were to work with local teams as everyone started sprinting together.

I distinctly remember at the time thinking how novel this was. My typical experience with firms kicking off agile in distributed teams was more along the lines of the following:

  • Throw disparate individuals (local and remote) together into “teams”
  • Tell them they’re “going agile”
  • Send them some references on agile; at best, run them through a short class
  • Expect the team to start sprinting … ASAP
  • Expect great results
  • Rinse and repeat if you still have a customer…

Clearly I’m joking a bit here, but there is a good bit of truth in these steps. Many firms don’t start up their distributed agile teams very well. So I was understandably surprised at how thoughtful my client was in investing in their teams’ start.

I returned to the client several sprints later to do an informal assessment.  By now the remote India team had returned home and was happily working with the local teams. I sat in on some of their stand-ups and other meetings. I was incredibly impressed with how well they were working as an agile team. I was even more impressed with how they integrated and collaborated with the local teams — it was virtually seamless.

It struck me that the cost the company had incurred in bringing everyone together to generate a solid start was paying them back big time. That solid project start-up had put everyone on the same footing and really solidified them as a set of cross-functional teams that had the same vision and were working toward the same goals.

As an aside, I’ve seen this same investment pay similar dividends at multiple clients. Now let’s explore another story.

The “Bad to Ugly”

I was invited to visit another set of teams to help them with some difficulties they were having working across distributed locations. They were executing sprint number five of a 12-sprint release sequence. There was a distributed UX/design team, two front-end UI development teams (one in the US and the other in Brazil), and a back-end development team in Singapore. In short, a very distributed mix across four distinct teams working on a single project.

One key challenge I remember was that the front-end and back-end teams were really struggling to figure out how to work together. They were using email and documents as their primary means of collaboration. But quite often, it would take days to sort out a simple interaction that was required to move a user story forward. And the issues weren’t focused on one team or one locale. There were pervasive communication problems across the teams.

One idea came up in a local (US) team's retrospective. It turned out that nobody had ever “met” the offshore Singapore team that they had to integrate with (at an API level and at a project collaboration level). The idea was to have a video conference call across the two teams as a means of introduction and familiarization. Everyone thought it was a great idea and we scheduled the intro.

I volunteered to serve as the facilitator of the video introduction. There were eight members on our local UI team. We fired up the video and zoomed into the room in Singapore, eagerly expecting to meet a team roughly our size and composition. And they started filling the room — and filling, and filling!

In the end, over 30 people came into the room from Singapore. We were amazed and during the course of the introduction quickly realized some things:

  • We had assumed some of them were men and they were actually women and vice versa … who knew?
  • There were two expectant mothers in the room … who knew?
  • We thought there were roughly 8-10 members of the team, and there were 30. Even funnier, we’d been working with them as if their capacity was 8-10. Who knew?
  • Clearly nobody on either side had ever seen or met each other. Apparently ALL collaboration was via email, text messages, and documents. Not a phone/video call to be had.
  • We learned about their background and skill levels, realizing that they knew much more than we had been giving them credit for … who new?
  • We learned that they were heavily multitasking and being interrupted across many projects. Ours wasn’t their highest priority … who knew?
  • We finally realized that they didn’t like this “agile stuff” and preferred more traditional development approaches. So this was a major and difficult change for them and their leadership … who knew?

It was a fantastic, baseline setting call for the two teams. It created a much better understanding and led to much improved empathy, understanding, teamwork, and results going forward. But why this wasn’t the first thing that happened when the teams were formed and the project begun? They could have avoided a tremendous amount of frustration, waste, and missed progress. Who knew?

Three CORE Starting Patterns for Distributed Agile Teams

I hope my two real world stories have convinced you that a fundamental aspect of successfully implementing distributed agile is how you start your teams and projects. Here is a bit of a checklist to help you improve your distributed agility:

Establish the Team(s)

  • Formation – Take some time to thoughtfully form your teams. Introduce them. Allow for social collaboration of some sort.
  • Leadership – Take a look at the leadership within your organization and ensure that each team has some experienced technical leadership. Also ensure that each team's local functional leadership is aligned with agile leadership fundamentals.
  • Co-Locate in Clusters – Look across the members you have to work with and try to cluster team members together (geographically) as much as possible.
  • Skills Aligned with Backlog – Remember that team skills need to align with the Product Backlog and that each team must have sufficient skill and domain experience to deliver high quality results.
  • Cross-Cutting Concerns - Consider how the team will handle cross-cutting concerns like UX design, architecture, and integration testing and deployment.

Train the Team Together

  • Basic Training – If possible, training should be approached as a whole team effort and is best done face-to-face. Everyone needs to hear the same things. Simulations should be a part of the training so that the teams get the opportunity to work together.
  • Roles & Responsibilities – Developing clarity around expectations is crucial for agile teams to start up. Taking the time to establish team and cross team roles and responsibilities and/or rules of engagement early will pay dividends during sprint execution.
  • Focus on Scrum Master and Product Owner – These are the most important and specialized roles within agile teams. Ensure you’ve selected wisely, don’t overload other roles, and provide sufficient training and ongoing coaching for these individuals. It’s crucial in distributed teams!
  • Start the First Sprint Together – If at all possible, start your first sprint with the team in the same locale. If that’s not possible, then start slowly, so that teams aren’t rushing to produce working software, but rather a “working team” should be their first goal.

Establish Norms, Standards, and a Charter

  • Team Norms – Set norms for listening, respect, behaviors, collaboration, quality, retrospectives, etc. Establish these as a team, post them on walls, and continuously remind yourselves of your agreements.
  • Meeting Norms – There can be an awful lot of meetings when moving to agility and conducting them can be exacerbated by time zone differences. Place heavy focus on just enough, just in time, and well facilitated meetings. Don’t forget the power of a time box.
  • Definition of Done – I have a nice presentation that depicts four levels of Definition-of-Done (DoD) or Done-Ness consideration within agile teams. There’s a link in the references. This is an area to truly focus on when working in a distributed team.
  • Tooling – Tools become more important in support of distributed teams, but they can also get in the way of collaboration and learning. Carefully select a minimal set of tools, while reinforcing face-to-face collaboration. Then grow your tools over time based on team feedback and needs.
  • Commitment to Agility – It is clearly harder to support agile tenants and tactics when participating within a distributed team. It will test your mettle. Establish broad commitment to your agile principles across teams and stick to them.
  • Chartering & Release Planning – These can be critical for cross team integration, dependencies, sharing a mission and vision, and determining and measuring success. The more time you can spend in up-front chartering activity, the better your results will be. So resist sprinting too soon!

Sprint Review Together!

One final point, distributed teams should perform their sprint demo/reviews together as much as possible. That would include members of each team and teams that are working together to deliver a project or product. The more you can integrate the demonstration of results, the more you will drive effective cross-team collaboration.

And improvements surfaced during the reviews will naturally cascade into the teams’ retrospectives, driving collaborative improvements.

Wrapping Up

Going back to my theme of what attendees ask me about distributed agile teams, there’s often another question:

Do we really have to do ________________?
It’s really hard to support that agile practice because we’re distributed!

You could fill in the blank with any of the following: swarm, collaborate, stand-up, groom, sprint plan, code review, design review, pair, test, talk to each other, etc.

My consistent answer is always — yes, you do. Now you may need to get creative with the how and the when in your support of solid agile team collaboration tactics, but skipping them when the going is tough is rarely good practice.

I’ll leave you with this thought.

Is agile harder to do in distributed teams? Of course it is. But is it possible to do it well in distributed teams? Absolutely. It’s truly up to the business to commit to properly starting their projects and the teams to commit to agility and figure out how to drive great results.

It’s simply another choice as you “go agile”. Please choose wisely.

For Further Reading

  1. A related blog post from Johanna Rothman and Shane Hastie:
  2. A presentation on agile done-ness criteria:
  3. I highly recommend a wonderful book related to Agile Chartering. The title is Liftoff: Launching Agile Projects & Teams by Diana Larsen and Ainsley Nies.
About the Author: 

Bob Galen is a software engineer by trade and a technical leader by experience. He is a principal in RGalen Consulting Group, based in Cary, NC. For the past 15 years, he has held significant leadership roles at Bell & Howell, ChannelAdvisor, EMC, Lucent, Thomson/Dialog, and Unisys. Currently his focus is Agile Methods Coaching, Training, Evangelism & Speaking. He has a track record of effectiveness in leading diverse technical teams towards project success in an energized and humane fashion utilizing Agile & Traditional methods. If there is a key to Bob’s style its Balance and Effectiveness. His is a member of the Agile Alliance, a Certified Scrum Master & Scrum Product Owner, and an experienced XP Coach.

Posted in: 

5 Ways to Get Ahead in the Digital Age

Learning how computers work is no longer an optional skill for people hoping to find jobs in the next few years. I don't mean being able to turn a computer on, or transfer a word document into a PDF format: new job seekers need to know how to present themselves, and their future companies online.5 Ways to Get Ahead in the Digital Age

I entered college hoping to study books, and will leave knowing how to code. In all honesty, I'm a novice computer programmer by any measure, and that's okay. Unless you want to build websites or fix technical problems, understanding the ins and outs of programming really isn't that important.

What's necessary for young job seekers is an understanding of the basics. Knowing what your company's site can and cannot do, how your web audience responds, and how to use social media effectively are skills that can make you more valuable to a company and help you do your job more effectively.

Understanding the internet on a personal level can be a great next step to helping a company work online. I manage an online media company in Austin, TX and have never had any formal classroom training.

Here are five things you can do that can help you get ahead of your peers and on your internet game:

Brand yourself: Companies spend years figuring out how to brand themselves in order to be the most appealing to their demographic, but how much time have you spent thinking about how you yourself are branded? If you know what you want to do, or even if you have a vague idea, branding yourself around your end goal can help you appear more qualified to prospective employers. For example, if you want to own a food truck that sells ice cream, you would try and make your presence online demonstrate both a love for ice cream, and a love for being entrepreneurial.

Understand Social Media: Social Media has much more potential than liking your Aunt Debbie's cat photos on Facebook. Social media can be a great way to brand yourself, and make connections to other people in your industry. I use Twitter to connect with other media industry professionals and to help reporters scoop stories more than I update my friends on the new Katy Perry song.

Keep up with Analytics: Nothing you can do in branding or social media is important unless you know if it's working or not. Playing around with an analytics site that tracks who comes to your website can help you get a grasp on what you are doing that works, and what doesn't. Sites like even have entrancing graphs.

Learn basic computer programming: You don't have to be able to code in Ruby to make a big impression on your future boss, but it certainly wouldn't hurt. Learning the basics of coding languages like HTML and CSS can help you understand the way sites work and help you communicate your ideas more clearly and effectively with your company's tech team. I learned to code on, which is a free website built to teach inexperienced people the basics of computer programming.

Showcase your skills: Building your own website is a great way to show off the skills that you've honed in the other steps to potential employers.  Sites like and can be great places to round out your online presence and display all of your abilities in one place. It will also increase the possibility that you show up in online search engines.

The internet can be what you make of it. You can use the internet to look at 27 photos of cats licking teacups, but it can also be a great resource to building your online identity and helping you find your next job.

About the Author: 

Kelsey McKinney is the Associate Managing Editor of The Daily Texan. She has written articles for Reader's Digest, The Atlantic, Slate and Time Out NY. Follow Kelsey online at or on Twitter @mckinneykelsey. She likes big sandwiches, Rangers baseball, and writing about feminism and popular culture.

Posted in: 
Job Seeker

Transitioning From IT Expert to IT Supervisor: Part II

This is Part II of Carol Hacker's advice for making the transition from IT expert to IT supervisor. Read Part I hereIT Expert to IT Supervisor

Learn How to Delegate

Experienced, as well as new supervisors, often struggle with the idea of “letting go.” Some supervisors are afraid to assign responsibility for fear of losing control.  This could be an unfounded fear or one that has its roots in bad experiences in the past. You cannot possibly look after every detail in the area for which you are held responsible.  You will have to delegate some of those details or you will find yourself overwhelmed with tasks, projects and customers.  In the words of mega-retailer, J.C. Penney, “The inability to delegate properly is one of the chief reasons leaders fail.” 

The critical issue is to know when, to whom and how to delegate.  Delegating is about sharing authority, not just assigning tasks.  If you are the type of new supervisor who believes that you are the only one capable of making decisions or completing challenging assignments, delegation will be a difficult skill for you to master.  Supervisors who fail to delegate tend to do so for the following reasons:

• They don’t trust the people who report to them.  They typical think: “If I want it done right, I have to do it myself.”

• They believe that if they delegate all of their work to others, that they might be seen as dispensable and lose their job.  Some supervisors are afraid that their employees will do a better job than they do and consequently make them look bad.

• Many supervisors have a need to know what’s going on at all times.  They think of their involvement as simply “staying on top of things.”

• Some supervisors get a lot of satisfaction from doing the work themselves and are thus unwilling to let go and delegate.

If you expect your employees to excel, you have to delegate and empower them to make decisions.  The benefit is not only happier employees, but also more time to do other things that you need to do.  Start by delegating in these four areas.

•    Simple and routine tasks
•    Repetitive tasks
•    Tasks that will help the employee grow
•    Tasks that can best be handled by someone other than yourself

The following basic steps will help you become more confident in delegating.

•    Decide what needs to be accomplished
•    Set up standards for results and control
•    Divide the project or task into segments that can be delegated
•    Know your employees, their qualifications, expertise, strengths and weaknesses
•    Decide who will be assigned what tasks
•    Explain standards of expectation and limits of authority
•    Let capable employees determine how to achieve the desired outcome
•    Expect people to make mistakes, but don’t count mistakes as crimes

Feel Comfortable Solving Problems and Making Decisions

Supervisors solve problems of all kinds every day.  It’s part of what they are paid to do along with making decisions.  The two processes are related; one requires the other.  Decision-making is the process of choosing between two or more alternatives.  The impact of the decisions you make can be far reaching, depending upon the type of decision you need to make.  Some decisions are spontaneous while others require considerable planning.  Following a step-by-step process will make problem solving and decision-making easier for anyone who has this important job.  The six steps of the problem-solving process are:

• Be aware of the problem; know what’s going on around you.  In some cases you can handle the potential problem before it occurs.  State the problem in writing.

• Discuss possible solutions.  Brainstorm, seek advice from others including experts, find out what’s been done in the past to correct the problem, form a task force, and don’t be afraid to get creative.

• Evaluate the possible solutions.  Compare the costs and benefits of each.  Of each possible solution ask yourself: “What will be the consequences if this action is taken or not taken?

• Make a decision.  You will be choosing one of the possible solutions.  If you have followed this step by step process, you should not be afraid to make a decision.  Avoid delaying the decision out of fear.

• Evaluate the outcome of your decision.  Was your objective met?  Was the problem solved without creating more problems?  Did productivity increase?  Did performance improve?  Was the decision a good decision?

In summary, moving from IT expert to IT supervisor is not about running a popularity contest.  Your goal is to develop and refine your leadership skills.  You will need them for survival.  Successful supervisors are confident, direct, caring and honest.  They respect people and know how to interact, delegate, empower, solve problems and make decisions.  If this is your first assignment as a supervisor, you have a lot to learn.  However, you can do it if you are committed and open to constructive feedback.  You may not always agree with what others are telling you, but it comes with the territory.  Good luck and have fun!

About the Author: 

Carol Hacker is the former Director of Human Resources for the North American Division of a European manufacturing company, Employee Relations Manager for the Miller Brewing Company, and County Office Director for the US Department of Labor. Headquartered in Atlanta, GA, Carol has been the President and CEO of Hacker & Associates since January 1989. She specializes in teaching managers, supervisors, team leaders, HR professionals, and executives how to meet the leadership challenge. Carol is the author of over 400 published articles and 14 books including the bestseller, Hiring Top Performers-350 Great Interview Questions For People Who Need People. She earned her BS and MS with honors from the University of Wisconsin. She can be reached at or 770-410-0517.

Posted in: 
Hiring Manager