Developers Corner


In this article we’ll learn how to write our own native MySQL client from scratch using no connector or external libraries.

In the previous article we researched MySQL Client / Server Protocol using WireShark. Now lets start to write our code in python to simulate MySQL native client. Final codes are here: Github repo

First of all we have to create MYSQL_PACKAGE class. MYSQL_PACKAGE class is the parent of all other package classes (HANDSHAKE_PACKAGE, LOGIN_PACKAGE, OK_PACKAGE and etc.)

It accepts resp parameter on initialization. Resp is the binary response received from the server in bytesarray type. One of the important and interesting method of this class is next method.

Method next reads a portion of the bytes from the binary response. When we call this method, it reads some portion of bytes and puts a pointer to the last position where reading ended (changes a value of self.start and self.end properties). When we call this method again, it starts to read bytes at the point it last stopped.
Method next accepts five parameters: length, type, byteorder, signed, and freeze. If freeze is True it reads some portion of bytes from the binary response but does not change pointer position. Otherwise it reads a portion of bytes with given length and changes the position of pointer. If length is None then method reads bytes until the end of response bytesarray. Parameter type can be int, str, and hex data types. Method next converts a portion of bytes into the appropriate datatype according to the value of type parameter.
Parameter byteorder determines the conversion of bytes to integer type. It is up to the architecture of your computer. If your machine is big-endian, then it stores bytes in memory from the big address to the little. If your machine is little-endian, then it stores bytes in memory from the little address to the big. Thats why we have to know the exact type of our architecture to be able to convert bytes to integer correctly. In my case, it is little-endian, that’s why i’ve set the default value of byteorder parameter to “little”.
Parameter signed is also used in conversion of bytes to integer. We tell the function to consider each integer as unsigned or signed.
A second interesting method of this class is encrypt_password. This method encrypts a password with the given algorithm.

This method accepts two parameters: salt and password. Parameter salt is the concatenation of two salt1 and salt2 strings from the Greeting Packet received from the server. And parameter password is the password string of mysql user.
In the official documentation password encryption algorithm is:
Here “20-bytes random data from server” is concatenation of salt1 and salt2 from the Greeting Packet received from server. To remember what the greeting packet is look at the previous article
Now I want to explain the encrypt_password method line by line.
bytes1 = sha1(password.encode(“utf-8”)).digest()
We are converting password string to bytes, then encrypting it with sha1 function and assigning to bytes1 variable. It is equal to this part of algorithm:
Then we are converting salt string into bytes and assigning to the concat1 variable.
concat1 = salt.encode(‘utf-8’)
Third line of the method is:
concat2 = sha1(sha1(password.encode(“utf-8”)).digest()).digest()
Here we are double-encrypting password string with sha1 function and assign it to the concat2 string.
Now we have two concat1 and concat2 variables. We have to concatenate them into one byte array:
bytes2 = bytearray()
Then we have to encrypt concatenated bytes with sha1 function and assign to the bytes2 variable.
bytes2 = sha1(bytes2).digest()
So we have two variables with encrypted bytes: bytes1 and bytes2. Now we have to do bitwise XOR operation between these variables and return the obtained hash.
hash=bytearray(x ^ y for x, y in zip(bytes1, bytes2))
return hash


In the previous article we’ve learned about Int and String data types of MySQL Client / Server protocol. Now we need some classes to be able to read fields from received packets.


