Ask vs Act

Wednesday, February 11, 2009 ·

By Guest Blogger: David Hemphill 

Balance1 Software development places many fine-grained decisions in the hands of developers. A differentiator that sets one employee apart from another resides in an ability to judge when they should act on their own initiative and when they should seek a wider audience before proceeding.

The meaning of “wider audience” varies for each situation. In some cases this could simply mean bouncing your idea off of the person sitting next to you or consulting with a peer down the hall. In other cases it could mean raising the issue in a group meeting, emailing a system architect, or notifying a supervisor.

The key is finding the right balance. Engaging permission-seeking behavior or a “cover your butt” approach is likely to wear on those around you. On the other hand taking initiative irresponsibly, even if you are successful, can have negative effects on how you are viewed by peers and superiors. Striking the right balance shows maturity and the potential to be entrusted with important tasks with minimal oversight. Finding an ability to demonstrate this repeatedly goes a long way in how your superiors will choose to position you for future projects and opportunities not to mention promotions.

Let’s explore some examples.

  • If you need to make a minor change to a database schema to add a feature do you first discuss this change with someone else?
  • When you find a solution to a problem that requires adding a new, cool open source library do you discuss the inclusion of the library before proceeding?
  • If you need to change a sorting algorithm (without affecting the public interface) can you proceed on your own?
  • In the process of enhancing an application you find it necessary to add parameters to a method call, can you proceed on your own?

In all of these cases the decision could go either way. It comes down to context.

  • Does your organization have a policy about schema changes and who makes them? Perhaps you are the sole developer of the application and database and these changes are a daily occurrence.
  • How are issues of third-party software licensing handled, including open source software?
  • Would changes to a sorting algorithm impact the order of non-English languages supported by the software?
  • Would changing the number of parameters introduce issues with generated code or component upgrades in the field?

Whether you are early in your career or have recently joined a new organization, striking the right balance in terms of initiative is likely to require exploration. In some cases you may take initiative only to find you’ve violated some company policy or touched on an area of sensitivity in the corporate culture. In a healthy organization a first offence is generally forgiven with an apology, along with an understanding that, “you’ll know better next time.” Exploring and bumping into these boundaries is expected and shouldn’t be taken personally or viewed as failure. It’s simply part of negotiating a new environment. However, it’s important to understand that how you take initiative plays a role in your career opportunities.


Connect with Mi

About this blog

I'm not a blogger. So consume at your own risk.
Since 1995 I've been working with software developers helping them increase their value through technical training and connecting them to great employers. This blog is dedicated to those technical professionals that want to get the most of out their career. I'll answer questions I get daily, common misconceptions and provide direction, but it's up to you to take action.
Please ask questions and leave comments. I can offer so much more with your interaction.

I invite you to connect with me via email, Twitter or LinkedIn.
Twitter: @Tavisd
Linkedin: Tavis Hudson

Twitter Updates

    follow me on Twitter