Process:
I call this stepped validation.
There are some processes out there that people don't care about or know about. This to me is *scary* territory, but it is also the land of opportunity!
For example, the process of publishing files to a destination is probably well baked but not very well understood by me. I had a situation yesterday were I published "with overwrite" to a destination and the overwrite did not succeed. So now, I am using the more brute method of "delete destination and publish".
In other words, I am doing something sub-optimal because I don't understand the process.
These sorts of areas are the land of opportunity. But when will I / we have time to look into / investigate them?!
If you're on a deadline, don't start what you don't know how to do unless it's the last thing to do.
Two really different things here: the process and its data.
The process is the thing that "works". The data are the things that the working produces (from both its working aspects and non-working aspects).
You can know the flow of the process without knowing much about its data. You may understand how things move and change but you won't necessarily understand what the data MEANS (or its purpose).
The skill/capability of knowing what the data MEANS is that of the data analyst.
The skill/capability of knowing how the data flows and its consumers is that of the process analyst.
Be both but you'll often have to choose one or the other.
Divide and conquer!
I learned a new trick at work today that lets me to make better, more complete, more interesting solutions now. I'm stoked.
Learning new stuff is great, but it abounds!
New technology changes the game and the workflow. Typical scenario:
Q: How did the thing/process used to work? What was the old workflow?
A: I don't know and I don't care!
People want new and better things all the time and when they learn them they forget what they never knew.
In project work, the Statement of Work (SOW) is the legal document intended to keep things in order and denote the shared understanding of deliverables between supplier and customer.
Don't update the SOW with each change to the project, only big ones, new deliverables, removed deliverables.
Contract at a high level: Be a service provider and offer your services (planning, development, etc.) on a daily or weekly basis. Charge for the number of resources. Get your estimates right and try to stick to them. Communication change.
Projects don't have to be bigger than a day and a couple of people but often are.
We've all probably taken jobs or gotten into situations—be they marriages, cars, or vacations—that were billed as one thing in the beginning and then turned out to be something completely different in the end.
This pattern is probably the norm in fact.
I took my current job for the money, company, and idea that I would be traveliong between Dublin, Bangalore, Singapore for a week a month.
Fast forward to this job today and I am leading projects but I have not traveled outside of the city and I am mostly doing software development. The pay and the company are the same. I am okay with all of these things but they are very different from what I expected coming in.
So I have a choice:
Those are the three basic choices I think we all face in our lives and jobs every day.
We are free.
An important part of leading or delegating work is being able to paint a picture for someone of what they need to do.
Often as managers we don't know what the person has to do exactly but they do have to start so there is something to review! The product can be made "tight" later but first the bulk of the work has to begin. You should be 80% sure what the right product is yourself or you shouldn't have anyone begin. This is the definition of start. (Contrast with Definition of Done in the Agile methodology.)
In general the team *collectively* owns the work. The person doing the work is the knowledgeable and capable one and the on-lookers are able to comment.
Good systems are open and encourage a full review of the entire work product by those involved or curious. There are no egos.
By knowing your assumptions up front or empowering/enabling the worker to make assumptions and then vet/verify them with the customers, work can flow and customers can be satisfied.
Developers are a lot better off when they get to "pair" with peers and analysts who can help them think through the problem and the plan for solving it. Coding is not easy. Learning new programming languages (any language for that matter) is not easy.
Learning languages rapidly should be one of the core capabilities of a programmer: "Oh, you only know one language or skillset / toolset? Sorry, I don't need you."
I'm sure some programmers prefer to read a book and learn the language that way. That's fine but to me this seems slow and tedious and may not even work. Maybe you don't even need that knowledge once you have it. But then again, I'm really not a book reader, I'm more of a doer and web-searcher and like to unblock myself now, when I'm stuck.
Enter the web, books, and peers.
I want to pick a project that requires (or might require) a technology and try to solve a problem with the technology through practice. It'd be nice to have someone that's used the technology to work with me but it's not required. They just have to be a programmer that's willing to learn and be stumped.
This might sound slow and tedious but at least I'm diving in and going for it; and building my network.
A recruiter the other day asked me what my ideal job was. Not sure what answer I gave them but now that I think about it, what I want to say when anyone asks me that question in the future is two things: A) Be independent and B) have positive cash flow.
Being independent is important to me. It means I am in charge of my own destiny.
Having positive cash flow is also very important to me. It means I am able to survive and that I am not spending more cash than I am making.
I really don't want to have a bunch of ups and downs in life.
10 years ago I was independent and had a positive cash flow. Then I graduated from college.
8 years ago I was not independent and had a positive cash flow. Then I bought a condo, a truck, and went back to school.
5 years ago I was not independent and did not have a positive cash flow. Then I started making better money.
Today I am not FULLY independent (am employed by another company but am working on what I want to be working on and having fun) and have positive cash flow.
My next step is to become independent again and keep my positive cash flow. I hope I can make that happen soon!!!!
Engineer-types can only do so much at once. You want them figuring out how to solve hard problems all of the time. Solving hard problems = making big money $$$$$, you know!!
But once this senior engineer person has named the solution to a hard problem, the engineering team has to come in to solve it indeed. (This costs money and should equal revenue for your organization).
Your senior engineers should be your top sales guys. Everyone else should be feeding business to them. They are probably the bottlenecks of your organization since real hard problems (remember this means real big $$$ opportunities) are many in number and hard to solve ie process!
Consumers *will not* purchase products for one of just a few reasons:
Consumers *will* purchase products for one of just a few reasons:
All the features and attributes in a product have to be about value INTERNALLY to the producer, but some of those features have to be about excitement and frivolities externally (gotta make that icing and excite the customer!!!). All of this requires work in the end, but some of it is fun and about sales and the customer. Maybe all of it should be fun!!!
Do this with your life partner or mate: make dinner, play a game, bake a pie, plan travel and go, have a conversation about something important.
Do this with your workmates: Resist producing things completely on your own with no feedback or shared responsibility. Look for opportunities to collaborate and co-create. Find opportunities to work *with* others. Create a product with them. Learn with them. Don't feel like your time together should be minimized, rather that the quality of it should be maximized.
It's your legacy in a way. Did the stuff you produced actually last and make a positive impact on the organization as you'd hoped or was it immediately uprooted and removed the moment you left?
When you work in organizational change management and project management, you'll realize at some point that the process you're creating (the outputs of your day-to-day work, the principles you instill, the standards you create, the policies you implement, and the practices you follow) is *the* essential product.
How do you market this product? How do you make this product consistent and continuously improve it? Who are your coaches in it?
It seems like there's almost always a gap between what we might think we want to have happen and what actually happens. Ie plans are infrequently realized.
The next step that is usually realized in a work/team environment is either:
The former is more collaborative and probably less frequent. It promotes better teams.
The latter is probably quite common because the actors in the company are the doers and there's usually no one standing in the way of the doers. People typically favor action. Another consequence is that those with the ideas and suggestions rarely get to implement their ideas because they're not the doers.
Sometimes the only solution you have is too monolithic to consider. Bail on it and keep thinking.
It could be argued that creating a process or prototype / product / model of something for the first time is not the same as producing or selling that product in mass scale. But they're kinda related, right?, because it's all about changing and innovating… I'll try to distinguish between the creation and the birthing.
Doing something for the first time is creating the process or business. It is akin to giving birth.
Selling the product after it has been created and first shown is akin to raising the child. It is a constant selling process.
Sometimes others' problems really are not your own; but they have to be. When I encounter this type of situation, I like to let the other person drive; make them set the sense of urgency and schedule things. Let the sense of urgency happen on their side. When they approach you with their thing, be nice, have good customer service, and move forward.
Don't waste your time thinking about something you could do later. If you're not fighting a fire or doing something urgent and important now, then you're wasting your time. Find the person that's fighting fires and take their direction on how they need help. If they don't need help, then something's wrong; you're not supplying them enough resources.
You've basically got two choices in work and getting things done from a communications perspective: solve it or sell it.
Sometimes the sellers have to be solvers, and sometimes the solvers have to be sellers.
Know your role and what you have to do next. Be flexible.
There are two primary learning methods in my experience:
Learning via method #2 is a luxury that we sometimes get. We want more of it but can't always find it because we don't know enough people who are as smart as we are or know as little as we do. I'm currently in a project that requires quite a bit of #1 work and I don't really have too much help on it.
We need to get better at learning in both of these ways.
From what I can tell there are just a few sensible ways to pay a professional services worker:
And metrics at play that would allow you to build a model are:
I want to be able to get paid for all of these methods but the company has to first determine how all of these options work such that the company can continue to grow rapidly and sustain its growth. No small task but I hope to continue to think about and develop a formal, flexible software model for this.
Business intelligence are the things that happen "behind the scenes" to achieve a business outcome. Business intelligence are the outsourced or "hidden" capabilities that the IT application or service provides for you without you knowing.
More later.
In order to get ahead we sometimes have to "kiss ass". It's not fun but we probably all do it sometimes. It's even a skill I would argue.
But it's not the same as "kicking major ass" and it's really not the goal. Let me explain. We can get ahead in one of two ways: A) climbing the ladder and B) doing good work. Climbing the ladder *may* come as a result of doing good work but can also come from kissing ass and "who you know".
Try to climb by kicking ass (doing good word) rather than kissing ass (building relationships) but recognize that don't matter and you probably can't do one without the other; you attract more bees with honey.
Why is this true? Life is a collection of tests. Tests must be clear, visible, and verifiable to be quality and so must life to be brilliant, resistant, and attainable. Test life with clear goals, visibly today.
How and why is this? Somehow it's true. If you see your organization or life as a collection of tests, you're set to succeed. But you need to make this a visual, visible, and measurable (external) system/process. How? Read on.
You have to know and define the *process* and *way* by which you will achieve your goals; you have to develop a tool and measurement system that throws off data that you can analyze. How? What's the data, what's the system, what's theprocess? What's the context? Read on.
You want to test and achieve your most important goals. Project management can help you get that. Goal statement and testing / verification of goals to achievement is necessary. You need data to *control and manage* your business. This gap *is* the system; the third leg of the define, do, achieve goal. It's how you adjust and get feedback.
A project is collection of tests. An organization is a collection of tests.
Tests arise in a couple of forms but the bottom line is that you have to be able to verify them *in* the computer, not in your head, against the model.
The activity of running a life or business *is* managing a collection of objectives and tests. This is often not done visually or systematically and is most commonly done randomly and individually. Bad!
As leaders, let's reduce the variability in our lives and organizations by managing things concretely and visibly; data-driven. Start unit testing your development projects today. Build your test suite as you build your business.
For years I've known about software testing but I never had to apply it. This probably means that I wrote crappy software; but the bottom line is that people "accepted" it, one way or another. I used to just "get by". That all changed today.
I used to be a DEVELOPER, plain and simple. I'd write a web site and show it to the customer or users and it they said it was done, it was done. Then I became slightly more advanced in my practice and learned about UML "use cases" or "scenarios"; user stories. I learned how to write a stories and workflows and make software that aligned with those high level structures. But there is an even lower level that I had to go to that I was missing: unit tests. These matter!
My brand new tool/to y in my tool-set/toy-box are unit tests. I love these. These are important. They are critical. They are potentially even THE GLUE that could unify technical and non-technical types. They represent A LANGUAGE that can be understood by technical and non-technical types together that could be a unifying force in the process of designing custom software and business rules.
Acceptance tests, use cases, scenarios, and this kind of stuff are too "high level". In a way they are very "ethereal" (understood by few) and unverifiable. One person might think the test passes, and the other doesn't. In that sense they are very QUALITATIVE and ambiguous. Bad juju in business and softare!! Bad!
On the other hand, writing unit tests and ensuring that the code or business rules you write (policies) adhere with the spirit of the law is a beautiful thing. They are very low-level, understandable, and I would argue are NON-TECHNICAL. Yay, a non-technical thing for describing the business rules and logic that must be written. Awesome! Win win!
Overall, I think our organizations need three, types of people: Those who make rules, those who break rules, and those who watch the system and determine what to change. Each of us may need to be all three types of people sometimes; wear many hats. But having these clear distinctions between responsibilities is, I think, game-changing.
When we write spaghetti code we mix all of these components up. We're not clear on the jobs of things so we make everything do many things. And it gets confusing!
On a data warehouse I'm building I have to be very clear on what are my inputs (the stuff flowing in), what is my process (the things I'm changing and I have to use temp tables during that process) and what I am outputting. Each one of these stages and events needs to be very clearly separated; ie I can't ruin my inputs while creating my outputs.
I have to preserve everything but also be able to create and destroy everything as well. That's a lot of power to harness.
Merriam-Webster's defines the word tenacious as, "persistent in maintaining, adhering to, or seeking something valued or desired". The only thing I would add is do this TOGETHER with someone and be tenacious about your ideas WITH others.
If you are good at product development, then YOU and not the customer will keep the product backlog. Never burden the customer with the list of open items or anything like that. The goal is work and progress and not the list.
Today I had a meeting with the customer and we agreed on the items that needed to appear in the next iteration. We made the list together and I shared it with him over email before I began. I'm now code complete on all of the changes. But I don't want to burden him with this detail. All he wants is quality, working software, not any administrative work.
So I'm going to demo the product to him tomorrow and tell him that all of the stuff we'd talked about last time was integrated and that we are now on a whole new review cycle. This keeps things fresh and focused.
Don't carry too much process baggage with you. The goal is the product, not the process, supporting artifacts, or other metadata.
Having a meeting with someone where you show them your work and/or art is great. Be thankful for an audience and a customer!! In these reviews there will ALMOST ALWAYS be comments, needs, and next steps (at least you should hope there are or you're likely out of a job!). So be very clear on what these are and commit then with them to the next iteration. Work with them through the process without bothering them too much. And then, when you're ready for a big demo with them (and another iteration), go for it!
Just because you demo your product or project to someone doesn't mean that you're done with it but sometimes you are indeed; that's the definition of "shipping".
As creatives, developers, makers, and artists at some point we have to let go of our art pieces and realize that our demo is indeed our FINAL demo; our MASTERPIECE…and we stop working on it. We ship it. We let it go.
There will always be more comments and more feedback on that thing but at some point we look the other way and move onto the next thing.
Think about De Vinci and the Mona Lisa, for example. At some point he surely said, "I'm done" and walked away. The feedback kept coming on it but he didn't look back and modify THAT piece of art; he modified others.
Organizations have a top for two reasons: accounting and accountability purposes. In our organizations we need "single wringable necks" and modular, replaceable parts so we can distribute risk and seek remedy as necessary. We need to know the parties we can rely on and those from whom we can seek remedy. In a way we are distributing our risks and interests to many players; outsourcing.
When it comes to organizing things, we like to "pool" our resources amongst many players; but we like each of them to have a very clear role and responsibility (jobs).
Take the case of cloud computing: "Put it in the cloud." (A single, centralized place). The redundancy in the cloud is the thing that *would* make us trust it. We as people rarely trust single entities alone, in isolation. We frequently create backups and distribute our risk; we often "trust but verify".
We need the things in our lives to do specific jobs for us so we can rely upon them for living our purposes. The only way to manage in this outsourced context in my opinion is to make our things' responsibilities very clear; oftentimes contractual. When the things aren't living up to their responsibilities and agreements, then we need to change them, the contracts, or start wringing wringable necks.
Given our current experiences, situation, and knowledge, we are able to determiune "What It All Means" and decide what we are going to do next. When we do some, most, or all of those next things we are able to re-assess where we are at and where we need to go (again). In other words determining "What It Means" is context-sensitive, constantly changing, and fluid. So, BE AGILE!!!!
In our work lives we frequently have to make and keep time-based commitments and estimates and work to schedules. This sucks but it's sometimes and for some often a reality. How do we cope and deal with high-pressure situations like this? By NEVER UNDERESTIMATING!
The old axiom is "under promise and over deliver" and that really is the goal. It helps with work life balance and a variety of other things. Doing this well has so many benefits it's amazing. I hope you can do this well and get good at estimating "just right" to give yourself some breathing room but not be overly padding your estimates such that's it's ridiculous and you're seen as lazy.
I was really good at building web-based systems when I graduated from college in 2000…at least for the time in my head. I was quite confident about my skills to say the least (cocky is probably nowhere close to an understatement). But my problem at the time was that I hadn't yet been able to realize my vision and in a lot of ways I was pretty insecure. I was very ambitious and wanted to build really big systems—and did build some—but I wanted more skills so I went back to school so I could achieve more.
When I went back to grad school at the University of Washington Foster School of Business I learned a few things:
Because of #2 above, I decided that I really didn't care too much about IT anymore and what I really wanted to do was get in management and AWAY from IT. I tried.
Fast forward two years from then to last fall when I was unemployed and needed work. I got a job as a software developer again but I was really rusty with my skills by this time even though I was probably WAY sharper analytically and from a thinking perspective than I ever had been. It took me many months (9 now?!) to feel confident with my software development skills again. I'd now say that I'm a pretty good software developer again. And I'm not worried about being one at the moment. It doesn't bother me that I'm writing code again because I know that I am also a talented analyst and project manager and I have my masters degrees and PMP certificate under my belt; my confidence is currently pretty high.
In total I guess I'm saying that I'm very thankful and appreciative right now for the roads I've been down and the place that I'm at now with my career. I'm 33 years old, 10 years out of undergrad, 5 years out of grad school, and I feel pretty good. I'm a consultant for a pretty cool company and make a pretty good wage with benefits. I like what I do. I'm technical and non-technical, businessy and nerdy at the same time. I think that I can go this way or that in my career (make choices that don't have ridiculous costs and consequences) and I really like that agility. I'm happy I finally landed here, it was a very long road.
It's very desirable to get into a pattern where you plan, then work, then deliver, then review, then do it all over again. The goal is to limit interruptions and make things predictable. Let the people do their jobs and don't let the jobs conflict or adversely impact one another. Harmony is a good word here. Of course this would be nice but it's not always possible. These phases, people and interests often overlap and sometimes get out of sync.
My current work project has a fairly decent cadence but it is not perfect. Overall we're doing a pretty good job. We usually plan on Fridays and deliver on Fridays as well. We commit for the next week late Friday. This gives us a day to assess where we're at and what we're going to do next week; but of course these plans can get interrupted by changes in the following week. In our project, the policy is "what is committed is the sprint" and everything else is the backlog. If we finish the sprint early, then we can work off of the backlog items of course. We've been lucky to not have too many fires. Sometimes the sprint itself generates more backlog items.
In my opinion a Business Analyst is someone who "gets it". I would say the same for a Solution Architect and Product Manager. They understand technology and programming well enough to determine the solution with the customer. They also know and understand business well enough to think through what's practical, pragmatic, attractive, and scalable from a business perspective. They are smart enough to work with developers and engineers to explain the solution requirements and do some translation.
Contrast the business analyst type person with a database person (what are their skills other than they can write SQL and work with databases?), and with a user interface specialist (who knows how to make a pretty user interface but who cares?).
Where's the process person in all of this? Who's the person that cares about the system and customer more than they care about a particular technology or capability?
In business in the end it's all about making kick ass products and services that people love; it's about engaging and possibly entertaining people. Loving one side of things (business, technology, user interface, design, etc.) too much is short-sighted. Focus on the customer, the market, and how to make as many people as happy as possible; and forget about yourself in the process.
From where does this type of confidence come? How and from where do people get it? Experience? Is there a source where I can find more of this energy?
You can't have confidence all the time. Sometimes you can "act as if" and get by but that not everything; unless you're in sales. If you are ever on the hook to do the work or job yourself (engineer a solution or produce a product), you have this sense of urgency and serious about yourself and that is not confidence. In fact I think that having that sense of urgency and seriousness about yourself actually DETRACTS FROM your confidence in some way. Confidence can be thought of as arrogance.
Is it so bad to doubt or be skeptical? Maybe in sales.
I guess I'd rather be scientific and fact-based rather than overly excited about "opportunities" myself.
Being confident all the time isn't possible but we want it for ourselves. When it comes to work, in the end SOMEONE has to be the one who takes the lead and ACTUALLY delivers the product with the skills, resources, and connections they have to the customer. This product has to be delivered to the level of quality that the customer actually requires, to a "confident" place. Delivering quality, to me, is confidence. But to get here requires much, much more.
I'm doing it right now. It's the worst. You have to do it sometimes but when you do it, you create redundancy and inefficiency in your program.
Alternatively—and sometimes there is no alternative—centralize your logic and create reusable components. Time-constraints and complexity sometimes (frequently?) prevent this from happening.
The innovation can and will come later. Doing things poorly is often a good lesson for how you'd do it better next time.
This is the type of culture that I want in my business. BluWater Consulting's scrum practice did this very well. Everyone on the team had a variety of skills from UI to the database and everyone TOGETHER was responsible for delivering the product successfully. The bottlenecks in the team were what they were and there was no preconceived notion that the company could perfectly staff a project with just the right resources. So they instead hired good balanced players and made sure that OVERALL they had the competence available to build the solution. They started into their projects aggressively and the team sorted itself out and figured out how to organize in order to deliver as effectively as possible; roles were project specific and always will be because there are different casts of characters on every project.
My current company is considering making teams of UI specialists people and teams of Database specialists generally and for each project. I'm not so much into the idea. I don't think we should be creating practice areas; we already know who the specialists are. Let's not take the focus off of shipping the best product with the resources we have and think about "organization". We need to organize around THE CUSTOMER, not ourselves and our competencies!
Yes, some people are talented designers and very artistic and others are highly mathematical and systems thinking but let's not pre-focus our teams on concepts other than the customer and getting things done.
When I was on the varsity baseball team I spent a lot of time as the "book keeper" because I was not good enough to be playing. I got REALLY GOOD at keeping book in fact. That's probably how bad I was at baseball.
I was doing programming working on my project for the customer today and thinking about some of the conventions and practices I am following on it—from coding standards to the way I format the font and release notes when I share the product with the client—and was reminded of how I used to keep the book. I used to be VERY anal about how I would keep the book and I would not let some of my teammates keep the book. Even they adopted my conventions and followed them. I heard years later that my format of book keeping on the baseball is still in tact; it's called "Veal book" and the team regulates it.
The goal in any business is to be consistent and let others see your quality ways through the conventions in your products. Be good and careful with your products. Put on fit-and-finish. It shows through.
I recently had the opportunity at work to accept help from a new resource. Accepting his help would have taken a lot off my plate and freed me to do other things; it would have taken a lot of stress from me. I came to find out after the resource was provided to me that he was also expected by a paying customer at the same time in her group full time. Because my project has a limited life and I believe I have no more right to the resource than a paying customer, I decided to let the resource "go" and I am now back working primarily by myself really long hours again; it's not fun. But I don't regret the decision at all; it's better for everyone (except for maybe me, now)…I'll elaborate.
Other than this lesson on the project I've learned a lot of other things, too. Below is a list of my top lessons from this project.
Some quick background first: I'm new to the company, new to the client group, and new to the type of project/product being produced: a reporting system re-engineering existing reports and merging several systems into one. I've been with the company for just under three months now and was hired on this project as a business analyst / delivery project manager.
Top 15 Lessons from my current project:
Overall I learned in this project that business is about risk and taking risks. Some people can tolerate more risk than others. I took this job not thinking of it as a risk but an opportunity. It has definitely been an opportunity for me to learn a lot about this organization and about getting things done. I also learned about a new subject area: report system automation and system integration.
I hope that my company matures its operations rapidly, that my current project wraps successfully and becomes a program/lasting account, and that my next project is fun, insightful, and does not require so many hours. (I worked a 14 hour day today BTW, and two weeks ago I worked 40 hours in three days. That is NOT THE GOAL!)
This is probably one of my bigger passions in life. I'm not sure why I like it so much. It must be a "control" thing for me where I want to have control over a domain or set of people; a system. I want to create new domains that I can advise.
Dealing with talent is tricky. In my company we have a guy that's good at organizing people and things and a guy that's great at selling things and dealing with perception. These two—if they knew each other well and how they can benefit each other—would be the perfect duo to kicking major booty. They don't currently realize how critical each other is to their mutual success—and mine. I'm trying to put bugs in each of their ears so they can start working together. Teams require strong individuals and strong relationships. Always fix the weakest relationship in the team.
What the developer cannot see (but tries to understand) is what the end user sees. Through feats of magic and mayhem, the developer tries his very hardest to be in the shoes of the user and understand all of the needs that the user has. If the developer did not understand (or think he understands) what the user's needs are, then a solution could not be developed and delivered. Yeah, a developer could "totally wing it" and shoot in the dark for a miracle but that's not the goal.
The developer has to put herself in the shoes of the user but can never BE the user because she IS the developer. It's hard to be two things at once and this creates a blindspot.
Not too many people are good at this. I'm not. As people we have to get a lot better about this. What do I need? What do you need? How can I help you? Many of us are probably either unwilling or unable to tell people what we really need. Some of us—myself included—may believe that they don't NEED anything…that they're "good". But none of us are good. None of us are complete. None of us are without the need to connect with and relate to other people and key concepts.
I'm setting a goal for myself to tell people what I need more often.
For every action there is an equal and opposite reaction.
Don't just ask for stuff because you want it. If you're doing that, then it means you don't really understand what you need. Maybe you don't need anything at all. Maybe you are not deserving of using the thing that is given to you. Maybe if the gun you want is put in your hand you will shoot people with it. Be careful on what you wish for.
Trust is a big thing and something that is very hard to manage.
When you get to the end of a project, it's good to level with people and tell them how you feel. Not a full-on berating of the individual but an assignment of responsibility for consequences rendered. Do you agree?
In the company that I work for we have a very flexible way of working. It is very "agile". There are no managers per se, although the pecking order is pretty clear at the highest levels. When it comes to the "consultants" (workers), however, things are very open and undefined. This is both good and bad. For example, in me looking to figure out what I am going to do next, I am likely going to find someone within the company who "needs help" doing what they're doing. This person could also be a client who "needs help" with what they're doing.
One of the following things could happen:
I'm hoping in my next gig that I find #2 but I'd be just as happy if #1 occurred.
Pray it's not you but beware because it could be. Figure out what you have to do/adjust in order to comply and take the pressure/attention off yourself. Do everything that's in your power to get out from behind the impediment, project, or task you are facing. If the project / problem / focus does happen to be someone other than you, then make sure they know it but be kind in how you tell them about it. Help them through the process and change curve. Don't embarrass them. Give them a moment to shine. Make the focus constantly change. Everyone should be the impediment / bottleneck at least once in your project. If they're not, then they're not critical path or necessary.
At work you're in a much better position if you are the guy that *is* the bottleneck than if you're the guy that *creates* the bottlenecks. Don't be the latter. You'd hate to be the guy that makes things slow or inefficient in the system through his actions in/on the system, tasks, and people. We all have limited bandwidth but don't be the guy that creates limited bandwidth in others. If you are this guy, question your policies, actions, and practices and determine what you can do to empower others and the system to be their/its best. Facilitate the production of the system; don't insist that you create it yourself. Be responsible for creating both the product and the process! The system (in my opinion) is intended to be created by/for the people, not something to be imposed upon or forced upon them.
Most business processes require COLLABORATION (shared activities) and DELEGATION (solo activities). Sometimes you really just want to GIVE work to others and not worry about it and other times you want to SHARE work with others. There are times for each modality. Some people use one too much.
On my new job I am way more in the COLLABORATE mode since I am still learning and want to build relationships with my peers.
Here's how I like to work:
Lots of collaboration. The delegation only gets done after everything is defined and clear, and then you send people out on their mission; very little ambiguity is left. I like it this way and I think this builds better teams and products.
"Impediments" prevent us, our projects, our processes, and our products from being efficient, effective, and complete. But not always at the same time or in that order.
Below is a brainstorm of what impediments cause by type. I'd like to know your thoughts.
Personal Impediments
Project/Task Impediments
Process Impediments
Product Impediments
When you're working hard toward getting to the finish line, many questions come up. Sometimes it's best to get information / input when you need it and other times it is best to DEFER getting the information. For example, if you customer joins you on a daily call, you can save all questions you have for that daily call and work on everything else. If on the other hand, you need/want the input from the customer NOW, you have to make the call and put up this "blocking issue".
Randomization of resources works both from customer-to-dev and dev-to-customer. Neither one of these parties should want to be constantly pinged by the other with needs and questions; that is unless their mutual goal is THE PRODUCT and the customer is HAPPY to be bothered with questions. If, on the other hand the project is seen as a burden and something that they are both going through together (A PROCESS), then they should touch base on a daily basis.
Thoughts?
We don't always realize that there is a constraint somewhere. We don't always realize when people are hurting, are overloaded, or overworked. I've been killing myself on a project (regularly working 12+ hour days) for the last month. It's not a reasonable or sustainable pace that I'm keeping. I am unhappy and the customer may be finally starting to become OKAY. They had really high expectations and we had a fixed resource constraint so I jumped in and did a lot of work. But my over-working is about to come to an end.
Hopefully soon, the customer will FINALLY REALIZE that there is a constraint in place and I have been that constraint. I can only do so much and that has to be understood. I can no longer continue the grueling pace that I've been under.
Be careful what you wish and ask for. Be careful of what you sign up for. Try your very best to set REASONABLE EXPECTATIONS with people and get out of the business (if you have to) of doing things above-and-beyond or setting stretch goals. You can only stretch for so long; at some point you will break.
Systems are weird in this way. Adding something to your database / model COULD BREAK EVERYTHING. Getting good at adding things to your model without breaking everything you did previously is a very important skill to have!! Taking good notes about what you did do is pretty critical here. And being able to "undo" is also very critical…
Don't confuse making fancy charts and graphs and figures and all that with the project itself. The project itself is that which produces the product. Nothing else.
I'm working to a deadline right now (yes, I have time to write a quick blog post when a good idea comes my way!) and am keeping track of my method and what I'm doing / producing and my assumptions and bugs generated as I go. I'm using MindJet MindManager, one of my favorite pieces of software (if not my favorite indeed). As I go, I am iterating and going down the road and making notes and fixing things and logging what I did. I'm tracking my progress in a document other than the code. I think if someone were to write a web service / site that sat on top of my MindManager file then it could be interesting for my project managers, team, or customer to look in and see what I'm doing. As I create new objects in the file, it would be a running log of what's going on. They could write things into what I'm doing and say hello, correct me, direct me and answer questions.
Bottom line, I'm going down the road HARD to make a deadline and deliverable and making A LOT of assumptions plowing the path. I'm prepared to review them LATER, but not now because I am busy and it would take a long time to "catch someone up". But if they were watching or could watch my "timeline", then they could see what I had been doing and we could share that information.
For now I will work in MindManager and plan to share my assumptions and questions later; after delivery.
This process could be improved.
Leadership, partnership, project, and business success happen at the Program level, not the Project level. Very few peoples' fortunes or successes are made on single projects but rather through well planned strategy and well considered tactical execution. If you want to "win it big" on a big project, go out and buy yourself a lottery ticket instead; save yourself the headache.
If on the other hand you are serious about turning around your business and are not sure how to do it, think twice before you go out and hire someone to "do a project for you". Instead, hire a program manager or "true consultant" and invest for THE LONG HAUL in someone who can understand your business and professional needs OVERALL and help you transform your business into what you want it to be.
Projects are temporary endeavors and necessarily have an end. Programs do not necessarily have an end; and their purpose IS sustainability, which is VERY DIFFERENT from the purpose of projects. The purpose of projects is to "have an impact" or "kick major booty" but these things are not sustainable or reasonable by themselves. There has to be a plan!
Management can't be careless or wild in today's complex, competitive environments. No project can deliver successfully without having something like a Program Office or support organization who can "catch it" and its results and maintain the things that it did or didn't deliver. Nothing in our universe is standalone, atomic, or unaffected by outside forces, projects included. They are not atomic and cannot be treated so; they must be treated as a program or portfolio.
People who shoot for big results through one-off projects are the true entrepreneurs and risk-takers of our era, and probably stupidly so.
I have a Masters degree in Business Administration (MBA) degree from the Univsersity of Washington Foster School of Business; one of the Top 20 business schools in the nation. I earned that degree about four years ago now.
I read about management, study management, and leadership frequently. I care far more about people and processes than I do about particular technologies but I love technology. I have to be a technology builder sometimes; the engineer; the guy that actually makes the thing. And I am good at making the thing…sometimes…
When I went back to school, I wanted to improve my technical skills and learn how to make "bigger systems" and increase my chances of getting promoted and hired; more upward career mobility / momentum. When I went back to school I decided not to do MBA school and instead decided to do the Master of Science in Information Systems program.
But when I finished my MS degree we were lured into doing "just a bit more school" and get our MBA also. I and quite a few of my classmates—probably half—chose to take this route. So we have MBA degrees also. What good has this done? Gotten me a lot of jobs.
I am technical and not technical at the same time. I can dumb it down. I am business and not business at the same time: a walking contradiction.
How many levels of translation / communication / management are required to support / separate / distance "competing" world views / opinions / people? What if they weren't competing at all but had the same goals and interests in mind but just didn't realize it?!
Examples of this pattern exist in technology (say between "marketing types" and "mathematical types"), in politics (say between Liberals and Conservatives) and in religion (say between Christians and Muslims).
The goal in my opinion is to have good and healthy dialog, debate, and constructive action for these two groups. I don't think war is constructive; maybe some would disagree.
How well each of these sides is organized is interesting but how about THEIR INTERFACES? How well are the interfaces organized?! Probably very poorly.
Let's ORGANIZE THE INTERFACES between competing factions toward productive shared means and goals; let's program manage this stupid dysfunction!
Plan your work and work your plan. Quality is job one. Sometimes these things don't come to fruition. Sometimes you are left alone to do everything, no time to plan or to check your work. When the work is checked, it results in another "Do" cycle and you are randomized while in the process of doing another key thing. You can get out of this spiral but only if you have help and process.
On the process side, if you REFUSE to work until there is a plan that is one way. If you INSIST to not start the next thing until the previous one is done, you will help yourself. But these things aren't always possible. Insist that people get into a reasonable cycle and care about the project/process overall. It has to be fair or it will never succeed.
On the help side, you can get help. You need at least one other person to PLAN WITH and you need people to give the customers time while they CHECK. And you need to be given the chance to plan and act on what was checked.
Where is it? Is it in your project? Your process? Your tool? Your team? You? You have to determine it. Sometimes it's tough, though, hard to identify. But if you have a high enough sense of urgency and focus then you will get very good at determining WHERE the current bottleneck is in your process or system and what to do about solving it. Be the master of your domain and seek to continually grown your domain.
Whether you're the big boss or a little pee-on minion or somewhere in between, create influence in everything you do no matter what you do. Be upbeat, be strong, be positive, be persistent, get results, and fight for what's right. Get things done and charm people.
Sure, you can make a table, a matrix…good for you. But is the data that you have just shoved into it valid, interesting? Spend your time focusing a lot more on DATA QUALITY than any rigid ideas you have about "this must fit". Maybe it simply doesn't fit and you have to break your matrix in order to accommodate a new item. Be flexible.
There are people in this world, myself included, who need to think in terms of matrices. I don't like to think in this way but I often must. I am building systems and databases in my trade and, as I said in a post earlier today, things either fit or they don't: they either fit into a/the matrix or they don't. It is not my INTENTION to think in these terms but I must on many occasions. Things have to boil down to a matrix.
I know a PM who is very good and talented at his craft and he frequently likes to put things into matrices. I think he overuses the tool in fact. When I'm building systems, many matrices are required. But I don't want to burden the customer or my peers with this extremely rigid way of thinking. Thinking in METAPHORS is much easier but not always possible. Asking questions and developing a mental model for MYSELF is often good enough. "Requirements statements", rules, and policies are often good enough to be clear. Knowledge can be represented in very many forms and the matrix represents just one. The world is not a database and never will be.
If you are a matrix-thinker, or a matrix-over-user, or are required by your line of work to be a matrix user frequently, consider your audience and use matrices and matrix-like-thinking sparingly. People are systems, not spreadsheets. Use a variety of methods and don't think of the world as if it will all ever fit into a/the matrix. It won't, so give it up!
Make a very clear distinction and separation between your "change layer" (that which changes, is variable within your business, etc.) and the presentation. That which is quality, confident, and customer facing. Decouple these things and separate them at all costs. Be consistent with customers and constantly work with your trusted team to clearly define and improve this interface.
Let's say you're building a system with a few inputs and a lot of outputs. They system is complex. You know that "garbage in garbage out" is true but there are also wastes within the system itself. Say you have two garbage inputs and want to make a good system. So the saying would be "garbage in, gold out". So if some of the garbage is gold, then how do you differentiate the two? You have to squeeze the garbage out and demonstrate the gold. You only know the gold is gold because you know the garbage is the garbage.
What is the model? Who cares about it? The model to me in work and business is the shared mental understanding between service provider and customer about what the current problems are and what possible solutions are.
A "good model" is shared and exhibits a few other key properties: resiliency, constant improvement, change, innovation, and frequent new insights and enhancements.
A "bad model" is one that is stagnant, one-sided, confusing, unclear, unshared.
I'm working on a project for a client right now that in my opinion has a "bad model". I am building the product and model that represents it and it is currently bad because I think I am the only one that understands it. This is the worst possible place to be in; but also potentially the strongest if you understand it and communicate effectively about it. Getting to this place of realizing a "bad model" comes from poor communication, lack of mutual understanding, poor collaboration, or a fullness of delegation and lack of care. Hoping for miracles will not create good models by itself. As I improve this "bad model" into a good one, it is my hope that the customer will start to realize that the bad model can potentially be good if we decide to build it together; but it requires cooperation and partnership.
We have to build a better reality with each other. I cannot build something "for you" without your input, knowledge, needs, or voice.
When you're designing a system or database, you can't have ambiguity. Things either fit in the database / model or they don't. You can backlog or table things that don't make sense but you as the system engineer have to know what's going on. You have to listen to the users and customers but you can't make concessions that break the whole system. In this way you have to be somewhat forceful with people sometimes to "make them" make decisions.
How is this possible or why is this possible? I don't know. Force of will? I believe in my consulting work some people really don't like me and really don't get me; they don't know what I'm trying to do or why. They may see me as inflexible. I can understand that. But I'm building a system and it has rules. I only know what I do and not know and am not willing to integrate concepts and ideas that cloud my world view. Sorry if this is selfish, strange, or anti-social but this is the way it is.
Do you have different ideas of how to design collaborative systems? My goal, in the end, is that the systems are collaborative and software based; that Eric Veal is not a part of the system, rather a facilitator to that which is OUR system. I am just a facilitator. Good processes will make the system go, not Eric Veal.
In database programming, I frequently use "views" to solve problems. Views have limitations, especially when you use "SELECT *". If the underlying schema is refreshed—at least in SQL Server—the data gets out of whack. I really want to figure out a better way of doing this; and I'm sure I will at some point…but I don't have time right now. Since I know how to make this method work (with all of its warts) I am okay to operate using this method because I know what I don't know.
Hopefully soon I'll learn how to work around this problem; either by automatically refreshing my views or by learning more about how to use SQL CTE's (Common Table Expressions).
I want people to think of me in this way. Not revered, necessarily, but respected; thought of as someone who requires time to think and when he is provided it, he comes up with good ideas. Sometimes the idea will come immediately, as part of conversation, and sometimes it will come hours, days, or years later. This is the type of "mental space" I would like people to provide me. It will be work for me to get to the place where I can expect and get it.
Requirements and fixed plans are a tricky breed. When you're on deadlines and things are either slipping or getting behind or, say, you're developing some technical debt from which you can't currently escape, go ahead and start thinking of what you can do NOW that will add the most value to the system OVERALL. Always think of the overall, even when you're in the weeds. My project for example has about 8 items due this week and we are scrambling to do as much as we can. Throughout the day we re-plan and reprioritized based on where we're at and where we have to go. We always keep in mind "What's the story", meaning do we have a good story to tell management or the customer about what we're doing. We don't want to be careless or wasteful so we think of what's the best next thing to to and we do it. After we're done with it we repriorize and adjust. New bottlenecks, roadblocks, and impediments are getting removed all of the time and freeing up new capabilities. There are SO MANY dependencies in a software system or software project that you could NEVER Gantt chart it all out and execute a waterfall process successfully; attempting to do so would be crazy.
At any rate, we're having some fun building this Business Intelligence application for the customer that takes from about 5 systems and integrates them into one. It's hard, challenging work but we have a pretty good approach: we've isolated the "pulling data" problem from the "unifying and normalizing data" problem from the "present the data" problem. We now have a very solid foundation that can create some real velocity within our team. One guy on the pulling, back-end, and automation, and a couple of guys on the front-end making it look real nice.
Probably the holy grail of software development or any project for that matter is to know how long you have to go until you're going to be done. This is a very important metric from a lot of angles.
In software as tasks get brought into scope for a current sprint or release, this spikes up our hours. We might think something will take a long time and it impacts our perception of completion time. But as we dig into our tasks and re-estimate how long they will take to complete, we get more accurate. By providing a system to keep estimated hours until completion at the aggregate for a release we can be in control as a team. All of the stakeholders can watch as things ebb and flow and hopefully the work is burning down in time to meet our deliverable milestones. By looking at big tasks (sorting by largest hours to complete) we can see our risk in the project. Start the big stuff now and knock it down fast.
How can you be fair in work? How can you kindly deal with other, hard-to-deal with people? Consistency is probably the number one way. But what if you're consistently a jerk, or consistently unfair? I believe that by being consistent in our decisions and ways of thinking (your process), people will have a way to view your inner world and question your—sometimes possibly unfair—intentions. Be open, be a book. Expose your reasons and why you're doing what you're doing and you'll get better at doing it.
"What are we going to get and when?" Not the easiest question to answer sometimes. When the requirements are vague and the climate is tough, you still have to be able to operate. Understand how to deliver the minimum possible deliverable that qualifies as that requirement by name. Try not to get into too many details with the highest-up sponsors. If you do get into details with them, renegotiate the dates and bring them into your process.
Why? Because it involves the commitment of others. You can create a plan for yourself; that's fine. But it almost always—especially in business—has dependcies on others. If you are the planner, the doer, the leader, the driver, the actor, then oftentimes your presence and energy makes people uneasy. They see you as frazzled, needy, and chaotic. But are you? Yes, but only because that is your perception. As a leader and doer, you have to be able to be calm, cool and collected and communicate effectively with others about what you need from them. If you have a plan and your hell-bent to execute on it you'd better be very careful about how you come across to and approach others. You have to be patient and communicate very well. You have to sell them on what you're doing and why, how they're involved and necessary and how their lack of commitment or engagement impacts the organization. When you get push-back or lack of cooperation from people it is your job to do two things A) try to convince them to partake B) find alternate courses of action to continue to drive the program forward and get commitment and C) be ready to communicate about lack of participation and engagement to senior leaders. Doing Item C will most likely give you more power to engage with these people. Having support of your senior leadership gives you the power of coercion rather than influence. This "real" power can help you get very far in organizational projects.
After a very long and trying month and a half on a new project, it may be turning around to a success?!!! Could it be?! Maybe. The suggestion was even made by a senior coworker today of having "more than weekly" recurring meetings with the client to sync. I joked about having "Daily Two-Hour Standups". We're in a development rhythm (finally) and that is really satisfying. I'm really the only developer, though. That's been hard. Really long hours. 12 hour days are typical. Our project and delivery schedule is as follows: Plan Mondays and deliver Fridays. I twisted arms to add a ton of risks to our risk register today. Seems very simple moving forward but it's been hell getting here. I'm not sure how many teams work the way we're working. We have a very difficult problem we're solving; many moving parts and tons of senior-management pressure. Dates and deadlines. It's fun at the moment and I hope going well. I have a huge deliverable tomorrow and I've learned so much on this project about data movement, ETL, and SSIS. Also about people and leadership. Roles, and stepping down when you can. Let quality people be quality; let them help you out.
I'm designing an automated business process that removes 204 manual hours of work monthly. That's fun and satisfying.
Two skills for PMs. Make sure that the work in process is going well and that impediments for the workers are removed. That is your job. Another job is to watch how much you are whipping your employees. Assume they are smart and good; doing a good job, with good intentions. Guide and lead them. Mind the whipping and don't whip too much. Choose carrots (vision and leadership) over sticks and whips.
Don't be a slacker. Be very clear on what you're doing and why. Who knows, the customer could join you right now and want to see what you're doing and why!!!! Be prepared.
I'm reiterating my point of getting the product into the hands of the customer or the testing team as fast as you possibly can. A developer cannot be a standalone entity, operating in isolation. All individuals need feedback and we cannot deliver quality unless we have an on-looker or customer. We need an audience or we are really just performing for ourselves, without feedback. We need a mirror at a minimum! Give your code to the customer and then determine what the portfolio of needs and changes looks like. Be agile.
I'm definitely not the best at this but I think I'm getting better. Some things are taboo, some things are sensitive. This is true in both work and life of course. With specific respect to work, however, we definitely need to figure out the best way to play the politics, get ahead, and engage in the (potentially difficult or touchy) conversations that we need. This includes subjects such as compensation, coworkers, the work itself, and assignments. "Managing Up" is a skill that is talked about a lot but it is neither a class I have taken nor a subject I've read about. I just did a quick search for books on this subject: http://www.amazon.com/Managing-Up-Forge-Effective-Relationship/dp/0385507720 Does anyone recommend any good books on managing up and doing well at politics in the workplace?
As a product developer, you have to be able to 'let go' of your product. It's not for *you* anyways, so get it out of your hands and into those of the customer! I'm building an app for a friend right now and am finally to the point where I am willing to give him access and let him test it and comment. That's a big milestone! I am sure he will have feedback that I do not expect. Your users are your best testers. I don't want to be perfectionist about my product and need outside help. I don't want to float too green of a banana but I think it's good enough for now. He wants the app and deserves to know what state it's in.
I was on the phone with the Hewlett-Packard Customer Support line this morning and (without the agent's help) figured out the solution to the problem I had called about. When I announced the solution, the customer service rep said, "You sound disappointed that you solved your problem." And I answered, "Yes, I do." (It shouldn't have been the case, I don't think that *I*--rather than *he*--had figured out my problem.)
I would add to this that there are other problems that when solved, there is no real "EUREKA" moment. As they say, "Huh" is a better discovery than Eureka. The truly big shifts do not occur via some drastic "explosion" of change, but rather a new realization or perspective that can be as small as "huh", or "that sucks".
An example of this is working on a computer bug that when you solve it you have tried so many things that cause so much time and pain that when you finally do solve the thing and make it work you are simply disappointed that it was THAT HARD. Such is life.
People have very different reactions while waiting for computer systems (any process for that matter) to complete or change. Take for example launching a program on your home computer: you click a button and the "wait cursor" comes out. What do you do? Get angry? Wait patiently? Hope for the best? Some people tap their foot and get anxious, others watch and wait and think about what might be happening and how things might be working. We have a chance to be introspective about systems other than ourselves.
We can witness the same behavior on the road every day in our driving: some drivers are patient and don't give too much thought about what the drivers around them are doing while others are very critical of the other "stupid" drivers. I'd say that the way we think about other systems and what they are doing is a very clear reflection of how we think about ourselves: Are we patient? Are we forgiving? Are we intelligent? Are others intelligent? …All of these things cross our mind in computing and in other life-systems as well.
In this way, I recommend that we be more patient and seek to UNDERSTAND what the other systems around us are doing and why…and in that process we will learn much more about ourselves, our intuitions, and how we are actually impacting the systems around us. Thinking at this level will help us change things for the better.
Many situations call for us to rise to the actual level of stress. This to me means that we are highly dependent on the context of the situation around us. For the most part, all we can really do (consistently) is to respond to how things are changing around us; we are a part of the system and are not—by any stretch of the imagination—the system itself. Systems are dynamic and we have to see and recognize ourselves as being a key and critical part of those systems. We must treat them carefully. We need to think very carefully about different perceptions and realities and decide to act in accordance with our beliefs and wishes. Act cautiously. Although we may be in a position of power or leadership, our thoughts should drastically govern our speech and actions. Seek to change the perceptions around us through our intuition and inner strength. Be careful with what you say and think very critically about the 'network effects' of your actions. You are at the center of the system but you are not the system yourself!
I'm skipping the Huskies basketball game right now and playing with friends because I am trying to help my buddy with his business. There are sacrifices that come with doing good. Working on my buddy's problems makes me feel happy and like I am doing something good. The Huskies will win or lose, my friends will (hopefully) still be there for me, and I am feeling better by contributing to my friend's business. Social to me is helping other people, not necessarily drinking or watching sports with them although that might be more 'fun'. Fun creates a short-term reward. Work has lasting benefits.
Nothing more to say here, really. As a developer, you are coding for one purpose: remove the most urgent and important business problem that exists. You are fighting fires all the time but you may not realize it. If you're not, then become a better business analyst. You are trying to free business resources so they can do more value-added things.
You might care, I might care, but how do we make 'everyone' care? It's impossible. We can't. We can attempt to add one person at a time to our way of believing. But most likely--by the time we reach the last person--our thought process and beliefs will have changed so drastically that our purposes will shift. It's like painting a bridge: by the time you're done, it's time to start over again from the beginning and repaint. Make your bridges small. Build many bridges. And be flexible.
