Help Your Business Be A Technology Company
Dec 16 2009It doesn’t matter what industry you work for- every company is a technology company. At the end of the day a business needs to provide something somebody wants- quickly and efficiently. This is- quite simply- driven by technology. And you- as a software developer- are directly responsible for making that happen. What will separate you from other developers is not how well you program- it’s how well you create the right technology to help your business work better.
Unfortunately most people don’t really understand technology nor how to use it. I’m not talking about silly things like printing a pdf or syncing your Outlook calendar- I’m talking about how technology can optimize business processes. How technology can both improve efficiency and quickly provide accurate, meaningful information. How technology can be the engine keeping your business two steps ahead of everyone else.
Luckily you have an advantage to accomplish this goal: you know how to create technology. The important thing, however, is knowing both what the business is and also needs so you can help make it work better. Building software isn’t nearly as important as knowing what to build.
Don’t just Program- Provide Solutions
Don’t be the type of heads down programmer that wants to be told what to do just so they can code. People that wait around for requirements and specs are a waste of time and energy. Everything has to be articulated to a T, then assumptions and misunderstandings lead to bad a deliverable which can sink a ship. Yes, it’s important to code and code well, but all too often code eclipses the bigger picture.
As a programmer, your job is to create something to fill a gap. You need to understand why that gap exists so you can figure out the best way to fill it. You’re the programmer- you literally create the solution. You know what’s possible and what’s not- what’s easy and what’s hard. And if you’re experienced you know the consequences of decisions. So don’t blindly accept solutions. Spend time understanding the problem- come up with the solution- and then work with people to figure out if your solution will solve the problem.
Lead by Listening
Coming up with the solution should not equate to arrogance. The world, unfortunately, does not revolve around you. Despite how annoying your users may seem, they are your responsibility and you have an obligation to them. Nobody likes to be told what to do or have something shoved in their face. Yes, it is a lot easier for you to just do it yourself and say “here”. Unfortunately, for everybody else, that way sucks. You need to lead by listening: sit with people, listen to what they have to say, and show that you get “it”.
If you listen well you’re in a better position to explain why you’re making the decisions you’re making. Work with users: build consensus and understanding. If you have a business advocate who’s on board with your plan, you have a powerful ally to help create the change you want. Bounce ideas off of people- and if you think an idea is bad, say so, but always provide an alternative solution. Being negative and impatient is the quickest way to alienate yourself and have the best idea shot down.
Change the Process
You can only make a car go so fast- at some point, you need to fly. So don’t just help the driver drive; help them get to the destination. Efficiency is key, but it’s found in unusual ways. People want to get their job done as quickly as possible with the least amount of annoyance. Helping them achieve this is often a good thing, but beware: making them do their job better could make a lot of other stuff worse. It can’t just be about speeding up the process- the process may need to change. It’s up to you to see the big picture and help everybody, not just a single person. It’s just like scaling a system: at some point the current process will hit a limit; you need to know what that limit is, when it will happen, and what the hell to do next.
Usually what’s being asked for is different than what’s actually needed. You need to create an “ah ha” moment- when you can take all the frustrations and problems of your users, combine them into one solution, and have everyone say “yes, that’s perfect”! Have a vision.
Roadmap
Sadly, you always have two things against you: time and patience. Nobody has either. You can’t drastically change a users day to day activity. Imagine if all of a sudden we had to start driving on the wrong side of the road- total chaos would ensue. It’s the same thing with drastically changing an application- for the end user, it’s hard for the long term benefit to outweigh the short term difficulties. It’s also a horrible idea to wait a long time for your great solution to be delivered: by that time, it’s no longer relevant, and everyone’s forgotten why it’s important.
Small, incremental changes are key: you need a roadmap to the goal. That’s why we have agile. You need to shepherd the heard to the promise land, and constantly remind them of the goal. As new requirements come up and new requests come in you need to make sure everything is fitting into that big picture. People may even come in with quick one-offs as stop gap measures- the biggest setback for moving forward. You need to be able to say “Here’s why this is bad” and provide better alternatives. If something must happen quicker, prioritize, refactor and meet half way. Agile development has numerous benefits:
- You can provide iterative releases. People can see progress unfold.
- You get in refactor/response cycles. It’s amazing how excited and appreciative people are if you make a change they ask for- no matter how small. If something isn’t working as envisioned, and gets changed quickly, you are a rock star.
- You can deliver faster: software can be used when it’s usable, not when it’s finished.
- Things can be prioritized. When you can’t do something somebody wants, it’s not a surprise. If you communicate well they know why it didn’t happen.
- The learning curve upon delivery is minimized. People know what they’re getting and how it works. After all, they were part of the design.
The Deliverable is not the Release
Good software is something that people like using. At the end of the day, it doesn’t matter which design patterns were used, how cool your ajax widget was, or even how many bugs the product has. Writing code well does not equal a good product. If it doesn’t help somebody do something better you wasted a lot of time- particularly your own and even worse your users. That’s why time to market is so essential- it gets the product used sooner so reactions can be gauged and adjustments made. Bells and whistles are nice to haves, but at the end of the day you need to ask yourself how important was it really? Would a simple web 1.0 form have been better? Would it have been easier to use and quicker to develop? Is this thing that I’m doing actually solving a problem?
All of these questions equate to a simple rational: Am I giving my business what it needs? The better you are at answering that question the better you’ll be at programming the solution.