Video: How to improve the user experience

Introducing Freddy, Kablamo’s Dev dog, and watch Allan Waddell and Victoria Adams weigh in on what’s needed to make UX work. Here’s a snippet:

It takes experience to know how to engage customers in the right way. It's not as simple as just putting a wire frame in front of a bunch of people and getting a result. You have to know what your tests are for. You have to know what hypotheses you're validating, specifically, and you have to get those answers and be able to measure that in the right way and then understand those results. It's like saying the difference between data and information. You get a whole bunch of data back, but it doesn't really mean what you think it means unless you thought about that preemptively.

Kablamo Appoints Kirsty Trask To Leadership Team

Screen Shot 2019-03-08 at 7.14.54 am.png

Great to see ARN and others cover Kirsty’s arrival at Kablamo as regional manager for Melbourne and a welcome addition to our leadership team. All the better because it’s International Women’s Day. Here’s an excerpt from the story:

Cloud software and product developer Kablamo has appointed Kirsty Trask as its regional manager Melbourne.

Trask joins from call recording services provider Dubber where she was a senior product manager.

In her new role at Kablamo, she will oversee the growth across Victoria, software and product development and also coaching teams within client organisations to "adopt and embrace an Agile culture".

Kablamo co-CEO Angus Dorney said Trask’s experience in managing high-performance teams and track record delivering innovative software-centric solutions made her the perfect fit.

“I didn’t want to hire someone with just ‘go-to-market’ experience, that’s a dime-a-dozen,” Dorney said. “I wanted someone who was more strategic, had experience with software and product strategy, someone who can lead the customer journey from a blank sheet of paper all the way through to taking a new product to market."

Trask is a member of the Australian Computer Society’s Women in Victoria Group, and has also worked to encourage more women to pursue careers in technology as part of Females in Information Technology and Telecommunications (FITT).

Read the full story on ARN here.

Kirsty.jpg

Ten ways to attract and keep the best tech talent (when everyone says it’s impossible)

Tenwaysimage.jpg

There is no question that strong tech talent is scarce, but how come some companies get the lion's share of the best and the brightest? Kablamo is a small but fast-growing cloud application development business and, so far, we seem to have a good formula for attracting and retaining really great technical talent, including some engineers with budding global reputations. How? Here are ten ways for organisations large and small that want to do the same. 

  1. Give them choices, change and challenge: The best technical talent needs to live in an environment of rapid customisation and variability – that’s the way they like it. No single solution is ever the same and you can't do cookie cutter. That means your tech team needs to constantly be able to find unique solutions to unique problems. Give them puzzles, hard puzzles and they will thrive.

  2. Forget the flash: Focus on skills and substance, rather than superficial polish. No one likes the developer who speaks the loudest but doesn’t have anyone understanding them. You want to promote as spirit of humility in that we’re here to look after each other and our customers, and stay committed to achieving the smartest answers – smart doesn’t mean shiny, it means real.

  3. Talk about Humans not Human Resources: Thinking of people as resources to be managed is counter-productive. Don’t have a rigid performance management framework. Don’t do mandatory breakfasts or culture-boosting posters. The traditional idea is building a beautiful office where you have employees who never want to leave from sunrise to, well, sunrise again. That’s old fashioned. Instead, work with a more flexible approach to geographic placement. When you attract the best, you trust and you adapt. And when you’re thinking about building human, rather than transactional relationships, you start to get materially better outcomes. 

  4. The best techs are looking for fast and different: Fewer and fewer top graduates from IT programs want to work for a big enterprise tech consultancies. The best tech talent are avoiding slow-moving enterprises and traditional IT vendors because it means a lack of interesting work. They’re not afraid of hard work, but they thrive when each day is different and things are fast-moving. And they now have more choice than ever.

  5. Count on gravity: Ultimately, we get drawn to the people we’d like to work with. This is especially true of tech talent. Great tech talent flocks together. Being interviewed by an outstanding technical mind, implies a wealth of opportunity in development and ground-breaking work. It’s the learning environment that pulls exceptionally bright minds together to tackle challenges in AI, machine learning, robotics, cloud and more. 

  6. Use real values not phoney corporate talk: Businesses talk a lot about values these days, but don’t even get us started on acronyms which sit on an about us pages gathering cobwebs. Yet actions speak louder than words. Not unlike other leading tech companies, Kablamo has already produced several open source projects. We actually built tech for techies that will never pay us a cent – we did this because the team believed in doing it. This also demonstrates commitment to our global developer community about what we contribute, what we stand for and what world we’re trying to create. The right (read: best) people get this. 

  7. Let them roam free: Top tech talent are mobile and flexible. These girls and guys embrace different communication tools and channels in order to make things happen. They work from home, from the train, or during unusual hours of the night – but they do so on their own terms. Unshackle your workforce. The worst trend is companies requiring a return to work-from-base model. 

  8. Treat them like adults and be transparent: You want your tech team to know the things that matter to the business – in other words, treat them like adults. Humans generally like some level of predictability when it comes to major changes to their work environment. It’s common sense, so we apply that basic knowledge to our business, and remain transparent with our team.

  9. Drive competition hard but leave egos at the door: We do ‘Thunder Dome’ at Kablamo, inspired by the movie Mad Max. Our Thunderdome involves someone throwing in a new idea, and having 20 or so engineers brainstorm, thrash, and debate it over drinks and a good time. It’s run by the engineering team and owned by them. Some of our people spend the weekend coding their own projects. It’s a way of life. So don’t get in its way; encourage it.

  10. Don’t force roles on great people who don’t want them: Some engineers strive to become managers. Some engineers strive to become subject matter experts. The latter approach shouldn’t stop anyone from achieving significant leadership positions on your team. Some individuals want to keep working with tools, follow a technical career path, and avoid the distraction or lack of passion for managing people. Too much to ask for? We tell them they can do that if they want to. A humans-first approach will keep driving both individual careers and your mission forward. 

All You Need To Know About Elasticsearch But Were Afraid To Ask.

Elasticsearch Color CMYK.jpg

When we find sticking points and technical hurdles that come up again and again for us as developers, we try to channel our frustration into something productive —like actually putting down in words something of use for other developers.

