Can you manage a team of Geeks?

A wife called her husband, a software engineer, at work. She said “darling please pass by the supermarket and get a loaf of bread, and if they have fresh eggs, buy a dozen”.

When he arrived home he came in the house and put down his briefcase then went back outside to the car and returned with two large bags both completely full.

His startled wife looked at him and said “what do you have there?”

The engineer looked her straight in the eye and replied “a dozen loaves of bread, just like you instructed they had fresh eggs so I bought a dozen loaves of bread.”

This summarizes one of the challenges that confronts front line managers of technical professionals.

While it is the job of the engineers to produce the product, it is the manager’s job to ensure the product specifications are not only clearly documented but also clearly understood by the engineers. This challenge varies greatly among organizations ranging from an organization with a very rigid software development life cycle (SDLC) and approval process to others with virtually no formal SDLC in place.

Consider the organization that has a very formal SDLC in practice. The application requirements are written, reviewed and approved before they ever arrive for consideration by the development team. The development team is then tasked with feasibility and a time for completion estimate. Most requirement ambiguities are clarified and the manager must actively serve as an interface between the developer of the business requirements and the software engineers in order to ensure both parties are in agreement regarding the application functionality.

The second role the manager plays is ensuring the application is built using existing technology, and extension of the previously developed code base. Much of this is done prior to application development by establishing functional utilities such as string manipulation and ensuring every new engineer is taught how to use these common utilities. During application code reviews by the manager or senior developers should be done at regular intervals to ensure extension of the organization’s common tools and to increase the engineer’s knowledge and skillset.

The third major role the front line manager has in this type of organization is investigating, evaluating and if applicable selling to sector and senior management why a new technology will not only improve the application in whatever way it could but also that it will not violate any valid concerns of a system sector such as network security.

Frontline supervision in this organization is structured and is primarily concerned with development that implements an existing approved framework.

At the opposite end of the application development universe is typically found at a startup, a semi-mature website and even behemoths. Typically, the SDLC consists of “code review? The changes to the home page go live tomorrow”, or somewhere close to that mindset. These shops often have a core of employees on the development staff supplemented by hourly contract engineers employed for the length of the project. In this environment the job of the front line engineering manager is much nimbler than the same position at a company with a developed strictly adhered to SDLC.

One of the two most important roles the manager plays in this type of organization is business requirements definition or ensuring the engineer returns home with one loaf of bread and a dozen eggs. Since the SDLC is far less stringent in this type of organization typically business requirement definition is far less stringent as well. The manager must actively ensure that requirements are understood by the business owner, the project manager if there is one, the quality assurance engineer and the software engineer and documented with approval by each of the aforementioned participating parties. Further the manager must actively participate in development progress reviews to ensure each party remains committed to the same business objective.

The second most important role the manager must play stems from the inherent nature of the organization’s lack of stability. Every engineer has a development framework or language they believe is the best the world has ever seen. Often this is the first they have mastered (it is human nature to love what you know). Similar to this task at a mature SDLC organization the manager must ensure extension of existing code base and utilities, but unlike the mature shop the job here is like that of a sheriff in the wild wild west. The following phrases are very helpful. “I do not care how great your framework is, you cannot use it here, we use this one instead” or “Blah is a great language but all of our other engineers know Blam so you will use Blam” and finally “I know you can write a browser based script tool to do X, but we already have a server based tool that does X so use that”.

The other role the manager must play in this type of organization is that of a flexible tactician. The talent of the staff is not constant, so constant evaluation of the existing staff and its shortfalls is an ongoing job and filling the inadequacies is an ongoing challenge. Regular evaluation of the progress of each engineer is another requirement. Review their code or have an experienced senior employee do so. Meet with business owners, quality assurance engineers and project managers to understand their perspective of your team members. Review your engineer’s work see what makes them excited, be excited with them.

Success as a front line engineering manager requires many skills and those differ between various development environments. While this is not for the timid or weak at heart, this is exactly that inspires a geek.

Great management equals great software

Cost effective software begins with management.  Currently the most expensive part of the application lifecycle is engineering.  While this will surely change as automation replaces repetitive tasks, and to be quite frank, writing code is a repetitive task, currently and for the next decade or so minimizing engineering cost should be the primary cost reduction goal of any management team. At the risk of sounding TEDish the most important contribution management can offer is vision.

Has management engaged the stakeholders or more basically stated does the software management team know what problems the business owners want solved and what the solution priorities are?  Have these been committed to a written document that the business owners approved?

Did the management team seek out the simple solution first?  Often times when a new software idea is introduced the stake holder is unaware of the information they truly need so providing inexpensive easy to obtain information can often flush out and improve the stakeholders understanding of what is needed before large investments are made in a system that does not offer truly useful information.

Have the preferences of all of the end users in its User Interface been addressed? A commercial internet operation typically has users who speak many different languages, has the architecture team envisioned that and planned for it using I18N?

Will the application architecture be based on common global standards that are shared across the programming industry or will the application be built on local proprietary standards that every new engineer will have to learn before they can be productive?

When designing the architecture have ongoing maintenance costs been  considered?  Are the points of access between tiers minimized so for example a change in the state model in the database will be minimized to a maximum 1 and only 1 change to the code in a single Data Access Object.  Are various functional pieces of code shared across many different jobs minimizing maintenance to one place instead of many?

Are engineers kept from using the latest and greatest language, library, code base before it is to evaluated to determine if and how it can be integrated into the existing architecture and in consideration of the knowledge and skills of the  existing staff?

Is there a person or team assigned to coach and train new hires on how to extend existing functionality?

 

To be continued …………….

What do Geeks have in common?

That is truly a rhetorical question because there are so many types of Geeks that seemingly have nothing in common, ok maybe wire rimmed glasses.

I propose the following thing is the only thing required to be a Geek.  A Geek must continually thirst for new knowledge.  The knowledge does not have to be useful knowledge although most times it is.  Learning is joyful not burdensome.   I am sorry if you no longer live to learn turn in your Geek card when you exit.