One question I’m frequently asked is, “you seem to have experience working as a business interface lately, what do you like more, technology or working with the business?” I never know if this question is a binary test, “if you say business, you’re out” or simply someone trying to understand more about who I am.
Recently I explained that my bias was 60/40 on the technology side, but that’s sort of an arbitrary, made-up answer, which I quickly confessed to the person I was having the discussion with. There are many applications for technology, particularly software, and it happens that the place where I’m personally most focused is in the realm of understanding a business challenge and solving it with technology.
It ends up being a very interesting question, and one that has career and success implications, no matter how you view yourself — as a technologist, a business person or somewhere in between. Technically, I’m somewhere in-between, I suppose. I’ve always been focused on business issues. As I discovered my career direction in school, I considered economics, business, journalism, and even this odd music technology hybrid.
As I find myself in roles at the intersection of those things that I enjoyed combined with what I finally earned my degree in, Computer Science, I have the most fun and consequently have the most impact on a product. The fact is that you don’t have to be a team leader, interfacing with the business, to make the most of that combination. You can do it with your IC dev hat squarely on your head, or as a dev manager, or wherever you live.
I’ve always believed that one of the foundations to getting a team running well is to foster clear understanding of why we do what we do, to build up the information that everyone needs to make decisions into the collective consciousness of the team. That way, when a developer is sitting at home or in her office late at night coding some new feature, they don’t get stumped and have to find a PM to answer an email, or a business partner or me to decide what to do. The understanding is in their head, for the most part, and they can proceed and check in on their decision in the morning when people are around. If the team truly understands what it is trying to accomplish the right decision usually gets made.
But what is the team trying to accomplish? Sometimes it’s an internal development goal. We need to re-architect the file structure. We get it, it’s a technical goal, clearly in our domain. Decide and move forward. But, what happens when the feature is requested by the business? You need to understand the business. You need to think like the business and act like the business to decide just exactly what it is that the business wants, or more specifically, since we are technologists, we need to decide how to translate what the business wants into what it really needs long-term. If you don’t understand the business, it is difficult to accomplish this.
In a Microsoft-style organization, this role might fall to the PM, but still, if you’re writing code, the more you understand of the business, of your customer, the more likely you’ll produce something that they like and ultimately need.
How do you foster this in a team? That involves communication in several areas, and most of all, relationships. In the technical documents, make sure that there is documentation of the problem and what the customer or the business partner expects and needs. In team meetings, take opportunities to discuss the projects and talk about wins and losses for the business based on what your team does. Tie your success to the business’ success, and do what you can to help the business succeed. Have the business representatives come to the team and talk about their plans, highs and lows and how your team fits with their success. One of the most empowering things for a team is to have the people that care come and say intelligent (this is very important) things about what they do and how you help them do it. This can backfire, however, if the discussion is not thoughtful and shows a lack of insight into the business and/or the technical challenges that the team faces.
One of the most inspirational moments on one of my teams was when one of the senior executives came to my team and said, “that little thing you did for us at the end of the last release is going to save us $4M in costs over the next year. Thanks.” Why did we do that little project? First, the business knew us well enough to ask if there was something we could do. They knew us well enough to know that we would be receptive to the idea of helping the company over the long-term even though it made our short-term work a bit harder. We understood our priorities. We succeed when the business succeeds, and we know that when a little extra effort is traded for a big payoff for our partners or our customers it is almost always worth the effort.
So, keep focusing on your relationship with the business. When there’s a problem that needs solved, have key members of your team be involved in the solution process, whether that means fixing the problem or just being along for the ride, offering help and suggestions. Without wasting time and creating randomness, push the relationships with the customer as low on the team as they should go and from the manager seat, set the priorities, the tone of the team and track the things that are coming out of the relationships you’ve fostered.
Measure yourself like the business would measure you. Help your partners understand how to measure your success and follow up by doing the measuring. If you impact sales, make sure that every release meets that goal. Use randomized testing to be able to clearly state, “We succeeded. Our goal was to raise metric X and reduce metric Y. The test demonstrates that we delivered exactly that for our customers who were exposed to the new system.” That would have meant +$Z in sales last year. Make sure that from the intern to the managers everyone knows exactly how you succeeded.
Be the solution and information source. Solve problems and provide the data that the business needs to understand its performance better. Be their partner and you will, by working closely with them, have more empathy and understanding for their priorities and goals.
Most of all, prioritize. Prioritize the projects, prioritize the customers and prioritize your values for code, documentation, testing and every part of the process. Make sure that everyone has a foundation upon which to make good decisions about what the team should be doing and the team will naturally start to move mostly in the right direction. That doesn’t absolve you of understanding what the team does, it just means that there is usually positive momentum in the direction you need to go.
If you do it right, one day, someone will have an insight that you never would have had if you hoarded the information, the priorities and the relationships, and you will see your team do something amazing. They’ll do the right thing without you having to ask, suggest, hint or manipulate them to do it, and in that moment, you can breathe out and savor your success…until someone comes to your office with the next crisis.