Rock Paper Coding: Chapter Five - Learn to Love the Business

This chapter is a play on two ideas: the business as a group of non-technical users and the business as in the company you are working for at the time of reading. Change the way you deal with both has the potential to impact your career significantly.

We should define some of the roles of the various business units and how they commonly interact with developers to ensure that we are all on the same page before beginning our discussion. While there are likely too many types of business units to enumerate, we can at least talk about some of the teams you’ll primarily work with as a developer. Most of my experience has been with project managers (PM), business analysts (BA), and product owners (PO). Of course, there are sales teams and many other non-technical groups, but they likely communicate with the groups I’ve listed here, and those groups connect with you. Most commonly, you’ll encounter PMs and BAs. They are usually responsible for writing/gathering requirements and setting the timeframe for a project. Often they will act as the primary channel for sharing information with you from other parts of the organization. In many companies, the business teams will work with the stakeholders who decide the direction of the product and you who is responsible for creating the product.

This relationship should be seen primarily as a partnership. As developers, we need requirements to successfully deliver a product that satisfies the needs of the business. Along with requirement documents, we need project plans and schedules. These artifacts are the responsibility of the BAs, PMs, and POs. They provide us with these documents, and we turn those things into software. Having a healthy feedback loop between the development team and the business unit helps to ensure the success of the project currently in development. Sadly, we as developers do not have the luxury of working until we deem the project complete. Our communication back to the business team is vital here. You create and ship products with the understanding that things may change mid cycle. The PMs/BAs have to operate with a similar understanding that things can change during development. Many times you’ll be in the middle of a task you estimated to take four hours, but an unforeseen roadblock increases that estimate by a factor of ten! If that feedback loop is functioning properly then at the first sign of a delay communicating that information is valuable to the business units. It allows them to make plans and adjustments. The business teams ideally are held to the same commitment of early (and constant) communication. If there are new changes to the requirements, timeline or overall expectations, that information needs to be communicated to the development team as soon as possible. Developers need the same cushion for course correction. Of course, we know that things aren’t always, ideal. It takes both parties to be willing to be successful to make things work best, but since you are reading this book and not a BA, I can only give you my thoughts on the actionable items you can have.

Your relationship with the product/business team is a partnership, and that absolutely must be the foundation. With this foundation in place, the next step is to work together to create a product of which the company is proud. At any given time you should be working with the ulterior motive of not only writing code but writing code that leads to a high-quality product. One of the obstacles that prevent this from happening is an imaginary line that separates the business and the development team. From my experience, developers tend to separate themselves from the non-technical team members to avoid dealing with their perceived lack of knowledge of technical topics. This separation is not the solution and only serves as to clog the feedback channels that we have already established to be vital for success. Even with taking into account the different work styles of various teams in a business environment the potential cost to the quality of the product is still too high to promote this behavioral pattern. My aim in this next section of this chapter is to walk through a common pain point you may experience when working with BAs/PMs and what could be done from your position as a developer to navigate it successfully.

Documenting features in requirements format is more than just a formality. It serves as a basis for the expectations set by the business users and the development team. These documents give developers a sort of roadmap to follow while implementing new features for the product. At times, an impromptu visit (or email) from a BA/PM/PO requesting a new feature can disrupt things and derail your workflow. Early on in my career (ahem, last week), a small fire would be set ablaze when one of these visits would end in a new request. The tiny rage was not born out of a desire to create a stressful working relationship. The reaction originated because the ask would feel invasive and disruptive. A little voice in my head would tell me that we developers knew what was best, not anyone else! It was almost as if the person making the request didn’t care what I thought about the direction of the software I spent so many hours crafting. This wasn’t the case, but it is what my mind conjured. Whether or not this feeling resonates with you, it is still vital to understand the implications. My feelings, justified or not, obscured my ability to see and champion the goal of the company. The goal is always to achieve maximum success. The business team member is only offering their solution that will hopefully move the needle toward that calling. A practical solution here is to keep a collaborative attitude and guide the situation back toward the process in place. We cannot be robots and reject the new request because it didn’t follow the process to the letter. What we can do is to keep our “how can I help” attitude and work with the user to get their request brought before project stakeholders for them to decide what happens next. The likely outcomes are either it will be escalated, descoped or put on the list for future enhancements. There is something to be said, however, for accommodating the ask (as long as it is reasonable) without pushing for it to go through the proper process. There’s an entire school of thought regarding “helping folks out” when someone is in a bind. I have seen this technique build good will and great relationships, but I’ve also seen it turn sour and lead to confrontations down the road when a request couldn’t be slipped through under the table. Use your discretion here as this will be a lesson you’ll have to learn on your own.

