Back to Blogs

Which Hat Do I Need Today?

  • Publish Date: Posted about 5 years ago
  • Author: Tom Williamson

Which Hat Do I Need Today?

Most corporate software developers are expected to perform a multitude of tasks outside their level of expertise. Often developers are asked to tackle QA, Technical Writing, Business Analysis, Project Management, and the beat goes on... Now pile on the fact that you are surrounded by lazy and sometimes inferior talent and you’ve got a ‘Kobayashi Maru’, the no-win scenario. You simply cannot do it all, so what now?

Educate

Make sure all parties involved understand the development process and what is required for success. Enlightening stakeholders concerning the SDLC (software development life cycle), or at least some equivalent, will ensure the business is educated on required processes.

Oftentimes business management has no idea on complexity. They think creating a contact is trivial, but we know differently as this depends on such items as scale, localization, and roles. Communicate this through emails, blog links, sequence diagrams, discussions, and any other way you can. Business doesn’t know about software development. That’s your job.

Organize

Regardless of team or project size, you must know what the finish line looks like; otherwise, you’ll never get there. Along with the business, define the end goal and formulate a plan to get there. If compromises are agreed upon with the business, ensure they understand the ramifications.

Process

Your plan needs to include solid processes such as agile in order to keep stakeholders and developers engaged and on the same page; especially since you’ve been wearing multiple hats. This will quickly show the organization your worth and expose slackers and misplaced developers. You won’t have to say a word.

Document

Try not to get too involved with this stage as hopefully you’ve obtained someone who can help (see technical writer role below), but the minimum following items need to be defined and documented:

  1. Sprint Deliverables i.e. On 1/22 users will be able to enter and save contacts.

  2. Project Responsibilities i.e. The business must deliver requirements two weeks in advance and be placed in the task backlog.

Now we are getting organized and acting like we know what we are doing. Expectations are everything. If everyone knows what is expected and it is clearly defined, then all parties are covered.

Roles

Each person within the organization needs to understand their role within the project. This is your opportunity to again show everyone the amount of business value you provide. At minimum, define the following:

  1. Business Project Manager. Your go-to person for all things business. When you need answers, this is the person who has them.

  2. Project Manager. Someone has to keep things in order and be responsible for development. All communication between the business and developers must go through this person; otherwise, you’ll open yourself up to misinterpretation. This person will end up setting schedules, allocating resources, controlling scope creep, and driving the project.

  3. Technical Writer. Who is going to work with the business to document use cases, user stories, deliverables, and requirements? The business needs to stay at least two weeks ahead of development with what they want to see delivered in the coming sprint. Now the business is driving exactly what they want to see developed. Beautiful.

  4. QA. Developers do not make good testers, so if you are pinned with this responsibility, make sure the business acknowledges the time requirements and risks. TDD (test driven development) will be your best friend in this case. Hopefully, at minimum, you’ll involve a few actors/users for regression testing.

  5. Development Team. Architect, Back end layers, Front end layers, middle tier, and production support. FYI… You can’t do them all.

  6. Systems Integration. Who’s responsible for saying the software is ready for production and where does the software live? Hopefully, you’ve negotiated getting everything up in the cloud as this will greatly speed up development and simplify items such as security, backups, and disaster recovery.

Sale

Time for you to wear yet another hat: sales. There are several ways to go about getting the above implemented in your everyday life. Threaten physical violence (highly recommend), tell your boss he’s a moron (highly likely) and threaten to quit, or be the consummate professional and present the facts.

  • Fact 1: Current processes are not rendering expected results. You’re not happy and neither is the business. Change is in order.

  • Fact 2: Current processes (if there are any) are not sustainable. High levels of anxiety prevail and top talent cannot be attracted. They know better than to enter here.

  • Fact 3: You must run software development like a business within a business. You cannot treat it like customer service or purchasing. It doesn’t subscribe to traditional business departments.

I could go on, but you’ll find plenty on your own that apply directly to your business.

Conclusion

The business needs you. You are the one who provides ‘business value‘. You’re asking for something that will improve the business by creating sustainable, extensible, and maintainable software that the organization can go forward with for years to come.

Time for business to realize chaos and grinding on their best performers is not a sustainable paradigm and will ultimately cost the business time and money, giving their competition the edge.

In the end, if the business does not want to listen to the wisdom with which you speak… Then it’s time to move on, professionally.