That’s what prompted Kablamo’s Ben Boyter to write 5,000 words plus on elasticsearch. Download it below.

It’s aimed at developers who need to write a search interface which is backed by elasticsearch. If you need to perform basic searches across documents with facets then you’ll definitely want to check it out. (It will not cover the setup or use of tools for elastic such as Kibana.)

Here’s a common scenario . . . The architect has decreed that for your next application you will use elasticsearch to provide a rich search experience. Your Operations/DevOp’s person has spun up some instances with elastic, deployed a cluster or through some other means provided you an elastic search HTTP endpoint. Now what? The team is looking to you to provide some guidance, to get them started and set the direction.

Ben’s pointers should be enough for anyone to get started with elastic, produce a modern search interface and know how to do most things. Anything beyond this should be fairly easy to pick up from the elastic documentation once you have this grounding.

Our Friendly AI Survey

tesla coil image.jpg

At Kablamo, we work with artificial intelligence at a pretty high technical level and with often very specific objectives (e.g., archival video management).

Being at the coal face means it sometimes really helps to gather a more general, everyday, "real" world take on how people think of AI and how they think it could change our future.

This survey is about helping us all to understand that perspective a little better (and, hey, it might even be fun).

My Business Talks To Allan --Entrepreneur reveals: ‘Why I hired a co-CEO’

KABLAMO -Allan Waddell and Angus Dorney.jpg

Kablamo co-CEO and Founder, Allan Waddell, recently appeared in MyBusiness to talk about the experience of going from solo to co-CEO. Full story below or you can read it on MyBusiness

It’s said to be lonely at the top when running a business, but as this business owner explains, appointing a co-CEO can be a beneficial way of positioning the company, and oneself, for growth.

Allan Waddell (pictured, left) founded Kablamo, a cloud software development firm, in May 2017, having previously built and sold another business. And, as he admits, he naturally gravitated towards the actual work of the business more than the running of the business itself, especially managing its finances.

For a mixture of business and personal reasons, he decided not to continue running Kablamo alone. So, mid last year, he took the plunge and appointed a co-CEO, Angus Dorney.

My Business spoke with Mr Waddell to find out why he took this approach, whether it has been worthwhile and what insights he can share from his journey so far.

Why did you decide to take on a co-CEO?

Someone wise once said to me, “You’ll be happiest at work when you are kicking goals doing what you do well”. Having already built and sold another consulting business, I knew what my strengths were, but most importantly I knew where I needed support.

When it comes to the technical, product development and sales sides of the business, I’m completely in my element. But I always knew I’d feel more comfortable if I had someone handling the financial and operations aspects of Kablamo.

That’s what makes Angus such a perfect fit; I come up with the ideas and he executes them.

How long did it take you to make that decision?

In the past, I’ve been bitten by having too much undeserved confidence in my leadership team, so since starting Kablamo, I have been aligning myself with mentors and leaders whom I’d one day think could make the leap from mentor to business partner.

Angus is someone I’ve known and respected for a long time, and we were both considering the opportunity for more than a year.

What fears did you have about the move, and how have/are you allaying those fears?

Leadership, and leader change, makes a team nervous. The Kablamo team is made up of incredibly smart people, but smart people naturally have a great deal of self-awareness, which can go hand in hand with self-doubt.

Bringing highly skilled and experienced oversight can sometimes trigger defensive behaviour and fear. Because of this, I didn’t expect the team to trust a new leader immediately, but with Angus, I already knew he would be a great fit culturally, so I could see trust on the horizon.

Did you hunt more widely for the ideal candidate before making the appointment?

I knew Kablamo would benefit from having someone drive the operational side of the business.

Having known Angus for sometime, he was always at the top of my list to share the helm with me at Kablamo — not only is he a great human being, but you’d be hard pressed to find someone with the wealth of experience he has.

He was a perfect fit, both in terms of his skills and how he fit into Kablamo culturally.

What has having a co-CEO enabled you to do so far that you would have been restricted from by flying solo?

Personally, the biggest benefits of having Angus as co-CEO is that I now have more time and our team has more executive skills.

While leading Kablamo by myself, I was in charge of everything — from business management, HR and sales to account management and operations.

Having Angus oversee the operations and financial side of Kablamo gives me more time to focus on building our vision — both from a business and product standpoint — as well as ensuring our culture is second to none.

What challenges have you faced in terms of decision-making and lines of authority, both from employees, clients and even between yourselves?

I anticipated some teething issues with bringing on a new leader, but the key to making this transition run as smoothly as possible was transparency. I was completely honest and up front with the team about why I was bringing Angus on board, and what responsibilities he would have in the business.

Equally, Angus and I clearly defined between ourselves how we would divide the CEO role.

Of course, at the start there were times when it was difficult to hand over control, but by communicating clearly and frequently, we’ve been able to solidify the relationship. When it comes to clients, Angus is well known and highly respected throughout the industry, so he was embraced almost instantly.

What challenges have arisen specifically because of the co-CEO model?

I won’t lie, the co-CEO model did take some getting used to. While I was leading Kablamo myself, I had the final say in everything and my decisions were largely made without scrutiny. With Angus, I now have eyeballs on me and my decisions, which I never had in the past.

While this was the whole idea of moving to the co-CEO model, the change from autonomy to observation was abrupt.

The key to addressing this, we’ve found, is clear and constant communication — if one of us doesn’t agree with the decision the other has made, we discuss it. We don’t let disagreements or clashes of opinion fester.

What advice would you give to other business leaders about the co-CEO model?

This model isn’t for everyone. If by nature you have counter-dependency issues, this power-sharing model will end your happiness.

There are a few key things to keep in mind if you want to explore the co-CEO model.

The first is to have a prior relationship with whoever you’re considering. If you already know much about how they work and how you each get along, you’ll have a greater insight into how the model will work in practice — without this, you’re basically crossing your fingers and hoping for the best.

Second, communication is absolutely critical. I can’t stress this enough. You both need to know exactly where you stand, and the only way to achieve this is to speak with each other frankly and frequently.

Finally, sharing for sharing’s sake will inevitably lead to complications. You must have clearly defined realms of responsibility. There will naturally be some overlap, but if you’re absolutely clear on what parts of the business fall under whose control, then each CEO is empowered to own their part.