Business users are not the enemy. Those particular team members (emphasis on TEAM) possess skills that fill needs within the organization. They fill a need the same way you fill a need as a developer. As a company, we represent a body, and the departments/teams are the various body parts. This body cannot function at maximum efficacy unless all of its members are working in concert. The body must develop into a well-oiled machine (robot much?). Those business team members are a vital part of the body just as we are. It is foolish to adopt the conceit that we as developers are more important than anyone else. Yes, we build the product, but we do not sell the product. We don’t conduct the market research necessary to guide the development and direction of the product. Even if that were the case, it would be an ineffective use of our time. Our core competency is problem-solving and creating things with code. It is challenging to be a full-time sales person and a full-time engineer. Baring experiences from building startups this is not the way we work best. Thus, it is mission-critical to get a grip on our disdain for those other teams and turn an eye toward collaboration.

Loving the business does not mean bending to their every whim and desire, rather it means that we start to look for opportunities to work in a collaborative state. A more comprehensive view of the goals of the business is more important than your ego. If you can learn to communicate and collaborate with the business team successfully, it opens doors that can personally elevate you to a new, higher level. It gives you an easy out against the “code monkey” moniker.

As developers, our first instinct is, of course, to code. We believe that the system that we are coding will bring money to the business. The ability to code and thus practically influence the platform can conflate our understanding of the actual value model. I’ve talked at some length (and will continue to) about the value we add being bigger than the code we write. The danger presented is in direct relation to our interaction with the business. Taking the hard stance that the business users are unable to contribute to the value model removes the opportunities to combine the subject matter expertise of both groups to create something groundbreaking. The intention is not to declare a winner in the business versus development battle royale. Deciding a winner is counter productive. A better way to navigate this relationship is to try to understand the motivations behind each party. What is the outstanding need that is behind the requests that are causing the tug-o-war? Choosing to position yourself in a way that is focused primarily on understanding can open communication pathways that can lead to healthy compromise. While idealistic, modeling this communicative state can inspire a reciprocal effect that can lead your teams into a new, more impactful, place.

After tackling the relationship with the business team we now have space to start working on the relationship with the business itself. Learning to love the business itself can be a gateway into valuable, career changing insight. Working someplace where you don’t believe in the mission and goals of the company means that you are going to resent your employment eventually. Life is too short to waste your time - change your attitude or move on. If you find yourself unable to love the business because of unethical or immoral business practices, my advice is a bit more one sided - get out now. If you don’t have any objections to your employer’s practices, let us explore the meaning of “love the business.”

Love here is a metaphor for the type of dedication I’m suggesting you have towards the company’s mission and the market the company operates. For example, if your employer works in medical device software one should start to understand the needs of that industry. Perform due diligence and try to gain insight regarding the motivations, needs, and direction of that space. Having more than a basic working knowledge of the needs of an industry allows you to develop intentional software. We often find ourselves having to make decisions about aspects of software features. At times it can be difficult to know what change to make when there isn’t a subject matter expert on hand to help. Your knowledge of the industry gives you the ability to think critically and realistically about potential suggestions. Having insight into the direction of things is significantly more challenging and thus potentially that much more rewarding. That knowledge gives you the ability to predict where the software should be going and supplies you an influential position in discussions about the future of the product. There is no guarantee that you’ll be privy to those conversations but when the opportunities present themselves, your knowledge will be useful. Consider the value you add in this scenario! Not only are you collaborating with business teams, but you are also adding meaningful input that can help the business succeed. This behavior is career rocket fuel. You can thank me when you get to the top.

Both these areas require effort and intentionality. If these tasks were easy, it would be the default behavior across companies, and we’d only hear about mega rock star developers killing the game everywhere. Not quite the case, right? Cross team collaboration (and humility) will create new opportunities for personal growth and growth in the team dynamic. Having a “how can I help” attitude gives you a better working relationship. Understanding and even growing to champion your employer’s place in the market does wonders for your value add to the company and for added value to your career.