Category: AdventureTech Culture

What Should You Look For In A Software Development Mentor?

Post written by Brett Gibson, Owner at AdventureTech

Every day I see more and more developers becoming agents of positive cultural change in their own organizations and IT communities. Either by nature or occupational hazard, we enjoy problem solving. It’s just how we tick.

Because software touches every aspect of a modern organization, our opinions are being sought to help solve larger systems pictures. As we do so, mentors and thought-leaders have become an indispensible part of that transformation to better practices.

Developers are in a constant learning culture and it can be an overwhelming experience for new developers to even know where to begin. Given the pace at which new technologies and practices arrive and the breadth (and depth) of knowledge we’re expected to retain, ours is an industry that benefits immensely from mentoring.

Mentoring assists with technology, practice and process learning curves, team cohesion, software delivery, stakeholder engagement and employee retention (something that all IT departments face).

Rather than tread ground that’s already been walked before, a mentor will show you solutions that have already been formed and help you avoid technical dead-ends that have already been taken. It can also help a company avoid Technical Debt born of rookie mistakes.

So what are the qualities you should seek in a mentor?

1. Seek out a subject matter expert (if one exists) in your area. Someone who has invested the time it takes to understand something deeply.

2. Seek out someone who actually practices what they preach and who can explain why alternate approaches might fail. But beware of a mentor claiming subject matter expert status in a technology that’s 10 years old… We call that archaeology.

3. Seek out developer mentors who are the communicators in your discipline. The ones who publically speak and blog are excellent choices because they’re brave enough to publically stand behind their facts and convictions.

4. Seek out developers who are trying to address larger industry dysfunctions like Agile, Lean, Kanban. These are your thought-leaders. They are the ones attempting to make this industry a better place to work in. They are the culture changers – the ones who can help with larger company pictures.

5. Seek out a mentor who is also focused on community. We’re fortunate in Kansas City that the developer community is so actively collaborative in nature.

Good developers love to learn and share it. Good mentors show up.

Here’s a quick list of groups and events that you might think about checking out. This list is not exhaustive, but a great starting point if you’re wanting to find a mentor or simply become more active in the community. 

Kansas City Developers Conference – A yearly event not to be missed. Mentors, MVP’s, speakers, bloggers, experts galore.

Limited WIP Society Kansas City - A monthly meet up for developers interested in the Lean and Kanban software development. A great roundtable on topics suggested and voted on by those who attend. Moderated by Troy Tuttle.

Kansas City IT Professionals – Run by community advocate Mike Gelphman. Mike also runs the most active IT LinkedIn group in Kansas City.

KCNext – Recently merged with SITAKS serving as a regional advocate for KC Tech companies.

Did you like this? Share it:

My AdventureTech Experience: A Post From “The New Guy”

Post written by Joseph Davis, Web Application Developer at AdventureTech, AKA "The New Guy"

I first came in contact with AdventureTech in September of 2011.  A good friend of mine, Donald Rossberg, had been attending a local business networking event where he met and became acquainted with Brett Gibson, one of the owners of AdventureTech, who was also attending the event. When Donald found out I was passively seeking a new opportunity he arranged a lunch meeting for the three of us so I could meet Brett.

Brett was a very talkative and friendly fellow. One thing that immediately stood out to me in his conversation was his deep interest and understanding of agile development principles. I could tell from the depth of examples he spoke of that, to him and to AdventureTech, “agile” wasn’t just some buzz word they adopted for a season. Instead, it was something they had successfully implemented, that they believed deeply in, and that they had enhanced through multiple experiences with clients.

Some time later I ended up in another lunch meeting, this time with several of AdventureTech’s developers, including Phil Ledgerwood, Troy Tuttle, Lee Brandt, and Brian Moon.  I was prepared for a technical drilling as is common with many panel interviews I’ve been through in the past. Instead it seemed they were more interested in telling me about themselves as a company, what they were all working on and what tools they were using in their various projects.  

They spoke of Inversion of control containers, object-relational mapping tools, test driven development, and other design and development patterns. Many of these were tools and practices that I had read about and of which I had a fair level of theoretical understanding but had not had the opportunity to put into practice in a professional work environment. The prospect of doing so was very appealing to me.

