by Soo Somerset, Green Mars CEO
The advent of COVID-19 and social distancing, coupled with many states implementing Shelter in Place orders, means a lot of folks will be working from home. If managing a team remotely is new to you, you might feel some trepidation around how to do it well. As the CEO of Green Mars Consulting, a fully distributed software engineering consulting firm, I thought it might be useful to share some of the lessons I live by when managing our remote team.
Nothing Replaces the Impact of Voice Contact
Our online, text-based, communication tools are life-savers, but they cannot accomplish what a 5 minute phone call can do. Each week, I host 15 minute conversations with every member of my team where we cover a short set of topics. We do a general check-in, review their schedule/availability, discuss their workload, and examine any issues they’re facing. I give them an update on what I know, answer any questions they have, and schedule working sessions to deal with any concerns that came up in our call.
I learn so much from my team in these weekly check-ins. The trust we build together through these conversations means that when things are intense (as they are currently), the team remains steady and focused on getting the job done.
Shine the Spotlight on Priorities and Expectations
Your priorities and expectations should be as clear as you can make them. Write them out in detail, set up a slide deck, keep the timeframe short (1–2 weeks), and review them with your team.
We utilize “user stories,” not just to specify our software requirements, but also when we make requests of each other for more information. For example, compare the difference between:
“Bob, can you send me the progress report for the team from last week?”
“Bob, I need the progress report from last week by team member by the end of Tuesday so that I can compare it against the project schedule and check in with folks who are falling behind.”
The detail I give Bob in the second example helps him understand not just what I need, but why I need it and how I’ll use it, making it far easier for him to assemble the information I need in an accessible way.
Focus on the Output, Not the Hours
This may be the hardest part of a transition to working from home: your focus must shift to progress, not hours. You can’t know for certain how many hours a person is working, but you can review their deliverables and check progress on tangible work. Even for research tasks or less concrete work, you can request, given the new paradigm, that the team member write up their notes, lessons learned, findings, etc., for the time spent on these actions. Let them know ahead of time that you will want to review these artifacts with them because of your limited ability to support them in person.
Be cautious in your framing here: you don’t want to suggest that they detail every step as an opportunity for scrutiny. Instead, work with them to cultivate a format or framework that encourages constructive communication.
Trust, but Verify
You must trust your team to do their job and do it well. For some of us, that’s easy, but for others, it’s a frightening prospect. Trust is crucial in a fully distributed team. Your confidence will foster engagement within your team and help them completely own their responsibility to you and to the rest of the team.
That said, an innocent miscommunication can send even the most trustworthy team in the wrong direction, so be sure you are verifying their progress at reasonable intervals. Once or twice a week should do it. Sometimes biweekly is frequent enough, depending on your team. This verification, such as an informal demo or a document review, gives your team a chance to show off their work and cover any issues that have surfaced, along with their plans to address them. Verification gives the work a sense of immediacy that might be lost in a longer-term project.
Ask the Hard Questions
Working from home full time can be a difficult transition for workers: time management, juggling priorities, and clear communication are all easier when you’re in the office. This is where management becomes, I think, the most critically different from in-house approaches. If you have a team member who is struggling, ask them how you can help. Don’t pretend there isn’t a problem. Instead, talk about the indicators you see that point to a issue and collaborate with that team member to come up with options to solve it.
This transition is going to test your team, your systems, your processes, and your patience. Keep your sense of humor, as much as you can. Never stop believing that your team is doing their best, and reassure them that anything that prevents them from meeting the needs of the company is a problem you can solve together.
Tech startups hire the best engineers in their field to build a transformative solution and deliver powerful change to their market. With more advanced technologies, the experts are often highly specialized for their technical niche. The value of having those experts on the payroll is immeasurable — they advance the technology for your customers, build scalable, elegant solutions, and solve problems and challenges that make your product unbeatable in the industry. Yet, this focus can introduce a challenge when needs arise for skills that are not directly related to that core technology.
Just as traditional manufacturers rely on distributors, many startups with core technologies in machine learning, fintech, biomedical devices, or IoT hardware need specialized software to reliably deliver their value to their users. Medical software requires diligent requirements and verification testing for FDA approval, intricate user interfaces need automated testing or continuous integration testing to make quality more efficient, and, of course, everyone is concerned about data security in their cloud solutions. This aspect of the startup’s solution rarely involves the “secret sauce”, but requires substantial expertise to implement with efficiency, reliability, and scalability.
More and more, startup founders and decision makers are engaging trusted vendor partners to offload the technical requirements that fall outside their core technology, where, for example, the setup and maintenance of a secure, reliable AWS cloud platform, the design and development of an intuitive, extensible UI/UX built in ReactJS, or the establishment of an automated front end test harness in Selenium, can be delivered and supported while your company grows through its most critical early years.
Green Mars has built a dedicated team of software and devops engineers, QA engineers, technical analysts and project managers for the purpose of supporting startups who have need of cloud, UI/UX or testing solutions that support and proffer their core technology. Our team works with yours, as a flexible extension of resources, and our project managers ensure that budgets and expectations are met and managed.
We attract solid engineering talent: passionate about reliable, maintainable, and effective software, and, as part of a consulting firm, they never run out of opportunities to build and support stable and secure platforms or to develop powerful interfaces that promote the value of our client’s core technology. Our team collaborates with each other and with our clients, building relationships and understanding priorities and caveats, an integral engagement that is rarely seen in other consulting models.
This is why Green Mars exists: so that startups can invest in their core technology, confident that we are filling the gaps in the technical stack while they grow.
Want to learn more about why companies outsource? You make like our article Top 5 Reasons to Outsource Software Engineering.
By Soo Somerset, Green Mars CEO
We hear this a lot as we get to know our clients: “We’ve had bad experiences with outsourced engineering in the past.” We learn that so much can and does go wrong with the work of outsourced engineering that it’s hard to have faith that it’s worth the effort to delegate.
It usually turns out that a lack of communication and transparency is at fault. This challenge is a hard one to solve, in that it requires diligence from both sides to work: the vendor must be proactive about progress and any issues that arise, and the client must be inquisitive and collaborative to find solutions. This is generally true of any vendor relationship, but especially so in software.
What can a client do to minimize the risk of an outsourced engagement? There are a few key steps to take from the outset:
Schedule and attend regular check-in meetings
There may be no other element of a vendor/client engagement that is more critical to the success of any project than the periodic check-in meeting. They are often small, simple meetings that can take fewer than 15 minutes, but I make a point never to miss a meeting with clients or vendors, and in the rare cases that I must, I prioritize the next one above everything else.
In these meetings, we communicate more than what is actually discussed in the course of the agenda — a commitment and a priority for the work being done, the value of that work to our success, and the importance of clarity and transparency with our vendors and clients.
When vendor meetings are missed, or routinely cancelled, it says to the vendor that you don’t care what they’re doing — that you trust them, perhaps, but also that they are on their own to resolve any issues. In the worst case, the vendor makes a long series of decisions about your engagement that may not align with your expectations, and this naturally results in some pretty nasty surprises on both sides.
When client meetings are missed, it communicates that we are not organized enough to communicate our progress, that we may be hiding something minor or major, or that we are not prepared to allow the client to help support the work and necessary decisions that need to be made in the course of its progress. By missing these opportunities, we create an atmosphere of mystery and suspense, which is obviously not what one looks for in a client/vendor relationship.
Set expectations to see two-week plans
Any seasoned project manager can tell you that a project plan beyond the next two weeks is progressively more likely to be fiction. Therefore, beyond the initial “reality check” that the work as estimated can fit in the overall timeline, the most important information about a project is what is happening right now, and in the next two weeks.
A two-week plan may or may not involve a “release” — and there is a whole philosophy of project management devoted to such “sprints” — but regardless of the labels and nomenclature, any vendor should be able to articulate what is planned to happen in the next two weeks, and allow the client the opportunity to ask questions, understand objectives, and clarify priorities to avoid misdirection.
In some cases, an engagement is quite fast-paced, and a strong vendor company will help triage and plan as far as the pacing will allow. These scenarios call for more transparency, clearer engagement processes, and quick response times, but still lend themselves to a rough plan.
The plan itself sends a message of set expectations from both sides of the engagement. For the client, it clarifies what to expect and hopefully identifies areas of high risk to the budget or schedule. It also makes clear to the vendor and its team what the client considers the highest priority. The focus stays on the work for that period, and as issues arise, or risks are identified, the client can support the vendor to mitigate.
Even in cases where the client prefers to be hands-off, the plan provides a sense of protection for both parties in preventing surprises. Without it, confusion, frustration, and disappointment can lead to contractual debates and long-term damage to the relationship between client and vendor.
Establish Balanced Communication
I have a friend who seems to only call me when they’re in trouble. I dread seeing their name pop up on my phone, because I know it’s going to be bad news, and it almost always is. However, when I have more regular contact with people, that emotional response doesn’t happen. The balance of good and bad news prevents any anxiety.
The same holds true for client/vendor engagements. The check-in meetings must cover positive (progress), negative (issues) and neutral (plans), establishing a steady balance of communication and reinforcing the importance of transparency.
This balance is harder than it looks, because when problems arise, it becomes more challenging to maintain open communication. If an error was made by the vendor, the client is justifiably unhappy about it, yet avoiding mention of the error undermines trust and confidence between them. It is important for the client to be open to bad news and respond with constructive efforts to resolve the problems, rather than expressing their anger with the vendor. This is easier to do for the client when the vendor has been clear about progress and efforts all along, and harder when the client only ever hears about problems.
Likewise, the vendor can more readily give the information the client needs if they have confidence that the client will support them to resolve it rather than to assign blame and react emotionally. When both client and vendor trust that news, good and bad, will be managed collaboratively, you can be confident that surprises will be few and progress will be expedient.
Perhaps most importantly, if you are considering an engagement with outsourced team or you already have one, we encourage you to have a candid conversation with them about your concerns, your expectations, and your priorities, and listen to what they have to say in response. Likewise, if you are a vendor, please do the same with your clients. The discussion will reveal valuable insights and bear fruit that will fortify your relationship for a long time.
Still on the fence about outsourcing? You may be interested in our top 5 reasons to outsource article.
Let us know if this resonates with you, and share your experiences in a comment!
By Soo Somerset, Green Mars CEO
It’s not uncommon for a small company to have a “one person software engineering team”, where a single full-stack engineer writes and supports all the software for the company’s main technology. The advantages of a single in-house engineer include having someone on hand to participate in discussions about requirements, address bugs quickly, develop product knowledge, and generally be dedicated to solving problems for the company. However, there can be drawbacks as well.
We often see this scenario: An engineer gives their notice, and the state of the software falls into chaos (through no fault of anyone involved). When that engineer transitions out, the disruption can mean major costs to the company, both in terms of lost time and resources, especially if the departure is poorly timed or quite sudden.
Faster Development, Lesser Maintainability
As a single engineer, one writes code in one’s own style and without the expectation to work with other engineers. The individual who wrote the code will most likely be the one to fix it. This permits much faster development, and the process, to be honest, is more satisfying for a developer — to write code without the encumbrance of design, coding standards, or (though rarely admitted) thorough testing.
Coding in Isolation
There is also the challenge of “delicate” code (a.k.a. “kluge”, “spaghetti”, etc.), where the solution works, but it’s been written in a way that is ultimately not maintainable by human hands. This occurs when engineers must find a way to solve a complex problem without the benefit of collaborating on ideas, and what results can be, well, a bit of a mess, but at least it works. Then, as features grow and usage builds, this code can become part of the foundation of the platform and create issues later on, whether or not the engineer is still working there.
In short, while there are a lot of good reasons to have a one-person engineering team, those reasons come with significant risks.
Lending a Hand
At Green Mars, we have supported many clients who have called after their consultant or their one engineering resource has had to suddenly leave (for any reason) and they are stuck in the void left by their resource. These are considered “Projects in Crisis”, and we have crafted a solid solution to serve those clients.
However, we also realize an opportunity for clients to evade that void altogether, and that is by prudent use of outsourced support — what we call “auxiliary support”, which provides a lightweight, cost-effective framework to team up with the resource and keep them in the right mindset for maintainable software.
What is Auxiliary Support?
Auxiliary support starts with code reviews. Our engineering team uses coding standards that are intended to promote maintainable code. Our practice of code reviews is focused on clarity and constructive feedback to encourage engineers to see the benefits of our standards. They are commonplace in our company as part of our work.
Design review is another feature of auxiliary support, where your engineer can bounce ideas, make sure they’ve addressed the whole problem, and considered details that could have been overlooked. With the objectives of the software held firmly top of mind, design support is about asking good questions and supporting strong documentation in preparation for testing.
Another aspect of auxiliary support is quality assurance (QA) testing. Our team tests the connected areas of the software to ensure that the changes have not disrupted functionality elsewhere in the code. Having outside resources objectively test your code and return clear steps to reproduce bugs confirms your software on two levels: first, that your requirements are clear and accurate enough to be tested, and second, that the functionality works as the requirements expected, all without taking up valuable resources in your own team.
As much as I love a good engineer, time management is rarely among their best strengths, which means that they are often over-committed and running behind schedule, and nearly always with the best intentions. This is a sign that project management as an auxiliary service may help a great deal, to assist in organizing the engineer’s workload and priorities, and support the consistency of their work.
Over all, auxiliary services in these forms make your engineer better at their work, more efficient, more reliable on deadlines, and more satisfied in their job. The collaborative nature of these services makes the role more fulfilling, and with added accountability, the software quality benefits.
But what does this service cost? Well, that depends on you — we recommend about 3–5 hours per week of support of this kind, maybe a little more for additional testing if a big release is coming up. It could be as little as 10–15% of the engineer’s salary. That’s a lot of value for the cost.
Then there is the perception of the “hassle” to bring in another team to support your engineer — it would slow down work, not to mention trying to coordinate time to make it happen. But we think you’ll agree, there’s a lot of benefit in slowing down just enough to produce quality work, then once that rhythm is established, efficiency goes up.
Finally, even if the above concerns aren’t relevant, you may think this may be a good idea for “later”, because there’s just so much going on right now. To this, we offer a simple response: all things being equal, it will never be easier to do this than right now, because the future will just get busier.
Still on the fence? You might find our top 5 reasons to outsource article helpful as well.
If these services sound like they’d be of value to you, please get in contact with us. We’d love to help support your team!
By Soo Somerset, Green Mars CEO
Full disclosure: I have been a “one-woman-show” consultant, and so I speak with some experience from both sides of this particular fence.
Once upon a time, there was an engineer named Chris. Chris was a very smart and resourceful engineer, who knew the full stack and wrote exquisite code. Chris was hired by companies all across the land to create inventive, reliable software solutions and deliver right on schedule.
It’s the dream, isn’t it? That we can each find a Chris to come and work with us — but the reality is often a bit more disappointing. The code has more bugs than we had hoped for, or did not quite meet the original specifications. The delivery was late, maybe very late, without much notice.
In truth, it’s nigh impossible for one person to be excellent at everything where software engineering is concerned. Part of what makes it difficult is the genuinely chaotic nature of software. In the simplest of systems, inputs and outputs and states can be clearly anticipated, but as the systems combine and become more and more complex, testing one’s own code becomes an exercise in trying to successfully second guess oneself.
It is a common trait for an engineer to envision a solution almost immediately upon understanding the problem, but it’s far less common that that engineer can accurately anticipate the time required to complete the work. This is because it is not only difficult to predict with precision how long it will take to write the code, but nearly impossible to know how long will be needed to test and debug it. It is infuriatingly reliable that the testing and debugging stages are the wildcards for any project.
There are many talented resources who describe themselves as ‘full-stack engineers’, though in my experience, that means they can expertly design and develop in one part of the stack, and are merely willing to work in the others. This works out great for the right clients, but not for those that need both UX design and architecture in highly-regulated industries.
Take biotech, for example. At Green Mars, many of our clients are biotech startups, where their users are doctors who need highly intuitive screen design, but their IT support demands the rigor of HIPAA compliance. These clients hire us because we can offer the best of both worlds on a reasonable budget.
This is not intended as a knock against one-man-show independent consultants — they are out there, and they might be right for you, but, as with most things, they are not perfect for every case. A good consultant knows their own strengths; a great consultant knows their own weaknesses.
A simpler solution may be to hire a small group of highly talented resources on a managed part-time basis, where everyone can contribute their strengths to a collaborative solution. This is the approach that we have taken at Green Mars to serve our clients, and we’d love to hear from you to discuss your next project.
Still on the fence about outsourcing? You may be interested in our top 5 reasons to outsource article.