How facial recognition can unlock video archive value

photosleuth-1496457709-44.jpg

Kablamo’s co-CEO, Angus Dorney, recently spoke to ComputerWorld about how facial recognition and AI can unlock tremendous amounts of value in video archives. Read the full story here. An excerpt is below.

Archive value

The capability also has enterprise applications – particularly for media organisations wanting to find relevant footage or stills in their video archives.

“They have millions of hours of video content and its typically stored in multiple legacy systems, there is no or varying meta-tagging, and the search processes for finding content are extremely old and they’re manual and they cut across multiple systems,” explains Angus Dorney, co-CEO of Sydney and Melbourne-based cloud technology firm Kablamo.

“If you’re a newsmaker in a media organisation or work for a government archive and somebody asks you for a specific piece of footage it’s very difficult and time consuming and expensive to try and find,” he adds.

Kablamo builds solutions that have a “YouTube-like user experience” to find relevant archive footage. Using AWS face and object recognition tools, users simply type in a person or thing “and get a list back of prioritised rankings, where it is, and be able to click and access that example right away,” Dorney – a former Rackspace general manager – says.

The machine learning models behind the capability, over time, can refine and adjust their behaviour, making results more accurate and more useful to users.

“You really have a computer starting to function like a human brain around these things which is incredibly exciting,” Dorney adds.

Importing Custom Findings into AWS Security Hub

Often, organizations have a suite of security products to help maintain their on-premises networks, their cloud networks and to help enforce the best practices they put in place. The AWS Security Hub service was announced at re:Invent 2018 and gives security administrators a centralized view of all of these tools by aggregating their findings in a common format, either within the current account or using a master account.

Though Security Hub is in preview, you can access it in your console now and it comes with out-of-the-box support for AWS services such as GuardDuty, Macie and Inspector as well as from 3rd party providers like Rapid7, Qualys, Splunk, Twistlock and much more.

In addition to the officially supported providers, you can also construct your own providers which will import findings directly into the Security Hub findings dashboard.

Writing a Custom Finding Provider

Troy Hunt created the Have I Been Pwned service which allows you to receive notifications whenever your e-mail address has been detected in a data breach that has been publicly disclosed. In addition to the e-mails, an API is also freely available to query for all breaches a particular identity has been involved in. Here is the template that will regularly poll the API for a number of e-mail addresses and produce findings in the Security Hub findings dashboard: https://github.com/KablamoOSS/Security-Hub-Custom-Provider-Demo

The template creates a Lambda which is triggered periodically by CloudWatch Events. The Lambda then iterates through a list of e-mail addresses and queries the Have I Been Pwned API to determine if any breaches have been detected. If they have, they are included in a batch_import_findings call to import the findings. Findings that are included in subsequent calls which share a common ID, will be updated.

The findings must conform to the AWS Security Findings Format which has optional and mandatory fields, including fields which represent the severity of the finding and finding or resource-specific custom properties. Normally, findings are required to target a specific AWS or 3rd party product, however each account comes with a default product which you can use to import your custom findings with.

Findings shown in the dashboard can be expanded to see the full description and additional detail. Custom Actions can also be created and executed against findings, which triggers a CloudWatch Event so that any supported targets can be executed, such as Lambda or Step Functions.

Once you have findings in the system, you can construct your own Insights which are views give you an overview of findings that match your predefined filters and grouping. The above screenshot shows an overview of the breaches for all Have I Been Pwned findings available.

Gotchas

There are some issues I found when developing for the Security Hub, which are important to note if you plan on developing your own integrations. It should be noted that since the service is still in Preview as of writing this article, these issues may or may not be fixed by the time the service reaches General Availability.

Findings cannot be deleted, but are retained for 90 days

There is currently no functionality to permanently delete a finding, however they have a 90 day retention period after which time the finding will be purged. You can archive findings during this period but unfiltered searches will still return these findings.

Updateable attributes may not update

The AWS Security Findings Format states which attributes can be updated with subsequent import calls, however some of these fields such as “Title” do not seem to update despite successful return codes from the API.

Date formats are sensitive

Though the format specifies any ISO8601-formatted string can be used in its date fields, any value with timezone information is rejected if it is not formatted in Zulu time. Additionally, errors in failed findings are not returned in the response contrary to what the documentation states. You must execute the call with a debugging log level to actually see the error messages.

Fields have undocumented maximum lengths

Also undocumented is that some fields have a maximum length. The “Description” field for example has a maximum length of 1024 characters so you'll need to trim values which are longer than that.

tl;dr

Despite the issues, AWS Security Hub is great offering for organizations looking to build their own SIEM and/or consolidate their findings into a centrally managed account. If you would like to hear more about how your organization might benefit from this new service, get in touch with us to find out more.

Just tell me how to use Go Modules

Screen Shot 2018-12-10 at 6.50.40 pm.png

I recently started using Go’s new inbuilt vendoring tool, Go Modules, and having come from both govendor and dep, this new tool was more of a change than I expected. 

I’m a fan of quick guides – just tell me what to do so I can start using it now. I don’t need an essay on why I should be using it or painful detail on the tool’s inner workings.

Unfortunately, a quick guide like this doesn’t seem to exist, so I’m writing one here. You’re welcome.

Put your code somewhere other than the gopath

You can technically use Go Modules inside the gopath, but you’ll have to manually set GO111MODULES=on in your environment variables. 

That being said, the whole point of modules is to not have to put your code in the gopath, so don’t do that.

Initialise Go Modules

Run this command in your go project:

go mod init <modulename>

‘Module name’ is whatever you want to call your module. This name should be fairly unique, because if you have module name clashes you’re gonna have a bad time. 

This creates a go.mod file, which you don’t need to touch.

Use go get to add the dependencies to the go.mod file

Just run this:

go get -u ./...

This will add all of your project’s current dependencies to the go.mod file and create a go.sum file. You don’t need to touch that file either. 

Vendor those dependencies

Run this:

go mod vendor

This will create a vendor folder and add copies of each dependency listed in your go.mod file to that folder. This folder also can’t be edited, so again, there’s no need to touch it. 

Update a dependency

Just run:

go get -u <repo url>
go mod vendor

This will update the dependency version in the go.mod file, and then update the code in your vendor folder for that dependency.

