you on you

The painter in you will find the new canvas intimidating. The writer in you will find the blank sheet of paper intimidating.

The manager in you will find the immaculate-white background of the email client window intimidating ... it is supposed to hold the yearly evaluations of your directs, instead it's blank. Where to start you're asking?

Meet self evaluations: I am finding them to be the easiest way to kick off the employee evaluation process. Is it as simple as you asking your directs for their own perspective on their accomplishments, contributions but also on unmet goals and targets over the past year. (in the Romanian immature corporate culture we sometimes call the latter bad things).

Give them time to think.

Then add your own observations - you should have observed them and taken notes throughout the year. Then add the others' feedback to the mix: team members, customers, other managers that happened to interact with your guy. Then look for some facts, in your project plan, bug tracker, emails, reviews.

That's it ... fully armed now to conquer that white background!

one team for the customer

What have you done lately to make your customers happier?

Have you called them more often? Have you stopped developing new features until you reach a Zero Known Bugs state? Did you hire the best Information Engineers to make your docs all bright and shinny?

If a lot more than this, or none, or none of the above, let me give you another idea of what we do:

We built a cross-feature team staffed with the brightest people who analyze customer escalations, observe trends and write beautiful code to make sure future escalations in the area are near to impossible. Out of 30 customer escalations on how slow your server compliance checking runs, they would come up with a new way to access your compliance rule repository using a proven web server instead of your custom (slow!) python multi-threaded code.

How would this setup work? Would they sprint together with the rest of the teams? When will they sync with the feature teams to make sure they are not writing the same optimizations? Would you have this team on a permanent basis or build it ad-hoc depending on the number of current escalations?

Know what, these are all up to you, in the end it's the client 'smile' that matters.

replacing technology <T>

- never heard of T, is it software?
  - sure I've heard of it
    - I'm a big fan
      - tried it in a Hello World
        - use T daily
          - reported a few bugs
            - contributed to the code base
              - I am T expert consultant
                - I developed a parallel technology
                  - it's history, my technology simply wiped T out of the market

- What do people say about your pet project?
  - Don't have a pet project?!
    - Are you a software engineer?!
      - ... um, never heard of you, sorry.

satisfaction

It is a few months before a new Server Automation major release ships, so it's time to let the customers take a peek at what we've been working at in the last 6 months. We are taking them on a test-drive (but don't let them in the driver's seat yet) of the new features to get them to comment, like:) or dislike:( them.

But we got more than this in the last demo. The client was so pleased with the features we developed that this got them into a chatting mood, so some of us ended up pouring questions onto the client about their environment, how they use the product for their use-cases, how they horizontally scale their work (or not) when dealing with tens or hundreds of servers. It won't be far from the truth if I said that our questions outnumbered the client's. So yes, we got something extra out of it.

And the client got something extra too: as the discussion developed, they got their share of answers and tricks about the old features they've been using for a while now.

Still, we got more than the client did: satisfaction. Satisfaction cause they were satisfied. And it was plenty of it to share, to the QA eng that did the demo cause his clicks unveiled the magic, to the functional architect who spec'ed out the magic and for the handful of developers that ... built the magic.

Are you feeling down? Ask your customer to come in for a demo!

are you the next FA? (2)

Had a discussion a few days ago with my FA, and we came up with this shorter definition of an FA, looking not at what s/he should know but instead at what s/he should do:

The functional architect is responsible for specifying a feature so that it both satisfies the client and is implementable.

Wanting to be an FA? Then make sure you can look at a problem both from 1km and 1cm away. Be able to stay off and on the ground.

are you the next FA?

It was supposed to be a very concise post, but since these guys don't know what an FA is, why risk you being in the same situation?

Story short, this is what a functional architect (FA) is for me: mostly a BA as his main job is to create requirements, with enough field knowledge so that he knows how a feature would fit customers best and beat the competitors' feature, with the guts and power of decision to cut down on or to extend his ask, with good project timeline awareness so that he can add a touch of prioritization to his ask, with enough UI design skills to add a drop of color to his words, and an English phrase not to far from that of a documentation writer.

(... now my FA, he used to code a lot before doing this role, so he also sees my point of view and he knows very well the technical architecture)

How do you know if you're destined to become an FA? The first sign is that you take special pleasure in writing down the Expected behavior of a new defect you are submitting: