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.
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.
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.
By Soo Somerset, Green Mars CEO
Let’s get something out of the way right now: yes, I am writing an article — as the CEO of a US-based software engineering firm — about how to get the best results from an offshore team. That’s not a mistake.
Offshore engineering has its place: where there are projects and interfaces that play a relatively harmless role in the success of your business, they are an obvious choice. However, allow me to begin with a few words of caution:
There are significant drawbacks that balance out the cost savings of hiring offshore:
Enough cautions, let’s get down to details on how to make it work:
If you feel that the above is daunting to ensure success, and you’re not willing to put that energy into it, that’s up to you, of course, but you should be aware of the risks and potential outcomes. I was able to successfully work with offshore teams when I was a project manager at Cisco Systems back in the day, and it was a full-time job to put together the documentation and communicate with the team. I’ve also watched many clients and colleagues in my business consulting years go on to lose hundreds of thousands of dollars to offshore engineering firms when they didn’t take the time to thoughtfully consider their potential engagement, which was tragic.
Of course, if you would like a second opinion on your software project, consider Green Mars as a trustworthy resource for perspective on the total cost of ownership and quality of your solution. We’d be glad to hear about your plans and support your success!
By Soo Somerset, Green Mars CEO
Which comes first: the search for an engineering firm or the need for one? Usually, it’s the need that prompts the search. As a result, there is a mad dash to find a suitable engineering team to start work as soon as possible, and this approach can lead to hasty decisions from limited options.
As an alternative, one could begin the search for the right engineering firm even before the need arises. This may seem counter-intuitive, since the basis of an initial conversation with a engineering firm is usually about project requirements.
Green Mars takes a different approach, forming connections and relationships that may be supportive from a distance for months (or sometimes years) before an engagement is appropriate. This was the natural result of working exclusively with startups, where the chaos of budget and deadlines can make for a bumpy roadmap.
Do you already know which engineering firm you would use if a need were to arise? You may want to work with them to develop a simple roadmap for the foreseeable future. Odds are good that they would be happy to support you and having some visibility into your plans, even in the somewhat distant future, can help calibrate expectations and still allow flexibility when change is needed.
If you are goal-oriented, these connections with your engineering vendor partner can act as a touchstone for accountability and clarify your company objectives so you’ll be ready for an engagement. And when you find yourself mired in the chaotic nature of the startup environment, they can provide a beacon to help you stay on course to your overall objectives.
Perhaps the best part of knowing your engineering firm before you hire them is the trust you develop: that when you need to move, you can move quickly and with confidence that you’re in good hands.
If you do not know who you would hire for your next software project, and you feel it likely that you’ll need one in the next six months to a year, I encourage you to ask around and see if you can find a firm that matches your potential needs and get to know more about them. In that case, I hope you will include Green Mars in your list of possibilities for full-stack software engineering. We would love to help you succeed!