Wether you are starting a new job, or you just got promoted, the first week as a Software Development Manger, VP, Director, etc, can be a dizzying experience.
Depending on your particular situation, you'll likely have to meet many new people, learn about new systems, and remember to smile often.
A good starting point is the be sure the following items are in place:
- Make a contact list of everyone in your department, your peers, you manager. Include their desk phones, mobile phones, and email addresses. Keep this list updated. You will use it for a long time.
- Find or Create the 'Development Procedures Manual.' Include in it the following:
- Corporate Mission/Vision Statement & Values
- Department Mission/Vision Statement & Values
- New Employee Hire checklist
- Development Workstation Setup checklist
- Software Development Procedures
- Coding Standards
- VPN Setup Instructions
- Weekly Meeting Schedules
- Create a 'Development Managers Log' containing the following:
- Employee Time Off Log
- Observed holiday list
- 3rd Party Software Licensing information
- Historical Release Log
- Be sure you have a source code repository
- Be sure you have an issue tracking system
- Review/Create the Disaster Recovery plan for all of your critical systems:
- Source Code Repository
- 3rd Party Code libraries
- Issue Tracking System & DB
- Make a 'projects list' containing an ever-updating list of projects and their status.
- Have a 'welcome meeting' with the group you oversee to tell them something about you. Whomever interviewed you knows about you, but chances are the group you are now managing doesn't. Tell them your past work history, your management style, communication plan, and something fun and personable about yourself.
- Ask your group what would make their jobs more rewarding. Ask this question a lot at first because they won't believe you mean it until you have asked the question many times.
Good Luck! You're off to a good !
Mike J. Berry
www.RedRockResearch.com
My sister was recently promoted to manage a team of software project managers for a large bank on the East coast. She told me she gets to hire someone for the first time in her career.
I told her that hiring is always a bit of a dice roll, but I offered her some advice after having hired about 15 people at various times in my career:
1. The most important indicator of future success is past success. Good interviewers know this. Dig into people's past work experience and try to find out if they have been generally successful, or not. Some indicators of this are whether they have changed jobs often. If they jumped jobs on their way up the ladder of responsibility, this is OK. If they jumped sideways, or sometimes down, this is a red flag. Drill them about each job change. You will get interesting results. People will say they were fired, or had fights with their boss or coworkers. These are usually not your desirable candidates. If they fought with their previous peers and managers, chances are they will fight with your group also.
2. Look for enthusiasm. Enthusiasm is a great sign of a star employee.
3. Examine their personal lives (you really can't do this in an interview). But whatever they tell you can be a clue as to how they respond to accountability, pressure, authority, and responsibility. If they hate police, or the government, or have been divorced five times, then they may have issues with authority or responsibility. You have to be careful here because you cannot descriminate.
4. Call their references and ask their references if that person was successful, and if they would re-hire that person. Ask how socially distracting they were inside the workplace, and what time they came in the morning and what time they went home. Ask if they were a good team-member, and if they were typically dependable enough to get things done. Ask why they left and compare their answers to the candidate's explanation.
5. Because software development is not always a 9-to-5 job, a good question to ask is if they have any extra-curricular activity that would prohibit them from staying late if needed. I have hired people to discover that every day at 5:30 they need to pick up their kid from daycare. This obligation makes them incompatible with leading a team that may require them to stay late and fix a critical problem. This is a good thing to find out before you hire someone for a position like that.
6. Try to get them to express an opinion about something business related and that they are passionate about. Pay attention to how they express their opinion. Do they express themselves dogmatically, as if their opinion is fact and you must argue with them to object, or do they express their opinion in a collaborative way, where they would be more of an asset in a group discussion where others may disagree.
7. Pay attention to how they show up for the interview. Are they on time, and dressed for the part. Did they bring with them a copy of their resume? Are their shoes shiny?
8. Ask them several obvious question about your company to see if they did any research before the interview. Find something on your website homepage that they would know if they looked there before the interview. This is a clue as to their proactive abilities.
9. Pay attention to how they describe their previous workplace, management, and executive staff. This will likely be an indicator of what they will think of your staff.
10. If you sense an extreme level of dissatisfaction, high-maintenance, or lots of questions about what's in it for them---beware! This is an employee that will likely perform the bare minimum and be unnecessarily needy.
There are lots of books and tips about how to be the interviewee, but not so much is written about how to interview. I wish I could have read these tips years ago when I began hiring people. I hope this helps others and I would be interested in hearing what readers have to add.
< ike J. Berry
www.RedRockResearch.com
John C. Maxwell's book, The 360 Degree Leader
, is an excellent field-guide for navigating the challenges of leadership at all levels of an organization.
Maxwell starts his book by dispelling many common dysfunctional myths that are found at line-level, or middle-level management. Ideas such as "When I get to the top, I'll be in control," and "If I were on top, then people would follow me" are inaccurate adolescent attempts to understand the true nature of leadership--which is influence.
Maxwell continues by explaining the characteristics of influence:
- Position - Influence because people have to follow you.
- Permission - Influence because people want to follow you.
- Production - Influence because of what you have done for the organization.
- People Development -Influence because of what you have done for them.
- Personhood - Influence because of who you are and what you represent.
Maxwell gives examples of effective leadership in all directions: up, across and down.
To lead up well, he suggests you lighten your leaders load, anticipate your leaders needs and use their time wisely, and invest in Relational Chemistry--get to know what makes your leaders tick.
To lead across, Maxwell suggests you focus on completing your fellow leaders, instead of competing with them. Be a friend, don't pretend you're perfect, and avoid office politics.
To lead down, Maxwell suggest you develop each team member, place people in their strength zones, model the behavior you desire, transfer the vision from above, and reward the results you desire.
Overall this is a good book worth reading and re-reading every so often. I recommend it for managers at all levels.
Mike J. Berr >www.RedRockResearch.com
What is a value system?
As of late, corporations have discovered that mission-statements are only somewhat helpful in providing direction to a company. Being strategic in nature, they don't provide enough detail to govern tactical decisions made by the corporate employees on a daily basis.
To answer this need, value-statements, and value-systems have come into vogue. Many companies have value-statements to underscore their mission statements.
Just as some mission statements are more effective than others, some value-systems are more effective than others.
The simple approach to establishing corporate, department, or team values is to get everyone together in a room and have them suggest values the team should adopt. Voting happens, and the group committs to their agree-upon values.
After one of these sessions, the group might come up with a list like:
- respect
- trust
- excellance
- high performance
This list is a start, but only representative of a one-dimentional value system. These values, by themselves, realy don't project any context or weight.
A more effective approach would be a two-dimensional value system. A two dimensional value-system provides a greater context fabric. For example, you could say your group values:
- respect over cynicism
- trust over hope
- excellence over heroics
- high-performance over sub-optimization
These comparison value statements proved direction and context. This represents a two-dimensional value system, and is more effective that a simple list of values.
A three-dimensional value system is a prioritized list of these comparison statements. For example, you could say your group values these statements in this order:
- trust over hope
- excellence over heroics
- high-performance over sub-optimization
- respect over cynicism
This list shows that trust is the highest factor in inter-departmental dynamics. It shows that excellence is more important than high-performance (so no cutting corners!), and that the group values trust, excellence, and high-performance more than respect.
Every group will have their own values and differences in priorioties, but putting a three-dimensional value-system in place with your team is a great step forward in building functional team cohesion.
Once in place, a reward-systems can be built around your value system to promote it' ectivness.
Mike J Berry
www.RedRockResearch.com
Jack Welch, in his book, Winning, talks about how to create great mission statements.
He says most mission statements are dull, uninspired, and even unhelpful. Most groups write their mission statement to describe only what they are in business to do. While this is not wrong, it creates a whole bunch of mission statements that all look the same among competitors, and are not really valuable.
Welch suggests that a good mission statement not only describes what the company is in business to do, but how they are going to succeed at it.
For example, "We are going to sell lots of chickens," is not as effective as "we are going to sell lots of chickens by growing the largest free-range chickens and advertising their value to the industry."
Following his logic, I did some research and found some interesting comparisons:
Ford Motor Company in Europe's mission statement (couldn't find the U.S. mission statement anywhere online) is:
"Our Mission: we are a global, diverse family with a proud heritage, passionately committed to providing outstanding products and services."
OK, so Ford's mission is noble, but there is no explanation as to how they will succeed at their mission. Compare this to Toyota's mission statement:
"To sustain profitable growth by providing the best customer experience and dealer support."
Toyota's mission statement expresses their intention to make money by providing the best customer experience and dealer support.
Indeed, their mission statement tells what they are doing and how they will succeed. This is an example of an effective mission statement.
There is a business principle at hand here: Ambiguity is the enemy to progress. It's nice Ford wants to provide outstanding products and services, but there is no formula or direction given in their mission statement as to how they plan to do this.
Toyota states it will succeed by providing the best customer experience and dealer support. Are they succeeding at this?
In 2007, Toyota became the largest seller of cars in America. As customers, we vote with our money. It seems then, that they are providing the best customer experience, and are fulfilling their mission statement.
On a lighter note, Enron's mission statement is/was:
"Respect, Integrity, Communication and Excellence."
Mike J y
www.RedRockResearch.com
I just finished reading The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich, by Timothy Ferriss. Timothy Ferriss is a 29-year old self-made millionaire, TV actor in China, athletic advisor to more than 30 world record holders, Chinese Kickboxing Champion, first American to hold Guinness world record in Tango, speaker of four languages, and a four-world champion cage fighter. This book now makes him an author.
Ferriss's book is about beating Corporate America, and becoming content and happy using the newer technologies available to us today.
He provides a formula for successful entrepreneurship. One important point he makes is the need to find a market, before investing in building the product. He suggests this successful pattern:
- Pick an industry you understand.
- Target a product you can Create, License, or Resell.
- Look at competition to see how you need to differentiate your product. Examples:
- More credibility indicators
- Offer a better guarantee
- Offer a better selection
- Offer free, or faster shipping
- Micro-test your product (before you put any money into it), by using eBay, or Google Ad's. Microtesting is "probing" customers to see if they would buy the product. Some examples:
- Put an add on eBay, then cancel the add minutes before the auction ends, to see how much people are willing to pay.
- Build a dummy website, with item, description, pictures, and pricing. After the user pressed 'purchase now,' display a "Thank you but this item is temporarily unavailable." This enables you to test your conversion rate up front, without needing to invest in manufacturing, etc.
This way, you can determine up front if there is a market for your product. He suggests putting the price on a separate webpage altogether so you can measure the effects that changing the price alone will have on your conversion rate.
Ferris goes on to explain how to transform managing a business into automating the business. He suggests time management is a thing of the past. The key to living better today is to remove distracting inputs from our lives.
He talks about outsourcing every part of you business and empowering the outsourcers. He talks about only answering email one day a week, and having your cell phone message redirect people to you email.
The final part of Ferriss's book talks about what to do after you have successfully started and automated you business. He talks about getting out of your comfort zone, travelling, learning new skills, and new languages.
I think this book is an excellent read, and surprisingly cutting-edge. It's nice to read a business book about PPC, Google AdWords, and eBay microtesting. Makes me feel understood.
Mi Berry
www.RedRockResearch.com
I finally finished Halo 3---in Heroic mode! Heroic mode is one notch above Normal, and one below Legendary. For those of you that have not completed the game, relax--there are no spoilers here. I will offer some strategy advice, though.
Halo 3 is the third installment in Bungie's highly-popular XBox video-game series. The storyline takes place in a futuristic world that has been infested with an alien army. Led by a creepy villain who calls himself the 'Prophet of Truth,' the alien onslaught will annihaliate the entire human race unless, of course, you and the space marines expel them.
Halo 3 is a little twist from 1 and 2 because you have an alien-defector who helps you during most of the levels, and well, it's the Xbox 360 this time!
The graphics are outstanding and the playability is great. I remember playing Halo 1 with my friend, Greg Wright. He came to my house the day I brought the game home. It was around 5pm when we started playing the game. After what seemed to us to be about three hours, his wife called us to ask if her husband was ever coming home again because it was 2:30 am and she hadn't heard from him.
With Halo 2, my neighbor Rob and I finished the campaign game in about two weeks. We'd play every night until about 1 am. By then, our brains were so fried we couldn't speak properly. We had to use hand signals to communicate 'good-night' and 'same time tomorrow.'
My all-time favorite games were Bolo and Bilestoad on the Apple II, Doom and Klingon Academy on the PC, and 007 on the N64. Ghost Recon is my most-played XBox game, and so far, Halo 3 is the best 360 game.
Heroic is a difficult level. It took me about three months to complete, playing solo and moderately during that time. The first few levels are pretty easy. You basically shoot anything moving at you. As the game progresses however, you start facing more difficult aliens and tougher challenges.
Here are some strategies that helped me:
1. Learn to be patient and lure the bigger aliens out one-by-one. You have a much better chance of being successful facing them one-by-one.
2. Don't feel compelled to annihilate every alien you come across. Sometimes, the melee was so chaotic it was simply easier to run past everything and through the next door.
3. Discover your melee-punch attack. This is where you run up on an alien, and punch them with your weapon. I found this to be the best way to clobber a tough alien. One or two hits and you can take down a Brute. This works especially well inside a shield-dome.
4. Chieftains are the toughest opponents. Wielding gravity hammers, and invincibility armor, they strike pure terror when they run at you. There are three excellent techniques to use to defeat them:
A. Blast them with plasma cannons. The continuous impact will stun and drain them of health.
B. If you have an invisibility shield, go invisible, quickly walk up behind the chieftain, and melee punch him in the back several times.
C. Learn to jump up over them when they run at you. You can stay alive and shoot at them for a while doing this.
5. Attack the exhaust vent of the Wraith.
6. Attack the legs of the Scarab SuperTank, then jump on, run up to the top, and blast it's power source.
7. This should be obvious to you-- running over the aliens is easier than shooting them.
Halo 3 is a guys game. It's full of marines, monsters, lasers, rockets, jeeps, four-wheelers, space-ships and shooting. There are only three women in the game. A dispatcher who you never see, the operations commander, and an attractive computer persona.
There are nine levels. The environments range from jungle, to desert, to internal facilities, to inside creepy, fleshy-spaceships. The final level is a unique racetrack-like experience.
I really liked the humor in the game. The little grunt aliens see you coming and say "Oh, no! A monster!" Sometimes the little grunts poke fun at their bigger alien buddies by saying "Brute's are jerks."
The brutes have their own humor. They are big, scary aliens that speak with deep voices. Sometimes, when you die, one of them will say "All to easy..." which is a direct quote from Darth Vader.
The brute comment that makes me laugh the most is sometimes heard when you are unfortunate enough to come across a mass of Brute aliens marching towards you. One of them will say, in their deep, Vader-like voice, "No inappropriate touching!"
I noticed a recent news snippet that Microsoft has released it's seven-year hold on Bungie. They're now free again to wow us with more great games.
I really enjoyed playing this game. I guess I'm ready for some Halo parties, now. If you are having one, let me know. Find me as MBER on Xbox Live. I'd welcome some comments from others who have finished the game.
Mike J Berry www.RedRockResearch.com
Ed Sullivan's book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.
In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do. It's refreshing to read a software development book that tells you "what to do" for a change.
Sullivan skips past conventional theory and provides real-world experiences and wisdom for how project managers and software development teams can succeed in this challenging industry.
Novel to Sullivan's recommended approaches is the concept of one-team-per-project, reporting to a single manager. Conventionally, most companies split out development, quality-assurance, and product management into different departments. Sullivan describres this configuration as a model set-up-for-failure. Too many factors, he says, complicate team performance when each team-member is reporting to a separate manager.
I consult with software development companies to improve their product delivery speed and product quality. I call Sullivan's single-team suggestion the "lean model," and I agree with his conclusions.
In the manufacturing sciences, there is a belief that the production manager and the quality assurance manager have an inherent conflict of interest, therefore, they should be separate departments within a manufacturing organization. Many business books are written about this.
In software, however, this model is a less-effective approach. It can work, but it creates barriers between project teams for several reasons:
- Contention can arise as an "us vs them" mentality builds when team-members go back to their respective departments dougouts, to commesurate with their non-project department staff.
- As team-members need each other to succeed, it becomes easy for a team-member in one department to delay requests, or grandstand, because their department manager "has asked them to work on other things this week."
- A department manager will tend to be uninformed about upcoming urgent project team needs and may unintentionally delay the project by asking their employee to do other things at the most inconvenient time for the project.
- A lack of focus will accompany any project team-member who has continuous department responsibilities outside of the project team.
- If contention arises, the project team-members from different departments may value disparaging another department, rather than working together to solve the problem at hand.
Sullivan goes on to discuss effective hiring techniques, retention techniques, and general healthy corporate culture factors. He talks about ranking employees in terms of inner-circle, middle-circle, and outer-circle. This reminds me of Jack Welch's theory on differentation.
Another novel concept Sullivan describes is his simple but effective project scheduling process. He breaks each month into daily rows, listing team members names as column headers. Inside of each cell is a letter/number combination representing who needs to be finished with what task on that day. In my opinion this is much better than a gantt chart.
Sullivan goes on to describe meetings, schedule management, release management, and project closure.
I found this to be a beneficial book to read. I would recommend reading it topically, as a reference, rather than cover-to-cover.
Mike J Berry www.RedRockResearch.com
About Me:
I've been involved in commercial software development since 1991. I've worked in various positions including:
- Retail Software Sales
- Support Technician
- Mainframe Programmer/Analyst
- Windows Programmer/Analyst
- Development Team Lead
- DBA
- Systems Architect
- Corporate Founder
- Development Manager
- Vice President of Development
- Consultant
Holding a Bacholors Degree in Information Systems and Technologies from Weber State University, I have worked or consulted successfully for the following companies:
- Zions Bankcorporation
- America First Credit Union
- Regents Blue Cross Blue Shield of Utah
- ChartLogic, Inc.
- Weber State University
- TeleperformanceUSA
- LDS Church
- Mortgage Computer Applications
- DAKCS Software
- Streamlined Information Systems
- Golden Getaways
- Beehive Clothing
- Software Plus
States I've visited (in red):
Create your own personalized map of the USA
Countries I've Visited (in red):
Create your own visited country map
I love mountains, deserts, and jeeps. Here's a few fun jeep videos:
In Steve McConnell's book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.
Researching from NASA, IEEE, and some other industry giants like Grady Booch and Tom Demarco, McConnell summarizes software development into six stages:
- Planning
- Design
- Construction
- Testing
- Release
- Wrap-up
McConnell also offers some great ideas like keeping a project history to record lessons learned and actual project data (time to completion, lines of code, etc.)
He talks about Quality Assurance practices and team development. Interestingly enough, his book starts with a diagram and commentary on Maslow's human needs heirachy, and how the needs of a software development group are similar. He proposes a Bill of Rights for the project team, and a Bill or Rights for the customers.
He offers a project health quiz--allowing you to measure your project to see how probable it is at succeeding.
McConnell ends his book with a chapter on project do's and don't, borrowed from NASA. These are:
Software Development Project Do's:
- Create and follow a software development plan.
- Empower project personnel.
- Minimize the bureaucracy.
- Define the requirements baseline, and manage changes to it.
- Take periodic snapshots of project health and progress, and replan when necessary.
- Re-estimate system size, effort, and schedules periodically.
- Define and manage phase transitions.
- Foster a team spirit.
Software Development Project Don'ts:
- Don't let team members work in an unsystematic way.
- Don't set unreasonable goals.
- Don't implement changes without assessing their impact and obtaining approval of the change board.
- Don't gold-plate (don't add features no customer asked for).
- Don't over-staff, especially early in the project.
- Don't assume that a schedule slip in the middle of a phase will be made up later.
- Don't relax standards in order to cut costs or shorten a schedule.
- Don't assume that a large amount of documentation ensures success.
Overall, this is a great book for new software development managers, and software development mangers who have chosen SDLC, or other non-Agile development methods. Published in 1998, this book came out before the Agile software development movement. Regardless, it's a good book to refer to occasionally.
Mike J Berry www.RedRockResearch.com