This should be enough for you to get up and running with Go Modules on your go project.



Why two CEOs can be better than one

Screen Shot 2018-12-06 at 3.31.06 pm.png

“Co-CEO… how’s that going for you?” This is a question I’ve been asked many times in my first six months sharing the helm of fast-growing cloud software engineering company, Kablamo.

Typically, the tone of the question gives away the enquirer’s underlying scepticism, but I get it. It’s an unorthodox leadership model, so it’s understandable that people are curious about it.

Historically, most famous CEOs are associated with an enduring personal brand, a big ego, strong individual decision-making skills, exceptional intelligence, and “star player” brilliance. None of these traditional CEO characteristics can be divided in two.

Also, it is more natural for humans to seek power than to share it. And I think this is the main reason so many people ask me about the Co-CEO model.

Honestly, I was nervous when I decided to join Kablamo as Co-CEO, sharing the CEO duties with the Founder, Allan. I was nervous because our decision to adopt an uncommon, shared leadership model put at stake the experience and engagement of our wonderful Kablamo team. I was also nervous because our commitment was public… and I hate to fail. (There’s still ego as a Co-CEO!) 

Almost six months into the journey at Kablamo, I now believe that the Co-CEO model can bring more benefit to an organisation than the single CEO model. The reason why Co-CEOs can be even more effective than an individual CEO can be summed up in one word – Diversity.

That said, having Co-CEOs would not work for every business. There are essential factors that two (or more) leaders need to make a Co-CEO model work, and fortunately Allan and I seem to have them. From my experience, here are the most important characteristics Co-CEOs need to make the combination a success:

  • Share common values: This is non-negotiable. Co CEOs must have common principles for how to treat people, how to behave, and what type of company and culture they want to build.

  • Embrace your differences: Here’s where the power of diversity between Co CEOs can beat individual CEO brilliance. For example, at Kablamo, Allan brings the creativity and technical vision to our team and my strengths are more organisational and strategic. Our skills compliment each other and allow us to focus on the aspects of the role in which we both excel.

  • Communicate again and again: Open, honest and regular communication between the Co-CEOs and the rest of the team is imperative. Importantly, the feedback loop between Co-CEOs needs to be direct, and as close to real-time as possible.

  • Trust each other: This is also non-negotiable. Once trust is gone, the Co-CEO combination is dead. I deliberately put this point last because, by doing the three former points well, Co-CEOs dramatically improve their chances of maintaining trust.

Allan and I are only at the start of our Co-CEO journey together at Kablamo but, so far, the signs are good. With each new customer win, with each conflict resolved, with each new hire, and with each great customer outcome, our Co-CEO partnership becomes stronger. (It also helps that we have an outstanding team of leaders, visionaries and thinkers at Kablamo to support us.)

At Kablamo, we strive to “Make with Heart and Mind”. So long as we both make decisions and act in line with this value, I am confident that both our Co-CEO combination, and Kablamo itself, have a very bright future.


Allan Talks AI and Slime Moulds in The Australian

slime mould.jpeg

The future of tech?

The Australian has just published Allan Waddell’s take on the biological future of AI. You can read it at The Australian here or the original text below:

Artificial intelligence is taking off. Virtual assistants, computer chips, cameras and software packages are increasingly taking advantage of machine learning to create pseudo-intelligent, versatile problem-solvers. Neural networks, AI modelled on the human brain, strike fear into anyone convinced that AI is ­already too close to being alive. The truth is it has ­always been easy to tell the artificial and the living apart — until now.

This biological-artificial distinction is about to get blurrier, and all of us need to pay attention. Among other developments, ­researchers at ­Lehigh University recently ­secured funding to grow neural networks out of living cells. ­Essentially, the researchers are going to recreate the neural-network architecture of an artificially intelligent algorithm using living cells. Theoretically, the ­algorithm should work identically in a petri dish as it does in a computer; the structure of the neural network is irrelevant in computational systems. This is a property of computers for which Justin Garson coined the term “medium independence”. In 2003, Garson said the medium used for computation didn’t matter — a computer could be made out of silicon or wood — as long as the logical basis of the computation was unchanged.

While this research is revolutionary, procedures involving cell-based neural networks have ethicists, law professors, philosophers and scientists raising concerns about using cerebral ­organoids — what you might think of as minibrains — for neurological research. Regular human brains are generally unavailable for study, so minibrains are a great ­research alternative. However, because minibrains are, well, ­actual brain material, ethicists worry they could become conscious if they reach a certain level of complexity. It takes only a small leap to raise these same concerns about growing cell-based neural networks. After all, neural networks are designed to work in the same way as a brain. So, what’s the difference between a human (or more likely, simple organism) brain and a neural network in a petri dish? And what if a research team combined these two approaches and grew neural networks out of human brain cells? All of these questions and more are rapidly forcing their way into public discussion as our biotechnology advances.

And it doesn’t stop there. The next big thing could actually be more advanced organisms like the slime mould. ­Believe it or not, slime moulds are solving organisational problems that have confounded the brightest math­ematicians in human history, and the mould isn’t even trying. Japanese and British ­researchers created a miniature map of Tokyo, stuck a bit of Physarum polycephalum mould on Tokyo, and put some oatmeal on other major cities in the greater Tokyo Area. Within a week, the mould had recreated a pathway model of Tokyo’s train system, simply by doing what mould does best: growing and seeking out ­nutrients. The New Jersey Institute of Technology boasts a “Swarm Lab” that studies “swarm intelligence” found in everything from colonies of ants to dollops of mould, in an attempt to learn how organisms make decisions — ­research that could one day refine the algorithms behind self-driving cars, among other things.

Network design by slime mould is an astounding breakthrough. Consider that when Japan began building its high-speed rail network in the late- 1950s, it was financed in part with an $US80 million loan from the World Bank. Adjusting for inflation, that totals more than $US680m, and some estimates put the actual cost of the train system at twice the original loan amount. Of course, a lot of this money was spent on materials and paying construction workers, but using general project cost estimates from a civil engineer, we can guess at a design cost of roughly $US54m. So, give a little mould a week to grow, and it will replicate tens of millions of dollars of design work for practically nothing. Furthermore, Tokyo’s rail system wasn’t designed and built all in one go; the rail system has been in some stage of development since 1872. The design produced by the mould nearly mimicked the final result of more than a century of development.

