Our Technical Vision and Objectives for 2017

Business man at the starting line
A long stretch of technical evolution and a large volume of client solutions shipped in a year.
That is the conclusion I came to when reflecting on the state of Mercury app dev at the end of 2016. The specific things that came to mind were:

  • We embraced the new JavaScript-driven method of developing modern applications
  • We moved to a continuous delivery/DevOps-driven method of shipping software
  • We significantly evolved and modernized our interface construction techniques
  • We incorporated native mobile development into our service offerings
  • We shipped over 50 production applications for clients (and a couple for ourselves)

For the technical leader of a custom app dev firm, that’s a pretty major year. After I got done patting the team on the back because of my newfound perspective on their accomplishments, I realized that a period of digestion was in order. Biting off more new technology was tempting but in the end I decided to go easy on that front – after all, rapid learning and growth is one thing but burnout is another.

My senior staff and I felt that 2017 was the year for us to mature how we build applications, ratchet up our focus on quality and overall become more masterful with our new skills; by early 2017 we had put together a top-level vision along with specific objectives to realize that vision.

In this blog post I intend to share that vision and associated objectives to spark a conversation with other technical leaders and perhaps provide some nuggets of guidance for other leaders of technically-oriented professional service firms (you know, people who build software for end customers not inside their own company).

Vision

“Reliably ship quality software that fulfills employees while delivering value greater than its cost”

While worded as economically as possible (without losing meaning) each component of that vision statement delivers a lot of meaning for us. Let’s unpack that a bit:

  • Reliably ship quality software
    In this case, “Reliably” is a bit overloaded – it denotes the need to not only perform dependably, it also means we need to do it across all of our clients and all of their applications. The “ship” brings home the point that committing good code is not enough – we must be able to build, test and deploy that code with just as much alacrity as we code. And the “quality software” clause says we aren’t just pushing out any old thing, we will focus on delivering software that is of value to our clients, is sophisticated code, has an excellent interface and low technical debt.
  • that fulfills employees
    There’s a name for companies that focus on software volume at the expense of employee welfare: “sweat shops”. At Mercury we recognize that only fulfilled employees are going to be motivated to build quality solutions and go the extra mile to do more than just what the client/user asked for. We want the right environment where team members add innovative touches and go beyond client commitments as a matter of course. Therefore, our Vision statement embraces the fact that our work is rewarding and fulfilling to each team member.
  • while delivering value greater than its cost
    In business terms this portion of the vision could be interpreted as “be the low-cost provider” – that is absolutely not the case. We are well aware that there are any number of off-shore and lower-end firms that are willing to build websites and simple applications for a low fixed price; Mercury’s mission is to build premium and complex enterprise applications. This aspect of our vision recognizes the fact that if we don’t provide at least $1.25 for every $1 of client spend, we will not deserve to be their premium partner.

Objectives to Meet the Vision

Mission, Motivation, Objectives word collage

As a follow-up to our carved-out 2017 vision, my entire staff spent time authoring and debating the right objectives to get us from here to there. The team came up with A LOT of material and we commenced to whittle, refine and whittle some more to get to a set of objectives that encapsulated what we really need to focus on. While we agreed that we need to stay on our game that has been successful to date, we need to focus on the following objectives in 2017:

  • Establish base-level proficiency with vanilla JavaScript
  • Unify code approaches and continuous delivery
  • Improve initial product quality
  • Improve ongoing quality of key applications
  • Improve health of Agile planning and sprint activity
  • Provide creative and enjoyable outlets for employees

Establish Base-Level Proficiency with Vanilla JavaScript

Anyone in our industry knows that as a language and ecosystem, JavaScript has begun to dominate strategies, technical direction and developer headspace in the last two years. From the ascendance of JavaScript frameworks like Angular and React to back-end service development in Node to JavaScript-adjacent build tools like Gulp and document databases like Mongo, JavaScript has staked its claim to development mindshare and in a very real way and it has really changed how we build apps.

While we are pretty good at JavaScript, one of the things our technical staff quickly concluded is that we all needed to be REALLY good at JavaScript; our developers and interface designers need to be as second nature with JavaScript as they are with C#, SQL, HTML and CSS. As such we decided we needed to undertake efforts to make sure we have a common baseline level of skill with modern JavaScript.

Tactics

First, our aim is to analyze the team’s base level skills with vanilla JavaScript using an objective diagnostic test to evaluate competency with basic/universal JavaScript aspects. I expect that many of our designers and developers will “test out” following that evaluation – those team members will function as mentors to developers and designers that do have areas for development with JavaScript.

The following are the baseline JavaScript concepts we want to make sure are second nature to all team members:

  • For loops
  • If Else
  • Switch statements
  • While Do
  • Comparisons
  • Functions
  • Objects
  • Arrays
  • DOM interactions
  • Event propagation
  • Debugging
  • AJAX

While not a particularly daunting body of knowledge, our thought is that with this objective we will ensure a uniform and strong level of knowledge to translate to rapid and effective development in React, Angular and Node along with a common shorthand across the team.

The team will work through online courses and resources targeting each person’s needs. Likely sources include paired mentors, Pluralsight courses and resources including the following:

Developers and designers will meet regularly for Q&A sessions with mentors and help with course work as they work against an assigned JavaScript challenge.

Measures

In the spirit of Key Performance Indicators and Radical Focus each objective is paired with a measure to quantitatively and objectively measure whether or not we achieved the goal. The following are the intended measures for our JavaScript objective:

  • Recommended course completion and mentoring participation by all team members
  • Ability to build the spec’d JavaScript-oriented exercise assigned to each team member

Up Next

Our next post will outline our objectives to unify code approaches and continuous delivery as well as improving product quality.  Leave your thoughts below in our comment section and check back often for our next post in this multi-part series.

No Comments

Leave a Comment

Your email address will not be published. Required fields are marked *