Until just recently, the team of developers at AdventureTech was composed entirely of very experienced senior level developers, many of whom are involved in the community and give talks at development conferences. Such was their culture and the nature of their team.  Now they have begun bringing on some younger developers with the intent of molding the next generation of senior level industry leaders in Kansas City.  

They aren’t looking for developers who already know it all, but instead they want people with an aptitude and thirst for learning along with good communication skills. One thing I heard a number of times during the interview process was: “How to write good code? That’s easy to teach.  How to teach a person to have good communication skills… that’s something they should have learned in kindergarten."

I’ve been with the team for about a month now and am pleased to report that it is turning out to be everything I was hoping for.  Many of the other guys on the team have titles on their business cards like “Software Practice Coach”, “Software Process Coach”, and “Developer Mentor”.  I find myself in a place where learning is fostered and supported, and I’m picking up many new things each day.  I feel empowered in this environment to be the best I can be and I’m very excited about the future of my career.

In addition to fostering learning and encouraging the use of new tools and technologies, AdventureTech also strives to create a compelling work environment and benefits package that will draw the best developers around. Apart from very competitive compensation and medical benefits, AdventureTech also provides an education and equipment budget so developers can stay sharp, and an extremely generous amount of Paid Time Off that I have only seen matched by some companies for their employees with decades of tenure.

Although I’m still fairly young in my career, I have been through several jobs looking for a place that had everything I was looking for.  I’ve finally found that place and I’m proud to be a team member at AdventureTech.

Did you like this? Share it:

The Human Cost Of Deadlines

Post written by Brett Gibson, Owner and Vice President of Business Development at AdventureTech