Network design is no simple task and the problems involved are some of the hardest to solve in computer science, generally ­requiring lots of approximations and algorithms. The slime mould isn’t concerned about the fancy mathematics, though. It simply spreads out, finds food, and then develops the most energy-efficient way to move nutrients around its mouldy network-body. The ­researchers involved in this project crunched some numbers and determined that, if constructed, the mould’s design would be “comparable in efficiency, reliability, and cost to the real-world infrastructure of Tokyo’s train network”.

The humble slime mould is teaching a lesson many business leaders should heed. Technologies like AI and machine learning are developing at an amazing pace, but we don’t yet know where they’re taking us. What we do know is that just like the mould, environments need to have the right conditions for these new technologies to thrive.

Allan Waddell is founder and CEO of Australian enterprise IT specialist Kablamo.

How do you architect culture at scale?

Angus Dorney and Allan Waddell tackle the question of how you build culture and then scale it. Watch the video or read the transcript below.

Great teams on the horizon….

Great teams on the horizon….


Angus: Whew! (laughs)

Allan: You got this.

Angus: Yeah, I got this. Well, I think architecting culture at scale is, I think, important's things to do if you're going to architect culture at scale. First of all, you have to define an organization stands for really and I think that the values are in an organization's DNA are set extremely early on in the life, the lifecycle of that organization. It's something that you can't change as the organization grows up. And so, I believe, that in order to scale culture in an organization, you have to be very clear in what your values are early, those values have to different, they can't just be innovation on a tea and trust like every other single business in the world. They have to different. They have to meaningful. They have to be something that, ah, g-, is going to motivate your employees and engage them as they grow and, if you set the blueprints early, then that can be a guiding light for scaling locally and internationally.

Allan: Completely agree. One of the key things a scale is, you need to be attractive the developmental, the capability market as opposed .. and that needs to marry into, I mean, y-, your internal values might not necessarily be the same as what you present your clients, um, but they need to be, they need to be, but they need to be alive, if that makes sense. And so, when you talk about cultural scale, attracting great people is one of the benefits, well, of having great culture and then also attracting great clients.

Angus: Yeah, uh, I think that a lot of organizations will say, "Here's our values", and print out a poster and stick in on the wall,

Allan: Hmm (affirmative).

Angus: and that's completely ineffective so it's actually about defining what it is that you stand that for and the behaviors that, how you stand for as an organization but it's about reinforcing those things with, um, the way that you act, the things that you do so you have to build customs and forums and reinforcing mechanisms around those values themselves. And, you know, whether that's with the group meetings that you facilitate, definitely the way that the leadership team acts, the types of behavior that's acceptable and [inaudible 00:02:46] on a daily basis in the organization, the recognition, the awards that you give out, all of these things serve to reinforce those set of values rather than just sticking a, a poster up on the wall and hoping that that's going to influence the way people behave.

Allan: Absolutely, I think it's, culture is not just about what leadership decides-

Angus: Yeah.

Allan: It’s, you know, your team has to embody that culture and that's the only way, w-, client, if, you know, if clients have your team on site you can't, (laughs) deploy, ready, win and go. Remember that we're humble. Like it doesn't work that way. But the leaders on the ground have to really believe that and be cultural leaders for their team,

Allan: .. just recently we had a, one of our old hands back at the office, he, and, um, one of our team was talking about the experience they were having on site and how that related so much back to the values that we have, how it related back to the integrity and the humility, and I stopped what they were doing for a moment and believed it was their chance to really operate in that mode? And, I think that's like a watershed moment for us, when we go, "This is, you know, we think we're going the right thing.". I don't think there is necessarily a direct path to building a culture scale, it's a journey, and you have to adapt and you have be on, everyone has to be on the bus together, .. but that was a really good indicator that we're on to something.


What every CIO should know about Cloud

Watch Angus and Allan talk about CIOs, Cloud and oranges or read the full transcript below.

What should every CIO know about Cloud, well, every CIO should know something about Cloud. I think we can agree on that part.

(laughing).

But, look, I don't have time for... I shouldn't put it that way. I think the era of the CIO that declared that we're a Cloud first business just because everybody else is doing that. I think that's finished and what we're seeing in Australia and you know from my experience internationally, as well, in some of the more advanced Cloud markets is, we're seeing people with technical understanding of what Cloud and other advances in technology can do for their business and that's what CIOs really need.

They need to understand how Cloud gives them and their businesses the freedom to be remarkable, not just we're gonna go there because everybody else is and that might deliver us some cost savings.

It's a variable topic, but I think that, you know. I think first of all, the move to, the move to Cloud is actually a, a move to make your business more nimble. Now I'm, that's the opportunity that lays in front of you. It's not always about cost savings. It's great that cost savings are a by product but that's exactly what it is, it's a by product of making a business more nimble.

I think, I think the agile model that, enables you to, you know to, to be more nimble. You, you need to be okay with value in some states and it's more about getting in there and trying uh, and doing some proof of concepts and you know, and just start building trust and start practicing the ways to make your business more nimble. It's not just about moving applications into, into any eco system.

It's always a great first step, but there has to be back in your mind. It has to be, actually you know, how do we transform this, how do we transform this business into being something that is going to adapt to oncoming competition.

Yeah, and the, the, the, the new generation of CIOs coming in. I think also need to realize that the partners that have got them to this point, can't get them to where they need to go next.

Yeah.

And, and it gets back to that conversation around the inter priority service delivery model. You can't get what you need from one or two big technology sourcing partners, I think. The best CIOs now understand that they need to engage specialists to deliver that transformation in their organisation. That's a very different perspective to what a CIO would have had in the past.

Yeah. Yeah, and I said if I bought apples today, 10 apples isn't gonna equal one orange. Like, it's like you could have a billion apples, you're not gonna get the orange they need, you know to be able to, at the level what they, they need to do.

I'm gonna have to get you to explain to me what that actually means later.

I don't know. I don't know. I just like apples. (laughing).

aidan-meyer-223547.jpg

Build Culture Around X-Factor Humans

Allan talks about the secret to building culture and business around X-Factor Humans. Watch below or read the full transcript.