Int class implements INT data type of MySQL Client / Server protocol. It accepts package parameter on initialization. Parameter package should be the instance of any package class inherited from MYSQL_PACKAGE class. Method next detects the type of integer (int<fix> or int<lenenc> (see previous article) and calls the next method of package object to read the byte portion of received response.


Str class implements STRING data type of MySQL Client / Server protocol. It accepts package parameter on initialization. Parameter package should be the instance of any package class inherited from MYSQL_PACKAGE class. Method next detects the type of String (String<fix>, String<Var>, String<NULL>, String<EOF> or String<lenenc>. See previous article) and calls the next method of package object to read the byte portion of received response.


HANDSHAKE_PACKAGE class is used for parsing the Greeting Packet received from server. It is inherited from MYSQL_PACKAGE class and accepts resp parameter on initialization. Parameter resp is the Greeting Packet response in bytes type recieved from the server.

Method parse reading fields from the response using Int and Str classes and puts them into a dictionary and returns.


This class is used for create Login Request packet.

This class accepts handshake parameter on initialization. Parameter handshake should be the instance of HANDSHAKE_PACKAGE class. In the __init__ method we call the parse method of handshake object and get all fields of the Greeting Packet received from the server.
Method create_package prepares the login request package to be able to send to the server for authentication. Accepts user, password and packet_number parameters.


OK package and ERR package are the response package of server after authentication or after sending query to server on command phase.


MYSQL class is the wrapper class which creates TCP connection with server, sends and receives packages from server using above classes.

I think everything is clear in this class. I’ve defined __enter__ and __exit__ to be able to use this class with “with” statement to automatically close TCP connection. In __enter__ method i’m creating TCP connection over socket. And in __exit__ method i’m closing created connection. This class accepts host, port, user and password parameters on initialization.
In the connect method we receive greeting packet from server:
resp = self.client.recv(65536)
In the login method we create Login request package using LOGIN_PACKAGE and HANDSHAKE_PACKAGE classes and sends to the server and gets OK or ERR packages.
That’s all. We’ve implemented the connection phase. To avoid making this article too long I will not explain the command phase. Because the command phase is easier than the connection phase. You can research it yourself with the knowledge you’ve accumulated from this and previous articles.
Demo Video:

By Oct 9, 2020

Ashu Garg is Bullish On Boundaryless Teams as the Future of Work

Ashu is equally bullish on the role that remote, distributed teams will play in the future of work. Join us and learn why Ashu likens the Bay Area today to Florence during the renaissance, why the world is flat, and why the companies he believes in incorporate boundaryless teams in their plan from the start.

In today’s episode of our podcast, we meet Ashu Garg, General Partner at Foundation Capital.

Ashu loves puzzles and making bold predictions, including the prediction he made in 1998 that the IT Services Industry would grow by 100x in the next ten years. A decade on, that projection proved prescient.

Today, Ashu is equally bullish on the role that remote, distributed teams will play in the future of work. Join us and learn why Ashu likens the Bay Area today to Florence during the renaissance, why the world is flat, and why the companies he believes in incorporate boundaryless teams in their plan from the start.

By Feb 10, 2020
Two empty chairs set across from one another, kept for the purpose of vetting remote workers
Hiring developers

Vetting Candidates for Remote Work | Turing Hire

What you need to know about a candidate to make a great long-distance hire Hiring remote, global talent is tough. Most of the usual signals you rely on when hiring someone in the US don’t apply. You may not recognize the school a candidate attended. You may never have heard of the companies a candidate… View Article

What you need to know about a candidate to make a great long-distance hire

Hiring remote, global talent is tough. Most of the usual signals you rely on when hiring someone in the US don’t apply. You may not recognize the school a candidate attended. You may never have heard of the companies a candidate has worked for, and you may not have any idea if the people providing references are genuine. You also can’t rely on recruiters because they’re likely dealing with these same problems.

So how do you make sure a remote prospect is up to the task and won’t simply slow you down?

Overcoming sourcing challenges with rigorous vetting

When the usual means of identifying talent are likely to fail you, a new process is needed. At my current company, we’re working to solve this problem. In this article, I’m going to share with you what I’ve learned during hundreds of technical screens. My goal is to help you identify best practices for vetting prospects and making sure your placements are going to be capable of delivering the results you require.

At Turing, we match developers from all over the world with positions at some of the world’s best and most interesting startups. Every time we make a placement, we put our reputation on the line. In other words, we can’t afford to make bad matches.

Since we are unable to rely on typical signals that would allow us to determine if someone is good enough for our clients, we’ve developed a system that provides unbiased feedback about a candidate’s skills in all of the areas critical for their remote-work success.

Core to our approach is a highly structured vetting process that incorporates sophisticated automated testing as well as detailed, in-person technical screening for individuals that have been able to successfully pass our coding examinations.

All of our testing is intended to help determine key facts about the experience, skills, and capabilities of a candidate. What we’re trying to understand through our tests and interviews will help us determine if a person has the skills they claim to have and whether they’re capable of performing basic tasks, managing projects, and people, or even leading entire projects from conception through implementation.

So, at a baseline, we’re trying to determine if someone can contribute to a codebase in a meaningful way. Maybe their skills only support accomplishing scoped, individual tasks. For example, can this person add a button that does x, y, and z on this web page and build it in a way that takes into account the full technical stack of the application?

Or can this person go in and add unit-testing to some kind of already written back-end piece of logic? Generally, can they contribute within an already established structure and do things that won’t upset that structure, if given functional requirements?

Then, there’s a level of complexity beyond that. Can this person take a direction like “Hey, we want this larger-scope feature built?”, and successfully run with it? And can they execute at that level of complexity, something that is going to be composed of many tasks? Can this person, for instance, build a new sign-up flow, or build a new matching algorithm for some sort of matchmaking service? Can they individually make the sorts of principled trade-offs in design and implementation that is inherent to successfully building at that level of complexity requires? Does this person have the sophistication to read between the lines and identify functional requirements implicit in a higher level and more coarse-grained specification?

But most critically, at both the task and feature-based levels, we’re trying to determine if this person will be able to contribute to an already established infrastructure, both technically and procedurally.

Identifying coders, leaders, and project architects

For more senior placements we start getting into higher levels of architectural complexity. Can this person start an entire project from scratch if they’re only given a general direction? If they’re tasked with building and deploying a new Android app that does something novel, can they deliver? Or if a company is expanding their product into a whole new space, can the developer take some rough business ideas and some rough sketches about how the company would like to go about doing this, and then build out a full-stack product, from the UI to the back-end architecture to the design of the database models?

Can they manage the entire process from system architecture design to writing elegant implementations? Do they possess the depth and breadth of experience, as well as just general horsepower, to be skilled enough to implement the MVP from the front-end to the back-end to the database as well as whatever infrastructure they’re going to use to actually deploy the code?

Even vetting somebody in terms of their technical acumen from a general level that seeks to get a signal on someone’s “seniority” is a really complex thing to do. Proper vetting needs to understand whether a person can design systems at a very high level. Can they understand how pieces fit together and how those pieces talk to one another? And then you start getting down into deeper levels of abstraction. Does a candidate understand how this feature fits into the greater scope of the product?

Can they assimilate to use the tools in a particular company? Can then adapt to the cadences and workflows of the team that they’re on, and work with other people to be part of a bigger whole? And then, at the task level, you need to determine if someone has fundamental baseline computer science abilities? Will they build efficient pieces of code? Do they understand notions of runtime and space complexity, and how that might apply to the code that they write, and the specific problems they are being asked to solve?

Are they able to conceptualize how their code will typically be used and how the stuff that they write will actually be run?

But the most critical thing to keep in mind is that it all comes down to code. Code has a dual purpose.  It is going to be executed by a computer, and it’s going to be executed at certain cadences and using certain pieces of data and memory. But it’s also the stuff that people are going to read, and have to maintain.  People will have to go in and either edit or understand what your piece of code is doing in order to write their own piece of code, to modify or extend the functionality of a given application. Designing abstractions and writing codes that can be comprehended by another human is extremely important.

AI versus Human Vetting

It’s almost an overwhelming list of skills that somebody requires to be considered a “good” software engineer. Trying to vet them all in an hour-long phone interview is very difficult. At Turing, we’ve realized that it’s possible to take the human out of it. To a certain extent, at least.

We do have an hour-long technical interview that we use with some of the most skilled developers that we’ve found on our platform, where we validate and extend upon things that we find through automated testing.

The technical interview allows us to screen for things that we find are very, very hard to test for. Of course, we’re interested in their communication capabilities, but we also like to test some technical things in an interview in addition to an automated test.

 Why Both?

During the course of developing Turing’s platform, we found that automated tests are really good for testing someone’s facility with specific technical stacks. For example, with programming languages like JavaScript, or Python or frameworks like React, or Node JS or Laravel, we found that we can test someone’s knowledge of how to use those particular things pretty well in an automated test format.

We can get a really good idea as to whether somebody actually knows a particular framework or whether they speak a particular language. What’s really nice is that we can provide skill-validation to clients who are looking to get somebody up and running with the stack that they’re using as quickly as possible.

We’ve also found that we can automate testing of more general-domain kind of format.

For instance, we can find out if the candidate knows how to build a server. Do they know and understand how a database is going to interact with a server, and how that server might interact with a front-end client? Do they know common design patterns that might be encountered in software engineering, and how those patterns might best be applied?

Is a candidate familiar with the types of algorithms they might encounter in software engineering? Or, given this piece of code in a language that you purport to know, can you tell us what you’d expect to happen if it was run with a certain type of input? We’ve found that those types of questions are really good for the types of automated testing that we currently do.

And we think that we get a pretty good signal on a developer’s mastery of a specific type of coding, say front-end development or back-end systems development, or mobile development or database design.

There’s really good tooling that we’ve built upon, that allows you to run codes in a browser. And this allows us to do things such as automated live coding tests. We can do automated live algorithm testing in this sort of format with a significant degree of success, in terms of being able to test algorithmic correctness and efficiency.

We’re able to test whether or not somebody can write code that fulfills a particular function within a particular amount of time, and with a particular amount of memory. is really excited to expand upon this method and see what further coding-based automated tests can be done.

Where automated testing breaks down

But even in a live coding format, there are holes that we have in terms of our automated tests.

Right now, it’s still very hard to get a computer to tell us what the elegance of somebody’s code is. Or how well it was organized, or how readable it is, or how well abstracted it is.

That’s where I really feel like a technical interview comes in handy. Because then I can present candidates with situations they might encounter during their work and they can walk me through how they’d design the solution to the problem. Doing this during a technical interview can help me understand what a candidate’s thinking is, and what kind of code, organizationally, they’d spit out to approximate a solution. This really helps me get into a prospect’s critical thinking. I can really see how they handle problems with uncertain specifications, how they ask questions about getting required specifications, and more generally a get a clearer idea of what the nature of their programming abstractions and elegance might be.

“Automated testing establishes a bar that filters people out. The in-person interview confirms the testing and tests the candidate on critical things that are currently hard to measure in an automated way.”

In general, what we’ve learned at Turing is that a well-designed and comprehensive automated testing facility is very cost-effective when you need to screen a large number of applicants blind. If I had to do an in-person interview, or even review and background check every candidate that wanted to work with Turing, there wouldn’t be enough hours in the day or enough days in the year.

And as our testing capabilities continue to evolve it makes our ability to find the best candidates and then invest our time where it’s most productive; doing technical screens for the top-tier applicants only.

What to do if you don’t have automated testing

In my next post, I’ll talk a bit about what you can do if you don’t have an automated testing facility. I’ll also dig into the way you can make the onboarding process simpler, and how you can spot early signs that a remote hire is struggling or even failing. Stay tuned!

You can read more on the best practices to keep in mind while hiring remote talent by clicking here.

By Feb 5, 2020
Doors that can lead to more opportunities for Remote Developers
Hiring developers

How to Become a Remote Developer | Turing Jobs

My goal with this post is to tell you how to prepare yourself to get your first serious remote gig.

Are you thinking of becoming a remote developer and working for a leading company – hopefully, one based in Silicon Valley – but you don’t live in the US and haven’t been able to secure a visa? Don’t despair. More and more of the latest Valley startups have discovered that there’s a ton of talent offshore. This means that today might just be the best time in history to become a remote developer.

As someone who’s been working remotely for about as long as it’s been possible, my goal with this post is to tell you how to prepare yourself to get your first serious remote gig. Today, I work for a company called that places developers with opportunities all over the globe. We have some of the most advanced developer testing and vetting of any company globally. What I’m about to share with you are vital insights I’ve developed first, as a person that’s gone through Turing’s testing and vetting process as well as someone that now works on making that process even more challenging and better.

But first, let’s answer some of those burning questions you may have about software development and working remotely.

What is a remote software developer?

A remote software developer carries out the same tasks and duties that a non-remote software developer would. He or she surveys a particular customer’s unique needs and then builds, tests, and improves upon software to help meet those needs. The most notable difference between the two is that a remote software engineer performs their duties from the comfort of their own home, while a non-remote developer does so from an office. 

Given the remote nature of their job, it’s typical for such developers to face little to no micro-management and hand-holding in their day-to-day tasks. Going remote also gives developers another important perk: more control over how they spend valuable time. Since this eliminates their daily commute to and fro work, developers can spend their free time as they see fit.

Can you work remotely as a software developer?

Yes! Software development is a highly flexible career choice. To work remotely as a software developer, all you’d need is a high-speed internet connection and a decent computer or laptop. Today, more programmers are working from home than ever before. A recent Stack Overflow survey revealed that nearly half of the participating developers worked remotely at least partly. A majority of these developers were regular, full-time employees.

Undoubtedly, remote working is becoming increasingly popular among software developers because of its many perks. Remote work opens up a world of possibilities for developers, including better salaries than local standards, less commuting time, and a healthier work-life balance. 

How much do remote developers make?

It’s no secret that remote workers often make more than non-remote workers do. In general, remote employees earn 7.5% more than non-remote employees who have the same amount of experience and perform the same job. Further, an uncontrolled group study found that remote workers in the technical field earn 39.4% more than non-remote workers, while a controlled study found that they make 3.1% more. 

Is it hard to get a remote programming job?

Getting a remote programming job is decidedly not easy. But, fortunately for developers, in today’s day and age, opportunities are opening up by the dozen. Web development, for instance, ranked in the top 15 on FlexJobs’ list of the most common remote roles. Engineering as a whole ranked 2nd. It’s clear, then, that remote programmers are in demand.

Additionally, platforms like Turing are now making it simpler for developers to find the best remote programming jobs. For instance, developers can score Turing jobs that are full-time and long-term. After you’ve completed your long-term engagement with a customer, Turing seamlessly rematches you with another company. Once you become a Turing developer, you never have to apply for another job again.

Are coding jobs stressful? 

Coding jobs are as stressful as any job. But the bottom line is, they don’t have to be. Working remotely as a coder could reduce stress levels by a great deal. Studies have demonstrated that remote work (or flexible work) lowers levels of work-related stress and helps employees prioritize their health and wellness. What’s more, it also helps boost morale among workers! 

Which coding skills should I have on my resume? 

If you’re looking to grow your skill-set, take inspiration from the list of most popular Turing software jobs to learn what companies are looking and hiring for. React-based developer jobs top the list of the most in-demand roles, followed closely by Python jobs. Roles that require developers with a firm grasp of React and Node are also particularly popular. Ruby on Rails, iOS/Swift, and Java jobs round off the top 6 most wanted skills. 

Is coding still relevant in 2025?

Yes! In 2020, even during a global pandemic, the worldwide software developer population continued to grow by a staggering 500,000, reaching a total of 24.5 million! If current trends are anything to go by, coding will remain a popular and relevant role in 2025 and beyond. The Bureau of Labor Statistics has forecasted a 30.7% growth in employment for software developers in the US between 2016 and 2026. This translates into 255,400 jobs opening up in the US alone. 

How do I get a job as a remote developer?

Like I mentioned earlier, scoring a job as a remote developer is getting simpler by the minute. Through, Silicon Valley and US-based companies hire for several remote roles. While only the top 1% of developers make it past Turing’s Silicon Valley-rivalling vetting process, there are ways you can dramatically increase your chances of becoming a Turing remote developer. I outline some of them below. 

First Things First, Be Prepared to Show Your Work

If you’re a developer applying right now, make sure that you’ve got a portfolio of some work you’ve done before. It could be code you’ve submitted to GitHub. It could be some art design work. Perhaps some websites you’ve developed or applications on the App Store.

Being able to showcase completed work is an excellent thing. When evaluating candidates who have passed our tests, we look at prior work. Additionally, many Turing customers want to see examples of the work a potential match has completed. 

The other thing that can help you stand out is a good CV. But be careful! Attention to detail is critical. Ensure there are no errors in any documents you share to showcase your skill. Nothing will shoot you in the foot the way an obvious mistake can. Believe me; I’ve seen so many people with errors in their CVs. To me, it’s a red flag if someone submits such an essential document with mistakes. It says you’re careless and don’t take the time to check your work. So, no errors on CVs!

It’s also essential to have relevant information included in your portfolio. If you say that you have a particular skill, make sure that there’s a related project where you have actually used that skill. You’d be surprised at how often someone will say they are proficient at coding in a particular language but then don’t provide a single example of their work in that discipline. If you say you’re good at something, impress me by showing me a sample of your great work!

Another critical skill for someone who wants to work for a high-profile US company remotely is strong English. I know many people are not native English speakers, so it’s always good to make sure that your English is concise. If this is a weakness, don’t ignore it. Do whatever it takes to make sure that you understand English very well and that you’re proficient in communicating in English, too. It’s the language your team is going to use, it’s the language you’ll be using to comment your code, and it’s probably the language of the people that will be using the product you want to help build. It’s easy to think people will overlook weak English skills. Still, if two candidates have the same experience and have performed equally well on the automated tests, the one with better English skills will perform more strongly in a live technical screening.

How to Ace Your Automated Testing

The key to an excellent performance on automated testing is to be very well prepared.

Ensure, for example, that if your area of expertise is Python, you have prepared yourself in terms of the coverage of the topics in Python.

Be sure you’re prepared to cover that language end to end because the questions will try to test your coverage. The exam will cover your in-depth knowledge as well. If it’s algorithms and data structures you work on, be sure you know everything from the most basic concepts to graphing algorithms and runtime complexity.

How Long Turing’s Automated Testing Should Take a Skilled Developer

For a skilled individual, I estimate that our current automated testing will take about eight hours. So, maybe a day. But of course, you may not want to put all that pressure on yourself to finish everything in one day. My recommendation is to allocate two hours per day and give yourself roughly a week to do just about all the MCQs in the qualifying exams.

Technical Exams – Where You’ll Sink or Swim

Just like with the automated MCQs, your performance during the technical Turing interview will come down to how well you’ve prepared yourself. During a technical screen, we want to understand your in-depth knowledge. We also try to validate your performance on the MCQs and understand if you have good working knowledge of design patterns.

You must know everything from the basics to some really advanced techniques for whatever programming language you use. And since we only pass the top 1% of developers, you need to be prepared to talk about the projects you’ve worked on in a bit of detail.

You also need to be able to answer system design questions. System design questions are essential for a screener to understand how you are able to visualize a product from an architectural point of view. You should also be able to go deeper, all the way to the code, and even up to how you’ll deploy the project. So, you need to be prepared to discuss end-to-end software development.

For example, if you are a Python Django developer, you should be prepared to answer any questions relating to that language in depth. It’s also good if you’re capable of answering questions about system design and planning.

Where Developers Get Tripped Up in the Technical Screen

During a technical screening, most people are not prepared to go into detail on algorithms and data structures. Again, it comes back to preparation. We often have people complain that they don’t need to know this stuff for the work they do but being competent with both algorithms and data structures is very important for high-level work. Another thing I see a lot of candidates struggle with is when we ask them to explain various concepts in English. I’ll emphasize again, having strong English communication skills is vital to ensure placement with top-tier US opportunities.

Final Words of Advice

To wrap up this post, I want to emphasize a couple of the key points I’ve made above. In Silicon Valley, it’s very competitive to find good work. If you’re trying to get into this market as a remote engineer, you have to be truly exceptional. The Turing developer tests are designed to filter out all but the best candidates.

If you’re serious about securing one of these most in-demand positions, my advice is as follows:

  • Preparation is critical. If you have a weakness, work to improve it
  • Don’t underestimate the importance of understanding algorithms and data structures because if you do, you’ll fail the MCQs or the technical screen
  • Make sure your ability to communicate in English is up to the task. If it’s not, take action to improve it
  • Be sure to have a portfolio that includes projects related to the languages you claim to know
  • Polish your CV. Scrub it of mistakes because if you don’t, we’ll notice them and that will hurt your chances

Next Time

In my next post, I’ll be talking about what you should expect once you’ve passed the MCQ and technical screens, how candidates are matched with opportunities, and what you should do to ensure that your onboarding process goes as smoothly and quickly as possible.


By Feb 5, 2020

The #Boundaryless Remote Distributed Teams Podcast with Murray Newlands:

In today’s episode of our podcast, we meet Jonathan Siddharth, CEO and Co-Founder of Turing. Jonathan built his last successful company, Rover, using remote, distributed teams. His new company, Turing, is based upon the idea that talent is global, while opportunities are not. Please tune in to discover how to hire remote employees and what it takes to build your company with a fully distributed team.

The #Boundaryless Remote Distributed Teams Podcast with Murray Newlands:

In today’s episode of our podcast, we meet Jonathan Siddharth, CEO and Co-Founder of Turing. Jonathan built his last successful company, Rover, using remote, distributed teams. His new company, Turing, is based upon the idea that talent is global, while opportunities are not. Please tune in to discover how to hire remote employees and what it takes to build your company with a fully distributed team.

About the Boundaryless Remote Distributed Teams Podcast:

The world has changed. In the past, companies were built with locally-hired teams, operating out of the same office. But today, entrenched competition, brutal commutes, exorbitant real-estate prices and more global distribution of talent have upended this practice. Now, billion-dollar companies are now created with teams working remotely and distributed all around the world. Creating #boundaryless companies is hard but we will give you the tools to succeed.

By Feb 4, 2020
Tweet: Women in the Gig Economy on Remote-Employees

A 7-Point Checklist for Remote-Employee Success in 2020 | Turing Remote Culture

  How does one ensure Remote-Employee success? Forbes contributor Diane Mulcahy recently interviewed Krystal Hicks on the topic of “Why Companies Don’t Trust their Employees.” (Krystal Hicks is the founder of JOBTALK – a resource for career-curious professionals throughout every phase of their journey.) When I read Krystal’s observations in this article/interview, it occurred to me… View Article


How does one ensure Remote-Employee success?

Forbes contributor Diane Mulcahy recently interviewed Krystal Hicks on the topic of “Why Companies Don’t Trust their Employees.” (Krystal Hicks is the founder of JOBTALK – a resource for career-curious professionals throughout every phase of their journey.)

When I read Krystal’s observations in this article/interview, it occurred to me that they were so good, they could easily serve as a Checklist for 2020 Remote-Employee Success.

So I decided to organize them into that list! Here are some highlights from the interview, along with my added seven checklist points (in bold headers.)

1. Do You Trust your People?

Diane Mulcahy asked Krystal why so many companies are slow to implement remote or flexible work policies. Krystal’s response? “It’s trust. There’s no trust. And the mistrust stems from leadership.”

To quote Krystal further,

“Companies that are attracting incredible talent demonstrate that they trust their employees. They provide people with a choice about where to work, and the tools, like video conferencing, to make sure that they’re successful… Trust is the new currency, and the best talent wants to work for a company that trusts them.” 

2. Do You Measure Productivity Effectively? 

Krystal told a story about a client of hers who was concerned that remote workers wouldn’t work as hard if they were unsupervised. Her response to this fear is excellent:

“The real question for companies and leaders considering remote work policies is: How do you measure productivity when employees are at their desks in front of you? And if you do not measure them in the office, then it’s difficult to assume that people are going to be less productive at home. Companies need to figure out how they can implement metrics to measure productivity for everyone, no matter where they are working.”

3. Do You Have The Right People Managing Your Remote Teams?

“The Achilles heel of most organizations is promoting the wrong people into people management roles,” Krystal said.

“I think we have this epidemic of people who were great producers who received promotions into management, and they are terrible managers. There was an assumption made that because they were a great performer, that they would be a great people manager. And I think those are two starkly different things. And I’ve seen it be such a devastating move at so many of the clients that I’ve worked with because bad managers will chase out great employees.”

4. Have You Shifted from Blockbuster to Netflix?

 Diane Mulcahy asked Krystal what she means when she uses the term Managerial Darwinism. Krystal explained that what she’s saying is “adapting or dying. It is the understanding that there is Blockbuster and there is Netflix – you have a choice about which one you’ll be.”

5. Do You Accept That You Have Less Power/Control Over Employees Than You Used To?

 “Employers have less power because they no longer have the same level of control over their employees. Most importantly, they don’t own the financial future of their employees anymore. More employees have side gigs and no longer rely on their employers for 100% of their income. They’re earning money outside their full-time job, and that changes the power dynamic.”

6. Do You Hold Retention Interviews?

According to Krystal,

“I’ve heard of a lot of people say that they do exit interviews, but I believe there is such good information in retention interviews, where you talk to people that have been at the company for 3, 5, and 10 years and learn: What has kept them? Companies have amazing employees that they are not leveraging as a source of information.”

7. Do You Budget for Consultants? 

Krystal has observed that companies are thinking about consultants differently.

“They’ve either already had success working with a consultant, or they hear about other companies that have had a good experience, or they’re watching their high-performing employees leave to become independent consultants. Companies are realizing and recognizing that consultants are a reliable source of talent.

I’m also now seeing companies start to budget for consultants, which is a significant shift, and a strong indicator of demand, because when a company has a budget, they’re going to spend it.”

One more quote from Krystal Hicks helps conclude our checklist:

“The stakes are high for companies to figure out remote work because employees are really demanding it.”

By Dec 6, 2019