How We Work: Our Process from the Tech Side
A look at how Myplanet structures our team, project, and organizational processes through the lens of a technologist.
In-demand technologists are faced with a big decision: do you work in professional services or in product? It’s not a trivial choice. The hard skills at the core of the work might be more or less the same, but the challenges being faced and the approaches to tackling them can be wildly divergent. As a professional services (PS) organization, we spend a lot of time helping prospective team members understand what it’s like to work in this environment, and whether or not it fits with their preferred work style.
Before we dig into Myplanet’s process specifically and what that means for day-to-day work as a technologist on our team, it’s important to know three high-level differences between a PS and product setting more generally:
- Short-term view: In product, things tend to work on 3- or even 5-year cycles; not so in professional services. Our projects are in 3–6 month cycles, by and large. (There are, of course, exceptions in both cases, but that’s the norm.)
- Fast-pace projects: Because of those tighter timelines, services work requires you to focus on the most important things and to cut anything extraneous away to meet your project goals in the time afforded.
- Cutting edge work: In general, we’re doing things for people that want to move quickly in a certain area, so we’re not constrained by backwards compatibility. A lot of enterprise work is often 5+ years old, but we’re not working that way.
But beyond those basic elements, what makes working in PS and more specifically, at Myplanet, different from working elsewhere?
Team Structure
At Myplanet, our teams have traditionally been built on a project-to-project basis, which means their composition can change fairly often, and with the steady flow of new clients and new projects, teams are challenged regularly to acquire and apply new skills. That kind of continuous change is par for the course in services settings, as is dealing with ambiguity and uncertainty. But even with the ambiguity of project work, the changing structures of teams (especially when projects kick off or wrap up), there is a general structure we operate under.
“I think you have to like new things. You need to be ready, willing, and able to deal with quite a bit of uncertainty, and you have to like continuously learning. You won’t rest on the knowledge you have.” — Nik Shenoy
New teams are usually composed of around 5 people. Individuals will have certain roles — Developer, Solutions Architect, and so on — and those roles are fairly stable team to team, even as the people that fill them shift.
We’re also in the process of piloting a stable teams approach. This model doesn’t tend to be the norm in services, because you lose staffing flexibility, but we’re experimenting with it for a couple of reasons.
“Because we have this extreme variability in what we work on and the technologies we use, stabilizing the teams can help to lessen some of the challenges faced when constantly changing,” says Nik Shenoy, Associate Director, Software Development Practices, Myplanet.
First off, we tend to tackle larger, more complex platform projects. For that type of work in particular, having a stable team ensures a continuity of knowledge that will serve the project best. And secondly, when projects change over, team stability means early project efforts can be laser-focused on getting the skills and tools we need onside without having to split focus to establish team operating norms.
The long and the short of it is this: we’re expecting and ready for team changes, but we’re targeting, more and more, an environment that allows for greater team continuity where possible.
Process and project structure
Beyond team structures, there are modes of operating that also lend themselves to a fairly standard arc. Though each project is different and comes with its own challenges and modes of operating, there remains an element of predictability in them that can be a helpful foundation to build from.
Design and research usually start the project, bringing tech in early on to vet any potential issues and minimize the risk of surprises down the line. Our teams work closely with our clients throughout the project — tech team members in particular — to ensure the clients can support the project long-term. Most importantly, the lines of communication between the disciplines are always open. We work collaboratively, because we know that’s what produces our best work.
As Nik notes, “Our project delivery model is fairly well defined. We have an extensive list of best practices for doing the types of work we do, and we tend to adhere to it fairly closely.” But that doesn’t mean we lock our teams into one way of working or a single path to success. “Myplanet is very open about allowing the dev team — the whole team really — to customize the process on a per project basis,” he adds. “You can choose the technology, the tools, the whole process to suit the project’s needs.”
So while there are definite “sensible defaults” for best practice (something we’re building out more and more all the time), overriding those defaults is always possible. There’s always a discussion on the team to establish why this method or tool makes more sense because it’s never set in stone that any one way is the only way to approach a project.
We’re an Agile environment at Myplanet, and Agile is designed to allow flexibility in your choice of tools, your process, even in the length of projects and the make-up of the team. “We’re not dogmatic about saying ‘You must do things this way’, but we have experience we’re trying to build from,” says Nik. “We use that as a base and then tweak it however we need to make it work for the project.”
Evolution Dynamics
Nobody has a monopoly on good ideas. That’s a belief we hold fast to at Myplanet, and in practice it means everyone’s input counts. Whether that’s code reviews or discussions about how we approach a project, each team member contributes at every stage.
We don’t have a strong command and control architecture for our roles or for project structures, and that means we’re not locked into one mode of operation forever. In some organizations, the current way of doing things is often the only way, a mode of working that has become entrenched and implacable over time. That just isn’t how we operate. Finding ways to iterate on and optimize our own process is as important as any other form of growth and improvement to us, and retrospectives are one of our most important practices as a result.
“We’re constantly analyzing how our projects are going — Is this working well? What isn’t working? How can we fix it? — and that lets us evaluate and improve on our process all the time,” says Nik.
We want everyone to have a chance to contribute and to learn throughout a project. More senior team members have experience we want to draw from, but just as important are the fresh perspectives that more junior team members bring to the table. We give people agency — you’re responsible for your work — but we operate as a team. You can and should get help and advice from anyone.
That style of work, to be regularly engaging in feedback and retrospectives, is not only a key mechanism for improving team outcomes, but also for how we improve as an organization. It’s embedded in our culture and we have a number of formal and informal ways to ensure we’re regularly checking in and making sure we’re on the right path for delivering our best work.
“It’s a critical difference between what we do here and what other places are doing,” says Nik.
Personal Growth Opportunities
Our work happens right at the cutting edge, especially when it comes to technology, so staying up to date on skills is essential. With each new project, there’s usually a period of pre-training to get up to speed on project needs, followed by the immediate application of those skills to the project work. We’ve found this not only sets up the project for success, but it also ramps up the time to expertise as team members are able to immediately begin internalizing the new skills they’re developing. And that has big impacts for individuals when it comes to longer-term career objectives.
“We’re always doing new things, so skills development is always important,” — Nik Shenoy
One way we’re supporting project connected skills development is through internal training programs we call Craft Development. These training programs are built around the core skills and technologies we’ll need to develop expertise on in the next few years in order to meet project demands and to keep pace with the market. “I think this is an important part of how we’ll keep our teams up to speed and on the cutting edge, and feeling motivated by the opportunities to learn,” says Nik.
We don’t focus exclusively on formalized training, however. “Tech Talks” is a weekly event, open to everyone to attend and/or present at, that allows us to constantly share back the work we do. Tech Talks gives people a heads up on what’s being worked on, and it spreads team knowledge throughout the organization on an ongoing basis, opening channels for more information to be shared through a cross-pollination of ideas.
Finally, we have our Professional Development program. With our PD program, we’re able to surface individual career objectives that can help us match those individuals with projects that align with their own growth plans. “We work with team members to determine what they like to do, what interests them, and where they want to grow their skills and career,” says Nik, “and then we try to target them to projects where those skills will be in demand.”
Working in professional services isn’t for everyone. You have to be open to challenge, comfortable with ambiguity and change, and keen to learn. But with that readiness to tackle anything comes an enormous opportunity for growth with a team that is operating with the same mindset as you. One thing is for sure: you’ll never be bored.
Visit Myplanet’s careers page to view our open roles and find out more about what it’s like to work at Myplanet.