There's something about how an x-factor human relates to a client as well as what they can do technically speaking so, over the years, we've crossed very few in the market globally actually have that gravitas that enables them to engage a client in a way that gets them really material outcomes, and when they have that x-factor technical capability, the outcomes they can drive are amazing. I think that's what we like to build up [is it surrounds us 00:04:46] having those really specialised great engineers that have that gravitas 'cause there's a perpetual business model in, you know, growing that culture behind team members like that and then also extending out their horizons and their sphere of influence into the enterprise space.

mohamed-nohassi-223475+%281%29.jpg

In ERP No One Can Hear You Scream

800px-Edvard_Munch,_The_Scream,_1893,_National_Gallery,_Oslo_(1)_(35658212823).jpg

Perhaps no enterprise technology is as divisive as Enterprise Resource Planning (ERP). Given the critical role ERP plays in an organisation - driving the core functions of business intelligence, CRM, accounting, and HR (to name a few) - it isn’t surprising that the popular opinion toward the technology is a mix of boundless love and seething hatred. To call the relationship ‘complicated’ is an understatement - a more accurate description would be the ‘Stockholm Syndrome’.     

Stockholm Syndrome describes the feelings of affection a hostage can develop for their captor. In ERP’s case, there seems to be little other choice for enterprises who have invested hundreds of thousands of dollars in ERP technologies over the past decade (or decades). The technology has become so ingrained in how enterprises do business, the thought of leaving - of decommissioning - these investments seems like pure fantasy.

Welcome to the world of ERP hostageware.

In the 1990s, when this technology first saw widespread adoption, ERP systems were a way for businesses to replace multiple aging back-office systems. For the first time, there was one ring to rule all the critical business functions - payroll, invoicing, logistics, supply chain - and enterprises couldn’t get enough.

With this central repository of all a businesses key data and functions, anything that could be handled by the ERP was migrated to the ERP.

What could possibly go wrong?        

ERP is a product of its time - massive on-site implementations, expensive maintenance and sporadic updates. When everything the business does runs off this central system, the thinking is generally “once its up, don’t touch it”.

While this might have served its purpose during the Y2K era and the early 2000s, it has inevitably led to two key drawbacks: business strategy is limited by the capabilities of the ERP, and so much reliance is placed on the system it seems impossible to ever leave.

So, despite the business world now being infinitely more dynamic than it was 15-20 years ago, enterprises are stuck using technologies designed for times when video rental stores still existed. 

Imagine using the same hardware from more than a decade ago in just about any other context. Its inconceivable in any other part of the businesses, but not when it comes to ERP.

This is despite clear failures of the ERP industry to change with the times.

Last year, one of the world’s largest ERP vendors, started suing organisations for using any software that connected with data stored on the ERP platform. When just about every business function touches the ERP system, this is almost impossible to avoid. One firm was ordered to pay more than £54 million (USD $70.4 million) after implementing Salesforce into their environment.

The blowback resulted in updates to ‘indirect access’ rules and the introduction of a new pricing model to bring more transparency to customers.

Still, the same organisations that once rejoiced in securing one-size-fixes-all software are now frustrated and cautious to admit those one-size-fits-all solutions no longer fit.

Perhaps it’s nostalgia. Perhaps it's the comfort of the fact that everyone else is in the same boat. Perhaps it’s about money, a clear-eyed awareness that dropping an ERP vendor can be incredibly expensive and disruptive to business.

More organisations today use the ‘hulking’ on-prem ERP systems of yester-decade, and those who have invested in these technologies are reluctant to explore new solutions.  

Regardless, customers often seem chained to these legacy vendors. Businesses are being held hostage and the only remedy in the past has been to accept it as a fact of life. To focus on what the vendors can do, not what they can’t. To develop Stockholm Syndrome.

Perhaps I’m naive, but I believe businesses should be able to make decisions based on what is the best fit for their current and future needs. They shouldn’t be shackled to decisions and investments made decades ago. They shouldn’t be forced to empathise with their captors just because the alternative seems too daunting.

So here are three simple pointers that can help counter this cycle of dependency: Build so you can get the data out; drive requirements for your customer downwards, not from the ERP upwards; and always keep an eye on the exit (many ERPs are looking for the lock-in).  

AWS Security: Rule-based approvals for CloudFormation

2000px-AWS_Simple_Icons_AWS_Cloud.svg.png

AWS CloudFormation is a great tool for developers to provision AWS resources in a structured, repeatable way that also has the added benefit of making updates and teardowns far more reliable than if you were to do it with the individual resource APIs. It is the recommended approach for teams to utilise these stacks for the majority of their workloads and easily integrates into CI/CD pipelines.

Being so powerful, the complexity of CloudFormation templates can quickly become overwhelming and shortcuts or mistakes can occur. One common solution to this problem is to define a set of rules for the stack resources to be evaluated against. These rules can be generically defined, or specific to a particular teams needs. For example, a common issue that teams face is S3 buckets being incorrectly exposed. A rule may be defined that prevents this from occuring or notifies security teams.

Pre-Deploy vs. Post-Deploy Analysis

There are two distinct approaches to performing CloudFormation analysis; pre-deploy and post-deploy. Pre-deploy analysis reviews the content of the templates before they are created or updated whereas post-deploy analysis will look at the resultant state of the resources created/updated by the CloudFormation action.

Pre-deploy analysis will catch problems before they have a chance to manifest themselves in the environment. It is a more security-conscious approach but has the drawback of being significantly more difficult to predict or simulate the result.

Post-deploy has a much clearer picture of the state of resources and the result of the stacks actions, however some damage may already have been done the moment the resources are placed in this state. Amazon GuardDuty is a service which will alert on an Amazon-managed pre-defined set of rules on all resources within your account and is an example of a post-deploy analysis and alerting tool.

Validating templates before deployment

Let's discuss how a pre-deploy tool might work. The following example is written in Python 3:

def processItem(item):
  if isinstance(v, dict):
    for k, v in item.items():
      processItem(v)
  elif isinstance(v, list):
    for listitem in v:
      processItem(listitem)
  else:
    evaluate_ruleset(item)

processItem(template_as_object)

This is a very rudimentary evaluator that looks for all primitive types (strings, integers, booleans) within the template and evaluates against the ruleset.