Deadline: Originally a Civil War term for a line that marked the distance a prisoner could go before being shot on sight. (source: http://www.thefreedictionary.com/deadline)

When I see an employee who is asked to guess on a timeframe, be held accountable for such random number theory, and then forcibly held accountable to that speculation – I become concerned.

When I hear an IT department say, "We need to identify these timeframes so we know how much overtime we'll have to put in to make our deadline"  -  I positively cringe.

Many companies still have an unhealthy "adrenalin-junkie" addiction to deadlines because they confuse them with results. The truth is, and what many companies repeatedly fail to understand, is that they are actually incurring larger costs in the form of waste, technical debt, staff turnover, disengaged employees, and eroded company culture.

As this self-induced erosion occurs, these companies get a reputation in the community as a place to avoid, both from consumers and job seekers.  

This tired practice of using wartime models for peacetime business practices is both misplaced and corrosive. Comparing workers to soldiers, projects to D-Day beach landings, and acceptable losses/collateral damage to the greater cause……all of this modern day nonsense eventually erodes the very business continuity and productivity gains they were trying to obtain in the first place!

 

If the goal is productivity – deadlines will guarantee the opposite. Forcing your staff to meet arbitrary timelines doesn’t build morale; instead it builds an unhealthy camaraderie of mutual hatred, resentment and distrust toward management.

Steady, predictable output, determined from actual metrics, gets you there – and more accurately. Agile principles, when applied correctly, have the ability to turn the tide of the deadline culture while simultaneously creating better work environments.

What company in their right mind WOULDN'T want that?

This year, why not change the way you've always done things? Let your employees enjoy the holidays without the threat of looming deadlines born out of someone’s need for their bonus or misplaced desire for a neatly packaged project completed at year end.

The deadline isn't what's most important.

Did you like this? Share it:

7 Interpretations of Silence

Listen

Listening to clients is at the core of solid communication efforts. This is perhaps even more important to IT professionals than it is to average consumerism because we often deal with complex topics.

But listening is not simply affording someone the courtesy of audience, nor is it simply letting them speak because it’s their turn. The goal of listening is to understand the true nature of a client’s problem. It is an interactive, engaged discussion of discovery whose fruits are clear problem determination and resolution. In that order.

Demanding that any client, user, manager or executive fully explain themselves is not good listening either. It is a poor one-way model for collaboration; it builds fences NOT bridges. When communication goes south, you will probably be faced with silence out of nothing more than false politeness.

Understand that silence and head nodding agreement can mean one of several things:

1 – Mission accomplished

Yes, I’ve understood you!

This is typically the one we WANT to hear, so we presume it to be so most of the time.

The Risk? Potentially none, but ignorance is bliss.

2 – Partial absorption: Requires further baking

“I haven’t understood you completely, and I’m still attempting to process all of what you’ve told me. I might require more time to fully understand all this information, and may have questions later when some of it starts to sink in. I might ask you again, but then again, I might not…”

The Risk? Partial knowledge or interpretation means the client will fill in the missing pieces with what they *think* they heard. Those assumptions will come back to bite you – especially if they choose not to reengage the dialogue.  

3 – Looking the fool

“I haven’t understood you, but I don’t want to look foolish in front of you because you act like your time is important – OR – I haven’t understood you and we are in a group setting. I don’t want to look foolish in front of my peers, boss or subordinates. They’re all nodding their heads and seem to get it, so I’m hoping someone will explain it to me later in language I understand.”

The Risk? No one likes to feel they haven’t understood something. Fear of asking important questions early leads to a paralysis of activity and co-operation later.

4 – Research required

“I haven’t understood you completely, and am hoping to research this all a little further to fill in the gaps myself. I have some lingering questions that I believe I need to ferret out myself.”

The Risk? IF a client takes it upon him/herself to get educated on your topic, understand that it is still potentially non-communicated. You won’t know if they actually performed any due diligence, so you cannot assume they did from silence.

5 – Wait and see

“I’m a practical/visual type. I’m hoping that later on, when I actually see this all in action that it will finally make sense. I’ll let you continue your speech and involve myself when this idea is made reality, and then provide feedback.”

The Risk? While you now believe that everyone has signed off and will start on your plan, this individual is withholding his/her vote of acceptance until it’s actually up and running. The potential waste of work here is high, and the 11th hour death-marches start with this definition of silence.

6 – The personal touch

“What I’m hearing is that later, you will hold my hand in this process and personalize it to me. I’m expecting that you will follow up with me personally, and your speech today is just an introduction.”

The Risk? Personal touch types cannot work from pieces of paper, emails, phone calls or boardroom presentations. They require face-to-face communication and an emotional connection to a concept. Without that personal touch, this type of individual will fail to engage. Silence of this kind is in the form of non-communicated, assumed, personalized expectations.

7 – Assumption of ownership

“I’m assuming that you are just explaining this to me out of full disclosure, but that you will actually be the one doing it because you’re the one giving the speech.”

The Risk? What this individual has heard, is that you are in charge of this entire process. They expect to be managed rather than a willing and active team participant exercising initiative. They expect that you will be the one both watching to see if a ball is dropped and catching it.

And the list goes on…

If you are the type of individual who always believes that silence and/or head nodding means #1, your professional life will prove to be a frustrating one. Do not attempt to interpret the meaning of silence – you will fail miserably and it will only serve to dismantle trust and foster antagonism.

Do not place the burden of silence on the client. When you hear silence, flush out misunderstandings with empathetic, engaged, courteous dialogue. When you see a look of mild puzzlement on a clients face – ask questions and try another angle. It means that at least one thing you have presented did not click with them.

The responsibility is on you to facilitate a solid understanding with your audience not for them to simply participate as spectators of your speech.

Silence is a red flag. Know how to spot it and use it to create a positive client experience.

Did you like this? Share it:

4 Characteristics Of Every Great Developer

At AdventureTech, we spend time carefully fostering what we refer to as "a community of developers for developers". While it might sound like an altruistic endeavor to allow local talent to congregate and collaborate, we believe it’s an essential component of every successful software development project. But there’s something in that picture that needs explaining and it speaks to the very reason we seek out excellence in Kansas City:

NOT ALL DEVELOPERS ARE CREATED EQUALLY!

With that in mind, let's take a look at 4 Characteristics Of Every Great Developer. This isn't meant to be an exhaustive list, but these characteristics are ones that are critical to successful software development projects.

1. Pure technical excellence. This one kinda goes without saying, but any great developer has extremely strong technical acumen.

2. Be a good systems thinker with the ability to understand how technology fits with business needs and knowing how to deliver value AND software.

3. Be a strong educator. When confronted by users “not getting it,” a good developer takes the time to explain choices and options in technology. Software development is truly a learning culture and placing clients within that team spirit affords the highest possible business value.  

4. Strong written and verbal communication skills. We saved the best for last and want to expand on this topic because we believe it is increasingly important and not discussed enough in the developer community.

At AdventureTech, we believe it’s important to speak directly to the traditional criticism surrounding the lowered expectation levels for communication skills in IT. While below average interpersonal skills are not unique to IT, we believe they lead directly to antagonistic client relationships, misunderstood software requirements and ultimately delayed projects. Stressful communication environments quickly erode customer confidence and can provoke the need for intermediaries. Business analysts, for example, are often simply replacement ambassadors to this forced need for mediation and translation.

Forcing the developer/client relationship into the realm of signed and sealed paperwork does not mitigate this antagonism either. We believe it only exacerbates it. Face-to-face collaboration is critical to project success and breakdowns in communication should be addressed directly and personably. When done correctly, the end result is successful, collaborative software that meets the needs of the client.

Have you ever sent an email or instant message to a client where the tone or intent of your message was misinterpreted? Developers who choose email or instant messaging as preferred methods for communication run an increased risk of miscommunication. While that preference might be appropriate for developer-to-developer interaction, we prefer face-to-face or phone calls when collaborating with a client. Email carries with it an inherent danger of allowing people to be braver (and less personable) than they otherwise would be face-to-face.

Additionally, blogging, writing articles, and speaking engagments are invaluable ways to stand out from the crowd of technical excellence. We not only hire educators and public speakers; we also encourage every developer to have their own personal blog and to contribute to the AdventureTech blog.

Clearly, everyone has different levels of proficiency when it comes to written and verbal skills…and that's OK. The only way to get better is to continue to fine tune these skillsets (just as you do your technical proficiencies) and seek out feedback on how to improve from people you trust and respect.

Those in our industry that do will undoubtedly evolve from good developers….to great ones. And that's GREAT for everyone involved.

What do you think? What have you done to improve your communication skills? What other characteristics do you think are important to becoming a great developer?

Did you like this? Share it:

Connect With Us

     

Contact Us

Toll Free: (888) 373-8718
Main: (913) 402-9600
Fax: (913) 402-9603
7450 W. 130th Street
Suite 320
Overland Park, KS 66213

Upcoming events

  • Events on May 16, 2013

    LWS Lunch

    Starts: May 16, 2013, 11:30 am

    Ends: May 16, 2013, 1:00 pm

    Location: DEG Offices

  • Events on June 18, 2013

    Kanban Training

    Starts: June 18, 2013, 12:00 am

    Ends: June 20, 2013, 12:00 am

  • Events on June 20, 2013

    LWS Lunch

    Starts: June 20, 2013, 11:30 am

    Ends: June 20, 2013, 1:00 pm

    Location: DEG Offices

  • Events on July 18, 2013

    LWS Lunch

    Starts: July 18, 2013, 11:30 am

    Ends: July 18, 2013, 1:00 pm

    Location: DEG Offices

  • Events on August 15, 2013

    LWS Lunch

    Starts: August 15, 2013, 11:30 am

    Ends: August 15, 2013, 1:00 pm

    Location: DEG Offices

  • Events on September 19, 2013

    LWS Lunch

    Starts: September 19, 2013, 11:30 am

    Ends: September 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on October 17, 2013

    LWS Lunch

    Starts: October 17, 2013, 11:30 am

    Ends: October 17, 2013, 1:00 pm

    Location: DEG Offices

  • Events on November 21, 2013

    LWS Lunch

    Starts: November 21, 2013, 11:30 am

    Ends: November 21, 2013, 1:00 pm

    Location: DEG Offices

  • Events on December 19, 2013

    LWS Lunch

    Starts: December 19, 2013, 11:30 am

    Ends: December 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on January 16, 2014

    LWS Lunch

    Starts: January 16, 2014, 11:30 am

    Ends: January 16, 2014, 1:00 pm

    Location: DEG Offices

  • Events on February 20, 2014

    LWS Lunch

    Starts: February 20, 2014, 11:30 am

    Ends: February 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on March 20, 2014

    LWS Lunch

    Starts: March 20, 2014, 11:30 am

    Ends: March 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on April 17, 2014

    LWS Lunch

    Starts: April 17, 2014, 11:30 am

    Ends: April 17, 2014, 1:00 pm

    Location: DEG Offices

  • Events on May 15, 2014

    LWS Lunch

    Starts: May 15, 2014, 11:30 am

    Ends: May 15, 2014, 1:00 pm

    Location: DEG Offices

Recent tweets