Diving in

Consider the following template:

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Description" : "A public bucket",
  "Resources" : {
    "S3Bucket" : {
      "Type" : "AWS::S3::Bucket",
      "Properties" : {
        "AccessControl" : "PublicRead"
      }
    }
  }
}

A rule that prevents S3 buckets from being publicly exposed may choose to interrogate the AccessControl property of any AWS::S3::Bucket resource for a public ACL and alert or deny based on that. This is how the majority of pre-deployment analysis pipelines work. Things can get tricky though when you involve the CloudFormation intrinsic functions, like Ref. Now consider the following template:

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Description" : "A public bucket",
  "Resources" : {
    "S3Bucket" : {
      "Type" : "AWS::S3::Bucket",
      "Properties" : {
        "AccessControl" : { "Fn::Join" : [ "", [ "Publi", "cRead" ] ] }
      }
    }
  }
}

You'll quickly notice that even if a tool were to iterate through all properties in every Map and List, they would never find the "PublicRead" keyword intact. It's very common to join strings, or reference mappings in templates so a string-matching approach would be fairly ineffective.

CloudFormation resource specification

AWS produces a JSON-formatted file called the AWS CloudFormation Resource Specification. This file is a formal definition of all the possible resource types that CloudFormation can process. It includes all resources, their properties and information about those fields such as whether or not they need recreation when they are modified.

We can use this file to evaluate the properties for each resource and apply rulesets directly to individual properties, rather than the template as a whole. With logic around the processing of the intrinsic functions, we have created an open-source CloudFormation template simulator that is easily deployable in any environment. This simulator is able to evaluate most intrinsic functions like the example above and properly evaluate with our ruleset.

The template simulator can be found at https://github.com/KablamoOSS/cfn-analyse.

Thinking maliciously

Now consider the following template:

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Description" : "A public bucket",
  "Resources" : {
    "TopicLower" : {
        "Type" : "AWS::SNS::Topic",
        "Properties" : {
            "TopicName" : "a-b-c-d-e-f-g-h-i-j-k-l-m-n-o-p-q-r-s-t-u-v-w-x-y-z-0-1-2-3-4-5-6-7-8-9"
        }
    },
    "TopicUpper" : {
        "Type" : "AWS::SNS::Topic",
        "Properties" : {
            "TopicName" : "A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W-X-Y-Z"
        }
    },
    "S3Bucket" : {
      "Type" : "AWS::S3::Bucket",
      "Properties" : {
        "AccessControl" : { "Fn::Join" : [ "", [
            { "Fn::Select" : [ 15, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicUpper", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 20, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 1, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 11, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 8, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 2, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 17, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicUpper", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 4, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 0, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] },
            { "Fn::Select" : [ 3, { "Fn::Split" : [ "-", { "Fn::GetAtt" : [ "TopicLower", "TopicName" ] } ] } ] }
        ] ] }
      }
    }
  }
}

The above template will actually evaluate to produce a public S3 bucket. This is because the S3 buckets "AccessControl" property uses characters from the "TopicName" attribute of the SNS topics. The format of these attributes is not formally documented in the CloudFormation resource specification, nor anywhere else. This means that there is currently no effective way to truly verify that resources with the intrinsic functions "Ref" or "Fn::GetAtt" are truly valid against the defined ruleset.

By the nature of CloudFormation, there isn't a perfect solution for static analysis which is why a multi-layered strategy is the most effective defense. If your organisation needs help protecting their environment, get in touch with us to find out how we can help you better protect yourself against these threats.

What is one simple thing you can do to improve UX?

Watch Allan Waddell, co-CEO of Kablamo, and Victoria Adams, Kablamo’s UX/UI Lead, tackle a thorny UX issue that comes up again and again, but is there to be solved. And Freddy, the Dev Ops dog, makes a special appearance.

If I were to pick one thing, in order to improve user experience that I've seen done, is honestly involving the user. User experience it's in the name but I see it time and time again that the user is left out of the table that's being discussed. We talk about features, we talk about what's in scope, what's out of scope and the user's voice is left behind. So even if they can't be at the table, having that research in the user experience person so that they can be that voice.
Isn't that ironic? The user experience the user is left out.
(laughs)
Yeah, that's often the case. I think--I don't think it's--sorry. It's Freddy. 
(laughs)
Um. Yeah. I can't take anything seriously with him sitting on my lap. I'm sorry but like it's--
It's a 'blamo dog.
Yeah, it's a DevOps dog. I think uh ... yeah, in user experience the number one thing that doesn't happen is users gets involved and I think it's not necessarily the fault of the customers that are doing it. It takes experience to know how to engage customers in the right way. It's not as simple as just putting a wire frame in front of a bunch of people and getting a result. You have to know what your tests are for. You have to know what hypotheses you're validating, specifically and you have to get those answers and be able to, be able to measure that in the right way and then understand those results. It's like saying the difference between data and information. You get a whole bunch of data back but it doesn't really mean what you think it means unless you thought about that preemptively. That's what Freddy thinks anyway. (laughs)

Is Cloud All or Nothing?

Screen Shot 2018-09-23 at 2.19.50 pm.png

When it comes to cloud adoption, there’s largely two schools of thought on the best approach. The first involves migrating most - if not all - business functions in a large scale transformation project. The second involves shifting functions piece-by-piece as and when the need or desire to do so becomes apparent.

You want to enable organisations to pursue both strategies. Perhaps most importantly, however, you want to take the time to listen to the organisation and understand which approach would be the best fit for their unique business circumstances - even if your advice runs counter to their initial thinking.

Regardless of which strategy is pursued, making the choice to move business functions to the cloud provides multiple benefits to an organisation. Whether it’s an improved security posture, better disaster recovery and backup processes, increased flexibility or lower IT overheads, embracing the cloud can bring huge competitive advantages.

When it comes to SMEs, perhaps the greatest benefit of cloud computing is that a smaller company can leverage all the tools larger enterprises use without the upfront investment needed for on-premise enterprise computing equipment.

The flip-side of this coin is that larger enterprises can use new-generation tools to either replace or compliment their current investments. This helps large organisations compete with newer, more nimble entrants to the market - assuming of course they’re willing to make the leap.

No matter the size of an organisation, a full-scale transformation project can be daunting. Many organisations can fall into the trap of rushing into a complete IT overhaul without being completely aware of the internal skill sets or retraining required to make the project a success.   

It is in these cases we’d advise a client to test the cloud waters first. Rather than migrate all functions at once, it could be more beneficial to embrace the cloud application-by-application. Below we’ve listed the most common business processes our clients migrate to the cloud, and outline some of the benefits of doing so. For the cloud-curious, these applications make the most sense to migrate first in order to introduce an organisation to cloud before exploring a more wide-scale transformation;   

Web Facing Applications: Websites, content management systems, mobile apps and online commerce sites should be the first applications to consider migrating to cloud. Not only are these typically more modern, meaning migration is much simpler, but they’re also less essential to business than applications like ERP -  if there’s any teething issues during the project, there is less disruption to business. Not only are these applications some of the simplest to migrate, but their performance can be greatly improved by shifting them to cloud as they typically require scalability to balance unpredictable online volumes - scalability that is both difficult and expensive to achieve on-premise.

Customer Relationship Management: CRM software keeps track of every aspect of the customer relationship from first contact throughout the entire lifecycle. A robust cloud-based CRM improves a business’ knowledge of its customers as all interactions are recorded and easily accessible; whenever a customer gets in contact, that customer’s history is available to the agent at the click of a button. Critically, cloud-based CRMs can extend this functionality to agents in the field as a smartphone with an internet connection can access all the same data as a computer terminal at HQ.  

Human Resource Management System: HRM systems focus on the human component of your business. It encompasses everything from payroll and benefits planning, to talent acquisition and reporting. A cloud-based HRM system enables an organisation to confidently manage the changing nature of work, for example more staff wish to work remotely and gig economy workers are becoming more prevalent. A responsive system enables employees to more efficiently track and log their time, while the inbuilt analytics of these systems gives the HR team a better of insight of employee productivity.     

The most important takeaway, though, is that cloud computing has something to offer almost every business. For some, it is leveraging powerful hardware, software, and services for a pay-as-you-go price. For others, it is a level of data security they could not achieve on their own. For developers, it is remote collaboration and multi-platform tools for creating, testing, and deploying highly available applications.

When considering cloud, it can seem intimidating. Not every organisation is ready to shift every application all at once, and there’s nothing wrong with that. Each business is unique and at a different stage of their cloud journey. Regardless of whether you’re ready to go all-in on cloud or would prefer to dip your toe in the water first, it’s important to find a partner who understands the specific outcomes your business wants to achieve and has the technical ability to help you achieve them.  



Bring Your Humans...

endless-long-road-5094.jpg

If you want a tech transformation.

Transformations are disruptive. I don’t mean this in the lazy, cliched, and sigh-inducing “X company is the Uber of Y industry, poised to disrupt the industry”, I mean it is a process of change that requires some adaptation.

Digital transformations involve overhauling processes and reimagining how an organisation does business. It’s not as simple as calling in a carpenter to renovate the office kitchen - although this too can cause some disruption - because transformations are underpinned by an aspirational vision of what the organisation could be.

This desired future state, by its very nature, is disconnected from the organisation’s current reality. It is this disconnect that is the cause of most of the disruption. Humans, being creatures of habit, become accustomed to doing things in a certain way - in a business context, this means using certain programs, processes, or resources to achieve a particular task. Transformation projects aim to overhaul this status quo and ultimately give a workforce access to tools to make it more efficient, more collaborative, and more responsive to change.  

While these are all noble aims, an organisation’s humans must be brought along for the journey so they understand why this transformation is taking place and what that desired future state looks like.

A people-first focus enables you to really listen, to ask the right questions and discover exactly what an organisation needs. This open and frank communication - devoid of any preconceptions - allows you to intimately understand what the organisation actually desires to achieve.

This free-flow of information is something we encourage our clients to undertake with their staff during a digital transformation. It is a disruptive time for any organisation, but below are a few tips to ensure employees understand what changes are coming and - most importantly - why they’re coming;   

  • Collaborative Enthusiasm. During a transformative project, every employee has a role to play and needs to be ready to collaborate across teams and disciplines. For example, the marketing team may need to start promoting the tech transformation before it’s implemented, and needs to mesh with the IT team to make sure their message is accurate and timely. Make these roles clear, and ensure the teams understand what they need to do and why they need to do it.

  • Common Vision. Building enthusiasm and cross-department collaboration is far more successful when the entire enterprise shares a common vision and understanding of the project. Outlining the project and its goals in a product development framework document is one important way for key stakeholders to gain an overview of the project and to communicate the cogent information effectively to employees.

  • Technical Skill. This encompasses not only the skills and knowledge of your employees but also your managers’ ability to evaluate potential vendors and the tech they’re providing. Sometimes the “best-dressed” vendor isn’t the best choice for a project; do your people have the knowledge to determine this? It is important to have an honest conversation with your technical team before evaluating any transformation initiative - what skills do they have and where are the blind spots?

These components won’t fall into place overnight. They require planning and a clear view of the organisation’s strategy and desired future state, but each needs to be addressed. Ask the hard questions: Do your people have the technical skill required for their particular piece of the project? Are they excited to join in the process of transforming your enterprise’s technology? Does everyone share the vision of the enterprise’s future that this technology will usher in?

Also apply these concepts when choosing vendors or consultants, who each contribute a piece to the overall project. How well do they know the product or technology they’re working with? Are they enthusiastic about the project and able to collaborate effectively with your humans? Inasmuch as you can share the details of the project with them, do they understand their role in making the company’s vision become a reality?

Evaluate the answers to these questions before launching a project, and return to them periodically throughout the process to make sure your people’s skill sets, enthusiasm, knowledge and collaboration - as well as those of your technology providers - are on track.

After all, technology is only as effective as the people using it. Bringing your people onboard early in the process ensures your organisation can navigate the coming changes as seamlessly as possible.  

What matters to you when you think about hiring an IT Consultant?

survey monkey image.jpg

Hiring an outside IT consultant is obviously a common business decision, but the experience can be complicated, costly and frustrating. How has it worked for you? We’ve turned to the monkey that surveys to learn a little bit more. Please take our brief survey and share your experience.